How to Use Smart Offline Handoff for Mobile App Data Encryption

This Knowledge Base article describes Appdome’s Smart Offline Handoff feature and explains how to add it to any mobile app as part of a comprehensive mobile Data Loss Prevention (DLP) solution.

About Appdome Smart Offline Handoff

Security-conscious developers may want to restrict access to offline data or introduce additional security requirements on users in order to grant offline access. For example, they may want to only allow offline access after successful authentication with a remote server. They may also want to limit offline access to the data to a specific time frame or require additional authentication.

With Appdome Data at Rest Encryption, all data stored inside the mobile app (including media files) is encrypted at run-time using industry-standard AES 256  cryptographic protocols. When the Appdome Smart Offline Handoff option is enabled, Appdome decrypts the app’s data only after the user successfully authenticates. Additionally, the developer can specify a folder for offline file access, along with the required conditions that must be met in order to permit offline access to the data  (for example, the required conditions may include a time expiration or require additional authentication, such as Pincode/ biometric authentication).

Adding Appdome Smart Offline Handoff to your app also requires Appdome input Threat-Events ™ to be enabled in your code. The Threat-Events ™ will inform Appdome when and how to enable offline access to the app’s files. Once the timeframe has expired, Appdome notifies the app via a Threat Event and re-encrypts the files.

Prerequisites for using Appdome’s Smart Offline Handoff

• Appdome account – IDEAL or higher.
• Appdome-DEV access
• Mobile App (.ipa for iOS, or .apk or .aab for Android)
• Signing Credentials (e.g., signing certificates and provisioning profile)

Appdome Threat-Events ™ Structure

Each Appdome Threat-Event™ is a set of key/value dictionaries. Both key and value are strings: Java Strings for Android App and NSString for iOS Apps.

iOS

How to enable Appdome’s offline access to the app’s files:

    NSString* onlineToken = @“myonlinetoken";

    NSString* offlineToken = @“myofflinetoken";

    NSMutableDictionary *userInfo = [[NSMutableDictionary alloc] init];

    [userInfo setObject: onlineToken forKey: @"onlineSecret"];

    [userInfo setObject: offlineToken forKey: @"offlineSecret"];

How to Follow and Receive Appdome Threat-Events ™:

    [[NSNotificationCenter defaultCenter] postNotificationName:@"AppdomeOfflineSetProfile" object:nil userInfo: userInfo]; 
[[NSNotificationCenter defaultCenter] addObserverForName: @"OfflineFolderAccessed" object:nil queue:[NSOperationQueue mainQueue] usingBlock:^(NSNotification *note) {
        NSString *action = [[note userInfo] objectForKey:@"action"];// expired, noSecret, accessNoLocalAuth or accessPincode
        NSString *timestamp = [[note userInfo] objectForKey:@"timestamp"];// UNIX timestamp when event happened
    }];

Android

How to enable Appdome’s offline access to the app’s files

    Intent intent = new Intent("AppdomeOfflineSetProfile");

    Bundle bundle = new Bundle();

    bundle.putString("onlineSecret", "myonlinetoken");

    bundle.putString("offlineSecret", "myofflinetoken");

    intent.putExtras(bundle);

    sendBroadcast(intent);

How to Follow and Receive Appdome Threat-Events ™

private final static String OFFLINE_FOLDER = "OfflineFolderAccessed";
private BroadcastReceiver reciever;
private Context context;

public void init(Context context) {
    this.context = context;
    reciever = new BroadcastReceiver() {
        @Override
        public void onReceive(Context context, Intent intent) {
           onEvent(intent);
        }
    };
    context.registerReceiver(reciever, new IntentFilter(OFFLINE_FOLDER));
}

public void stop() {
    context.unregisterReceiver(reciever);
}

