7

We are rolling out a new mobile app. Our security team recommends us to pin the public key in order to avoid MITM. iOS already has CT checks and we can enable that for the Android app as well.

The security team's arguments for pinning are:

  1. Pinning is a more hardened solution
  2. CT is more reactive, we might have to live with a rogue certificate until it is revoked and logged in CT logs
  3. CT checks would not work in environments where corporate assets may have company PKI deployed and MITM attack is done using the company PKI

My argument for not pinning: Assume we generate a certificate and it is a 2048-bit RSA key pair. The certificate expires in 1 year, maybe 2. We go to the CA for a new certificate and the CA says “No, your key is too small, come back with a 4096 RSA key pair”. In effect, because we pinned the public key in the app, the app is bricked.

Now we release a new version of the app, but it takes typically > 1 month for the app to be adopted by all the customers. During this time, while our customers are trying to access the app at home, trying to look for offers to come and spend money in our ecosystem, they won’t be able to use the app and hence we stand to lose the customer and potential revenue.

A rogue certificate might affect 1, maybe 2 customers if someone is really being targeted to be hacked (MITM target), but the above risk is a risk to the entire customer base and for amount of time that is not directly quantifiable.

Does it really makes sense to pin? If yes, how do we mitigate the above scenario? Am I not seeing something?

Glorfindel
  • 2,235
  • 6
  • 18
  • 30
Aman
  • 171
  • 3
  • At least for web, HPKP is deprecated in favor of CT. – multithr3at3d May 06 '20 at 21:52
  • 2
    @multithr3at3d: HPKP as a HTTP header for dynamically associating keys with a site is disabled since it resulted in too many problems in practice and not because CT provides the same level of security. Static PKP is still build into the browser for essential sites like www.google.com, facebook.com etc. – Steffen Ullrich May 07 '20 at 06:26
  • 1
    @multithr3at3d Also, HPKP allowed me to be an absolute arsehole, buy a domain for a year, set up HPKP for 10 years, then let my domain expire. Good luck to whoever buys it now. –  May 07 '20 at 07:33

2 Answers2

2

they won’t be able to use the app

If this is true, it means your application design is not good. One of solutions is that if you switch key you should also provide a new end point. For the transition phase you would support both end points, with the old and with the new keys.

When you switch they key, you would also release a new app version with the new key pinned. The old app will use the old end point and the old key. The new app version - new end point and new key.

After transition phase ended, you shut down the old end point. After this phase (1-3 months) only the users who refused to update the app will have problems. All other users will not even notice that you have switched the key.

mentallurg
  • 8,536
  • 4
  • 26
  • 41
  • Doesn’t answer my use case. I have pined 2 keys. Two years down the line, I am being forced to change my RSA key pair because of the weakness of the key pair. How do I avoid a situation where the app is not bricked for the customer? – Aman May 07 '20 at 02:39
  • I explained that and don't understand what is not clear. Do you understand what is an end point? Do you understand what it means to have 2 end points with different keys but with the same functionality? Do you understand that for the transition phase you would have 2 versions of the app - one using the old end point and one using the new one? Do you understand that because of this the old app version will be not broken and will work without any conflicts the whole time? Please explain why doesn't this solve your case? – mentallurg May 08 '20 at 00:48
0

As you see yourself CT provides much less security than HTTP pinning. Thus the question should be more on how to address the problem you see with HTTP pinning.

First, there are multiple ways to pin: one can make sure that only a specific key is allowed in the certificate as the only check or one can pin to a key in addition to other checks. What you describe is the latter: the normal certificate checks are done including expiration check and in addition to this the key in the certificate is checked. By simply pinning only to the key and not doing any further checks you completely avoid the situation you describe where a CA does not issue a certificate anymore since the key is too weak.

Second, public CA's don't stop accepting weaker keys without announcing this many month before actually doing this. Thus there is enough time to prepare for this and roll out a new version of the app long before the CA actually switches their policy.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424