2
$\begingroup$

Brief rundown of how Apple Push Notifications (APN) work:

  • Generate a keypair, generate a CSR for it
  • Upload the latter to your Apple Developer account and associate it with your mobile app
  • In the process, your CSR is signed and you get to download the certificate
  • Connect to the APN server using the key + certificate, send your notifications

Note that this is a separate key/certificate just for push notifications. It is distinct from the code signing key, and not used anywhere else. And, TTBOMK, the mobile phones never see that key, they verify that push notifications are genuine based on the fact that they receive them via a secure channel from the Apple HQ.

Here is my alternative, simpler idea: create a keypair and upload the public half to Apple. You can then send messages by authenticating with the private key.

So, why does Apple sign my key? What do I actually use the certificate for, while connecting? Is that signing dance done because SSL supports client certs but does not support bare private keys?

I'm not a cryptography expert, so please correct any wrong assumptions I've made!

$\endgroup$
  • $\begingroup$ my educated guess: Apple wants to bind push notifications to developers and enforces the use of the certificate to ensure only "authorized" developers can issue push notifications and if they abuse this, Apple can easily revoke the dev's right to push notify users. $\endgroup$ – SEJPM Mar 21 '16 at 19:26
  • $\begingroup$ @SEJPM: To upload the pubkey/CSR, you must be logged into your Apple Developer account. So Apple already knows who the key belongs to. To push to an app, you must upload the key to the same account that owns the app. Push notifications are pretty tightly controlled. $\endgroup$ – Christian Aichinger Mar 21 '16 at 19:45
1
$\begingroup$

I'm guessing that the need for a certificate has nothing to do with authenticating the upload, but so that people's iPhones can authenticate the app at install time / runtime.

[Ah, I see your edit that this is not right. I'll leave it here for posterity anyway. Are you sure you can't find documentation for this somewhere?]

  • As a developer, you create code-signing keys for yourself.
  • You announce to Apple "Yo Apple, I'm the developer of this app, and here's my code-signing key".
  • Apple makes a certificate out of your public key, telling the world that Apple agrees that you are the rightful developer of this app.
  • Apple distributes this certificate along with your app to millions (we hope!) of end-users who download your app.
  • Any update you push must be signed by the same code-signing key as the original, otherwise the end-user iPhones will reject it. (How to you prevent malicious updates and NSA-style sideloading?)

I'll also address this part of your question:

Is that signing dance done because SSL supports client certs but does not support bare private keys?

No, SSL does not support "bare private keys" and here's why: how do I know who the private key belongs to? Any bloke can walk up and say "Hi, I'm Christian Aichinger, here's my public key, and I'm going to use the corresponding private key to sign some data". Ok, fine, but how do I know that I'm talking to the real Christian Aichinger, and not somebody pretending to be them.

The commonly accepted way to solve this is to have some third party that we both trust verify that you are who you say you are, and that this public key does in fact belong to you. That trusted third-party is called a Certificate Authority, and that statement that this public key belongs to you is called a Certificate.

$\endgroup$
  • $\begingroup$ This is a separate key just for APN, distinct from the code signing key (updated my question to reflect that). A few reasons: you don't want your code signing key laying around in your datacenter; you want to be able to cycle APN certs without having to update your application; ... $\endgroup$ – Christian Aichinger Mar 21 '16 at 20:29
  • $\begingroup$ Re second part: so maybe the cert is just there to be used as client-certificate in the SSL connection. If you took my bare-key route, you couldn't use off-the-shelf SSL, which would be a pain in every way. That'd seem like a reasonably good reason for the cert signing dance. $\endgroup$ – Christian Aichinger Mar 21 '16 at 20:30

Not the answer you're looking for? Browse other questions tagged or ask your own question.