Securing Mobile Apps with MASC

MASC SECURITY CONCEPTS

• The Sentinel Framework Cryptomathic

  MASC’s multi-layered evolutionary security is designed to protect against the ever-changing threat landscape, with protection measures resistant to today's attacks and responsive to future needs. MASC stays ahead of attackers by offering regular updates to the mobile app security layers and defense mechanisms. The building blocks for proactive protections and Runtime Application Self-Defense are provided by ‘sentinels’ scattered around in the MASC library. They appear and operate in many different ways to detect and react to attacks:

  • The detectors have been fine-tuned over several code generations and are known to work very well in deployed customer scenarios.
  • The detectors differ on how aggressively they search and what they try to detect.
  • The reaction can be as soft as a warning message to the backend system or set to extremely aggressive, such as crashing the application.

   

  MASC’s anti-debugging and anti-reverse engineering measures also fit into the sentinel framework, randomly distributing detections and reactions throughout the MASC code. The combination of regular updates of the security layers and the randomization of the sentinel framework makes each release of MASC a new adversary for an attacker.

  This means that the MASC defense mechanisms remain a moving target for attackers and prevent the circumvention of the countermeasures.

• Assurances

  Apps and mobile software components are rarely standalone. They frequently perform their most important operations on various backend systems, and both parties in this communication need assurance that they are talking to an authentic partner at the other end.

  Assurance and API Protection

  Assurance makes it possible to control who has access to using private backend APIs and gives a high confidence that the backend is talking to a genuine app - in the same manner the app knows that it is talking to the genuine backend. This security mechanism introduces several layers of obfuscation in the build process for protection of the assurance building blocks. The MASC sentinel framework protects the software component against reverse-engineering and tampering. A challengeresponse protocol based on the above building blocks assures the server that it talks to a genuine app. This also serves to protect the server API from unauthorized access, by preventing non-approved 3rd party apps or aggregators from accessing the APIs, already at the outer perimeter.

  Device Assurance

  It is possible to upgrade the Assurance to work with device / app specific secrets. This is known as a device binding and can be done after the first contact between a newly installed app and the server backend. The binding protocol with the backend authenticates the software and backend to each other without sending the shared secrets across the network in-the-clear.

  Device-unique keys are negotiated to protect communication with this device and identify this device (app installation) on subsequent encounters.

• Secure connectivity

  MASC is designed to be responsible for secure communication between the business app and the backend systems. MASC provides the ability for customers to set up a root certificate store independent of the device certificate store. Server certificate pinning is provided. To ensure that the app only communicates with the intended system, it maintains its own root certificate store. It implements pinned server certificate verification and as well as client certificate storage. The range of measures, provided by MASC, to secure communications are described here.

  HTTPS Tunneling

  HTTPS traffic to the backend must be tunneled through MASC to be able to use the keys controlled by MASC, this means that an attacker cannot just circumvent MASC. The HTTPS tunneling applies a whitelist to the host names and certificates (certificate pinning) presented by the hosts to further prevent man-in-the-middle attacks. The whitelists are provisioned to MASC and kept protected to prevent access and modifications by an adversary.

  Encrypted Transport

  Additional transport encryption is provided on top of TLS, to guard against TLS man-in-the-middle attacks, or to be used when TLS is unwrapped at the server perimeter, but end-to-end encryption is required.

  Strong Authentication

  MASC provides strong app authentication, by generating an elliptic curve key pair on the phone, with support for uploading the public key to a server. Another API allows using the generated private key to sign data and upload it to the server for verification.

  Access Token Protection

  Access token protection and replacement ensures that secret OAuth2 access tokens are kept securely inside the core, and do not reach the upper app layers.

  Cookie Protection

  MASC allows a set of HTTP cookies to be configured as retained. Retained cookies are handled entirely inside the MASC core, and are not accessible to the upper app layers. This can be useful to protect secure session cookies, for example.

  Device Health and Audit Logging

  MASC continually monitors the app or software components for debugging and tampering, and the device for jailbreaks and rooting. This information can be relayed to the backend via the device health and audit log services. The backend can use the information to deny, or limit access from, jailbroken or tampered devices.

• Application Hardening

  Code Hardening

  The MASC code is hardened to make it difficult to attack. Different strategies are employed to make it harder to modify the behavior with tools such as function hooking, replacing system calls or modifying state.

  Data Obfuscation

  Build-time configuration constants are obfuscated by our own white box encryption algorithms: (the code is the key), as well as standard AES encryption, and only reside in clear in RAM as short as possible.

  Native Code Obfuscation

  MASC is delivered as native code that has been extensively obfuscated to make the control flow unintelligible, and to obfuscate all constant strings.

  Protected Configuration

  An app or software component frequently needs build time configurations, like license keys, API keys, backend host names for specific brands, certificates etc. A build time tool is part of MASC, which allows build-time obfuscation of such configuration constants. MASC provides an API to access the constants at run time, but they reside encrypted at rest.

  Anti-debug

  MASC continually monitors to identify debugging attempts and emulated environments to protect against run-time analysis. Detection results can be relayed to the backend. When a definite sign of debugging is detected, MASC can deliberately crash the application process in ways that make it hard for an attacker to identify as a deliberate crash.

  Anti-tamper

  MASC detects various signs of tampering with the code: checksumming, detecting function hooking or replacement, detecting hooking frameworks, etc. Both the anti-debug and anti-tamper mechanisms are able to detect the presence of common hacking tools and will react appropriately when detected.

  Emulator Detection

  Android emulators are often used in reverse engineering. MASC looks for various signs of being run on an emulator and can crash the app or report to the backend in such cases.

  Root and Jailbreak Detection

  Jailbroken or rooted devices are often used in reverse engineering and provide less protection of the user against malware. MASC continually detects various signs of the device being jailbroken or rooted. The detection results can be relayed to the backend via the health and audit log messages.

• Secure storage

  A core component of MASC is Secure Storage which implements protection measures designed with two main objectives:

  • Prevent separation of data and application
  • Prevent migration or copying data to other devices.

   

  All application data is dispersed to make it hard to identify, separate and migrate from the application. The secure storage protections are extremely creative about where data is positioned. Cryptomathic’s design uses as many operating system services as possible.

  On top of this, there are controls in place to prohibit attackers from monitoring where the data is accessed; the application is designed to be cautious about the circumstances and times when the application stores and retrieves the data, because it never knows what might be watching. Where available, dedicated phone hardware is used as part of secure storage protection.

  Key Protection

  Cryptographic keys generated and managed by MASC are protected by device hardware where possible. The keys are encrypted as long as possible and stay within MASC.