Securing Push Notifications in Mobile Apps

Author: Anshika Agarwal, Software Development Engineer

If you’re like most mobile app developers, you’re using push messaging as a powerful way to communicate with your users and grab their attention with the right information at the right time. When used with discretion and personalization in context with the target user, this channel is extremely useful, enabling cost-effective, regular interaction with customers, increasing engagement, and improving conversion rates. What’s more, you can track user behavior by capturing complex analytics on open rates, delivery receipts, open time, and engagement — and then use this information to improve business strategies.

However, integrating push messaging with your mobile app comes with its own challenges. Frequent and often generic push notifications may annoy users and can cause them to uninstall your app. To avoid this fate and retain users, it’s important to pay attention to relevance, context, and personalization. And with that comes the need to help ensure better security and data privacy.

Push messaging can offer things as simple as meeting and appointment reminders, location details, and the purpose or reason for your visit. It can also enable fitness app notifications that share your vital statistics and track your personal health. But is this popular communication channel secure enough to handle these sensitive types of information?

First, let’s look at the steps in a typical push messaging flow. Then we’ll discuss how end-to-end encryption — with the help of asymmetric key pair generation and other techniques — can help secure this popular communication channel.

Typical push notification flow

Here’s the flow of a typical push notification, with the steps corresponding to the numbers in the image above:

1. In order to enable push notifications functionality, a mobile app developer uses the mobile platform’s (Apple iOS or Android) SDK APIs to register with a cloud messaging provider: Apple Push Notification service (APNs) for iOS and Firebase Cloud Messaging (FCM) for Android.

2. In response to the registration request, the cloud messaging provider sends a registration token, also called a push token. This token works like an address, identifying which device and mobile app are the intended recipients of the message.

3. The mobile app sends this push token to the customer engagement platform’s server (in the example above, we used Adobe Experience Cloud) because the server must be aware of the push token before it can send out a push message to a recipient. This one-to-one association between the push token and the user’s unique identifier enables the system to ensure that the personalized content and experience is only received by the intended user.

4. The remote server collects data on user profile attributes and interactions, giving the app developer the ability to:

• Design specific customer journeys;
• Author a message and attach it to the appropriate stage of the journey;
• Segment customers to target the right set of users based on their usage patterns and attributes; and
• Personalize message content.

5. The personalized message is tied to its push token and sent by the remote server to the mobile platform cloud messaging service.

6. The cloud messaging service then sends the message content to the right device and mobile app, and the app displays the message as a push notification.

7. The app developer can then track user interactions with the push notification, such as impression events and user clicks, to analyze and improve business strategies.

But what about data privacy?

While these types of push notifications create a more meaningful, real-time experience for your users, it is a complex collaboration of service-to-service communication that requires attention to data privacy from the point of data collection on the user’s mobile device to the remote server — as well as all subsequent flows that use the data.

This is especially true for applications such as financial services or healthcare, where personally identifiable information (PII) is commonplace and some of the contextual and personalized message content is likely to be sensitive. For example, a push notification reminder for a medical appointment may contain sensitive information such as the doctor’s name and the time and place of the appointment, which could reveal the user’s medical history. Therefore, it’s important to secure content from the time of message personalization at step 4 to the point when it reaches the device and is ready to be displayed at step 6.

Securing the push notification flow

One way to help ensure data privacy is to implement end-to-end encryption with the help of asymmetric key pair generation. Here’s how you could do that:

1. The mobile app generates a pair of asymmetric keys: private and public. The private key can safely be stored on the device in keystores, APIs which are provided by the mobile platform SDKs. Information encrypted with the public key can only be decrypted with the private key located on the device.

Here is sample code to generate the key pair and store a private key on an Android app:

2. The public key is sent to (and stored on) the remote server and stitched to the customer profile data.

3. The personalization attributes are selectively encrypted when embedding values in the authored message template.

Here is a sample Java code for encrypting any string data using a public key:

4. The final composed message targeted to each recipient is sent to the cloud messaging provider.

5. The push provider then delivers the secure, encrypted push notification to the right device and mobile app based on the push token.

6. Finally, once the message is delivered to the mobile app, it decrypts the message with its private key and displays the notification.

Here is a sample code for decrypting a string after fetching the private key from the key store on an Android app:

Some helpful tips

If you decide to implement secure push notifications, here are some things to consider and be aware of:

• The size of encrypted data is many times larger than the original data, so encrypting the entire content of a push notification isn’t recommended. Instead, you should flag sensitive personalization attributes and encrypt only those portions of the message.
• In order to avoid processing latencies due to encryption and a large set of target users, you will want to precompute and store encrypted values in the profile store alongside the flagged personalization attributes.
• The key generation, encryption, and decryption code should be tweaked based on desired encryption mechanism and data to be encrypted. In fact, they can be further sophisticated by using libraries like Google’s open-source library, Capillary, at https://github.com/google/capillary

Implementing end-to-end encryption for push notifications isn’t difficult, but it can be time-consuming. However, if you’re dealing with sensitive information and data privacy laws, it’s worth the time to ensure that your users’ data remains safe and secure.