Sending Device Token Safely for APNs

Question

For iOS applications that require push notifications, it must first request the user for permission to do so. After that, a device token is generated and with this, the remote server may communicate to the user through this token.

I have read a similar question here and I do not feel it is enough. The picture below is a trusted certificate, it allows me to view all traffic that happens on this device.

With Fiddler2 as well as CertMaker, I can sniff HTTPS traffic, which means the client can probably know what data they are sending, and to where.

My question is, knowing that SSL is not secure from protecting my clients from seeing what I send to the remote server, should I simply encypt with a secret key found within my application?

Such as encrypt("device_token","secretkey_a0a0a0a") (pretend this is Objective-C)?

Couldn't someone just find that key within my application? I also read this question, and it seems that it would be possible to get back the secret key.

My plan for this goes like this:

1. Within the iOS application, Generate a random string named activate.
2. Encrypt (not hash), the token by the random string and a secret key that I only know. (secretkey_a0a0a0)
3. Send the encrypted string along with the generated randomly generated string (active).
4. Within serverside, I check if I can decrypt a valid token from using the active and my secret key.
5. I save the token in my database if it is valid.

This prevents people from random entering tokens yes, however, secretkey_a0a0a0 is a string literal. It's very possible to get this within the application binary itself.

My question is, how do I protect this secret key? The answer can also be, how can I prevent people from sending invalid tokens to my server as well.

I have heard of encryption, but doesn't that only apply to resource files?

How should I approach this?

Suspect

You're being paranoid. SSL is quite enough. Once the app is out of your hands, it can be broken. Just ask all the companies who have spent millions, probably billions collectively, on DRM only to see it broken within hours. Do you really think you can do better? – Dropsical

Why exactly do you want to encrypt the device token? What harm would be done if anybody can read that? – Provenance

So that it may be validated serverside. I would like to prevent people from sending fake tokens. Whenever someone does send a token, it's instantly added into my database. – Suspect

Answer 1

If you do SSL-Pinning ( AFNetworking has this implemented ) you won't be able to (in a reasonable timeframe) sniff the https traffic between the client and server if you don't have the servers private key.

Dahomey

Wow, I never knew you could force the client to use a specific certificate. Thanks, accepted, up-voted, and bounty awarded! – Suspect

SSL pinning is matching the credentials provided by a host against an expectation. The client checks the certificate the remote host provides, and if it does not match the expected value the client aborts the connection. There is no traffic to sniff beyond that point. See: owasp.org/index.php/… – Gusto

Answer 2

If your fear is that man in the middle can steal your token and send fake push notifications to users of your application, be sure that this cant happend. Since requests to apple apn servers must be signed with pem file, the main concern should be how to keep certificate file secured, and not apn token. If you want to prevent writing invalid tokens in your database then you should implement some CRC or odd/even bit mechanism.

Kastner

Answer 3

You might want to check the security section in the Push Notifications Guide, in particular the section titled "Token Generation and Dispersal".

The device token is generated by the device connecting through the Apple's APNS. My guess (they don't say in the docs) is that it's unique for a given app identifier.

The APNS then will probably match those identifiers with the pem certificate you use to communicate with it thus validating that the push notifications are actually originating from your app.

Encrypting the device token seems overkill in this scenario.

Planarian

I'm afraid that they can sniff where the tokens are being sent -- and send a bunch of fake ones themselves. – Suspect

Answer 4

To prevent someone maliciously spamming your server with tokens, I would hash the token when a secret key and send both the token and the hash to the server. You can then hash the token again on the server, with your secret key, and check that the request is valid.

Misha