Encryption

Criteria: Information I provide is encrypted so that it can't be easily read or used by attackers.

See this test in action:

Indicators

  1. Transmission of user communications or information is encrypted by default.
  2. Transmission of user communications or information is encrypted using unique keys.
  3. Users can secure their content using end-to-end encryption.
  4. End-to-end encryption is enabled by default.
  5. User information and communications are encrypted by default when at rest.

Methodology for Assessing Each Indicator

1) Transmission of user communications or information is encrypted by default.

  • Note: This indicator has been broken into two tests, one that marks what a company may say about their use of encryption and another that captures what the app is actually doing.

a) Investigation and analysis of publicly available documentation.

  • Search the application provider's website for any publicly available documentation regarding the use of encryption within the product.
  • Determine whether the documents describe what if any types of encryption are used.
  • If the provider describes the types of encryption in use and states that user communications or information are encrypted by default or automatically, mark PASS.
  • If the provider describes any encryption even if they do not describe specific schemes, mark PARTIAL PASS.
  • If the provider does not describe the use of any encryption, mark FAIL.

b) Inspect app traffic to check for TLS (transport layer security) encryption use.

  • Note: The Procedural Overview in the Digital Standard uses the term “SSL” (secure socket layer). While the terms TLS and SSL have popularly been used interchangeably, SSL no longer qualifies as a secure protocol. The implementation of SSL instead of TLS would constitute a FAIL condition in this methodology. For that reason we have opted to exclusively use the term TLS.
  • Obtain a copy of the manufacturer's application for testing, and install it on a testing device.
  • Set up and configure the app, mimicking normal use.
  • Capture the network communications from the app, and ensure that all communication between the app and any servers is encrypted.
    • The best way to capture packets between an app and the internet may vary based on your testing environment, but a Linux-based router, such as one running OpenWRT, should allow you to capture all traffic on a test wireless network. If you are running the app in an emulated environment, you should be able to capture traffic from the host system.
    • With a packet capture in hand, you can analyze the traffic with a tool like Wireshark.
  • If the app uses TLS, or other recognizable encryption protocols, mark PASS.
  • If the app does not use TLS or other recognizable encryption protocols, mark FAIL.

2) Transmission of user communications or information is encrypted using unique keys.

  • Open and close the app multiple times, capturing the network traffic between the app and the app’s servers.
    • The best way to capture packets between an app and the internet may vary best on your testing environment, but a Linux-based router, such as one running OpenWRT, should allow you to capture all traffic on a test Wireless network. If you are running the app in an emulated environment, you should be able to capture traffic from the host system.
    • With a packet capture in hand, you can analyse the traffic with a tool like Wireshark.
  • Examine the network traffic between connections and determine if the app attempts to use new session keys when communicating with the server.
    • You should be able to find this by looking at the “Protocol” column in the Wireshark interface, for TLS, and the “Info” column for Client Hello, followed by Server Hello. Looking at those packets you will see fields for “Session ID,” as well as the Server and Client “Random ID.”
    • See if those fields change between opening and closing the app. If they do, that is evidence that new TLS session keys are being generated.
  • If a new session key is used per session (or more frequently) mark as PASS.
  • If a new session key is not used per session (or more frequently) mark as FAIL.

3) Users can secure their content using end-to-end encryption.

  • Examine the settings for the app to determine if the user can enable end-to-end encryption or if it is already enabled by default.
    • Look around in the settings of the app you are testing to find what encryption settings are made available to users.
    • Note if end-to-end encryption can be enabled or disabled by the user.
  • If the app does not allow for the creation or sharing of user content sent from one user to another or to a group of others, mark as NA.
  • If the app provides an interface for enabling/disabling end-to-end encryption, mark PASS.
  • If the app provides no interface for enabling/disabling end-to-end encryption, mark FAIL.

4) End-to-end encryption is enabled by default.

  • If end-to-end encryption is user-configurable, check the settings to see if end-to-end encryption is the default selection.
  • If the app does not offer any ability to communicate with other users or the company, so that there are no communications that could be protected by end-to-end encryption, mark NA.
  • If end-to-end encryption is configurable, and enabled by default, mark PASS.
  • If end-to-end encryption is configurable, and not enabled by default, mark FAIL.

5) User information and communications are encrypted by default when at rest.

  • After configuring the app for normal usage, find any files touched by the app.
    • On Android, apps are supposed to write data to standard places (/data/data/<package_name> and/or /sdcard/Android/data/<package_name>). However, there is no technical limitation on where an app can write data to the sdcard.
    • One method is to use the “find” command before and after installing the app, as well as before/after configuring it. In a terminal or adb shell, run “find /sdcard -mmin -60” to get a listing of every file in the last 60 minutes.
  • Examine the files, and note if data is left unencrypted.
  • If data is stored in an unencrypted fashion, examine it to see if it contains what could be considered “user information” or “communications.”
  • If the app does not store any data on the device, mark NA.
  • If the app stores some data, but only less sensitive information like non-identifiable configuration settings, mark NA.
  • If the app stores only encrypted data, mark PASS.
  • If the app encrypts data such as user credentials, customer information, or other data that could be used to gather information on a user, or communication between users, but does not encrypt less sensitive information like non-identifiable configuration settings, mark PASS.
  • If the app stores data such as user credentials, customer information, or other data that could be used to gather information on a user, or communications between users and does not encrypt it, mark FAIL.

Table of Contents

Close