What Is a Mobile Application Containerization, or Wrapper, and Why Must It Die?
Containerization is an alternative for full machine virtualization. You probably have heard of the well-known containerization technology from Docker or Rocket.
In the case of Docker or Rocket, the container communicates directly with the operating system (OS) core without the need to deploy an operating system inside the container. Many containers share the same OS functions, which results in lower performance consumption used by the deployed containers and also the applications installed within these containers.
However, in this article, we want to discuss mobile “containerization,” which is used to isolate the mobile application from the mobile operating system or other applications installed on the same device. This type of “containerization” works in a different way.
Mobile “containers” behave similarly to an adapter pattern - a software design pattern that allows the interface of an existing class to be used as another interface. The container is not a box with an application in it. The original system calls from an application are rewritten to communicate not with the operating system library but a different library created by the container. Now, if you think that it is easy to hijack every application’s system calls that way, you are wrong. There are many applications that are uncontainerizationable. And if so, not every call can be hijacked.
Some apps just can’t be contained. One simple reason is that not all of their system calls can be intercepted.
As you can see, mobile “containerization” is not a real container. It's just an adapter between the application and the operating system, and it’s not even a perfect adapter. Let’s call it a wrapper.
What is a wrapper?
The wrapper is not a complicated thing. It is just another application which has a sole function of controlling other applications in advance. Unfortunately, wrappers usually require remote management via centralized management tools like Mobile Device Management (MDM) or Mobile Application Management (MAM).
We don’t have to tell you that MDM and MAM solutions cost a lot of money. To compound the issue, in many enterprise mobility use cases, MDM and MAM solutions simply don't work.
Then what are the benefits of mobile app wrapping?
Mainly protection of the OS and the user. Android and iOS operating systems limit applications from manipulating with some protected OS settings. For example, it is not possible to send an SMS from a 3rd-party application on iOS. You have to use a built-in app for that. iOS limits this feature, and no application can perform this action without manually confirming each SMS. Because of such a limitation, it is not easy for application developers to build an advanced application management system or peform other higher-level kinds of application manipulation.
Wrappers can do it.
Sometimes wrappers are used to protect an app from other apps installed on the same device. Sometimes they are used for better portability of the wrapped application and make life easier for app developers. It is true that this portability feature is more related to the wrapper than to a wrapped app. The reason is obvious. The wrapper hijacks most of the application’s calls, and it is the wrapper that communicates with the operating system.
The downside of app wrapping
1. As for security, app wrapping is not an option.
Security is not about relying on the security of the wrapper and letting the wrapper hijack the app’s system calls. Every company wants and demands secure apps. They don’t want another flawed application, additional tool to manage the wrapper solution or integration issues. A wrapped app has more demand on resources e.g. data storage, processor performance, etc. which impacts the user experience.
Security has to be integrated into the mobile app and become an inseparable part of the app.
2. But what about risks from other applications?
There is no way that the wrapper can prevent every access method from communicating with the wrapped application.
Attackers can hijack all application’s system calls in the same way the wrapper can. If the device is rooted (jailbreak on iOS), the wrapper can detect this and prevent the application from connecting to application's backend systems. However, it cannot prevent access to the application data already stored on the device.
It is simple. If the application doesn’t encrypt data-in-motion and data-at-rest, the data is vulnerable and available for attackers.
Alternatives to container and wrapper technologies
1. Android and iOS
The newly released functions from Google and Apple factories are probably more useful than wrapping. Both Android and iOS can separate applications or provide advanced control and manipulation features to maintain the security of the application and its data (Android for Work, Apple iOS 8 Enterprise features).
Are you familiar with the term security-by-design?
Why don’t we build a mobile app that doesn’t rely on other applications for security? Why not use a technology that provides ultimate security protection directly within the app and at the same time without impacting the user experience? Do you know how many people own old smartphones that do not have the capability to support advanced security protocols (e.g., TLS 1.2)?
All of us know and agree that we need to build secure mobile apps. However, pressured by the deadline, heavy workload, and lack of security awareness, it’s very tough to design, build and deliver a secure mobile app that has all necessary security measures.
It is time to rethink and retire with app containerization and wrapping.
What is a proper mobile app security technology?
- Gives visibility into who is accessing and using the mobile app and the application backend to detect the bad actors
- Integrates easily with actual mobile app
- Speeds up data transmission
- Shields the mobile application backend systems from any unauthorized access
- Operates with millions of devices
- Meets high availability demands
- Creates secure private network regardless of the technology used for data transfer, endpoint devices
If you don’t know about such a technology, we do.
Learn more about the most comprehensive application technology for mobile apps by visiting our website or contact us and talk to our security specialists.
- Custom Made vs. Off-The-Shelf Mobile Apps – The Issue of Security
- You Can Build Apps for the Apple TV, But Do You Know How to Do It Securely?
- We Know Why 85% of Mobile Apps Suck in Security. Do You?
- 7 Reasons Why Testing the Security of Mobile Applications Is Crucial for Enterprises
- The Top 5 Mobile Application Security Issues You Need to Address When Developing Mobile Applications
- 5 Security Measures You Need To Know to Ensure the Security of Your Game App
Most Recent Articles
- TeskaLabs helps LINET with cyber security compliance for medical devices
- TeskaLabs and University hospital in Pilsen launches a pilot of zScanner - open source mobile app for medical photo documentation
- EV Charging Station security demonstrator
- Five Ways AI And Machine Learning Can Enhance Cybersecurity Strategy
- C-ITS ITS-S Security microservice
You Might Be Interested in Reading These Articles
Mobile applications use HTTP communication between the application backend and the clients. Because of the demand for higher level of security, IT people implement HTTPS by setting up certificates issued by LetsEncrypt Certification Authority in their application backend server. The shift between non secure HTTP connections to HTTPS connections leads to a significant increase of amount of data being transferred from/to the clients. How is this possible?
Published on June 14, 2016
The automotive industry recently witnessed several cases of cyber-hacking that made driving connected cars dangerous if not impossible. Companies like Jeep, Volkswagen, and Tesla all have recently dealt with cases of hackers taking over cars and stopping them while the cars were in use as well as stealing customers' Social Security numbers, financial details, and other sensitive information.
Published on April 04, 2017
The goal of this article is to create a simple iOS client which generates a simple POST Request which will be read in host written in Node.js and the output generated in the console. The whole comunication will be handled by SeaCat which help us to establish fast and secure connection among our key components.
Published on September 09, 2014