Cwa-documentation: [CWA-Docu] Translation error for certificate pinning/public key pinning and clarification needed

[rugk]

Where to find the issue

In the English version you say here:

To further reduce the possibility of man-in-the-middle attacks, certificate pinning shall ensure that trusted communication only happens between the Corona-Warn-App and the server.

You translated this to:

Um das Risiko von Man-in-the-Middle-Angriffen weiter zu reduzieren, wird durch HTTP Public Key Pinning sichergestellt, dass vertrauliche Kommunikation nur zwischen der Corona-Warn-App und dem Server stattfindet.

Describe the issue

This is a mistranslation resulting in a technical incorrectness or at least an unclear statement.

First difference:

• _certificate_ pinning pins the hash of the certificate (i.e. "basically" public key + the CA signature/everything you've got as a cert including expiration time etc.)
• _public key pinning_ pins the hash of the _public key_ (i.e. "only" your own public key cert, so a new cert may be generated with new expiration time this does not matter)

For operating a server this makes a fundamental difference.

Secondly:

• _HTTP Public Key Pinning_ is the "web-term" for a now deprecated/removed technology in browsers that used HTTP headers to transmit the hash and pin it for a period of time. It's kind of a "dynamic" pinning.
  I doubt you use this, as that would be totally unnecessary for an app and also a security risk as it relies on TOFU (trust on first use)..
• However, _static_ pinning (of public key or certificate) is what is usually done in apps, where you just hardcode the pin.

While you are at it you could clarify what exactly do you pin, i.e. do you pin the leaf certificate, and intermediate certificate or the root CA? This needs clarification.

Suggested change

• both translations should state the same
• clarify whether _certificate_ pinning or _public key pinning_ is done
• clarify whether HTTP headers are really used or _static_ pinning is done
• clarify which certificate exactly is pinned (leaf, intermediate, root, …?)

---

Internal Tracking ID: EXPOSUREAPP-6345

[dsarkar]

@rugk Thanks. Internal Tracking ID EXPOSUREAPP-6345

[vaubaehn]

Hi @rugk ,

may I ask you something which is obviously within your expertise?
Last summer, we had an issue with CWA Android, where suddenly (at least for some parts of the users) without any user interaction suddenly their on-device T-Systems root certficate had been blocked, resulting in a complete refusal of any connection to the CWA servers. In my perception, at the times when the T-Systems root certificates had been blocked, there was a CWA server maintenance ongoing shortly before.
Would it theoretically be possible, that the server maintenance could cause any issue with certificate pinning and/or public key pinning and/or server certificate validation (e.g., after server restart the server is reachable but still in a start up process where the server certificate is not provided yet), leading some hyper-sensible Android OS versions to automatically block the root certificate?
You'll find the whole story here: https://github.com/corona-warn-app/cwa-app-android/issues/968

The original cause leading to the root certificate blocks has never been found out, or at least, has never been communicated transparently. I'd appreciate to nail down the cause to prevent any similar issue in the future.

Thanks very much for your response in advance,
V.

[rugk]

Would it theoretically be possible, that the server maintenance could cause any issue with certificate pinning and/or public key

Well, it causes an issue if you use a public key or certificate that you have not pinned. That's why you usually may pin more than one certificate.

That said, if you have a pinned certificate or public key you actually could ignore usual CA certificate validation, as the verification by hash is more secure anyway.
That said (again), the source issue that was the issue there, seems to be the T systems cert to be blocked, which is the root issue which should not happen.

[vaubaehn]

Hi @rugk , thanks very much for your response.

From your OP:

While you are at it you could clarify what exactly do you pin, i.e. do you pin the leaf certificate, and intermediate certificate or the root CA? This needs clarification.

For me it looks like, the intermediate cert ("TeleSec ServerPass Class 2 CA") is pinned (according to the expiry date): https://github.com/corona-warn-app/cwa-app-android/blob/main/Corona-Warn-App/src/main/res/xml/network_security_config.xml
As the expiry date is taken into account seperately, probably the public key is pinned. But for sure the product owners should clarify.

That said (again), the source issue that was the issue there, seems to be the T systems cert to be blocked, which is the root issue which should not happen.

What I did not understand yet: Let's assume after server maintenence CWA is able to reach the server, but validation of the pinned public key (obviously intermediate cert) fails for any reason. Would you think it's possible that Andriod OS automatically _permanently_ deactivates/blocks the root cert in the chain (="T-TeleSec GlobalRoot Class 2")?
I don't see any other explanation for what happened in August and October last year for some users. The above linked GH issue are just some people, there were more people reporting on Google Play Store Reviews.

Thanks for your time!

[rugk]

Would you think it's possible that Andriod OS automatically deactivates/blocks the root cert in the chain (="T-TeleSec GlobalRoot Class 2")?

No, I don't see any way, but I'm also no Android developer.
If the validation fails, the request just fails, if it succeeds later on, the request should succeed. Maybe the CWA app or some library (OkHttp) has some caching or so in there, which influences that, but generally the OS has nothing to do with that, pin validation is done in the app.

[vaubaehn]

generally the OS has nothing to do with that, pin validation is done in the app

I think, it will just stay a mystery what had happened these days... 👻

Anyway, thanks a lot for your assessment and enjoy your night!