No longer can smartphones and tablets only be used at home or for personal use? Bring Your Own Device (BYOD) is a trend that has grown as more companies realise the benefits of letting their employees follow their own mobile device management. But this popular trend is linked to several concerns about data security. After all, mobile devices can be hacked, just like laptops and desktop computers.
In this blog, we overview how mobile device management works and usually talk about how to build an MDM solution. We also give tips on implementing MDM components and examples of code for systems that manage Android devices.
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
MDM solutions typically use various technologies for mobile device management, including over-the-air (OTA) updates, device management protocols, and servers. They also may integrate with other systems like Active Directory for Authentication & Management.
An MDM platform can automatically identify networked devices and update their configurations, instructions, and settings. This procedure is totally automated to ensure the constant operation of the gadget. An MDM system should keep track of the state of the devices being watched and log the commands given. Also, it has to be able to deliver the essential settings to all devices, to a specified group of devices, or a single device so that it may meet the granularity requirements of the management system.
In a network, there are two ways to distinguish between devices:
- International Mobile Equipment Identity (IMEI) number
- International Mobile Subscriber Identity (IMSI) number
A Mobile Device Management system utilises IMEI to identify a device, whereas IMSI identifies a SIM card’s end user.
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.
In summary:
- 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
Middle-tier and backend (like Firebase Cloud Messaging) servers talk to each other over HTTPS using an API with commands for tasks like:
- 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
In the MDM server database, a device can be found by its phone number, IMEI, or IMSI (if it’s connected to a SIM card).
SMS is how client devices talk to the middle-tier server. Messages are kept safe with a client-side certificate. The system stores a public key on each device in a standard encrypted container used by the Android KeyChain API. SMSs from the server is signed with a private key.
The device also has a safe place to store the phone number that both the server and the client device used to send and receive messages. Handset software checks the device’s phone number and SMS signature to ensure they are correct. If you send a command to this container from a valid phone number, you can change it.
To fully understand how the backend server works, we’ll look at how its parts work together. Look at the diagram below to see how mobile device management architecture works.
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
Its send admin’s commands to the MEPL, which sends them to the devices and the database through the SMS gateway.
An internet connection is needed to connect to Firebase Cloud Messaging or other similar services and to other backend infrastructure that plays a small role in managing devices.
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)
It’s important to note that security is the most important thing in an Mobile Device Management architecture. If we can’t assure 100% security for devices and data, we need to ensure that hacking one device doesn’t make it easier to hack other devices on the same network.
On the client side of an MDM system, the following are the most important things to keep in mind:
- 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)
The majority of these functions are implementable using the Device Administration API. DeviceAdminReceiver is an implementation-level class for a device administration component. It assures the understanding of the system’s raw intended actions.
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
The gadget will immediately notify the server if any of these scenarios occur.
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.
Conclusion
Even though enterprise mobile device management technologies and methods are always changing, MDM is still the most important tool for keeping mobile devices safe and under control. MDM solutions let companies enforce security policies and restrictions without making things uncomfortable for end users.
At TECHOM Systems, we work hard to improve our customers’ technical experiences while ensuring that our IT services align with their business requirements.
We provide the best mobile device management service among Melbourne-based businesses in Australia.
Scheduling a call with us right now to get the best information about TOS services.
You can contact the TOS expert at any time via call at +61 3 9005 6868 or email at hello@techomsystems.com.au
