Push messages isn’t secure enough

Why isn’t end to end encryption in place yet?

Apple, Google and Microsoft all have cloud based services that allows developers, behind apps on their respective platforms, send what is called push messages to the devices. The users of the application can of course enable and disables if he/she wants to receive the push messages as well as how intrusive they are displayed on the device.

It’s an amazing service that allows users to get the right information at the right time where the delivery mechanism doesn’t cost anything for the users as well as the developers behind the app. So it isn’t any surprise that Apple, Google and Microsoft combined delivers billions of these messages yearly.

Apples service, Apple Push Notification Service (APNS), Googles service, Google Cloud Messaging (GCM) and Microsoft service, Microsoft Push Notification Service (MPNS) all share the same basic architecture setup to enable an app to receive push notification. And it’s this setup that doesn’t fully take the consideration of a users privacy or developers needs to send more sensitive information over push notification. The missing part is end to end protection of the actually push message.

The basic architecture of how push messages is sent to devices.

The app ask a service on the operating system push client service that it wants to be enabled to receive push notifications. The service connects to the push service cloud to get some for of unique id (it is a URI in the case of MPNS but will use the term unique id in this article). This id is returned to the app that normally shares this with the apps cloud service.

The apps cloud service can then connect to the push service cloud and send a notification and by using the unique id target the specific device. The cloud service makes sure that notification is delivered to the device and the app the message was aimed for.

Transport security

The connection between the device itself and the push cloud service is of course secured over a TLS channel. But actually getting the unique id by itself isn’t anything compromising but there is no excuse to send unencrypted information over the Internet. In the NSA times that we all experiences right now these unique id’s could of course be used to track the device in some clever way.

The app sends the unique id back to the apps cloud service and it’s recommended that this is done over a secured channel but it is up to the individual developer of course. As noted before the unique id isn’t anything compromising but could be used for tracking. Most developers uses secured channels between the app and it’s cloud service.

The transport of the actual push message from the app cloud service and the push cloud service is also done over a secured channel as well. There is a different how the push cloud service authenticate the app cloud service as a trusted party that is allow to send push messages to the unique app. In some cases it’s a shared secret and in others the use of signed client certificate setup within the secured channel.

The last transport is sending the push notification from the push cloud service to the actual device. This isn’t actually a real push as the device itself open the connection to the push cloud service but that’s a technicality. But this connection is as well done over a secured channel and their are different technics for making sure that the device can authenticate itself against the push cloud service as the right owner to receive any sent push messages to any of it’s apps. This mechanize will not be covered in detailed here.

Message end to end encryption

But what about the actual text and other meta data that is sent with the push message from the app cloud service to the app installed on a device. How it is secured? The thing here is that it is always secured in transport as described above but the message itself is in clear text between these transports.

And it is here the problem with users privacy comes in. All push cloud services have every push message, that is sent through their systems, in clear text.

That is they have the ability to analyze, look at, share/sell the data. And they have the risk of getting compromised and loose the data to cyber criminals. Or as all these services are US based NSA has the possibility to request the data with a NSL (National Security Letter). Or NSA can use the more offensive way to for instance tab none encrypted communication between data centers or what ever they think would protect US against terrorist or other national states.

And I have not been able to find anything from Apple, Google or Microsoft that specify how long they store a delivered push message or what they use the data that is sent through their systems.

But why should a push message contain private information?

Sure we can limit the value of push message and don’t send push messages with information that leak privacy information. But this type of service is so popular and the users of apps assumes they can rely on push message services to bring them relevant information and therefore it’s my view that limiting what type of information is sent over push messages isn’t a viable option. Also from a user perspective is it very hard for a normal app user to understand that the actual content of the push message can be read in before it is delivered to their device.

The other thing we can do of course is to live with the possibility of the privacy leak. Most of us in tech are fully aware of that it is hard to use the Internet these days and have your privacy intact. But that is in my view to surrender and simply give up.

But if I come down to some examples of push notifications services that I as an app consumer really like to have that all impacts my privacy in some ways.

  • Reminders of meetings, appointments, etc. For example doctor appointments. Can be used to understand where I am at certain times as well as my intent of the visit.
  • If I use my debit/credit card I would like to have a push notification with the amount left on the card. Can of course be used to track my expenses as well as my financial situation.
  • Fitness push messages. I am a wearables junkie at the moment as I like to try out the new technology and having the ability to get push notifications about my progress, reports etc is a real motivation booster. But this type of information can be used to track my personal health.

So have I convinced you yet? Take a minute and think about the push notification you receive. Are you totally ok with all this data is possibly shared beyond your control?

So what can be done?

The simplest solution is when the app is requesting the ability to receive push notification the operating system generates a secret. This secret is given to the app alongside the unique id. It is important here to state that the secret may never be sent to the push cloud service. It is stored on the device along side the unique id.

The app then sends both the secret and the unique id to the apps cloud service. And the app cloud service uses the secret to encrypt any message that should be sent. The encrypted message and the unencrypted unique id is sent to the push cloud service for delivery to the device. The push cloud service doesn’t have the secret and therefor is unable to decrypt the actual payload of the push message.

The operating service asks the push cloud service for its messages and the cloud push service returns the encrypted messages that match the device. The device can then use the unique id of each message to fetch the corresponding secret and decrypt the message and display it to the user.

Using a secret the push cloud service is unable to read the actual push message.

This explanation is on a very high level and there are issues that needs to be handle of course. One large thing is that it breaks backward compatibility which means that the push cloud services must be able to handle both unencrypted as well as encrypted messages. Also for apps that today have registered for unencrypted messages there should be a way to upgrade to the end to end message encryption solution so all future push notification can be delivered securely. And I think there are other areas as well that needs more investigations as I have not taken that much time doing a deep analysis.

There is of course other solution than a symmetrical key for handling the encryption of the messages but it is a very simple and effective solution.

An plee to Apple, Google and Microsoft

Please take the need for end to end encryption into consideration. Best solution would be if we all started to move to secured push messages for all messages but a viable solution is also if the developers behind the app have the possibility to choose end to end encrypted if they see that the data being sent could be be a privacy violation.

As Apple is very keen on the users privacy I have always been a bit surprised they don’t have this in place already. Especially when I look at the great implementation of iMessage that truly covers all privacy concerns. So Apple, time to upgrade the APNS to v2 that take your customers privacy into account.

Google has most to gain to have the push messages in clear text as their services like Google Now could use the data sent over push messages and tailor your Google experiences in new and fantastic ways. But still, at least give the possibility to have push messages delivered with end to end encryption.

Microsoft I am not fully sure where they stand in this area. Somewhere in between I guess but my view is they also see the privacy of their users to be a benefits for usage of their services.