This is Part 2 of a series on Security & Privacy for Mobile Apps.

In this Part 2 of the series, we will cover the elements of mobile apps, and some guidelines related to security and privacy.

(Note: in this article mobile apps means both native and webapps)

Personal and sensitive information include any critical information such as credit card numbers, credit card validation codes, social security numbers, driver’s license numbers, name, addresses and date of birth, and other Personally Identifiable Information (PII). Such class of information must be properly handled and secured.

Recall from Part 1 the main classes of “privacy functions” performed by mobile applications:

  • Class A — Collects data
  • Class B — Stores data
  • Class C — Shares data
  • Class D — Tracks the user

Each of the above functions may have an impact on your mobile application design and implementation, as well on how you should craft your privacy policy document/content. It is not only about collecting or not sensitive information, but it is also about:

  1. Only collect, store, share, track if really needed; vs. collecting information “just in case for potential future use”, and,
  2. Preventing others from gaining access to the sensitive data collected by your app (that is, protecting the information), and,
  3. Communicating to the user what the app does with respect to sensitive data (via private policy page).

Let’s go a step deeper in understanding how the security and privacy functions listed above may affect your mobile application; to better visualize this let’s look at the following diagram which illustrates the typical elements of a mobile application with annotations on security and privacy:


Diagram Source: http://CEnriqueOrtiz.com. Click to enlarge.

In this diagram we can see the user interface, access to local storage, network transmissions/access to remote information and/or APIs, sharing, and other — most if not all parts of the mobile app have security and privacy considerations:

1. The Device/Smartphone/Tablet

  • Your application — your app, native or webapp.

2. Graphical User interface with its screens, widgets, navigation, web-views, etc.

  • Always have a Privacy Policy page; typically web (view)-based allowing you to simplify related maintenance/updates by centralizing the location of privacy text itself
  • Protect access to critical app paths/screens with a PIN — prompt the user for PIN

3. Local store

  • This can be a local DB, the filesystem, configuration files, preferences
  • All sensitive data in local store must be encrypted, using a unique secret key
  • For key generation use the PIN from the user + a device unique ID; calculate the hash, store the hash – do not store the PIN. Recalculate the hash dynamically for comparison/key-validation
  • Examples of sensitive data: payment-information, cardholder information, related 2D barcode images
  • Store critical files on the app’s storage area (vs. public storage) so that such information is automatically removed when the application is uninstalled
  • If utilizing an encrypted database, be aware of potential performance issues — encrypting/decrypting data are expensive operations!

4. The Network / Data transmissions

  • Most apps are connected to the cloud — to invoke a service on the web, to push analytics data, other
  • All data over the network shall be encrypted — use HTTPS/TLS, VPN
  • Depending on your app requirements, you many have to encrypt your messages using additional encryption + keys
  • Consider tokenization — critical information shall be tokenized; don’t use information such as Social Security numbers, drivers licenses directly; tokenize such
  • All data between the device and the server shall be encrypted as previously described

5. Context Information – this is information like time, geo/location, sensor/ambient data, preferences, social, other

  • The user shall be notified if ambient, social or profile information is utilized by the application
  • This is done (a) via application permissions, and (2) via Privacy Policy page/screen

6. External services/servers — Analytics, Facebook, Twitter, etc

  • The problem is that often “how and when” related data is “collected and shared” is totally out your apps’ control
  • Make sure you protect yourself — the user shall be notified about things like analytics-data being collected/utilized by the app.
  • This is done (a) via application permissions, and (2) via Privacy Policy page/screen

7. The Activity Log is used to record key activity information that can be used for debugging or support purposes, and that may or not be accessible remotely.

  • Encrypt the activity log on local store
  • Encrypt activity log when/if transmitted

8. Your App Servers on the Cloud

  • Designing a secure network architecture is important
  • (a) Use DMZ for publicly visible servers
  • (b, c) Servers with sensitive data shall resides behind a firewall
  • (d) All server DBs shall be properly protected and encrypted if possible

And very important is to keep good separation between the mobile app and the server-side; and to push complexity as much as possible to the server, with the goal of localizing all critical information, related-functions and validation to the server-side of things. Remember, while you personally may not get audited for security and privacy considerations, the company you are developing the app for might be; so minimize complexity by pushing as much responsibility as possible to the server.

Tokenization & Encryption

Tokenization and encryption were mentioned a couple of times on the annotations/guidelines above; let’s expand a bit on this. Tokenization & Encryption are two ways of protecting sensitive data.

Tokens are abstractions used to hide real data. Tokens are used as substitutes to Personally Identifiable Information such as SSNs. A simple example of a Token is a customer id (vs. using SSN):

  • Avoid storing personal identification; instead use the Tokens to access critical information,
  • Because the actual critical information doesn’t have to reside locally, the location of the critical information can be centralized, helping minimize sources of leakage.
  • But this comes with a price: Tokens must then be created, mapped/substituted, and managed.

And of course, Encryption is a very important way of protecting sensitive information. Always encrypt data that must be stored and/or transmitted. Encryption also comes with a price:

  • You may need to identify and implement the encryption functionality explicitly,
  • You may have to select specific algorithms (such as AES) and key-sizes (such as 1024) depending on your business needs,
  • You have to deal with key management — key generation (for example, based on PIN and device unique ID), storage, and other related key-management,
  • There are performance implications.

Encryption and tokenization are not mutually exclusive and you should consider using both techniques on your mobile application. 

To conclude this article, I am including some related guidelines that I originally wrote back in 2004; still very applicable today.

Summary General Guidelines for Mobile Applications with Sensitive Data

Always Alert the User

  • Show a privacy policy notice – The user must be notified that the application collects, records and transmits personal (location) information.
  • This privacy notice must be properly localized (i.e. right language for the particular country) and must be explicit.
  • This privacy notice must be displayed and acknowledged, at least once (probably the first time the application is used). This acknowledgement must be recorded. Note that recording the acknowledgement also serves to protect you, validating you did your part notifying the user.
  • This privacy notice should be re-displayed every once in a while, lets say once a month, or once a quarter, or something that is configurable, but the notice should never be disabled.

The End-User, the Ultimate Decision Maker

  • The application must provide the means to turn off location tracking at ANY time. Always give the device-user the ultimate decision for being tracked or not, for using geo-location information or not!

Safeguard All Captured Information

  • Location information and ALL personal information, if stored on the device, must be safeguarded: 1) not accessible by other programs or entities, 2) and possibly encrypted.
  • Location information and all personal information, if transmitted, must be properly encrypted.
  • And if stored on the server, must be totally safeguarded (access-control, encrypted).

Use the User Context responsibly

  • The mobile context can provides awesome information to your application; for example, you can use location information for location-based reminders.
  • Geofencing, the ability to track using GPS or Wi-Fi (or other means) when a person crosses a pre-defined boundary or area, can be a scary thing if used for tracking others. Don’t use geofencing to track others.
  • Always ask for permission.

Conclusion

Mobile applications may Collects, Store, Share sensitive data, or even track the user’s location. Each of these functions may have an impact on your mobile application design and implementation, as well on how you should craft your privacy policy document/content. In this article we covered the different elements of a secure mobile application with guidelines that you should take into consideration when designing/implementing your mobile app.

Stay tuned for Part 3 of this series which covers the Payment Card Industry Security Standards and related-guidelines.

Related

/CEO