Conceptual overview

Any app protected with App Shielding has its own internal, encrypted configuration. In contrast, the updatable configuration is an App Shielding configuration file that is generated and encrypted separately from the app. The configuration is then hosted on your own web server where it can be downloaded from an HTTPS address via a GET request.

App Shielding in the app can be configured to download the new configuration from the given HTTPS address. If the downloaded configuration is valid and considered newer than the existing configuration, it is stored on the file system. On the next app startup, the protection features of the downloaded configuration are applied instead.

App Shielding triggers a configuration download for the following reasons:

• The app was shut down due to a security policy violation.
• The app requested an update via the SDK API.

The process only succeeds when the following conditions are met:

• The server hosting the configuration responds with an HTTP status code 200 with a non-zero data payload.
• The data payload can be validated via cryptographic signature and decrypted.
• The configuration data contains a time stamp that is newer than the existing configuration.
• The configuration data contains an identifier (i.e., configIdentifier option in the XML file) that is equal to the existing configuration .

App Shielding silently ignores any configuration which fails to download or verify, and will continue to use the last known configuration.

One reason a configuration might be considered invalid is that it was generated with the wrong version of App Shielding. Each version of App Shielding contains a unique signature key that is used to verify downloaded configuration data. This means that a configuration update is specific to the App Shielding version that was used in the targeted apps.

HTTP headers

App Shielding uses the following HTTP headers to provide additional information when requesting an updated configuration:

• X-update-custom-id
  

  An optional, custom identifier set via the API in the app code. App Shielding attempts to store and persist this custom ID for any future update requests.

• If-Modified-Since
  

  The server’s previous Last-Modified response header. It is used for cache purposes and allows the server to simply reply with a 304 status code in case no change has happened on the server side.

An example request might look like the following:

 

GET /new_config.dat?dev=Samsung&mod=SM-G950F&pkg=com.example.myapp HTTP/1.1
Host: config-update.example.com
If-Modified-Since: Mon, 21 Jan 2019 12:00:00 GMT
X-update-custom-id: fb14234c73e0b9d8e68dc3932a3cfb3ce7982fdc