Mobile Device Management (MDM) architecture uses an endpoint software called MDM agent installed on end-user devices that receive commands and MDM server either in premise or on cloud installed in company data centres for administrators to deploy company security policy and manage employee’s profiles, deploy applications and manage security among other features. MDM server consoles send commands over the air to the MDM agent, who then sends those commands to devise Applications Programming Interfaces (APIs) embedded in the device Operating System (OS).

Introduction

In earlier times, all company employees were required to access company servers and functions in the office. This used to provide in-premise security, and all devices being used were secure as well. In recent times with the development in cloud technology and Bring Your Own Device (BYOD) policies, employees can access servers anywhere, anytime, and on their own devices. These devices are usually unsecured and connected through local networks. This poses a great threat to the security of company assets as in case of compromise of any of employee devices, hackers can easily access sensitive company data.

Mobile Device Management is a set of technologies that allows company IT administrators to remotely deploy and control security policies, applications and provide additional layers of security for endpoint devices. The endpoint devices consist of mobiles, tablets, desktops, virtual systems, and terminal devices like printers, Point Of Sales, etc. The devices are continuously monitored for any unusual activities, and security measures are remotely deployed in case of a breach.

Key features of MDM are:

• Remote access and control of endpoint devices
• Application deployment
• End to end encryption
• Remote wipe
• Access management by giving different levels of access to company servers and functions according to employee designation
• GPS tracking
• Deploying company security policies
• Multi-level authentication
• Secure digital card encryption

Mobile Device Management Architecture

MDM architecture works based on the MDM endpoint device agent and server model. MDM server is a central administrator server, either on-premise or cloud-based, which sends management commands over the air (OTA) to endpoint devices. The MDM endpoint device agent receives these commands and integrates them to device Application Programming Interfaces (APIs) embedded in the device Operating System (OS). The server and client components can be separately developed and customized, keeping devices interfaces and data exchange protocols in mind. The server end automatically detects all devices connected to platforms to ensure continuous device usage, sends commands, settings, and configurations, and collects data from endpoint devices. Log records all sent commands. Micromanagement of devices is possible by sending commands to individuals or a group of devices. Enrolled devices can be identified by MDM software by the following two parameters:

• International Mobile Equipment Identity (IMEI) number: Used to identify a single device.
• International Mobile Subscriber Identity(IMSI) number: Used to identify SIM associated with the device

MDM architecture consists of three layers:

• End-user device software
• Middle Tier Server
• Back End Server

Server Side MDM Architecture

Middle tier and back end devices communicate through HTTPS, and devices receive commands on their respective APIs. The commands can be:

• Push notifications
• Activation, deactivation, or locking of a device
• Activation status

The device is identified in the MDM device database based on IMEI, IMSI, or phone number.

SMS establishes communication between end-user devices and the middle tier. Security of messages is ensured with client-side certification. A public key in a standard encrypted container is stored locally on the device and used by Android Keychain API. A private key is used to sign SMS from the client-server. The phone number used by the client and user server for communication is also stored on a securely encrypted container on the device. The container can be updated with a command sent via SMS from a valid phone number. The validity of the phone number and SMS signature is verified by Handset software directly on the device.

Backend server and its components:

• Backend server
• Administrator Console
• Main Event Processing Loop
• Database(Post greSQL)
• SMS
• SMS Gateway
• User Handsets

Let us learn about these components in greater detail:

Main Event Processing Loop

MEPL is a link that manages other components by

• sending and receiving requests
• processing requests by calling other components of the system to generate messages,
• sending messages internally within the network
• updating database

MEPL stores sent and received commands in the form of Binary Large Objects (BLOBs) stored in a database such as PostgreSQL. Commands need to be stored to rectify errors and monitor user activity.

SMS Gateway

SMS gateway does not require an active phone number to send and receive messages within the system. The SMS can be sent as an email or HTTPS request, and vice versa. No charge is levied for sent messages. Due to technical restrictions, a limit may be put in place to the number of messages sent per day per computer. HTTP or HTTPS is used to connect to the main server. HTTP requests to MEPL are converted Short Message Peer to Peer (SMPP) by processing the content of the message and sent back by the gateway.