private void onEvent(Intent intent) {
    String action = intent.getAction();
    switch (action) {
       case OFFLINE_FOLDER:
           if(!intent.hasExtra("action") ) {
               Log.e(TAG, "illegal event recieved.");
               return;
           }
          String offlineFolderAction = intent.getStringExtra("action");// expired, noSecret, accessNoLocalAuth or accessPincode
    default:
          Log.e(TAG, "unknown event recieved " + action);
   }
}

On Appdome, follow these simple steps to create self-defending Mobile Apps that Initialize In-App Generated Seed without an SDK or gateway:

1. Upload a Mobile App to Appdome’s Mobile App Security Build System

   • Upload Method: Appdome Console or DEV-API
   • Mobile App Formats: .ipa for iOS, or .apk or .aab for Android
   • Data at Rest Encryption > Smart Offline HandoffCompatible With: Obj-C, Java, JS, C#, C++, Swift, Kotlin, Flutter, React Native, Unity, Xamarin, and more

2. Build the feature: Data at Rest Encryption > Smart Offline Handoff

   • Building Data at Rest Encryption > Smart Offline Handoff using Appdome’s DEV-API:
     1. • Create and name the Fusion Set (security template) that will contain the Data at Rest Encryption > In-App Generated Seed feature as shown below:

     

     Figure 1: Fusion Set that will contain the Data at Rest Encryption > Smart Offline Handoff feature
     Note: Naming the Fusion Set to correspond to the protection(s) selected is for illustration purposes only (not required).

     • To add the Data at Rest Encryption> Smart Offline Handoff feature to this Fusion Set, follow the steps in section 3, Building the Data at Rest Encryption > Smart Offline Handoff feature via Appdome Console.

     • Open the Fusion Set Detail Summary by clicking the “…” symbol on the far-right corner of the Fusion Set, as shown in Figure 1 above, and get the Fusion Set ID from the Fusion Set Detail Summary (as shown below):
       

       Figure 2: Fusion Set Detail Summary
       Note: Annotating the Fusion Set to identify the protection(s) selected is optional only (not mandatory).

     • Follow the instructions below to use the Fusion Set ID inside any standard mobile DevOps or CI/CD toolkit like Bitrise, App Center, Jenkins, Travis, Team City, Circle CI, or other system:

       • Build an API for the app – for instructions, see the tasks under Appdome API Reference Guide
       • Look for sample APIs in Appdome’s GitHub Repository

3. Building the Data at Rest Encryption > Smart Offline Handoff feature via Appdome Console

   Follow the instructions below to build the Data at Rest Encryption > In-App Generated Seed protection using the Appdome Console.

   • Where: Inside the Appdome Console, go to Build > Security Tab > TOTALData™ Encryption section.
   • How: Toggle (turn ON) Data at Rest Encryption >Smart Offline Handoff, as shown below.
     Note: In order to enable the Smart Offline Handoff feature, make sure that your app contains the “OfflineFolderAccessed” Threat Event implementation.
   • Specify a Designated Folder into which data will be saved for offline access.
     On Android, this folder will be created on both
     /data/data/<app-bundle-id>/files and on/sdcard/Android/data/<app-bundle-id>/files.
     On iOS, the folder will be created under
     /var/mobile/containers/data/applications/bundle-id
   • Optional – specify the Session Timeout, an expiration time-frame for offline access (in days – 0 means no expiration time), or toggle the Require Local Authentication switch to require the device Authentication for offline access.
   • Optional: Enable the Store in Protected Memory option to allow keys and secrets to be automatically stored in protected memory. Protected memory items are encrypted while in use.
     
     
   • Figure 3: Initialize Smart Offline Handoff option
   • When you select the Data at Rest Encryption > Smart Offline Handoff, you’ll notice that the Fusion Set you created now bears the icon of the protection category that contains Data at Rest Encryption > Smart Offline Handoff.
     

   • Figure 4: Fusion Set that displays the newly added Data at Rest Encryption > Smart Offline Handoff protection

   • Click Build My App at the bottom of the Build Workflow (shown in Figure 3).