MDM technology overview
Mobile Device Management (MDM) is a type of software that allows organisations to manage and secure the use of mobile devices, such as smartphones and tablets, by employees. MDM solutions typically include remotely configuring device settings, monitoring device usage, and enforcing security policies. Some common features of MDM systems include:- Device enrollment
- Inventory management
- Configuration management
- Security management
- data encryption
- access management
- secure digital card encryption
- geolocation monitoring and reporting
- International Mobile Equipment Identity (IMEI) number
- International Mobile Subscriber Identity (IMSI) number
MDM, EMM, and UEM, respectively: What is the distinction?
- MDM (Mobile Device Management) focuses on managing and securing mobile devices such as smartphones and tablets
- EMM (Enterprise Mobility Management) expands on MDM by also including management of mobile apps, content, and identity
- UEM (Unified Endpoint Management) expands on EMM by also including the management and security of other endpoint types such as laptops, desktops, servers, and IoT devices.
- MDM is focused on mobile devices
- EMM is focused on mobile devices + mobile apps, content, and identity management
- UEM is focused on mobile devices + mobile apps, content, and identity management + laptops, desktop, servers and IoT devices
Server-side Mobile Device Management architecture
A typical architecture for a mobile device management solution has three layers:- Handset software
- Middle-tier server
- Backend server
- turning on and off the locking mechanism
- checking if something is turned on
- Putting a device to sleep and waking it up, sending push notifications,
- Requesting and getting information about a device's lock status in an asynchronous way
Main event-processing loop
In order to produce messages, transmit them within the network, and update the database, the main event-processing loop (MEPL) must first accept requests and then call other components. The MEPL is, therefore, a component management link. Keeping track of past server-device command history is crucial for error tracking and user data collection. The MEPL generates binary big object database requests for sent and received instructions (BLOBs). This solution utilises a database like PostgreSQL to keep BLOBs safe and secure.SMS gateway
A system can send and receive SMS messages through an SMS gateway even if it doesn't have an active phone number. Using an SMS gateway to send a message is free for the person sending it. But there may be technical limits, like how many messages can be sent from one computer in a day. Also, the gateway can change SMS into email or HTTP requests and vice versa. HTTP or HTTPS can connect the gateway to the main server in our example system. Once the MEPL gets an HTTP request from the gateway, it processes the message data, makes Short Message Peer-to-Peer (SMPP) messages, and sends them back.Alternative to an SMS gateway
There are several methods of establishing two-way communication between controlled devices and an MDM server besides using an SMS gateway. In order to provide real-time messaging with an assurance of successful delivery, internet-based frameworks like as- Ably.io
- Catapush
- PubNub
- Firebase
Administrator console
The administrator console is a way for a system manager to control how the system works. In our example, this console is a desktop app that talks to the server through a secure channel made possible by a proxy server. The administrator can do many things with this console, such as:- examining the work performed on company devices
- monitoring the use of business gadgets
- delivering instructions manually to mobile devices
- identifying device use breaches and disabling specific functions
Mobile Device Management architecture on the client side
In our example MDM system, an Android app does a few key functions:- Keeping server commands to work
- Reporting on the status of server commands
- Keeping company information safe
- Putting limits on how a device works (up to full locking)
- Device policy controller
- Owner of the device and their options
- Not provided for and provided for states
Device policy controller
It requires preloaded Mobile system applications. They need to integrate into a device's Android ROM. A device policy controller (DPC) for Android handles system and client application access privileges. A DPC must be a system app to control other apps' permissions. Let's see how non-rooted devices handle this. Our objective is to prevent rooted devices on our network. Non-rooted devices can only read /system/app and /system/priv-app. You can update system apps, but they won't be part of the ROM, and restarting the system would destroy them. To install system applications, you must provide permission that's generally available for system apps exclusively in the AndroidManifest file:
Since every ROM has its unique signature, it would be impossible to post such software to the Play Store.
Device owner
When configuring a new device, the device owner asks adding for the first user. The ability to set rules and limits on a device privilege assures a particular programme (mobile device management software or another comparable solution).Provisioned and unprovisioned states
A target device is unprovisioned before it is set up for the first time. The state of the device to set up is the provisioned state. The DPC app will be the owner of a business device that already has a DPC app. So, the DPC app will have access to more advanced ways to manage devices, such as:- Hiding installed apps (both in the app list and in settings)
- Getting rid of the status bar
- disabling notifications
- Services like turning off Google Now and Google Assistant. Apps are installed and removed. The screen doesn't turn off quietly.
- retrieving all necessary DPC runtime permissions
- Preventing the debugging mode (so that ADB doesn't connect to the plugged-in via USB)
Implementing Mobile Device Management (MDM) in practice
A web-based interface should allow an administrator to limit device functionality and prohibit non-corporate usage. The mobile device management system should also get device status updates. Android 6.0 and above device owners may utilise the LockTask API to do this. Limiting a gadget to one activity and preventing it from doing anything else is more precise. Users must be able to use the Back and Home buttons to get back to this task. It helps to make our app the default launcher. In lock mode, use the home screen only.
In order to identify a specific device, such as an IMEI or IMSI, an administrator may turn on and off this mode for that device individually; if the usable illegal gadget detects or under suspicious circumstances, it will lock itself. The following are some examples of what may happen under such circumstances:
- Invalid SIM card insertion
- Replacing a SIM card
- Defects in the device's provisioning
- Escape from the monitored territory
- Lost or broken device
Here, we'll focus on the acting techniques that make lock mode possible.
But what if your device requires access to certain normal functionalities even while locked? Let's do that using a basic Android component named EmergencyDialer. Assume that emergency calls should still be accessible, which is for the locked device; the screen will display an emergency call button.
Lock tasks cannot make emergency calls. Thus, accessing the notification bar or recent apps button will disengage the lock mode. Since the activity is a launcher, pressing Home or Back restarts the lock task.
This issue has numerous solutions. It appears the pinned EmergencyDialer component. These system buttons won't work (available on Android versions 5.0 and higher).
Intercepting system button taps is another option—it requires the more reliable old procedure. The BroadcastReceiver class processes the ACTION CLOSE SYSTEM DIALOGS event to intercept button taps.
So, when a user taps on a system button, the system will catch it and stop the lock task from restarting.