Internet-based frameworks which use real-time messaging can be used as alternatives to SMS gateway. Examples

• io
• Catapush
• PubNub
• Firebase

Developers need an activation key for APIs of these frameworks.

Administrator Console

The administrator console is a central console that provides Unified Endpoint Management Capabilities (UEM) and Mobile Device Management (MDM) capabilities and deploys company security policy, applications, configurations, and push notifications to all enrolled devices. The endpoint devices can also be remotely controlled, locked, or wiped in a security breach. The console can be implemented as a desktop application that communicates with the server through a secure proxy channel. The admin commands are sent to MEPL, which forwards them to endpoint devices and databases via a secure SMS gateway. The connection to backend infrastructure such as Firebase Cloud Messaging with no significant role in device management relies on internet connection.

The main features of the administrator console are:

• Real-time monitoring of enrolled devices
• Analyzing and keeping a log of corporate devices
• Detecting security threats
• Blocking particular apps or locking the entire device
• Manually deploying commands to devices

MDM Architecture on the client-side

The main functions of client-side MDM architecture are:

• Carrying out server commands
• Reporting and keeping a log of the status of server commands
• Securing company database
• Controlling the device with features like locking, blocking certain applications, and complete wipe in case of a security breach to prevent other devices and servers in the network from being compromised.

The key components of the client-side architecture are:

• Device policy controller
• Device owner and its alternatives
• Unprovisioned and provisioned states

Device policy controller

Device policy controller (DPC) manages access rights for clients and system applications and includes all functions of client-side architecture. DPC is implemented as an android or iOS application on a device and should be a system app to have all permissions and privileges to manage other applications and permissions. The problem here is system apps are preinstalled apps and baked into the system image (Android ROM) of a device. The settings need to be modified in the Android Manifest file to set a permission for a system file only (Pre-installed or same certificate as ROM) to install system files. Mass deployment of applications through the play store is not possible because each ROM has a unique signature. The systems folder for the non-rooted devices has read-only access, which prevents applications from becoming part of ROM, and resetting the device will only delete these apps.

Device owner and its alternatives

The device owner is used to deploy policies and restrictions on a target device and is a privilege assigned to a specific application (MDM or any such solution). When the device is set up during initial configuration, the first user created is the device owner.

Samsung Knox, a mobile security platform, can be used as an alternative to traditional device owner profiles. An MDM profile can be created and assigned as device owner by running Knox 2.8 or higher only on Samsung devices. A Knox SDK is provided by Samsung for third-party applications but requires a license key for which a Samsung account must be created, and terms of partnership must be agreed on. Different features are provided for different license keys. Knox Platform for Enterprise (KPE) license is used for Knox SDK. The permission-based license provides paid and free features among the following three different types of licenses:

• KPE Standard: Manages basic device features by providing access to call APIs such as data encryption, user accounts, GPS, network connections, and security configuration. KPE standard is free of cost. Sufficient for implementing most features of MDM architecture on the client-side.
• KPE Premium: Allows access to advanced security features such as container VPNs, certificates, advanced kiosks, and comprehensive device customization by granting access to KPE Standard plus API.KPE Premium is a paid version.
• KPE DualDAR: Ensures double data encryption at rest by including KPE Premium capabilities and permissions to call APIs. This software is a paid version.

Provisioned and unprovisioned states

The state of a target device before the initial configuration is called provisioned state. The state of a configured device is called provisioned state. The corporate device owner for a device with preinstalled DPC app will be the app itself. This allows the DPC app to access advanced device management features such as:

• Hiding status bar
• Hiding notifications
• Hiding installed apps
• Keeping display on
• Admin controlled app installing and uninstalling
• Allowing DPC runtime permissions
• Debugging and blocking mode, so a connected USB is not allowed
• Disabling Google now and google assistant services

Device admin receiver is used to implement these features through a Device Admin Receiver which is a basic class for implementing device administration components by interpreting raw intent actions received from the system. This also enhances Broadcast Receiver Class.