# Licel — App Security and Protection (Full Content)
> Licel provides powerful app security products that protect mobile apps, SDKs, and Java applications against reverse engineering, tampering, and fraud. EMVCo evaluated and approved.
This file contains the full content of licelus.com pages for LLM consumption.
For a concise overview, see llms.txt.
---
## Homepage
URL: https://licelus.com
# Mobile App Security Solutions for Android and iOS apps and SDKs, Java applications and libraries| Licel
## We're helping to make global payment data secure
[Certified: ISO/IEC 27001:2022](https://licelus.com/company/news/licel-is-iso-iec-27001-2022-compliant)
Our powerful app protection products make your app or SDK safe to use in a world full of fast-shifting cyber threats.
Interconnected layers of protection interact closely with both the app and the operating system. Together they form a solid shield against damaging attacks.
- ### Code and resource hardening: The act of obfuscating, encrypting, virtualizing, and isolating your app’s code and resources.
- ### Secure runtime environment: RASP checks to make sure your app isn’t exposed to harmful threats in its environment.
- ### Secure network communications: SSL pinning and certificate transparency to prevent man-in-the-middle attacks.
- ### Application integrity: Dynamic cryptographic key calculations at runtime stop your app from working if it has been tampered with.
## Our layers of app security provide unbeatable protection against a variety of threats.
### Static attacks
Bad actors will try to decompile your app to examine its code, reverse engineer its logic, discover vulnerabilities to exploit, and design malware to target it. Our products use encryption, obfuscation, and virtualization to make the decompiled code impossible to understand.
### Dynamic attacks
These days, most reverse engineering attempts are dynamic and take place during runtime execution. Our products use Runtime Application Self Protection (RASP) which spots dynamic instrumentation tools like Frida and dangerous mobile malware. Then it stops them from working.
### Network-based attacks
If the communication channel between your app and the server isn’t protected, it can be targeted. And sensitive data and assets can then be stolen. Our products secure this channel, keeping your app safe from man-in-the-middle attacks and preventing data being funnelled to a bogus server.
## Why Licel?
We helped to define the world of app security. Now we’re working hard to shape its future. Forward-thinking businesses see us as trust enablers who empower them to focus on what they do best.
- 310 million mobile banking users protected
- 450,000 smart home networks secured
- 135,000 smart car keys made safe for drivers across the globe
- 83 million patient medical records protected from sensitive data harvesting
## Supported platforms
- android
- ios
- flutter
- react
- xamarin
- java
- angular
- spring
- oracle
- js
- maven
- ionic
- and many[more](https://licelus.com/products/dexprotector/docs/android/implementations-and-integrations#dexprotecting-cross-platform-applications)
## Prevent strategic, reputational, operational and compliance risks.
App protection doesn’t only secure your application. By stopping attacks, it also protects your reputation and the trust you’ve built up with your end users. And it means you avoid revenue loss, penalties, and compliance violations.
### [DexProtector](https://licelus.com/products/dexprotector)
Dynamic protection for iOS and Android apps and SDKs.
### [Stringer Java Obfuscator](https://licelus.com/products/stringer-java-obfuscator)
Java code protection for standalone, desktop, and enterprise apps.
### [Alice Threat Intelligence](https://licelus.com/products/alice-threat-intelligence)
Mobile app telemetry solution that provides trusted signals about what is happening on end user devices, enabling smarter security decisions.
### [vTEE](https://licelus.com/products/vtee)
Unmatched protection for sensitive mobile operations.
## Cyber threats are constantly evolving, so our products can’t and don’t stand still. They’re regularly being refined, evaluated by independent labs, and [approved](https://licelus.com/emvco-evaluated) by industry bodies.
### The state of mobile app security report
In recent years our mobile phone usage has evolved dramatically. We’re asking more and more of everyday mobile apps, but are they as secure as we need them to be?
[read report](https://licelus.com/resources/state-of-mobile-app-security)
### A guide to mobile application protection
Attacks against mobile apps are getting more dangerous. To defend against them you need to know how and why
attackers target them and what you can do to stop them succeeding.
[read guide](https://licelus.com/resources/guide-to-mobile-application-protection)
### [Our latest articles](https://licelus.com/insights)
- [Mobile API Protection: From afterthought to necessity](https://licelus.com/insights/api-protection-from-afterthought-to-necessity)
- [Why trusted signals are the key to closing the widening mobile trust gap](https://licelus.com/insights/why-trusted-signals-are-the-key-to-closing-the-widening-mobile-trust-gap)
- [How Not to Lose Your Identity in 2035](https://licelus.com/insights/how-not-to-lose-your-identity-in-2035)
### News
- [20 Nov 2025 **The Licel vTEE earns second consecutive EMVCo security approval for iOS.**](https://licelus.com/company/news/the-licel-vtee-earns-second-consecutive-emvco-security-approval-for-ios)
- [20 Nov 2025 **Licel awarded the highest tier of CSA’s Cyber Trust Mark Certification for its Mobile Security Solutions**](https://licelus.com/company/news/licel-awarded-the-highest-tier-of-csa-s-cyber-trust-mark-certification-for-its-mobile-security-solutions)
- [22 Aug 2025 **Licel is ISO/IEC 27001:2022 compliant**](https://licelus.com/company/news/licel-is-iso-iec-27001-2022-compliant)
### [LayersBulletin](https://licelus.com/layers-bulletin/)
Your new and improved mobile channel security update. Sign up for the latest product updates and improvements, plus insights and solutions to core app security challenges.
---
## Products
### DexProtector
URL: https://licelus.com/products/dexprotector
# DexProtector
## Dynamic mobile app security for Android and iOS.
[documentation](https://licelus.com/products/dexprotector/docs/android/introduction-to-dexprotector)
## Powerful app and SDK security, whatever platform you’re using.
The integrity of your app or SDK is under constant threat. **DexProtector's robust security mechanisms keep your application safe from tampering, reverse engineering, and malware designed to target it**. Encryption, obfuscation, and virtualization harden your app, RASP checks detect threats in its environment, and communication hardening prevents network attacks.
Supports applications and libraries for Android Android Wear, Android TV, and Android Things from version 4.4 to 15.x.
[read android documentation](https://licelus.com/products/dexprotector/docs/android/introduction-to-dexprotector)
Supports applications and libraries for iOS and Apple Watch from versions 11.0 to 18.x.
[read ios documentation](https://licelus.com/products/dexprotector/docs/ios/introduction-to-dexprotector)
### DexProtector works just as effectively for hybrid apps as it does for native applications.
- [Flutter](https://licelus.com/frameworks-technologies/hybrid-frameworks/flutter)
- [React Native](https://licelus.com/frameworks-technologies/hybrid-frameworks/react-native)
- [Xamarin](https://licelus.com/frameworks-technologies/hybrid-frameworks/xamarin)
- [Web-based](https://licelus.com/frameworks-technologies/hybrid-frameworks/web-based)
*also supports Ionic, Kendo UI, NativeScript PhoneGap and more.
### DexProtector 15.0.9.86
The latest version of DexProtector comes with expanded support for Mobile API Protection on both platforms.
[learn
more](https://licelus.com/products/dexprotector/updates/dexprotector-15-0-9-86)
## DexProtector is designed to make developers’ lives easier.
#### Save time with instant integration
Seamlessly integrate DexProtector into your development lifecycle. Whether you use DexProtector Studio, integrate into the CI/CD process via the Gradle plugin or the command line, it’s as easy as “unprotected app in, protected app out.”
#### Protect on premises and avoid online risks
Bypass unnecessary risks associated with cloud-based security solutions. DexProtector operates offline in a safe environment that you control.
#### Secure your app without slowing it down
DexProtector’s multi-layered protection doesn’t compromise performance. Your app retains its speed and responsiveness, giving you robust security without a lag.
#### Features
## An app protection pioneer packed with features to secure your digital assets.
#### Obfuscation, Encryption, and Virtualization
DexProtector works directly with compiled apps at both bytecode and native levels to harden strings, classes, and metadata, as well as app resources, assets, and internal data. A combination of obfuscation, encryption, and virtualization mechanisms stops reverse engineering, modification, and IP theft.
#### Anti-Tampering and Integrity Control
DexProtector applies sophisticated encryption-based integrity controls involving unique context-sensitive keys calculated dynamically at the point of protection. These controls, in combination with runtime code checks, certificate checks, and file content checks, prevent attackers from modifying and exploiting protected applications.
#### RASP (Runtime Application Self-Protection) and Device Attestation
The DexProtector Runtime Engine is the first component of DexProtected apps to be initialized on launch. It scans the device for threats and enables the app to protect itself against them. The comprehensive range of device attestation mechanisms including anti-debug, anti-emulator, anti-root and Jailbreak checks help to prevent reverse engineering and tampering.
#### Anti-Malware and App Blacklisting
DexProtector’s Runtime Engine detects and reports known malware infecting end users’ devices. This protects your app and its users from malicious interference. You can also configure DexProtector to detect and blacklist specific packages.
#### UI Protection
DexProtector enables you to block screen capture and prevent keylogging. It also offers protection against overlay attacks, activity hijacking, Remote Access Tools (RATs), and Virtual Network Computing (VNC) exploits.
#### Public Key Pinning and Certificate Transparency
DexProtector enables protected apps to perform secure, client-side validation of public key certificates at the native level. This ensures the confidentiality and integrity of network communications and helps to stop man-in-the-middle attacks.
#### API Protection
With the DexProtector Runtime Engine managing network communications client-side, your app’s backend servers can check whether requests are coming from legitimate, unmodified, DexProtected applications, running on secure devices.
#### CryptoModule: White Box Cryptography Add-On
The DexProtector CryptoModule operates as a software alternative to a hardware-backed Trusted Execution Environment or Secure Enclave. Its applet automatically takes control of your app’s cryptographic processes, protecting user keys and sensitive data through white box cryptography and device binding.
#### Threat Intelligence and Fraud Monitoring
Alice receives and analyzes security-related data from DexProtected applications and libraries, offering a dashboard for data visualization, event correlation, and suspicious activity analysis. It also comes with add-ons available for API access, SIEM integration, and custom data reporting.
### DexProtector was the first software protection tool [approved by EMVCo](https://licelus.com/emvco-evaluated) for both Android and iOS. It continues to be evaluated regularly to make sure it stands up to the latest threats.
- EMVCo SBMP Compliant
- FIPS140-2 Compliant
- PCI MPoC Compliant
- PCI CPoC Compliant
- PCI SPoC Compliant
- PSD-2 Compliant
- NIAP PP_APP_v1.4
- 3DS SDK Compliant
- OWASP MAS, MASVS, MASTG
- IEC 62443
### What's at stake?
- ### Mobile app security is more important than ever
Mobile apps are the lifeblood of modern-day interactions and transactions. Every day, streams of sensitive end user data flow through them, which is why bad actors see applications as such a huge opportunity (and why protecting them is so important.)
- ### Without it, user trust and loyalty can erode
**Mobile app security is a shield against the consequences of malicious attacks**. It protects you from financial losses and fines. But more importantly, it safeguards the reputation, credibility, and trust you've worked so hard to cultivate with your user base.
### DexProtector provides a solid shield against a range of security threats targeting Android and iOS. By doing so it protects both your app and those using it.
- vulnerabilities
- IP theft
- fraud
- malware injection
- repackaging
- runtime tampering
- sensitive data theft
#### How it works
### Only a combination of DexProtector's four layers of app protection can keep your app or SDK safe.
### Code and resource hardening
DexProtector's code and resource hardening (obfuscation, encryption, virtualization, and isolation) is vital. It makes your app's decompiled code almost impossible for an attacker to make any sense of. This first protection step is important in stopping bad actors from static reverse engineering - and decompiling and modifying - your application. It also helps to mitigate dynamic analysis and tampering.
### Secure runtime environment
Rooted devices, customized firmware, malware, and dynamic instrumentation tools can all make the runtime environment untrustworthy and dangerous. This is a problem for both your app and its end users. **DexProtector's Runtime Application Self-Protection (RASP) enables your app to protect itself at runtime**. If it detects any of the threats listed above in your application's environment, it can prevent it from starting up.
### Secure network communications
Almost all apps communicate with the outside world via the network. Financial and healthcare applications dealing with sensitive information are particularly reliant on this channel. Hackers know this and are on the lookout for ways to hijack it - be that via sniffing tools or man-in-the-middle attacks. **DexProtector provides Public Key Pinning and Certificate Transparency to block the flow of data to bogus sources**.
### Application integrity
Application integrity is all about preventing an attacker from tampering with your app's binaries. This is crucial because tampering could result in malicious code injection, repackaging, and cloning. Without integrity control, a bad actor could even remove other protection mechanisms like RASP. If **DexProtector detects that any of your app's code has been modified**, it will stop it from running without exposing any sensitive information.
### There’s too much at stake to leave your app's security to chance. With DexProtector you don’t have to.
### vTEE
The Licel Virtual Trusted Execution Environment (vTEE) provides a secure space for trusted applications to perform sensitive transactions and operations. As well as a secure storage space for sensitive key material and assets, the Licel vTEE also provides dynamic security mechanisms based on the very latest cryptographic techniques.
[learn more](https://licelus.com/products/vtee)
### Alice Threat Intelligence
Protecting against attacks is only half the battle. It’s also vital to know how threats are evolving over time. That’s where Alice comes in. A mobile app telemetry solution, it ingests tamper-proof signals from trusted in-app sensors (secured by DexProtector) and turns them into actionable intelligence for fraud scoring, risk assessment, and SOC analysis. See the full Alice product page content in the Products section below.
[learn more](https://licelus.com/products/alice-threat-intelligence)
### A guide to mobile application protection
Attacks against mobile apps are getting more dangerous. To defend against them you need to know how and why attackers target them and what you can do to stop them succeeding.
[read guide](https://licelus.com/resources/guide-to-mobile-application-protection)
## DexProtector Android Documentation
[DexProtector](https://licelus.com/products/dexprotector)
Search
DexProtector Android documentation
---
## DexProtector Documentation
### Introduction to DexProtector
URL: https://licelus.com/products/dexprotector/docs/android/introduction-to-dexprotector
# Introduction to DexProtector
#### What is DexProtector?
**[DexProtector](https://licelus.com/products/dexprotector) is an EMVCo-certified, post-build, no-code protection tool for Android and [iOS](https://licelus.com/products/dexprotector/docs/ios/dexprotector-for-ios) applications and SDKs.**
Installed fully on-premises with an offline implementation, DexProtector runs as an additional step in the application build pipeline.
DexProtector:
- **Takes as input the app package** (APK, AAB, AAR, IPA, XCArchive, Framework, or XCFramework)
- **Obfuscates, encrypts, and tamper-proofs** app code, assets, and data
- **Automatically integrates** powerful security and anti-fraud capabilities via dedicated, proprietary **in-app modules**
- **Outputs** the **repackaged**, **secured**, **tamper-resistant** app, signed and ready for release
Once the app has been released, in-app modules continue to monitor and protect it on end users’ devices, enabling the app to:
- **Prevent automated, scalable attacks:** malware, credential theft, API abuse
- **Block local threats:** reverse engineering, tampering, and security-control bypasses
- **Reinforce authentication and ID verification** processes
- **Provide essential platform and device attestation data** for fraud monitoring and prevention
Apps integrating DexProtector also have the option to **report to Licel’s Alice Attack Telemetry & Threat Intelligence** platform for enhanced analytics.
**Alice** turns runtime signals into actionable intelligence for fraud scoring, risk assessment, and analysis by SOC teams. It ingests events from protected apps and enables organizations to search, correlate, and link suspicious activity across users, devices, and sessions.
#### Obfuscation & Encryption Capabilities
DexProtector delivers comprehensive code, asset, and data protection at every layer of your mobile app or SDK, across both Android and iOS, blocking static analysis, reverse engineering, and unauthorized access to secrets.
- **String & Metadata Encryption** — Constants (URLs, keys, flags), exported symbols, and sensitive metadata are encrypted at rest, making secrets, signatures, and class structures unreadable to attackers, whether in bytecode (Android) or Mach-O binaries (iOS).
- **Class Encryption & Hide Access** — Method calls, field accesses, and entire classes are obfuscated and encrypted. App logic, data flow, and class hierarchies stay invisible until runtime, defeating reverse engineering through static analysis.
- **Native Library Encryption & JNI Obfuscation** — JNI bridges and native (.so) libraries are obfuscated and encrypted, hiding implementation details and business logic from binary analysis.
- **Manifest & Symbol Mangling** — Entry points and component names (AndroidManifest.xml) are obfuscated or encrypted, eliminating human-readable anchors used for repackaging and automated attacks.
- **Resource Encryption** — Security-critical assets, including JSON, databases, models, and cross-platform code files, are encrypted within the app package, denying adversaries access to sensitive information and logic
As well as making code and assets virtually impossible for attackers to access, encryption offers a level of protection that simple obfuscation, like renaming classes or methods, can’t match.
Encryption creates a cryptographic bond between protected components and the DexProtector Runtime Engine responsible for decrypting them during runtime; this enables DexProtector to enforce a robust chain of trust from build-time to runtime, with RASP, security, and anti-fraud modules locked to the app. Any attempt at tampering instantly breaks this bond, keeping code and assets encrypted and stopping the attacker in their tracks.
**TIP:** Even if preventing reverse engineering is your only priority, obfuscation, encryption, and protections against static analysis alone are not enough. Attackers routinely use dynamic analysis (running the app in real time, hooking APIs, instrumenting the runtime, or dumping decrypted code from memory) to bypass static protections and uncover app logic, secrets, and sensitive operations. This makes Runtime Application Self-Protection (RASP) a necessity.
#### RASP, Security, and Anti-Fraud Capabilities
DexProtector automatically integrates an array of in-app security components in the form of statically and dynamically linked libraries, cryptographically bound to the host app.
**Engineered for bypass resistance.** DexProtector establishes a cryptographic chain of trust from build-time through runtime; in-app security and anti-fraud modules are cryptographically bound to the host app; in case of tampering, protected code and assets cannot be decrypted and the app's execution is prevented.
At launch and throughout runtime, this chain of trust underpins integrity checks that validate each component of the app, preventing bypass of RASP mechanisms and attestation signals, and protecting the app’s own security-critical operations.
##### **DexProtector Runtime Engine**
- The DexProtector Runtime Engine (DRE) controls access to the app’s **DexProtector-encrypted code and assets**, and extends a **protective shield** over app components and other security modules.
- The DRE implements
- **Anti-Tampering** (Cryptographic Integrity Controls; Code Integrity Checks; Asset Integrity Checks)
- **Runtime Application Self-Protection** (Anti-Debugging; Anti-Hooking; Anti-Frida; Anti-Instrumentation; Anti-Code Injection; Anti-Virtual Containers)
- **Platform & Device Attestation** (Emulator Detection; Root Detection; Jailbreak Detection; Custom Firmware Detection)
- **UI Protection** (Anti-Keylogging; Anti-Screen Capture; Input Event Analysis)
- **Network Security** (Public Key Pinning; Certificate Transparency)
- These capabilities enable apps to prevent & mitigate threats based on **reverse engineering**; **tampering**; **code** **injection**; **compromised** **networks**; **man-in-the-middle attacks**; **remote** **access** **tools**; **bots**; **screen capture**.
### **Mobile API Protection**
- The Mobile API Protection module integrated in the app by DexProtector generates short-lived **cryptographically signed tokens** confirming the app's **integrity**, to be included in **API requests** and validated at the backend.
- Enables backend servers to confirm that a request originates from a **genuine**, **up-to-date**, and **secure instance** of the mobile app, and to reject requests from insecure, tampered, or untrusted endpoints.
- Prevents & mitigates threats based on **API abuse**; **bot attacks**; **credential stuffing**; **replay attacks**; **version rollbacks**
### **User Preference Encryption**
- The User Preference Encryption module integrated in the app by DexProtector ensures security for **data at rest**, i.e. data stored locally on the user’s device, through a combination of **encryption** and **device binding**.
- For apps using SharedPreferences (Android) and NSUserDefaults (iOS) to store sensitive or security-critical data, such as PINs, auth tokens, session tokens, usernames, email addresses, phone numbers, and location history, persistently on the user’s device.
- The User Preference Encryption module ensures that such data is stored **encrypted with a device-specific key**, protecting it from unauthorized access and extraction from the device.
- Prevents & mitigates threats based on **stolen devices**; **malware**; **remote data extraction**.
### **Malware Detection**
- The Malware Detection module integrated by DexProtector enables the app to detect and report known **malware**, **potentially harmful apps (PHAs)**, and **blacklisted apps** on the user’s device.
- DexProtector integrates a database of known malware signatures and identifiers, sourced directly from the comprehensive **Alice Malware Database**.
- The Malware Detection Module references this database when scanning the end-user's device. If any listed apps are identified on the device, their presence is reported to Alice.
- Prevents & mitigates threats based on malware & PHAs, e.g. **banking trojans**, **spyware apps**, **remote access apps**, **virtual camera apps**, **cloning apps**, **GPS spoofing apps**, etc.
### **Licel vTEE CryptoModule**
- The Licel vTEE CryptoModule is an in-app component which provides secure cryptographic services - ensuring the confidentiality and integrity of key material, keys, and the most security-critical sensitive data – through a combination of **white-box cryptography** and **logical isolation** within an instance of the Licel vTEE.
- Unlike traditional hardware-based TEEs, the Licel vTEE is a software-based implementation. It creates a virtual, logically isolated execution environment directly within the mobile application itself.
- This enables capability for a fully ‘secure channel’, such that (1) key material and secret keys are never exposed outside of the vTEE, and (2) whenever sensitive data exists outside vTEE (whether in memory, in storage, or in transit) it can always be in encrypted form.
- The outcome is the prevention and mitigation of exploitation based on **malware**, **memory dumps**, **replay attacks**, **unauthorized access to cryptographic keys**, **theft of EMV payment card credentials**, and **theft of tokens**.
- The CryptoModule TA is therefore ideally suited to apps and SDKs with **software-protected cryptography** requirements, as defined by **PCI MPoC** and **EMVCo SBMP** specifications.
- The CryptoModule TA is integrated by and configurable via DexProtector, and secured by both the Licel vTEE and the DexProtector Runtime Engine.
[NextDexProtector for Android](https://licelus.com/products/dexprotector/docs/android/dexprotector-for-android)
[iOS documentation](https://licelus.com/products/dexprotector/docs/ios/introduction-to-dexprotector)
### DexProtector for Android
URL: https://licelus.com/products/dexprotector/docs/android/dexprotector-for-android
# DexProtector for Android
#### Overview
[DexProtector](https://licelus.com/products/dexprotector) secures Android applications, libraries, and SDKs against static and dynamic analysis, tampering, reverse engineering, and [Man-in-the-Middle](https://licelus.com/insights/how-to-counter-man-in-the-middle-attacks) attacks.
As the final stage of the build process, **DexProtector works on compiled packages of any size**, integrating its protection mechanisms at both bytecode and native levels.
And **it is easy to integrate DexProtector into any development cycle**, with support for both native and cross-platform apps, as well as build tools like Gradle, and CI/CD platforms like Bitrise, Jenkins, Azure Pipelines, and Bitbucket Pipelines. For more information, see our [Implementations and Integrations page.](https://licelus.com/products/dexprotector/docs/android/implementations-and-integrations \"Implementations and Integrations\")
Key features of **DexProtector for Android**:
| | |
| --- | --- |
| Code Protection | - String Encryption
- Class Encryption
- Hide Access to Method Calls and Fields
- Native Code Obfuscation
- Native Code Encryption
- Native Code Anti-Debugging
- Annotation Encryption |
| Content Protection | - Resource encryption
- HTML, JS, & CSS code encryption
- DRM for media resources
- Game engine resource encryption
- Support for external access to encrypted resources
- Encryption of `res` folder & `strings.xml`
- `AndroidManifest` mangling
- Encryption of resources in `root` folder
- Cryptographic material encryption |
| Integrity Control | - Certificate Checks
- Code Integrity Checks
- Content Integrity Checks |
| Network Security | - Network security status monitoring
- Public Key Pinning
- Certificate Transparency |
| Runtime Application Self-Protection (RASP) | - Anti-debug mechanisms
- UI protection mechanisms
- Environment checks (detection and reporting of rooted devices; emulators; debuggers; hooking; tampering; and more) |
**Note**: For some features, a DexProtector Enterprise license is required. For more information, see our [feature comparison for DexProtector Standard and DexProtector Enterprise](https://licelus.com/downloads/DexProtector_Feature_Matrix.pdf \"feature comparison for DexProtector Standard and Enterprise\").
[NextGetting started](https://licelus.com/products/dexprotector/docs/android/getting-started)
### Getting started
URL: https://licelus.com/products/dexprotector/docs/android/getting-started
# Getting started
#### 1. Download
Downloading and activating **[DexProtector](https://licelus.com/products/dexprotector)** is straightforward. Once you have [requested a trial](https://licelus.com/get-a-free-trial) or purchased a full license, we will send you an email containing a download link and a unique, single-use activation code.
Click the link to download a zip file containing the distribution package. Extract the contents of the zip file to the destination folder.
#### Distribution package contents
- Executable jar file - `dexprotector.jar`
- Annotations library - `dexprotector-annotations.jar`
- Maven plugin - `dexprotector-maven-plugin.jar`
- Gradle plugin - `dexprotector-gradle-plugin.jar`
- Configuration file - `dexprotector.xml`
- Ant settings file – `custom_rules.xml`
- License texts - `NOTICE`, `LICENSE`
The email containing the distribution package will also contain a link to DexProtector Studio. For more information, see [our guide to DexProtector Studio](https://licelus.com/products/dexprotector/docs/android/dexprotector-studio).
#### 2. Activate
You can activate DexProtector either via your command-line interface, or via DexProtector Studio; activation is possible both online and offline.
Activation codes are single-use. If the original license file is lost, or if the hardware or software configuration is changed, you will need to contact [support](mailto:primary@licelus.com) for a new code.
#### Activate via CLI (online)
To activate DexProtector online via the command line, run the following command, then follow the instructions generated:
```bash
java -jar dexprotector.jar -activate
```
After successful activation, the license file `dexprotector.licel` will be created in the user's home folder.
To use a license file not located in the home folder, specify the path to the license file via the special option provided in the CLI.
#### Activate via CLI (offline)
To activate DexProtector offline via the command line, run the following command:
```bash
java -jar dexprotector.jar -activationRequest
```
Enter your activation code as prompted. When you have entered a valid activation code, a request code will be generated. Email this request code to [our support team](mailto:primary@licelus.com \"primary\").
You will receive a response code as soon as possible, within a maximum of 1 business day.
When you have received the response code, run the following command and then enter the response code when prompted:
```bash
java -jar dexprotector.jar -activationResponse
```
After successful activation, the license file `dexprotector.licel` will be created in the user's home folder.
To use a license file not located in the home folder, it is necessary to specify the path to the license file.
#### Activate via DexProtector Studio (online)
1. Click on ‘License Info’ to the right of the bar at the bottom of the window.
2. Click ‘Activate License’ and follow the instructions in the new window. To activate your license and obtain a license file **online**, simply enter the unique, single-use activation code provided in the email with your download links. If you don’t have an active Internet connection, or prefer offline activation, see how to [Activate via DexProtector Studio (offline)](https://licelus.com/products/dexprotector/docs/android/getting-started#activate-via-dexprotector-studio-online \"Activate via DexProtector Studio online\").
3. After successful activation, the license file `dexprotector.licel` will be created in the user's home folder.
#### Activate via DexProtector Studio (offline)
1. Click on ‘License Info’ to the right of the bar at the bottom of the window.
2. Click ‘Activate License’ and follow the instructions in the new window. If you don’t have an active Internet connection, or have prefer offline activation, enter the unique, single-use activation code provided in the email with your download links, and then click ‘Generate activation request’.
3. When you have entered a valid activation code, a request code will be generated. Email this request code to [our support team](mailto:primary@licelus.com \"support\"). You will receive a response code as soon as possible, within a maximum of 1 business day.
4. When you have received your response code, return to the same ‘Activate License’ window, and click ‘I Already Have My Activation Response Code’. In the following window, enter the response code you’ve received and click ‘Activate’ to complete the license activation procedure.
5. After successful activation, the license file `dexprotector.licel` will be created in the user's home folder.
#### 3. After activation
Once you have successfully activated DexProtector, you can begin the process of protecting your app. The first step is to specify what you want to protect and how exactly you want to protect it by [configuring your protection settings](https://licelus.com/products/dexprotector/docs/android/getting-started#configuring-dexprotector \"Configuring DexProtector\").
[NextConfiguring DexProtector](https://licelus.com/products/dexprotector/docs/android/configuring-dexprotector)
### Configuring DexProtector
URL: https://licelus.com/products/dexprotector/docs/android/configuring-dexprotector
# Configuring DexProtector
#### Introduction to configuring DexProtector
**[DexProtector](https://licelus.com/products/dexprotector)** works best when it is tailored to your app.
Configuration is by means of a single XML file, which can be edited directly or via the DexProtector Studio interface. A default configuration file (dexprotector.xml) can be found in the root folder of the distribution package, but every app (or SDK) has different requirements. We therefore strongly recommend that you create your own tailored configuration, in order to target the correct code and resources for protection.
You can use the configuration file to control the DexProtector process according to your needs. The configuration file allows you to specify the details of:
- **Build and logging settings for the DexProtector process**
- **Signing methods**
- **Protection mechanisms and filters for including/excluding code and resources for protection**
- **Environment checks, for the detection of rooted devices; debuggers; emulators; and hooking tools**
- **Network security options, including certificate monitoring for both Certificate Transparency and Public Key Pinning mechanisms**
- **Integration with Licel's Threat Reporting and Attack Telemetry system, [Alice](https://licelus.com/products/alice-threat-intelligence)**
#### Protection Recommendations
We recommend making use of all of the security features provided, as each element of protection adds more security and more resistance against malware, reverse engineering, tampering, and Man-in-the-Middle attacks.
**Note**: For some features, a DexProtector Enterprise license is required. For more information, see our [feature comparison for DexProtector Standard and DexProtector Enterprise](https://licelus.com/downloads/DexProtector_Feature_Matrix.pdf).
#### Configuration file overview
xml
```xml
false
false
no_default
debug
no_default
no_default
no_default
no_default
no_default
no_default
no_default
no_default
no_default
no_default
no_default
no_default
no_default
true
true
true
true
0
block, report
no_default
0
no_default
no_default
0
```
| Build Settings | Description and values |
| --- | --- |
| Verbose Logging
boolean | **_Element_** _:_`verbose`
**_Description_**: _Enables/disables verbose logging for the DexProtector process._
**_Valid values_** _: true; false._ **_Default value_** _: false_
```xml
false
``` |
| Code Optimization
boolean | **_Element_** _:_`optimize`
**_Description_** _: Removes redundant metadata from the package that might otherwise affect performance and/or be exploited by bad actors_
**_Valid values_** _: true; false._ **_Default value_** _: false_
```xml
false
``` |
| Security Assessment
signingCertificateCompromised
signingCertificateWeakKey
dependencyCheck | **_Element_** _:_`securityAssessment`
**_Description_**: _With Security Assessment enabled, the DexProtector process will fail if the signing certificate is known to be compromised, or recognized as weaker than recommended._
**_Valid values_** _: true; false._ **_Default value_** _: false_
**_Nested elements_**(`` _,_`` _,_``)
**_Element (nested):_**`signingCertificateCompromised`
**_Description_** _: If the signing certificate has been compromised, the DexProtector process will throw an error and the build will fail._
**_Valid values_** _: warning; error; off._ **_Default value_** _: error_
**_Element (nested):_**`signingCertificateWeakKey`
**_Description_** _: If the signing key is weak (i.e. an RSA key that is <2048 bits), the DexProtector process will throw an error and the build will fail._
**_Valid values_** _: warning; error; off._ **_Default value_** _: error_
**_Element (nested):_**`dependencyCheck`
**_Description_** _: Checks application dependencies for known vulnerabilities._
**_Valid values_** _: warning; error; off._ **_Default value_** _: warning_
```xml
``` |
| ProGuard mapping file
string | **_Element_** _:_`proguardMapFile`
**_Description_**: _Specifies the absolute path to ProGuard's mapping file. If you use ProGuard for name obfuscation, it is necessary to provide the path to ProGuard's mapping file so that DexProtector can locate classes for encryption._
**_Default value_** _: no default value._ **_Note:_** _When using the DexProtector Gradle Plugin, the value for the proguardMapFile (if necessary) is set automatically._
```xml
/Users/developer/project/proguard/mapping.txt
``` |
| Signing | Description and Values |
| --- | --- |
| Signing Mode
string | **_Element_** _:_`signMode`
**_Description_** _: Specifies options for app signing._
**_Valid values_** _:_
- `debug` _- signature is performed with a debug key, derived from ${USER_HOME}/.android/debug.keystore_
- `release` _- signature is performed with the developer's key_
- `google` _- signing mode to be used with Google Play App Signing (see Google Play App Signing)_
- `amazon` _- signing mode to be used for Amazon Appstore (see Amazon App Signing)_
- `none` _- no signing key. This is only appropriate in cases when signing will take place at a later stage, for example with a manufacturer’s or platform key for system apps._
```xml
google
``` |
| Keystore information ( _for signMode == release; signMode == google; signMode == amazon_)
Keystore
Keystore password
Key alias
Key password | **_Element_** _:_`keystore`
**_Description_** _: Specifies the path to the keystore containing the relevant signing key_
**_Default value_** _: no default value. Note: With the DexProtector Gradle Plugin, the path is specified automatically._
* * *
**_Element_** _:_`storepass`
**_Description_** _: Specifies the password to the keystore containing the relevant signing key_
**_Default value_** _: no default value. Note: With the DexProtector Gradle Plugin, the path is specified automatically._
* * *
**_Element_** _:_`alias`
**_Description_** _: Specifies the alias string for the relevant signing key in your keystore_
**_Default value_** _: no default value. Note: With the DexProtector Gradle Plugin, the path is specified automatically._
* * *
**_Element_** _:_`keypass`
**_Description_** _: Specifies the password for the signing key_
**_Default value_** _: no default value. Note: With the DexProtector Gradle Plugin, the path is specified automatically._
* * *
```xml
/home/developer/example.keystore
examplestorepass
examplealias
examplekeypass
``` |
| Keystore information ( _for signMode == google_)
SHA-256 Certificate Fingerprint
Legacy SHA-256 Certificate Fingerprint | **_Element_** _:_`sha256CertificateFingerprint`
**_Description_** _: Specifies the SHA-256 Certificate Fingerprint corresponding to the Google Play App Signing Key used in Play app signing._
**_Default value_** _: no default value. Note: with the DexProtector Gradle plugin, the value is derived automatically._
```xml
google
/home/developer/example.keystore
examplestorepass
examplealias
examplekeypass1B:5F:8B:D0:5A:A2:37:FC:D3:5F:AF:21:B7:F1:57:BD:E0:17:17:FA:6D:C3:35:FC:D5:AB:7A:2A:A5:70:33:2E
```
* * *
**_Element_** _:_`legacySha256CertificateFingerprint`
**_Description_** _: If you publish your app to Google Play, you can upgrade the signing key for your published app through the Play Console—your new key is used to sign new installs and app updates, while your older app signing key is used to sign updates for users who installed your app before the key upgrade. If you have upgraded the signing key for your published app and are DexProtecting an update, you must specify both the SHA-256 Certificate Fingerprint corresponding to the new key, and the Legacy SHA-256 Certificate Fingerprint corresponding to the original key._
**_Default value_** _: no default value._ |
| Code Stripping | Description and Values |
| --- | --- |
| Logging Call Stripping | **_Element_** _:_`stripLogging`
**_Description_** _: Prevents unwanted log outputs by blocking the calling of methods with android.util.Log. The scale of verbosity (from least to most) is WTF, ERROR, WARNING, INFO, DEBUG, VERBOSE._
**_Valid values_** _: wtf [strip_`android.util.Log.wtf(...)` _]; error [strip_`android.util.Log.e(...)` _]; warning [strip_`android.util.Log.w(...)` _]; info [strip_`android.util.Log.i(...)` _]; debug [strip_`android.util.Log.d(...)` _]; verbose [strip_`android.util.Log.v(...)` _]; all [strip all of the above]_
```xml
all
``` |
| Method Call Stripping
filters | **_Element_** _:_`stripMethodCalls`
**_Description_** _: Blocks the calling of specified methods (for example, the method calls of third-party logging libraries)_
**_Element (nested)_** _: filters (Only when mode != off):_
**_Format_** _: string_
**_Default value_** _: no default value_
```xml
android.util.Log.println
``` |
| Code Protection | Description and Values |
| --- | --- |
| String Encryption
filters | **_Element_** _:_`stringEncryption`
**_Description_** _: Enables DexProtector's String Encryption mechanism._ **_Note_** _: We recommend encrypting as many strings as possible, but especially those containing sensitive data (logins, passwords, API credentials, keys, etc.). There is no need, on the other hand, to encrypt any strings contained in publicly available third party libraries, and DexProtector’s default configuration file contains certain example filters to exclude such libraries from the string encryption process._
**_Element (nested)_** _: filters_
**_Format_** _: string_
**_Default value_** _: no default value_
```xml
glob:!**/**
glob:com/test/**
``` |
| Annotation Encryption
filters | **_Element_** _:_`annotationEncryption`
**_Description_** _: Encrypt Kotlin annotations to protect sensitive metadata._ **_Important_** _: Filters for Annotation Encryption work differently than for other mechanisms. Filters must target the classes in which annotations are defined, and not the classes in which annotations are referenced. DexProtector will then locate all instances of the annotations and encrypt them._
**_Element (nested)_** _: filters_
**_Format_** _: string_
**_Default value_** _: no default value_
```xml
glob:kotlin/Metadata.class
your/own/secret/Annotations.class
other/framework/secret/Annotations.class
``` |
| JNI Obfuscation
filters | **_Element_** _:_`jniObfuscation`
**_Description_** _: Enables the obfuscation of JNI (Java Native Interface) method names in native libraries and classes, in accordance with the specified filters. Note: When setting filters for JNI Obfuscation, you only need to specify the classes that contain JNI methods. DexProtector will then automatically process native libraries containing the JNI methods from those classes._
**_Element (nested)_** _: filters_
**_Format_** _: string_
**_Default value_** _: no default value_
```xml
glob:com/sample/NativeLibrary.class
``` |
| Hide Access
filters | **_Element_** _:_`hideAccess`
**_Description_** _: The Hide Access mechanism conceals method calls and field accesses in the packages and classes specified in the filters, breaking the link between the call site and the function being called._
**_Element (nested)_** _: filters_
**_Format_** _: string_
**_Default value_** _: no default value_
```xml
glob:!**/**
glob:com/test/**
``` |
| Class Encryption
filters | **_Element_** _:_`classEncryption`
**_Description_** _: DexProtector encrypts entire classes.dex including Application, Activities, ContentProviders, and Receivers, in accordance with the specified filters._ **_Note_** _: DexProtector will encrypt all classes by default, without affecting the application’s performance. However, it is important to exclude any classes that must remain accessible to third parties, such as those that form part of a public API._
**_Element (nested)_** _: filters_
**_Format_** _: string_
**_Default value_** _: no default value_
```xml
``` |
| Native Library Encryption
filters | **_Element_** _:_`nativeLibraryEncryption`
**_Description_** _: DexProtector encrypts native libraries (.so files) within the target package, in accordance with the chosen filters._
**_Element (nested)_** _: filters_
**_Format_** _: string_
**_Default value_** _: no default value_
```xml
glob:libsample-jni.so
``` |
| Resource Protection | Description and Values |
| --- | --- |
| Resource Encryption
assets folder encryption
res folder encryption
resources.arsc string encryption
resource name obfuscation
root folder encryption
AndroidManifest mangling
Xamarin assemblies | **_Element_** _:_`resourceEncryption`
**_Description_** _: Resource encryption protects against malicious copying, modification, and piracy by encrypting an application's internal resources; resource names; and, for cross-platform apps, HTML, JS, and CSS code. Filters can target the assets and res folders, as well as resources in the root folder, and individual string resources._
* * *
**_Nested elements_** _(, , , ,, , ):_
**_Element (nested):_** _assets_
**_Description_** _: Encrypts files in_`assets/` _. Files can be targeted by file pattern (i.e. .png denotes all files of PNG file format_ **_),_** _name pattern_ _(i.e. File1 denotes all files whose names begin with the string \"File1\"), by specific file name (e.g. File2.json), or by path (e.g. TestDir/File3.txt)._ **_Note 1_** _: If there are no assets/res elements in the configuration file under the resourceEncryption section, the encryption of the assets folder will be performed in accordance with DexProtector’s default settings._ **_Note 2_** _: Assets directly accessed by the OS must not be encrypted._
**_Format_** _: contains nested elements_
**_Element (nested)_** _: filters_
**_Format_** _: string_
**_Default value_** _: no default value_
**_Element (nested)_** _: res_
**_Description_** _: Encrypts files in_`res/` _. Files can be targeted by file pattern (i.e._ **_**_** _png denotes all files of PNG file format), name pattern (i.e. File1** denotes all files whose names begin with the string \"File1\"), by specific file name (e.g. File2.json), or by path (e.g. TestDir/File3.txt)._ **_Note 1_** _: If there are no assets/res elements in the configuration file under the resourceEncryption section, the encryption of the res folder will be performed in accordance with the default filter._ **_Note 2_** _: Resources directly accessed by Android must not be encrypted._
**_Format_** _: contains nested elements_
**_Element (nested)_** _: filters_
**_Format_** _: string_
**_Default value_** _: no default value_
**_Element (nested)_** _: strings_
**_Description_** _: Encrypts strings and string arrays in_`resources.arsc` _._ **_Note_** _: If there is no ‘strings’ element in the configuration file under the resourceEncryption section, the encryption of strings and string-arrays in resources.arsc will be performed in accordance with DexProtector’s default settings._
**_Format_** _: contains nested elements_
**_Element (nested)_** _: filters_
**_Format_** _: string_
**_Default value_** _: no default value_
**_Element (nested)_** _: nameObfuscation_
**_Description_** _: With Resource Name Obfuscation enabled, DexProtector will obfuscate names of names of files in res/. It is possible to set filters for Resource Name Obfuscation independently of the filters specified for res folder encryption. For more information, see the guide to [filters for resource encryption](https://licelus.com/products/dexprotector/docs/android/configuring-dexprotector#additional-notes-on-filters \"filters for resource encryption\")._
**_Format_** _: contains nested elements_
**_Element (nested)_** _: filters_
**_Format_** _: string_
**_Default value_** _: no default value_
**_Element (nested)_** _: root_
**_Description_** _: Encrypts files in_`root/` _. Files can be targeted by file pattern (i.e._ **_**_** _png denotes all files of PNG file format), name pattern (i.e. File1** denotes all files whose names begin with the string \"File1\"), by specific file name (e.g. File2.json), or by path (e.g. TestDir/File3.txt)._
**_Format_** _: contains nested elements_
**_Element (nested)_** _: filters_
**_Format_** _: string_
**_Default value_** _: no default value_
**_Element (nested)_** _: androidManifestMangling_
_Description: Mangling settings for AndroidManifest.xml. If the element androidManifestMangling is included in the configuration file, DexProtector will mangle entities in the AndroidManifest.xml file._
**_Element_** **_(nested)_** _: xamarinAssemblies_
**_Description_** _: Encrypts Xamarin assemblies_
**_Attribute_** _: dir_
**_Description_** _: If the assemblies are not in the default folder (assets/assemblies), you can set a path to them using the attribute dir. The path should start from the APK’s root, for example: assets/xxx/assemblies_
**_Format_** _: string_
**_Default value_** _: no default value_
```xml
glob:cert/**
glob:raw/**
glob:fonts/**
my_api_key
glob:mobile_token*
glob:payments_**
glob:sensitive_strings_arrays_etc*
``` |
| RASP (Runtime Application Self-Protection) - Environment & Runtime Checks | Description and Values |
| --- | --- |
| Anti-Debug | **Element**: `antiDebug`
**Description**: With this setting enabled, the DexProtector Runtime Engine will close the app instantly if it detects that a debugger is attached. |
| Anti-Emulator | **Element**: `antiEmulator`
**Description**: With this setting enabled, the DexProtector Runtime Engine will prevent the app from running on an emulator. Note: Client-side API and callback options are available as an alternative to closing the app. Please request more details on configuration and implementation. |
| Anti-Manual Install | **Element**: `antiManualInstall`
**Description**: With this setting enabled, the DexProtector Runtime Engine will prevent the app from running if it was sideloaded. Note: Client-side API and callback options are available as an alternative to closing the app. Please request more details on configuration and implementation. |
| Anti-Malware | **Element**: `antiMalware`
**Description**: With this setting enabled, the DexProtector Runtime Engine will report malware and Potentially Harmful Apps detected on the device to the organization's Alice Threat Intelligence database. Note: must be enabled. Client-side API and callback options are also available. Please request more details on configuration and implementation. |
| Runtime Checks | **Element**: `runtimeChecks`
**Description**: With this setting enabled, the DexProtector Runtime Engine will prevent the app from running on custom firmware and rooted devices. |
| Network Security | Description and Values |
| --- | --- |
| Public Key Pinning | **Element**: `publicKeyPinning`
**Description**: Settings for SSL/HTTP Public Key Pinning. These can be specified **either** via a security configuration file in res/xml (in accordance with [specification for Android N](https://developer.android.com/privacy-and-security/security-config \"Network security configuration\")), or via the network-security-config nested element. If you have a separate security configuration file, you must set the path to it within the attribute ‘src’.
**Attribute**: src
**Valid values**: Path to a security configuration file (see details [here](https://developer.android.com/privacy-and-security/security-config \"Network security configuration\")).
**Default value**: no default value
*
---
## Insights — Articles on App Security
Full text of all insight articles published on licelus.com.
### Mobile App Security Integration.
URL: https://licelus.com/insights/how-to-incorporate-mobile-app-security-testing-into-your-build-pipeline
# Mobile App Security Integration.
## How to incorporate mobile app security testing into your build pipeline
DevSecOps is a philosophy that integrates security into the DevOps process: it has gained significant traction in recent years.
Build pipelines serve as the backbone of this approach, automating the software delivery process and incorporating various stages of testing, including [mobile app security](https://licelus.com/products/dexprotector/docs/ios/introduction-to-dexprotector) testing. By embedding security checks into the build pipeline, you can identify and remediate vulnerabilities early in the development lifecycle, and so reduce the risk (and costs) associated with security breaches.
If you're interested in understanding **how to incorporate mobile app security testing into your build pipelines**, then read on.
In this article, you’ll learn about different types of security testing, the tools that are available, and some best practices to make sure your [mobile applications are as secure](https://licelus.com/insights/ongoing-security-a-step-by-step-guide-to-a-secure-app-development-process) as possible.
### The current mobile security landscape
You've probably heard of the Open Web Application Security Project (OWASP). It has identified the [top ten mobile vulnerabilities](https://owasp.org/www-project-mobile-top-10/), which include insecure data storage, insufficient cryptography, and insecure communications. These often serve as entry points for attackers to [compromise mobile applications](https://licelus.com/insights/ongoing-security-a-step-by-step-guide-to-a-secure-app-development-process).
Here’s the OWASP Top 10 list in full:
- M1: Improper Credential Usage
- M2: Inadequate Supply Chain Security
- M3: Insecure Authentication/Authorization
- M4: Insufficient Input/Output Validation
- M5: Insecure Communication
- M6: Inadequate Privacy Controls
- M7: Insufficient Binary Protections
- M8: Security Misconfiguration
- M9: Insecure Data Storage
- M10: Insufficient Cryptography
It’s worth pointing out that M2 and M8 in this list don’t relate only to mobile security. You can see them as part of a more holistic security strategy your organization might employ that requires incorporating DevSecOps practices into your day-to-day work.
The importance of following guidelines like those championed by OWASP is reinforced daily by news articles highlighting the dire consequences experienced by those who haven’t followed them. These include financial losses, legal repercussions, and a tarnished brand image.
According to Cybersecurity Ventures, [the cost of cybercrime](https://cybersecurityventures.com/global-ransomware-damage-costs-predicted-to-reach-250-billion-usd-by-2031/#:~:text=The%20cost%20of%20cybercrime%20is,to%20exceed%20%241.75%20trillion%20USD.) is estimated to reach $10.5 trillion USD annually by 2025 (a 15 percent yearly increase). And a significant portion of this can be attributed to mobile security lapses.
### What is a Build Pipeline?
In order for a car to reach the dealer’s warehouse, a complex manufacturing process must take place behind the scenes. The metal arriving at the factory is converted into the chassis, the spare parts are assembled together, and then a quality check will be performed.
Only then will it be delivered to the dealers.
A similar process happens with software, including with mobile apps. A build pipeline is an automated workflow that encompasses every step involved in building, testing, and deploying code. It serves as a crucial element in implementing Continuous Integration/Continuous Deployment (CI/CD) practices.
Your typical pipeline will consist of the following stages:
**Source Control**. This is when developers commit their code to GitHub, Gitlab, Bitbucket or a similar system. The build system then copies the code from a repository there.
**Static code analysis**. Developers are human beings, which means they can make mistakes because of a lack of attention or distractions. Automated static code analysis tools can spot security bugs that might otherwise have crept in.
**Dependency resolution**. Every application uses third-party libraries. The build pipeline should download these dependencies from the systems like Sonatype Nexus, CocoaPods, Swift Package Manager, and so on.
**Compilation**. The source code should be transformed into the code representation understandable by target devices. Java/Kotlin code gets compiled into the DEX format, and Objective-C/Swift is compiled to the arm instructions.
**Unit Testing**. Unit tests are small programs which run isolated parts of the application and make sure that they work as expected.
**Integration Testing**. Integration Tests run the app through different scenarios to make sure that it works as a whole.
**Application Security Testing**. Security tests try to find vulnerabilities in the app before it reaches the production stage.
**Application Hardening**. Your app will face multiple security challenges in the wild world it operates in after launch. [App hardening measures](https://licelus.com/resources/guide-to-mobile-application-protection/threats/decompilation-and-modification) are vital in fighting these threats.
**Deployment**. This is when the validated code is rolled out to a staging or production environment and your app is sent to Google Play channels, TestFlight, and/or custom services like Azure AppCenter for testing.
Each of the stages above can contribute in some way to enhancing the security of your application.
Dependency resolution and static analysis can protect against supply chain attacks. Unit and integration testing should catch problems in app logic like authentication. And deployment should securely deliver the application to app stores.
### The need for mobile app security testing in build pipelines
You've probably read about the \"shift-left\" movement in DevSecOps.
Instead of treating security as an afterthought, shift-left is all about bringing it front and center, right from the get-go.
Imagine you spot a nasty bug in your app early on in the development process. Not only does this save you days and days of debugging time, but you also make your app safer for your end users and you don’t suffer all the negative consequences of a breach that we touched on earlier.
Early detection saves you money as well as time, of course. Fixing a security issue at the outset is a bit like catching a leak before your whole basement floods.
Then there are the compliance requirements that you need to follow. Whether you're dealing with GDPR, HIPAA, or PCI-DSS, integrating security measures early can make the auditing process a breeze.
But let’s go back to the end user for a second and the importance of building trust. A secure app is a trusted app. And in today's market where everyone is more aware of privacy and data security, [having a secure app can give you a leg up on the competition](https://licelus.com/insights/why-you-should-see-mobile-app-security-as-a-unique-selling-point).
Let's take a look at a couple of examples from two different industries:
Firstly, imagine a financial services app whose developers decided to integrate Static Application Security Testing (SAST) right into their build pipeline. Because they catch some serious SQL injection vulnerabilities before they hit the production phase, they could save a huge sum in potential breach costs.
Secondly, a healthcare provider uses DAST (Dynamic Application Security Testing) to scan their application. By doing so, they discover they were storing patient data in an insecure manner. Fixing this not only saves them from potential legal headaches but also makes sure they stay HIPAA compliant.
Hopefully, you're getting the sense that integrating mobile app security testing into your build pipeline isn’t a \"nice-to-have\". It's a \"must-have\".
It saves you money, it keeps you compliant, and it builds trust with your users.
### Types of mobile app security testing
So, what does mobile application security testing actually involve?
Well, it's important to understand that it isn’t a one-size-fits-all kind of thing. There are different flavors of mobile app security testing, and each one has its own advantages.
Let's take a look at them.
#### **SAST for mobile apps**
SAST (Static Application Security Testing) is a bit like an English tutor who corrects your essay for grammatical and structural errors before you hand it in. It does this by scanning your source code, bytecode, or binary code during the development phase.
By doing so, SAST allows developers to identify vulnerabilities such as insecure data storage, weak encryption algorithms, and hard-coded secrets early in the development cycle. For Android apps developed in Java or Kotlin, SAST tools can identify vulnerabilities specific to Android SDKs, such as insecure SharedPreferences or misuse of Android KeyStore.
For iOS apps developed in Swift or Objective-C, SAST tools can flag issues like insecure data storage in UserDefaults or insecure network calls that don't use App Transport Security (ATS). These vulnerabilities can be classified as **M9: Insecure Data Storage** if we return to the OWASP Top 10 list above.
[Android Studio Lint](https://developer.android.com/studio/write/lint) provides good security capabilities from an Android app perspective. And, though not mobile specific, [SonarQube](https://www.sonarsource.com/products/sonarqube/) offers plugins for both Android and iOS. It can analyze Java, Kotlin, Swift, and Objective-C codebases.
#### **DAST for mobile apps**
DAST (Dynamic Application Security Testing) is a black-box testing methodology that analyzes a running application, often from an external perspective, to identify vulnerabilities that may be exploited during real-world attacks. Unlike SAST, which examines the codebase, DAST focuses on the application in its operational environment.
[Mobile applications are susceptible](https://licelus.com/insights/mobile-app-development-frameworks-a-security-guide) to a variety of runtime vulnerabilities, such as insecure data transmission, broken authentication, and insecure direct object references. DAST is important for mobile app security because it allows you to simulate how an attacker might exploit these vulnerabilities. This gives you a more realistic assessment of your app's security posture.
Mobile apps frequently communicate with backend services, and DAST can help here too by identifying insecure API calls or data leaks over the network. It can also test the robustness of unique authentication mechanisms such as biometric authentication.
Some popular DAST tools for mobile development include:
[OWASP ZAP](https://github.com/zaproxy/zaproxy): An open-source tool that can be configured to proxy mobile traffic, allowing you to identify vulnerabilities in API calls and data transmission.
[Burp Suite](https://portswigger.net/burp): A mobile extension that can be used to intercept and modify HTTP/S traffic between the mobile app and the backend, providing insights into potential vulnerabilities.
[Mob-SF](https://github.com/MobSF/Mobile-Security-Framework-MobSF): A tool that provides both security and dynamic testing.
[Frida](https://linuxsecurity.expert/tools/frida/): While Frida is often used by bad actors for dynamic instrumentation, its ability to inject custom code into binaries and hook to function calls means it has also become a popular form of DAST for mobile apps.
#### **IAST for mobile apps**
IAST (Interactive Application Security Testing) is a security testing methodology that combines elements of both SAST and DAST.
It analyzes an application's source code and its behavior during runtime to provide a more comprehensive view of potential vulnerabilities. IAST tools are typically integrated into the application as agents or libraries, allowing them to monitor the application from the inside.
Mobile applications often have complex interactions between the frontend and backend, as well as third-party libraries and services. IAST allows you to monitor these interactions in real time, offering insights into how data flows through the application and where vulnerabilities may exist. This is particularly useful for identifying issues like insecure data transmission between the mobile app and backend services, or [vulnerabilities in third-party libraries](https://licelus.com/insights/how-to-stop-software-supply-chain-attacks).
Mobile apps often have complex data flows involving multiple services, databases, and APIs. IAST can track data as it moves through these components, identifying insecure practices like SQL injection or data leakage. Mobile apps also often use third-party libraries for functionalities like payment processing or social media integrations. IAST identifies vulnerabilities within these libraries that could compromise the application.
### How to incorporate mobile app security testing into your build pipeline
Hopefully by this point we’ve convinced you of the merits of mobile app security testing. But you might be wondering how you actually go about incorporating it into your build pipeline.
Fortunately, it's not as daunting as you might think.
#### **Assessment and Planning**
First things first, you've got to know what kind of threats your app might be up against and where it could be vulnerable. That’s where [a threat model](https://licelus.com/resources/guide-to-mobile-application-protection/principles/develop-a-threat-model-for-your-application) comes in.
This process should help you to answer some important questions:
What are the [security requirements](https://licelus.com/insights/ongoing-security-a-step-by-step-guide-to-a-secure-app-development-process) for your app?
Are you storing sensitive user data?
Are you processing payments?
Only after creating a threat model can you start picking out the right tools for the job. That’s because the risks you’ve identified will dictate your setup strategy.
#### **Configuration and Setup**
You'll probably be tweaking build scripts, most likely in YAML if you're using something like Github Actions, GitLab CI or Bitrise. The goal here is to make sure that your security tests run smoothly every time someone pushes new code.
#### **Execution**
This is where your security tests kick in and you can begin scanning your code for vulnerabilities in earnest. And here's a pro tip: try to parallelize your tests. It will make your pipeline run faster. The trick with mobile app security testing is not only performance, but also flakiness: so you will also probably need to run them several times.
#### **Monitoring and Reporting**
You can't fix what you can't see. So, make sure you've got a solid monitoring system in place, which will provide test reports. And don't keep those test insights to yourself; share them with your team. Generate reports that can help you to make better data-driven decisions over time.
#### **Feedback Loop**
Last but not least, keep the lines of communication open. If a test finds a vulnerability, make sure it's flagged and sent back to the development team for fixing. This isn't a one-and-done deal; it's an ongoing process that keeps getting better with each iteration.
The integration of **[mobile app security](https://licelus.com/products/dexprotector) testing into your build pipeline for mobile development** is not merely an optional best practice; it’s a critical necessity.
The digital landscape is fraught with evolving security threats that pose significant risks to user data, corporate reputation, and financial stability. And so the adoption of a robust DevSecOps strategy, underpinned by a well-configured build pipeline, is vital for any organization committed to delivering secure, reliable mobile applications.
Testing enhances cost-effectiveness by reducing the resources required for late-stage remediation, it facilitates compliance with regulatory standards, and it contributes to building and maintaining customer trust.
By actioning some of the steps outlined in this article, our hope is that you can significantly mitigate the risks associated with mobile application development.
Did you know our own mobile app security solution, [DexProtector](https://licelus.com/products/dexprotector), can be easily integrated into your mobile CI/CD pipeline?
There is also [a DexProtector step on the Bitrise platform](https://bitrise.io/integrations/steps/dexprotector).
### How to secure a safer future for mobile banking
URL: https://licelus.com/insights/how-to-secure-a-safer-future-for-mobile-banking
# How to secure a safer future for mobile banking
It’s interesting how quickly our use of digital technology can feel normal.
Several years ago, transferring your half of the bill to a friend with a quick tap on your smartphone sounded pretty futuristic.
These days we do it all the time.
It’s quite common to hear younger Londoners telling each other to “Monzo me” or to “find me on Revolut” if money is owed when they say their goodbyes.
But there are others - 23% of Brits according to a [YouGov study](https://yougov.co.uk/topics/finance/articles-reports/2020/01/21/third-brits-dont-use-mobile-banking) earlier this year - who are still uncomfortable with online banking.
And this word, uncomfortable, hints at an ongoing issue for mobile banks and a challenge for its future success. As long as bad actors continue to succeed with their attacks, mobile banks will fail to convince everyone to move from traditional banks.
So, what’s the answer? How can we secure a safer future for mobile banking?
### The number one target for bad actors
The YouGov figures shouldn’t mask the rapid growth of mobile banking. After all, the consultancy [Caci reported](https://pages.caci.co.uk/rs/752-EBZ-498/images/caci-future-growth-digital-banking-report-2019.pdf) that in 2019 there were more customers using mobile banking apps than there were using more traditional internet banking.
With good reason, too. As with most digital technology innovations of recent years, mobile banking has made our lives easier.
And while it’s true that usage sways towards younger demographics, that’s the generation mobile banks are interested in most. That’s where their growth is going to come from in the next few years.
The issue, as is the case with IoT, is that where we see opportunities for growth, so do bad actors.
Mobile banking is the most lucrative industry for [hackers](https://licelus.com/insights/why-we-need-to-understand-the-hacker) to attack. Beyond being able to glean valuable data, they can also steal money directly from banks’ customers.
And their starting point is often to attempt to run a dynamic analysis on the app itself.
### The danger posed by dynamic analysis
By running a dynamic analysis on mobile banking apps, bad actors get to see how they work.
It’s like they are able to open a door into a library that contains instructions for how the app is put together. Once inside, they can take a look around. They can scope out that library for weaknesses.
A dynamic analysis is also the starting point for reverse engineering the app. If hackers can do that, then they can release a fake version of it that customers of the bank might accidentally download from the App Store or Google Play.
Those customers wouldn’t notice anything untoward at first. After all, the hacker has released an almost identical app to the original. You’d be hard-pressed to spot any differences. That is until a transfer is made, and it’s the bad actor’s account that the money lands in.
Mobile banks are faced with other threats, too.
The attack [suffered by Capital One](https://techcrunch.com/2019/07/29/capital-one-hacked-over-100-million-customers-affected/?utm_source=Triggermail&utm_medium=email&utm_campaign=Post%20Blast%20%28bii-banking%29:%20106%20million%20customers%20affected%20by%20Capital%20One%20data%20breach%20%7C%20Rakuten%20applies%20for%20an%20ILC%20%7C%20Green%20Dot%20introduces%20high-yield%20savings%20account&utm_term=BII%20List%20Banking%20ALL) last year made headlines around the world. And even before it happened, [the New York Times was reporting](https://www.nytimes.com/2018/05/20/business/banks-cyber-security-military.html) that banks were learning lessons from the military in order to ward off hackers. This shows how seriously some banks are taking the threat.
Those who have already suffered an attack can testify to how hard it is to regain the trust they had worked so hard to build with their customers.
But [fake apps](https://www.techradar.com/uk/news/android-banking-malware-hitting-more-users-than-ever) seem to be the growing threat that many banks have yet to find a reliable solution for.
### How to keep hackers out of the library
If we return to the app as a library metaphor, the danger comes from allowing the hacker into the library in the first place. You need to keep its doors locked.
And the best way of doing that is to protect the code within the app so that bad actors can’t get their bearings. Quality protection and cryptography hides the keys to the library and makes sure that any files hackers do find contain scrambled code that they can’t make any sense of.
The problem is that not all mobile banks are using this robust level of in-app hardening and cryptography.
That’s despite their customers relying on them to do so and demanding [other security features](https://www.businessinsider.com/mobile-banking-market-trends?r=US&IR=T) such as temporarily turning off a payment card.
But as we’ve said, it’s not only their customers’ data and finances these banks stand to lose, but their own reputation, too. It takes a lot less time for [customer trust](https://licelus.com/insights/how-in-app-protection-can-help-you-to-build-trust) to evaporate than it does to build it up in the first place.
If some mobile banks are being a bit lax with their security, their hand could be forced in the coming months. The PSD2 regulation in Europe will mean banks being obliged to commit to more stringent security measures.
However it happens, it’s clear that the main threat for mobile banks comes from dynamic analysis. Preventing this is the best first step to secure a safer future for mobile banking.
### Do remote critical checks offer a way in for bad actors?
URL: https://licelus.com/insights/do-remote-critical-checks-offer-a-way-in-for-bad-actors
# Do remote critical checks offer a way in for bad actors?
“Wait a second, I’ll send it to you.”
If you were looking for a phrase to sum up the last decade or so, this one would have to be right up there.
The more our phones have become semi-appendages at the tips of our fingers, the more skilled we’ve become at instant, spontaneous sharing.
So much so, in fact, that businesses have begun to take advantage of this newfound skill. Some of their processes that used to take hours now take minutes. Think about opening a bank account, for example. It used to involve hours of queuing, filling out forms, waiting, and then a lengthy conversation with the bank manager.
Now, all you need is the camera on your phone and your ID to hand. You can get verified and approved for a bank account from the comfort of your home.
But is there a danger lurking behind this modern way of sharing your details?
Are we offering bad actors a route to our sensitive information that didn’t exist before?
### KYC checks
Remote critical checks are often also referred to as “know your customer” (KYC) checks. They exist so that companies can check they’re entering into an agreement with who they think they are.
As we’ll explore, remote critical checks without robust security can lead to opportunities for hackers. But the reason for having them in the first place was [to avoid fraudulent activity](https://bis.lexisnexis.co.uk/due-diligence-and-compliance/glossary/kyc-check). To stop bad actors from illegally profiting from a business relationship.
And for banks, these checks aren’t a nice-to-have. They’re essential. [Not carrying them out can lead to significant penalties](https://www.thalesgroup.com/en/markets/digital-identity-and-security/banking-payment/issuance/id-verification/know-your-customer). In Europe, [the AMLD5 legislation](https://www2.deloitte.com/lu/en/pages/risk/articles/amld5-has-entered-into-force.html) came into force earlier this year. AMLD stands for Anti Money Laundering Directive. It requires that banks carry out even stricter due diligence than they did before.
These days, a lot of these checks are done remotely. That might sound like a particularly smart move in the age of covid-19, but it was actually already a trend before the virus arrived.
If you’ve tried to open a bank account with a mobile bank like Starling or Revolut, you’ll have experienced it yourself. You use the bank’s app to take a photo of your passport or other ID, fill in your personal details, and then wait for an email confirming approval.
But the nature of these banks being 100% digital means they’re well-versed in this remote KYC check process. What’s more, they know their reputation relies on customers trusting them to look after their money. So they often - but not always - protect their app robustly.
The problem is that others are carrying out remote critical checks, too. Not only more traditional banks, but even real estate companies and government departments. And they don’t all use the same level of security that challenger mobile banks do.
### How bad actors can exploit remote critical checks
There’s no problem with companies asking customers to supply sensitive information via a well-secured app. But some businesses ask customers to send photos of their ID via email. And email isn’t always a secure communication channel.
Bad actors can hijack this line of communication. They can intercept messages from customers and steal the valuable attachments within them for use in future attacks. [This is called a man-in-the-middle attack](https://licelus.com/insights/how-to-counter-man-in-the-middle-attacks).
Often, when customers do send this information to a bank, it isn’t actually the bank that verifies they are who they say they are. Rather it’s a verification body that owns the KYC technology.
A bad actor who carries out a man-in-the-middle attack might use their own malicious server to communicate with the customer. They could pretend to be somebody from this verification body. Then they could claim that they need even more information from the customer.
This type of fraudulent request tends to start out as a phishing email.
Social engineering has been on the rise in the last few months - partly to profit from the general anxiety around coronavirus.
After all, there’s a danger that people might be even more prone to trusting seemingly-authoritative emails or [SMS messages](https://licelus.com/insights/why-our-emotions-make-us-more-vulnerable-to-cyber-attacks) in the current climate.
And hackers know it.
They could send a message with a link to download a fake app that they’ve re-engineered. They could then instruct unsuspecting customers to upload their personal details and a photo of their passport from that app.
There are also root and emulator attacks, where a hacker can force a device’s geolocation. They can also fake user and device information, such as a fingerprint.
All of these risks show us why companies mustn't only see the benefits of time and cost savings of doing these checks remotely. Their reputation relies on them first making sure that they can protect the process.
As we’ve said before, the balance between speed and security is a delicate one. But if you have to go one way or the other, always choose security first.
### Protecting the modern, sensitive application
So, mobile banks are well placed to defend against hackers because they realize that [their business is their mobile app](https://licelus.com/insights/3-trends-that-make-mobile-app-security-impossible-to-ignore). They don’t have physical stores where they can build up a rapport.
Instead, their success and their reputation relies on them keeping their customers’ money and personal details safe.
That means they know that their app has to protect against static and dynamic analysis. They understand that they have to [block tampering](https://licelus.com/insights/how-to-counter-the-dangers-posed-by-tampering) and man-in-the-middle attacks.
Other companies that carry out remote critical checks have to recognise this, too. But even this level of security isn’t enough for the modern, sensitive application.
You need to make use of a full stack of technologies. As well as in-app protection, it’s worth investing in upper levels of protection. This includes fraud monitoring and prevention, and biometric and behavioral analysis.
With these in place, you can get back to profiting from our very 21st century skill of sharing via a few swipes of our smartphone screens.
### Protecting tracking apps in the post-coronavirus world
URL: https://licelus.com/insights/protecting-tracking-apps-in-the-post-coronavirus-world
# Protecting tracking apps in the post-coronavirus world
Our idea of normality has changed beyond recognition in a matter of weeks.
Across the globe, we’ve learned to stay indoors. We’ve transformed our dining rooms into offices. And we’ve accepted the need to sacrifice privacy to save lives.
There’s no doubt that the post-coronavirus landscape is going to take some getting used to. When we do venture outside again, it won’t be into the same world we left behind in the middle of March 2020.
For a start, there will be a lot more surveillance. Government apps will track our movement and our health to keep the virus at bay.
The idea of allowing our governments such power might be uncomfortable for some. But what if this power were to fall into more harmful hands?
Given the amount of citizen data on covid tracking apps, there's a danger bad actors will view them as the ultimate prize.
That’s why protecting tracking apps must be a crucial objective in the months ahead.
### A new era of surveillance
The Chinese state’s [measures to tackle the coronavirus pandemic](https://www.bbc.co.uk/news/av/world-asia-52104798/coronavirus-how-china-s-using-surveillance-to-tackle-outbreak) won’t have surprised many people. After all, they’ve built up a surveillance system over time. A lot of the pieces were already in place.
But people in countries less known for overt surveillance of its citizens have also accepted the need for such a system.
Crises tend to normalise policies that would ordinarily shock us. Not long ago, the announcement of a mass surveillance system would have led to people protesting in the streets. But our world has changed since then.
As Yuval Noah Harari [wrote recently](https://www.ft.com/content/19d90308-6858-11ea-a3c9-1fe6fedcca75), when people are given a choice between privacy and health, they tend to choose health.
In the UK, [the NHS is currently working on an app](https://www.wired.co.uk/article/nhs-coronavirus-tracking-app) designed to track people’s movement and how long they stay outside. There’s also talk of the app playing a role in the anticipated immunity passports for those who have already recovered from the virus or have been vaccinated.
There’s an acceptance that apps like the NHS one might be helpful. That said, people want to know whether governments will stop the surveillance once the crisis is over. There are plenty of examples of other temporary measures put in place during a crisis that remain in place decades later.
Yet there’s another equally important question that people aren’t asking quite as much.
Will these new tracking apps be safe and secure from outside attacks?
### The threats facing tracking apps
It might be the case that citizens simply expect robust security of surveillance apps to be a given. But examples from Asia suggest that we need to stay vigilant.
As much as we’d like to think that everybody buys into the communal spirit of working together to beat the virus, there are those who are looking to profit from it. For bad actors, a government app full of sensitive personal data sounds almost too good to be true.
To get an idea of the opportunity offered them, we only have to look at privacy leaks from tracking apps in China and South Korea. In both countries, some personal details of those who have tested positive for Covid-19 have accidentally been exposed. The consequence for those individuals has included [public ridicule and harassment](https://www.bloomberg.com/news/articles/2020-04-06/coronavirus-surveillance-helps-but-the-programs-are-hard-to-stop).
Imagine if a bad actor obtained a list of those who had tested positive. What damage could they cause to those people’s lives?
Analysts have suggested other apps are at risk, too. One example is Slovakia’s track and trace app. The country announced a few weeks ago that they’d passed a law [allowing the state to use data from telecoms companies](https://www.ft.com/content/64539a44-6e87-11ea-89df-41bea055720b) to track the movement of people suffering from the virus.
We already know from the world of IoT that bad actors can cause a company or individual a lot of harm [if they’re able to find a weak link in a network](https://licelus.com/insights/why-striking-a-balance-between-speed-and-security-is-key-to-iot-success). But the same is true of a tracking app. If an app is used by millions of people across a variety of devices and networks, then there’s a greater risk of hackers finding a weak spot. A gate somewhere that hasn’t been locked.
In China, there’s an app that doubles as an immunity passport. A green code means that you don’t have Covid-19 or that you’ve recovered from it. A red one means that you’ve tested positive for the virus. If you have a red code, your movement is severely restricted. But citizens in Hangzhou have reported their codes [flickering from green to red](https://www.ft.com/content/760142e6-740e-11ea-95fe-fcd274e920ca) and back again without an explanation.
If a hacker was able to take control of this system, they'd have the power to change a green code red, or vice versa.
### By protecting tracking apps you can build trust
Some commentators [have pointed out](https://www.forbes.com/sites/zakdoffman/2020/03/30/forget-chinas-excessive-coronavirus-surveillance-this-is-americas-surprising-alternative/#6216983f7773) that there’s an awkward truth behind our opposition to tracking apps:
We often let companies track our movement when we download their apps. So why not governments?
Most of the time there’s no need for these companies to know where we are. Instead, they use this information for marketing. And because we want the app, we mostly accept it without complaint.
Surely then there’s no problem in letting our governments have this data if it’s going to save lives rather than make money?
The key difference here is that we’re generally more sceptical about those who govern us. They have to work harder to gain our trust.
Governments around the world will be aware of the tightrope they’re walking with these new surveillance apps.
As much as people accept there’s a need for them right now, they will be vocal if they think the government is abusing its power.
And voices will grow louder still if the apps citizens are using don’t seem safe.
It explains why governments don’t only want to block bad actors for national security reasons. They also know how quickly public trust will evaporate should hackers find a way inside their apps.
That’s why robust protection for tracking apps is a must - while also keeping them as transparent as possible. We have to make sure that they’re safe from static and dynamic analysis, cloning (we’ll cover fake covid-19 apps [in a later article](https://licelus.com/insights/the-risks-that-threaten-the-success-of-track-and-trace-apps)), code injections, and [man-in-the-middle attacks](https://licelus.com/insights/how-to-counter-man-in-the-middle-attacks).
Then we can focus on using them safely to help beat the virus, without having to look over our shoulder for a very different kind of threat.
### Why it's so important that we protect the connected car
URL: https://licelus.com/insights/why-its-so-important-that-we-protect-the-connected-car
# Why it's so important that we protect the connected car
Sometimes the excitement around a new technology can blind us. Like a kid dreaming about riding her new bike, we often rush outside without first grabbing our crash helmet.
The buzz around the connected car is a pretty good example. And it’s little surprise we’re so eager to embrace the technology. We know that connecting our car to our smartphone can lead to much greater comfort and convenience.
But are we rushing into things without making sure we’re protected first?
Some analysts think that our eagerness to connect our cars to the internet might be to the detriment of safety and security. After all, we’re not the only ones who are happy with this trend. [Hackers are, too](https://licelus.com/insights/why-we-need-to-understand-the-hacker). They see enticing opportunities in this space the same way we do.
That’s why it might be worth us pausing and taking a step back. We can still enjoy all the comforts that come from the connected car. But after we’ve first secured the communication channels and client-car interaction methods.
### The connected car
The connected car is fast becoming simply “the car”. It’s not a novelty anymore.
We’re connected at home, in the office, and as we walk around our towns and cities. So why not in our cars, too? As creatures of convenience and comfort, we expect to have access to the same instant information on the road that we enjoy at home.
These days you can heat up your car before you pour your morning cup of coffee. You can listen to your favourite podcast on Spotify while you drive to the office.
Such is the demand for technology like this, that [Business Insider](https://www.businessinsider.com/iot-connected-smart-cars?r=US&IR=T) expects the shipment of connected cars to increase from 33 million in 2017 to more than 77 million by 2025. Between 2020 and 2021 alone, the value of connected car commerce in the US is set to increase by $2.5 billion.
If these figures are impressive, then so too are the numbers within the car itself. The average car today comes with around [100 million lines of code](https://www.mckinsey.com/industries/automotive-and-assembly/our-insights/the-race-for-cybersecurity-protecting-the-connected-car-in-the-era-of-new-regulation). That’s about four times as much as a modern fighter jet.
And in ten years, the car is expected to have 300 million lines of code. The more lines there are, the more convenience we enjoy. But the danger is that all this data being transferred is unprotected.
To what extent is the car manufacturer actually in control?
Are they ready right now to create secure communication channels and secure client-car connections?
There’s concern among some analysts that the connected car is just one more example of [security being sacrificed in favor of convenience](https://licelus.com/insights/the-delicate-balance-between-personalization-and-security).
### The hacker’s head start
This status quo could be a big problem for the industry as a whole. Not least because the balance of power is currently swaying in favour of bad actors.
Provided they have the right skills and tools, hackers can attack your car with limited investment and effort. And because the focus in the manufacturing industry has historically been on safety rather than digital security, bad actors have enjoyed a bit of a head start.
A hacker can carry out a dynamic analysis on the app you use to control your car. And if they’re successful, they can re-engineer that app. Then it's possible they could track your car, unlock it, and steal it.
But there are other types of attacks, too.
Earlier this year, it emerged that [a Tesla car had been tricked](https://www.technologyreview.com/s/615244/hackers-can-trick-a-tesla-into-accelerating-by-50-miles-per-hour/) into accelerating by 50 mph after someone added a sticker to a road sign that made 35mph look like 85mph to its built-in camera. And [Wired reported](https://www.wired.com/story/hackers-can-clone-millions-of-toyota-hyundai-kia-keys/) that hackers were able to clone millions of Toyota, Hyundai and Kia keys by cracking the cryptography within them.
Car manufacturers are also vulnerable to attacks when their cars are in diagnostic or repair centers. After all, the cars contain a lot of valuable logic and intellectual property that they don’t want in the wrong hands.
Attacks are evolving all the time. Hackers have recently taken to posting adverts on the dark web for real user account details gleaned from connected car apps.
Manufacturers aren’t blind to these threats. They’re just not used to confronting them. But the signs are that awareness is increasing of a need to act, particularly with regulations due to come into force in the coming months.
### Let’s secure the connections we’re making
One such regulation is the World Forum for Harmonization of Vehicle Regulations under the United Nations Economic Commission for Europe (UNECE). [Its software updates will affect more than 60 countries](https://www.mckinsey.com/industries/automotive-and-assembly/our-insights/the-race-for-cybersecurity-protecting-the-connected-car-in-the-era-of-new-regulation).
This means that car manufacturers will soon be obliged to include robust protection in their connected car apps.
Some are already blocking bad actors, of course. But regulations like this one will help to make sure there’s a consistency in approach across the industry. It will convince manufacturers to protect the code within their apps and to secure the communication channels between that app and the server.
After all, protection doesn’t only benefit the end user. An attack on a large scale could also badly damage a manufacturer’s reputation.
Particularly at a time when customers will come to expect protection from hackers as part of the service.
It feels like we’re at a bit of a crossroads moment in the evolution of the car. Most of what we can glimpse over the horizon is positive. The car is about to become much more than a vehicle for movement, taking us from one place to the next. It’s about to become an extension of our homes, too.
But because of these changes, the car is going to need protection against a different kind of threat. One that the automotive industry isn’t used to.
We should still be excited about the possibilities that come from rushing outside into this new world.
Let’s just make sure we take our crash helmets with us.
### Why striking a balance between speed and security is key to IoT success
URL: https://licelus.com/insights/why-striking-a-balance-between-speed-and-security-is-key-to-iot-success
# Why striking a balance between speed and security is key to IoT success
Have you heard the story about the hackers who used a fish tank to steal data from a casino?
It sounds too incredible to be true. [But it happened](https://www.washingtonpost.com/news/innovations/wp/2017/07/21/how-a-fish-tank-helped-hack-a-casino/).
Bad actors used the tank - which was connected to the internet - as a way into the wider network of the casino in North America. And from there they were able to access data from other, more valuable devices.
This story is a perfect illustration of the dangers facing businesses and end users embracing IoT. It shows that it’s easy to forget to protect devices that don’t appear to have much value to bad actors. Especially if your focus is on getting it up and running quickly.
But those who threaten your data rarely target one single device. Instead they’re looking for a weak link. A way in. As [this video explains](https://www.youtube.com/watch?v=B8DjTcANBx0&feature=youtu.be&t=797) (watch from 13:15), it’s possible for a bad actor to break into a security camera at an office or facility. And once they’re root with that camera, they can more often than not access the wider internal network. They can use the camera as a base for other attacks.
That’s why it’s so important to secure all the connected devices and sensors that form part of the network. That could be your smart home or office. It could be a power plant, or a hospital.
Or it could be a whole city.
When you find a balance between speed and security, you can enjoy the positive benefits that come from an interconnected network of devices, without worrying about attacks.
### Adding gates to the city walls
For a long time the buzz around IoT lacked substance. Devices sometimes seemed a little gimmicky. After all, just how useful is an internet-connected fish tank?
But things have changed.
Take a look around the office or living room that you’re sat in right now. Chances are you’ll be able to spot a variety of helpful devices that are linked to the internet - and to one another. For example, as I write this my phone is sat alongside my laptop. The smart watch on my wrist has just reminded me about the call I have scheduled an hour from now. And across the room, Alexa is ready to take my requests to shift to a different Spotify playlist.
The list of connected devices is growing all the time.
Some objects that you wouldn’t expect are now logging and sharing valuable data. The vending machine in your office, for example. Or the lampposts on your street.
[Gartner predicts](https://www.gartner.com/en/newsroom/press-releases/2019-08-29-gartner-says-5-8-billion-enterprise-and-automotive-io) that the IoT market will grow to 5.8 billion endpoints in 2020. A rise of 21% from 2019. And this growth is only going to speed up once 5G is in place. The new mobile technology means that single-use devices [will be able to carry out digitally automated services](https://www.forbes.com/sites/forbestechcouncil/2019/11/18/the-5g-iot-revolution-is-coming-heres-what-to-expect/#3811a24d6abf).
This combination of 5G and IoT [has the potential to enable smarter cities](https://licelus.com/insights/the-iot-landscape-in-2020-and-the-need-to-keep-our-connected-devices-secure). Thousands of otherwise ignorable objects will send updates and measurements about what’s happening around them. Much like ants sending messages along the line and back to the nest.
In theory, this data will make our commute easier. We’ll know ahead of time when infrastructure needs to be repaired and replaced. It will make living in busy cities less stressful.
But there’s a problem. The more objects we connect to the internet, the more gates we’re adding to the city walls. And all it takes is one unprotected fish tank or security camera for one of those gates to be prized open.
### The danger of delaying security
There are parallels between IoT and [the connected car](https://licelus.com/insights/why-its-so-important-that-we-protect-the-connected-car). We’re so keen to make as many connections as possible that the need for protection is ignored. Or at least put off for a while.
In a recent [Verizon report](https://enterprise.verizon.com/en-gb/resources/reports/mobile-security-index/) on mobile security in the US, two fifths of respondents admitted they’d sacrificed IoT security to “get the job done”. Getting products to market quickly and making sure you protect them don’t always go hand in hand.
But here’s the thing. The group in the Verizon report who had sacrificed security were almost twice as likely to have suffered an attack against an IoT device. That’s why striking a balance between speed and security is so important to IoT success.
After all, bad actors can be creative in their attempts to glean valuable data. Hacking a casino’s fish tank isn’t the only outlandish story that has circulated in the press. There have been others about [hacked dolls and teddy bears](https://www.bbc.co.uk/news/world-europe-39002142) gathering personal information from unsuspecting children.
More typically, IoT devices exist to record data on our daily habits, or to collect information on the things that surround us. Switches, lamps, motors and power outlets have become data-sharing sensors.
But this novel habit of recording everything can invite risks, too. Bad actors can get a pretty good picture of our movements if they manage to hack one of these devices.
After all, many of them store valuable information in plain text. So, if hackers can access the cryptographic keys within your IoT device, then your passwords or even your credit card details are also within their grasp.
### Cryptography keeps the key secure
It’s understandable for people to overlook - or even be ignorant about - security measures in their own home. But companies have less leeway for being lax because they’re often responsible for their customer’s data - and even their welfare - too.
Right now, though, a lot of businesses aren’t protecting the code within their IoT devices. In the same [Verizon report](https://enterprise.verizon.com/en-gb/resources/reports/mobile-security-index/) I mentioned earlier, the vast majority of respondents thought their data was valuable. But less than half said they encrypted all IoT data sent across public networks.
This will likely change in the coming months and years. Attacks other companies have suffered - and the struggle to rebuild their reputation - have shone a light.
Businesses are beginning to realise that a device they see as unimportant could be attractive to a hacker.
And more importantly, they now see that their network of connected devices is only as strong as the weakest link within it.
If you’re concerned that there might be a door ajar in your network, then robust cryptography is the best way to seal it shut. Protection measures hide the sensitive code within your devices and wider network. They prevent bad actors from gaining a foothold.
It’s the best way to make sure that our network of useful devices continues to work for us rather than for bad actors.
Code protection, cryptography, integrity control and communication hardening are key tools to achieve this. They help us to restore some of the balance in IoT between speed and security.
## Track and Trace Risks
[All insights](https://licelus.com/insights)
### Follow us
17 Jun 2020
### The risks that threaten the success of track and trace apps
URL: https://licelus.com/insights/the-risks-that-threaten-the-success-of-track-and-trace-apps
# The risks that threaten the success of track and trace apps
More than two months on from the start of the lockdown, there are signs of strain. As spring turns to summer and the heat begins to rise, thoughts have turned to going back outside.
Governments also want people to reclaim some small semblance of their former lives. Not least to get the economy moving again. But they, like individual citizens, know that the balance has to be right. The next phase of the pandemic has to be managed carefully to avoid another spike in the level of infection.
Many analysts see track and trace apps as a key component in achieving this goal. Politicians across the globe are putting their faith in them. But for these apps to work well, citizens also have to trust them.
Winning this trust could come to define the next stage of the pandemic. Because amidst a lingering air of uncertainty, [a different kind of threat is lurking](https://licelus.com/insights/why-we-need-to-understand-the-hacker).
This one looks to exploit the security weaknesses of the track and trace apps that promise to bring us one step closer to the life we knew before.
### Welcome to phase two
We spend so much time on our phones already that using them to navigate our way out of the pandemic makes quite a lot of sense when you think about it. Sure, we’ll have to make some privacy sacrifices along the way. But we already do that with all the other apps we use. Right?
Well, like we said [in our previous piece on track and trace apps](https://licelus.com/insights/protecting-tracking-apps-in-the-post-coronavirus-world), governments have to work a bit harder to earn our trust. Rightly or wrongly, we’re often more sceptical about their intentions.
[As David Mattin says](https://newworldsamehumans.substack.com/p/new-world-same-humans-17), we accept the privacy trade-offs that brands promise us and have done for years.
Instagram distracts and entertains us. Amazon offers us convenience. The privacy trade-offs from governments around the world tends to be a tougher sell.
Their pitch to get you to download their track and trace apps goes something like this:
Sacrifice a little bit of your privacy so we can regain some of the freedoms we’ve lost.
How much privacy do you have to sacrifice? Well, that seems to depend on the system governments choose for their track and trace apps. In an interesting - if not slightly unsettling - development, Google and Facebook are dictating the terms. They’re telling governments how their apps should work. The tech giants’ preference is for a decentralized model. And one of the reasons for that is the theory that [it makes it harder for hackers to track individual users](https://www.bbc.co.uk/news/explainers-52442754).
But not every government agrees. Take the UK, for example. NHSX, who are building the UK’s track and trace apps, favor a more centralized model.
With this strategy, anonymized data for those who declare virus symptoms would be sent back to a central database. There’s no such database under the Google-Facebook model. But by having one, the UK government feels it would be able to keep [some measure of control](https://www.wired.co.uk/article/nhs-covid-19-tracking-app-contact-tracing) over its own app and data.
The UK approach does worry some analysts, though. They think such a system might lead to other surveillance measures being added over time. But while it’s true that a central database might make incursions by bad actors more likely, there’s potential for harmful attacks with both models.
This risk is heightened by the current climate of uncertainty. People are more trusting right now. And that means they’re [more likely to open an email or SMS message](https://licelus.com/insights/why-our-emotions-make-us-more-vulnerable-to-cyber-attacks) they think is from an authoritative source.
But what if that message isn’t from who they think it is?
### The threats facing covid-19 track and trace apps
The last few months have seen people relying on government guidance more than at any other time this century.
Bad actors are aware of this reality. They know that people are vulnerable at the moment. They know that many are desperate to return to how things were a few months ago.
And this knowledge has given them an opportunity. Earlier on in the pandemic, Google reported that they were [blocking 18 million phishing emails each day](https://www.bbc.co.uk/news/technology-52319093) related to Covid-19.
When track and trace apps are released across the globe, people will be invited to download them. But Google’s revelation about the growth in phishing emails hints at a potential problem. What if people receive a fake email from bad actors pretending to be a legitimate government body?
Phishing emails and texts are pretty sophisticated these days. Even in normal times it can often be difficult for people to tell the difference between the real deal and a fake. Never mind when people are already more anxious than usual.
In a phishing email related to a covid-19 tracking app, the recipient would be presented with a web page asking them for their personal details. More details than they’d need to provide for the actual app. Bad actors then collect this sensitive information and can use it for another attack in the future.
Hackers might also try to release fake track and trace apps in the hope that people download them by mistake. They would include a link to download them in the aforementioned bogus email or text message.
Simon Chandler, [writing in Forbes](https://www.forbes.com/sites/simonchandler/2020/05/08/nhs-contact-tracing-app-will-cause-flood-of-phishing-attacks-experts-warn/#4ba4a86261d5), is one of many analysts predicting that SMS could become the go-to attack vector for bad actors. SMS phishing, or smishing, is on the rise. People are more trusting of messages that arrive at their phone, after all. So they’re more likely to open them.
There are also concerns about the potential dangers of using bluetooth as the main measurement gauge for track and trace apps. That’s because signals can be hijacked by hackers carrying out [man-in-the middle attacks](https://licelus.com/insights/how-to-counter-man-in-the-middle-attacks).
But not all the threats facing covid-19 track and trace apps target end user data. As we’ve said before, some hackers just want to add to the chaos by tampering with the apps. That could be changing someone’s status from green to red on China’s colour coded app. Or it could be a so-called “drive by” attack. That’s where someone beacons out as an infected person, forcing those they come into contact with to self isolate.
Analysts are reporting that for the apps to work, around 60% of the population will need to download them. But if attacks like the ones we’ve listed above were to happen, there would be a negative impact on people wanting to download them.
So, what can we do to reduce the risks?
### Physical and digital vigilance
Most people are about as vigilant as they’ve ever been right now. They’re washing their hands more. They’re keeping their distance from others. They’re wearing face masks.
But people often let their guard down when they’re using their phones because it's a device they associate with their friends and family.
It might be that to keep bad actors at bay, people will have to become equally vigilant in digital spaces from now on as they are being in physical ones.
In defence of those designing and creating the track and trace apps, many are being as transparent as possible. Ian Levy, the Technical Director at the National CyberSecurity Center is leading the creation of the UK’s app. And as part of his role, he has been sharing updates and learnings as part of a regular blog.
He’s even acknowledged some weaknesses and risks [in a recent post](https://www.ncsc.gov.uk/blog-post/nhs-covid-19-app-security-two-weeks-on). This level of transparency will help to keep citizens as informed as possible in the next few months. It will also help to [build trust with them](https://licelus.com/insights/how-in-app-protection-can-help-you-to-build-trust).
But could government transparency go even further?
[The Australian Federal Government is considering releasing the source code](https://theconversation.com/covidsafe-tracking-app-reviewed-the-government-delivers-on-data-security-but-other-issues-remain-137249) of its track and trace app. Releasing the source code builds trust too as people can check there’s no added surveillance that doesn’t need to be there. And it also involves citizens in the process by asking them to help improve the app over time.
Finally, governments need to make sure that the apps themselves come with robust protection. One of the weaknesses noted by Levy in his blog was related to encryption. He admitted there was a chance a bad actor could break in and access the proximity log data.
The UK app that is being tested on the Isle of Wight is a beta version. And as such the hope is that issues like this will be ironed out before a nationwide rollout. But governments have to get the balance right. Sure, they want to get the app to the public as soon as possible, but first they have to make sure that bad actors can’t access the app’s sensitive code and logic.
There are many risks threatening the success of track and trace apps. That said, a combination of all of us being vigilant, governments being transparent, and robust app protection being implemented can stop these risks.
Then we’ll all be in a better position to get closer to the life we left behind back in March.
## Security vs Usability
[All insights](https://licelus.com/insights)
### Follow us
12 Sep 2023
### Balancing security and usability
URL: https://licelus.com/insights/balancing-security-and-usability
# Balancing security and usability
As we integrate apps more deeply into our everyday lives, the need for robust security measures surges.
It’s ironic, but **the very security that aims to protect users can, at times, diminish user experience** (and security itself). Take the example of new security policies being introduced to the system that force users to create long passwords containing special characters and numbers. Imagine if users are encouraged to rotate their passwords regularly and are asked to enter them every couple of days. In this scenario users might save them in an unprotected note-taking app so they can reach for them quickly.
This scenario begs an important question for developers: How does one go about **[balancing security and usability](https://licelus.com/resources/security-by-design/there-s-a-fine-balance-between-security-and-usability)**? It's certainly a tricky task when you consider that leaning too far in either direction could result in loss of user trust or a potential security breach.
In this article, we’ll explore this delicate balancing act. And we’ll share some strategies employed by successful mobile apps that have seamlessly integrated top-tier security without compromising on user experience.
### Understanding the trade-off between security and usability
In the sprawling matrix of the digital realm, two architects, **Security and Usability**, are at the drafting table. Security, with its blueprints of cryptographic algorithms, firewalls, and intrusion detection systems, is the guardian of the digital domain. Usability, on the other hand, sketches fluid user interfaces, intuitive navigation patterns, and adaptive user feedback loops, ensuring that every digital traveler feels welcome.
Imagine Security's design: a structure with SSL/TLS protocols reinforcing its entryways, end-to-end encryption shielding its chambers, and regular penetration testing to ensure no cracks appear in the foundations. Each additional layer, such as OAuth for authentication or HMAC for data integrity, is like another moat or drawbridge.
It is all meticulously planned to keep malicious entities away from the castle walls.
And yet Usability, the advocate for the user, worries. With each added security layer, like 256-bit encryption or the periodic need for CAPTCHA validations, the journey inside those walls becomes less straightforward. Inhabitants find locked doors all around them, halted by the intricate demands of two-factor authentication. They find themselves daunted by frequent mandatory password updates that demand a mix of characters, symbols, and numbers.
Consider the landscape of a banking application. Fortified digital citadels, they safeguard not only monetary assets but vast amounts of personal data. Here, Security integrates technologies like tokenization to ensure that every transaction is both authenticated and masked from potential eavesdroppers. Biometric scans, each using intricate algorithms, allow users to validate their identity using just a fingerprint or a quick glance at a screen.
There’s no doubt these are all important measures. But it’s also true that they might lead to a complicated user experience of entering the password, typing the OTP from an SMS, taking a selfie and then entering a long passphrase only to make a submission for a small loan.
Social media platforms, designed as vast digital plazas, prioritize seamless interaction. Their OAuth integrations allow for quick sign-ins via linked accounts. They employ adaptive UI/UX designs, ensuring users from diverse digital backgrounds feel at home. And yet because of this very adaptability, and without robust session management or secure APIs, vulnerabilities might lurk in the shadows.
The shifting scales between the technical depth of Security and the user-centric designs of Usability form the cornerstone of all mobile app development. There’s a constant tension between marrying RSA encryption with intuitive design. Of ensuring that behind every easy swipe, there's a secure and robust protocol in play.
### The principles of security and usability
In the delicate ecosystem of mobile applications, the balance between security and usability often determines an app's success and user retention. To strike the right chord, **it's essential to intertwine cutting-edge security protocols with user-centric design principles**.
The **Transparency** principle is a good example. In security, this isn't just about a general declaration. It involves practices such as showcasing encryption standards (like AES-256 bit encryption for data at rest) and protocols like OAuth for secure third-party integrations. Usability translates this transparency into clear notifications about permissions - perhaps explaining why an app needs access to a user’s location or contacts - as well as ensuring GDPR compliance and fostering user trust.
The ever-relevant principle of **Simplicity** is another example. From a security point of view, simplicity may involve the implementation of a single sign-on (SSO) using secure token services or biometric logins leveraging hardware-backed keystores. The usability angle, on the other hand, focuses on creating intuitive UI/UX, possibly by utilizing mobile-specific design frameworks like Google's Material Design or Apple's Human Interface Guidelines.
Then there’s the fluid principle of **Adaptive Design**. In the realm of security, this encompasses risk-based authentication. We’re talking here about the utilization of machine learning algorithms to identify and adapt to suspicious patterns or unfamiliar login locations, prompting additional verification layers like time-based one-time passwords (TOTPs). From the perspective of usability, it’s more about ensuring that apps function seamlessly across various devices and screen resolutions, perhaps using frameworks like React Native or Flutter for cross-platform consistency.
A central pillar, **User Education**, shapes the next phase. Mobile security often introduces novel concepts like end-to-end encryption, zero-knowledge proofs, or sandboxing. Educating users about these - perhaps via in-app tooltips or short animations - can foster appreciation and compliance. At the same time, usability is about making sure that these educational snippets are unobtrusive and intuitive. This can be achieved by using adaptive UI elements and possibly leveraging mobile OS features like Apple's \"Callout\" or Android's \"Snackbar\" for guidance.
When it comes to **Layered Defense with Choice**, security principles include introducing multi-factor authentication, giving users the option between SMS-based codes, app-generated tokens, or hardware tokens like YubiKeys. Usability can complement this by offering customizable security settings, each neatly integrated within the app's settings, allowing users to tailor their security experience.
Finally, there’s the principle of **Consistency**. Security considerations demand the consistent implementation of protocols, whether that’s employing HTTPS across all external connections or maintaining uniform encryption standards. Usability, on the other hand, is concerned with making sure this consistency translates smoothly to the end-user. Options include using mobile app design patterns, frequent UI testing, and maintaining a consistent color palette and typography.
In essence, the future of mobile applications hinges on these two keeping in step with one another. Balancing security and usability might seem like a complicated dance, but by diving into the technical nuances while keeping the user's journey in focus, developers and designers can craft experiences that are both secure and inviting.
### Strategies for balancing security and usability
Achieving an equilibrium between security and usability is akin to threading a needle; it requires precision, insight, and an understanding of both technical intricacies and user psychology.
Here's how mobile developers and designers can best find that balance:
**You can start by implementing layered security measures**. Just as a fortress doesn’t rely on a single wall for defense, mobile applications should have multiple layers of security protocols. There are four advanced layers of protection that all developers should make sure their app can use to protect itself from sophisticated threats. [We’ve covered those in detail in our guide to mobile application protection](https://licelus.com/resources/guide-to-mobile-application-protection/principles/the-four-layers-of-mobile-application-protection).
But there are other user-focused layers to consider, too.
**Transport layer security, like HTTPS, encrypts data in transit**. Coupling this with data-at-rest encryption methods such as AES is always a good idea. As is integrating Intrusion Detection Systems (IDS) and Intrusion Prevention Systems (IPS) to ward off malicious attempts. Session-based tokens can also be used to make sure that time-limited sessions deter unauthorized access.
The idea with these user-focused layers is that even if users bypass or prefer not to engage with one layer (like not setting a passcode), other security measures will still guard the fortress. The key is to ensure these layers work silently in the background, not overwhelming the user with constant prompts.
Leveraging user behavior analytics can help you to understand how a typical user interacts with the app, meaning that anomalous behaviors can be swiftly detected and dealt with. This offers proactive security without hindering the standard user flow.
**[Integrating machine learning models](https://licelus.com/insights/zero-day-attack-prevention-via-enhanced-mobile-app-security) is another good idea**. These can help you to learn typical user patterns like login times, commonly accessed features, and typing speeds. When deviations occur - like logins from new locations or erratic typing patterns - the system can flag or challenge the activity, perhaps through additional authentication requirements.
Most users won’t even realize a security layer like this is in operation. It remains non-intrusive unless a potential threat is detected, at which point it offers necessary interventions, ensuring the user's peace of mind.
You should continue to **make use of biometric authentication methods**, too. They’re unique to each individual and, as such, they offer a robust security layer without the hassle of remembering complex passwords.
Modern mobile devices come equipped with fingerprint scanners, facial recognition systems, and even iris scanners. Developers can leverage native APIs, like Android's BiometricPrompt or Apple's FaceID and TouchID, to integrate these into the authentication process. But please resist the urge to [reinvent the wheel and create custom versions of these measures](https://licelus.com/insights/why-you-should-think-twice-about-creating-custom-security-solutions).
**The speed and ease of biometric systems enhances usability immensely**. A quick fingerprint scan or face recognition not only speeds up access but also feels more personal and futuristic to the user.
Another strategy worthy of consideration is to offer customization of security settings. **Empower users by allowing them to adjust the security settings to their comfort level**. While the application should have default settings that ensure robust protection, customization options cater to varied user preferences and risk tolerance.
Implement a modular approach to security settings within the app’s architecture. Allow users to toggle between different authentication methods, set the duration for automatic logouts, or even adjust the sensitivity of behavior analytics.
When you offer them a choice, users feel like they’re in control. They can set up their environment, knowing that they aren't being forced into a one-size-fits-all security protocol. This fosters a sense of ownership and enhances trust in the application and your business as a whole.
By weaving these strategies seamlessly into the fabric of mobile apps, developers and designers make sure they secure the digital treasures within the application while also opening up the drawbridge and welcoming those who are seeking access. The upshot of this is a harmonious blend of impenetrable security and unparalleled user experience.
### The role of transparency in balancing security and usability
In an age where data breaches and cyber threats frequently make headlines, users have become increasingly wary of how their data is handled. Transparency, then, is not merely an ethical standard but rather a powerful tool that can be used to shape user perceptions and interactions with mobile applications.
Being transparent about security protocols can build user trust
Modern mobile users aren't just concerned with how an application functions. They're also keenly interested in the 'why' and 'how' of security protocols. **When applications openly disclose their security measures, users perceive it as a sign of openness, responsibility and maturity**. This proactive approach dispels doubts and fosters a sense of reassurance and security.
Imagine an application uses AES-256 bit encryption for data protection. While many users might not understand the intricacies of this standard, being upfront about employing such high-grade encryption at the very least sends a signal that you’re committed to data security and you’re doing everything within your power to protect your end users from cyber threats. You might even explain that AES-256 offers far more possible combinations than, say, AES-128, underscoring your dedication to employing best-in-class security mechanisms.
Ways to communicate security measures to users effectively
Merely having robust security protocols isn't enough on its own. You also need to communicate these to users in a manner that's easily digestible and actionable.
Use the initial onboarding process to highlight key security features. Animated walkthroughs can simplify complex concepts like end-to-end encryption or multi-factor authentication.
Within the app, a dedicated 'Security' section can detail all the measures you have in place, from data encryption methods to session management protocols. This serves as a quick reference for users keen to understand the app's protective layers.
Convert technical jargon into engaging, interactive tutorials that the majority of your users will be able to understand. For instance, rather than merely stating that the app uses TLS 1.3 for secure connections, offer a visual representation of how data gets encrypted, transmitted, and decrypted, showcasing the secure channels in action.
Whenever a security protocol activates, such as when a suspicious login is detected or a password needs changing, guide users through the necessary steps. Explain the 'why' behind each action.
Allow users to ask questions or raise concerns about security features. Direct channels of communication, be it through in-app chat support or dedicated forums, can address queries and reinforce trust. Make it a two-way conversation so they feel involved.
In essence, the magic lies not just in deploying formidable security measures but in ensuring that users recognize, understand, and appreciate them. By championing transparency and effective communication, mobile apps can transform potential points of user apprehension into pillars of trust and confidence.
And remember it’s absolutely vital to explain to users how you plan to communicate with them [so that they have a better chance of spotting social engineering scams](https://licelus.com/insights/how-can-you-protect-yourself-from-social-engineering). [Bad actors](https://licelus.com/insights/how-bad-actors-deliver-mobile-malware-into-your-device) might contact your users pretending to be you in order to trick them into disclosing sensitive information.
### Case Studies: mobile apps excelling at both security and usability
Across the spectrum of mobile applications, some have set benchmarks by harmonizing robust security protocols with exemplary usability. Let's take a look at a few standout examples that highlight this synergy.
Signal's claim to fame is its end-to-end encryption, ensuring only the sender and receiver can read messages. It employs the Signal Protocol, renowned for its strong encryption capabilities. Despite its intricate encryption processes, Signal offers an interface similar to conventional messaging apps. It doesn’t burden users with technical jargon but it does provide optional insights for those who are interested.
Apple Pay utilizes a method called tokenization. Instead of transmitting credit card details, it sends a one-time code. And this makes sure that actual card information never gets revealed. Moreover, transactions require biometric verification, which adds an extra layer of security.
Making payments with Apple Pay is almost frictionless. Users simply double-click, authenticate, and hold their device near a reader. The process is intuitive, speedy, and offers visual feedback.
Okta is an authentication provider which leverages two-factor authentication (2FA) services. When logging into a platform integrated with Okta, users receive a push notification to confirm their identity, thereby adding a second layer of verification. The push-based authentication approach eliminates the need for manually inputting time-sensitive codes. Users receive a notification, tap to approve, and then proceed. It’s an almost instantaneous process, marrying security with convenience nicely.
ProtonMail offers encrypted email services. Emails are encrypted at the sender's side and decrypted at the receiver's end, ensuring data in transit remains private. Even ProtonMail themselves cannot access user emails due to this encryption.ProtonMail’s interface is sleek and resembles familiar email platforms. Advanced features like setting message expiration or sending password-protected emails are integrated smoothly without cluttering the user experience.
These case studies show us that with astute planning and user-centric design, mobile applications can offer fortified security without compromising on user experience. Each of these apps addresses a unique challenge and serves as a testament to the potential of combining technical prowess with intuitive design.
### What future trends mean for mobile app security and usability
The confluence of security and usability in mobile applications is an ongoing journey, with emerging technologies and methodologies continuously reshaping the landscape.
**Quantum Computing and Cryptography**
The dawn of quantum computers is on the horizon, bringing forth both challenges and opportunities. Quantum computers have the potential to break many current encryption methods. However, they also usher in the age of quantum cryptography, promising even more secure methods of encrypting data. Mobile apps will eventually need to adapt to this paradigm shift.
**Decentralized Systems and Blockchain**
With the increasing acceptance of decentralized systems and blockchain technology, mobile apps can capitalize on its innate security features. For example, decentralized identity solutions can provide users control over their personal data, ensuring security without compromising usability.
**Zero Trust Architectures**
The traditional 'trust but verify' model is making way for a 'never trust, always verify' approach. Zero Trust architectures, which necessitate every request to be authenticated and validated, can be adapted for mobile apps to ensure enhanced security while optimizing the user's interaction at the same time.
### How the integration of AI and machine learning can help you to achieve the right balance
AI can sift through vast amounts of data at lightning speed, detecting patterns that may signify a security threat. For mobile apps, this means proactive security measures that detect and mitigate threats before they manifest, without the user even realizing it.
**Adaptive authentication**
Machine learning algorithms can study a user's behavior, such as typical login times, geolocation, and even typing patterns. By understanding what 'normal' behavior looks like, the system can challenge or prompt users only when anomalies occur. This offers a nice blend of security and unobtrusive user experience.
**Natural language processing for user queries**
NLP can be integrated into apps to allow users to voice their security or usability concerns. Imagine a scenario where a user could simply ask, \"Is my data encrypted?\" and the app provides an immediate, comprehensible response, bridging the knowledge gap and fostering trust.
**Personalized user experiences**
With machine learning, apps can tailor the user experience based on individual preferences and behaviors. If a particular security feature or prompt is often bypassed or ignored by a user, the app can adjust its interactions, ensuring essential security while optimizing the user journey.
The horizon of mobile app security and usability is vibrant, with innovations poised to redefine how we perceive this delicate balance. While challenges are inevitable, so are the solutions. As AI and emerging technologies become integral to mobile apps, the waltz between security and usability is set to become more synchronized, sophisticated, and user-centric.
Our hope is that the strategies, principles, and case studies above have convinced you that the relationship between security and usability need not resemble some kind of tug of war. Rather than being opposing forces, security and usability can - and should - coexist harmoniously. They should complement one another.
The most compelling mobile applications today aren't just those fortified with layers of impenetrable security measures. They are the ones where these protective layers are seamlessly woven into the fabric of the user experience. Such apps understand that every security protocol, no matter how robust, is rendered useless if it alienates the very users it seeks to protect.
But achieving this balance is no mere stroke of luck. It requires a form of choreography. It needs insights into user behavior, a deep understanding of technical nuances and, above all, a commitment to transparency and user empowerment.
As developers, designers, and stakeholders in the mobile app industry, our challenge is to continually push boundaries. To innovate and iterate, making sure that as technology advances, so too does our approach to balancing security and usability.
By championing this symbiotic relationship, you’re not just building apps. You’re sculpting trusted, user-centric digital experiences that will stand the test of time.
Read more about [the four advanced layers of protection](https://licelus.com/resources/guide-to-mobile-application-protection/principles/the-four-layers-of-mobile-application-protection) all apps need to protect themselves from sophisticated threats.
### Our latest articles
[View all](https://licelus.com/insights)
- [
**How to incorporate mobile app security testing into your build pipeline**
#Security by design](https://licelus.com/insights/how-to-incorporate-mobile-app-security-testing-into-your-build-pipeline)
- [
**Ongoing Security: a step-by-step guide to a secure app development process**
#Security by design](https://licelus.com/insights/ongoing-security-a-step-by-step-guide-to-a-secure-app-development-process)
- [
**9 App Security Best Practices Developers Should Follow**
#Security by design](https://licelus.com/insights/9-app-security-best-practices-developers-should-follow)
## Counter Man-in-the-Middle
[All insights](https://licelus.com/insights)
### Follow us
08 Jul 2020
### How to counter man-in-the-middle attacks
URL: https://licelus.com/insights/how-to-counter-man-in-the-middle-attacks
# How to counter man-in-the-middle attacks
In the anxious years after the English Civil War, paranoia reigned.
As part of Oliver Cromwell’s strategy to protect his power, [he encouraged his agents to intercept letters and packages](https://theconversation.com/britains-obsession-with-secrecy-goes-back-to-the-tudors-and-stuarts-and-is-still-at-work-today-66601). After they had gleaned the secrets within, they would send the mail on its way to the original recipient.
Technology has changed in the years since Cromwell’s espionage team carried out their dark arts. But the fundamentals of man-in-the-middle attacks remain the same today. The main difference is that these days it isn’t only governments that have the ability to steal secrets. And the pool of potential victims has become a lot larger.
In the first in a series of articles about specific threats to your security, we’re taking a closer look at man-in-the-middle attacks.
So, read on to find out how they work, what bad actors are trying to achieve, and how you can counter them.
### What are man-in-the-middle attacks?
As was the case in the time of the Tudors and the Stuarts, man-in-the-middle attacks today are all about intercepting a line of communication. A bad actor could decide to just read the information, or they could change it first and then send it on. But either way, the final recipient would be none the wiser.
Some of the most common man-in-the-middle attacks are those that take place over public wifi networks. That’s because intercepting this line of communication is relatively easy. After all, [neither the router nor your connected device has to verify its identity](https://www.techrepublic.com/article/man-in-the-middle-attacks-a-cheat-sheet/). This is more of an issue [now that remote working is more common](https://licelus.com/insights/mobile-security-in-a-zero-trust-world).
For this kind of attack, the bad actor would have to also be on the network, or be nearby. But for many man-in-the-middle attacks, proximity isn’t necessary.
Another defining feature is the bad actor using their own server to communicate with an application.
Let’s use the example of a banking app. When a customer uses that app, they’re communicating with the bank’s server. But bad actors use various techniques to make the app think it should communicate with their server instead of the bank’s IP address.
If the app in question doesn’t have any countermeasures against faking a server certificate, it could be in danger. Because once the app is connected to the bad actor’s server, then [that server can send data as a proxy to the bank’s server](https://owasp.org/www-community/attacks/Man-in-the-middle_attack). And it can even change information such as account numbers.
So, the bad actor’s server pretends to be the bank’s server. Then it sends data back to the legitimate one. These messages are often signed with crypto keys, but it’s still easy to intercept credentials and sensitive data.
It's also worth adding here that man-in-the-middle attacks are sometimes used in tandem with phishing scams.
Going back to the banking app example, a bad actor could set up a server and make that banking app think it’s the real one. And instead of redirecting traffic to the real server, they would direct traffic to some separate pages. Once there, bad actors would ask for the customer’s personal information.
One way to glean this information would be to tell the customer that they need to confirm they are who they say they are.
### Who’s at risk from man-in-the-middle attacks?
In the example above, we spoke about banks and banking apps. [They’re an obvious target of man-in-the-middle attacks](https://licelus.com/insights/how-to-secure-a-safer-future-for-mobile-banking) because the motivation for bad actors is often financial.
As we’ve said, if a hacker is able to hijack a communication channel, they can intercept important personal information. Then they can make changes to account information. And they can profit illegally from transactions customers make.
But banks and their customers aren’t the only ones at risk.
As industries evolve, physical conversations become digital ones. Doctors and patients can now communicate via an app, for example. When they do, they share sensitive information with one another.
A bad actor might try to intercept this modern communication channel. If successful, they could do a lot of damage to the reputation of the individual or the health center in question.
IoT is also a common target of man-in-the-middle attacks. Cybercriminals are constantly probing for weaknesses in large networks of connected devices. All it takes is for [a door to be left ajar](https://licelus.com/insights/why-striking-a-balance-between-speed-and-security-is-key-to-iot-success) somewhere for them to find a way in.
For businesses with IoT systems, this is a real threat that has to be taken seriously. After all, successful attacks can cause a serious amount of downtime as well as the loss of proprietary information.
### How to defend against man-in-the-middle attacks
So, businesses and individuals have a lot to lose from man-in-the-middle attacks. How can they protect themselves and avoid the risks?
[Google’s Certificate Transparency project](http://www.certificate-transparency.org/) is helping to counter them. It fixes some of the structural flaws in the SSL certificate system - the main cryptographic system that underpins every HTTPS connection. And strengthening this helps to prevent interceptions by bad actors. Certificate Transparency also helps to detect SSL certificates that have been issued maliciously.
Some mobile banks we work with use Certificate Transparency to sure up their defence against man-in-the-middle attacks.
But they use it together with other layers of protection.
One crucial weapon against man-in-the-middle attacks is reinforced public key pinning implementation. This is important because it secures the SSL certificate pin. And that’s often the starting point for hackers looking to intercept your communication channels.
General vigilance is important, too. It’s a good idea to [be transparent with your customers](https://licelus.com/insights/how-in-app-protection-can-help-you-to-build-trust) about how you’ll communicate with them. That way they have a better chance of spotting suspicious emails or [SMS messages](https://licelus.com/insights/why-our-emotions-make-us-more-vulnerable-to-cyber-attacks) from bad actors that ask them to share their information on a separate web page.
All these actions combined can help you to counter man-in-the-middle attacks. By doing so you secure your customers’ data and your reputation at the same time.
### Our latest articles
[View all](https://licelus.com/insights)
- [
**What is a Trusted Application?**
#Threat protection](https://licelus.com/insights/what-is-a-trusted-application)
- [
**How malware spreads: investigating a dangerous infection across India**
#Threat protection](https://licelus.com/insights/malware-spread-india)
- [
**Why virtual trusted execution environments are set to boost mobile payment security**
#Threat protection](https://licelus.com/insights/why-virtual-trusted-execution-environments-are-set-to-boost-mobile-payment-security)
## IoT Security Insights
[All insights](https://licelus.com/insights)
### Follow us
13 Jul 2020
### The IoT landscape in 2020 and the need to keep our connected devices secure
URL: https://licelus.com/insights/the-iot-landscape-in-2020-and-the-need-to-keep-our-connected-devices-secure
# The IoT landscape in 2020 and the need to keep our connected devices secure
### Time travel
One of the great things about the internet is that it allows you to travel back in time.
Whenever you feel like, you can journey to a specific moment over the course of the last 25 years or so. Read an article from 2004, and it’s like you’re peering through a window into that world. If you squint a little, then you can just about gauge the mood on the other side.
What worried people back then? What did they see coming around the corner?
Sometimes you don’t even need to go that far back to find a completely different landscape.
Travel back six months from today and you’ll find a very strange world indeed. A world that existed before news websites and Twitter feeds first whispered rumours of a virus emerging from a market in Wuhan.
Some articles from the end of 2019 look a little naive from our vantage point in the post-covid-19 world. Reading them, you feel like a member of the audience in a theater, urging the next victim in a horror flick not to run upstairs.
But others haven’t aged as badly.
Here at Licel, we’ve been thinking and talking a lot about IoT recently. And because of that, we’ve done a bit of time travel ourselves. We’ve taken a look at some of the IoT trend pieces for 2020 that were written in the weeks leading up to Christmas last year.
As we read them, we realized something. In some ways, the impact of covid-19 has been to speed up IoT trends rather than render them meaningless.
So, we thought we’d reflect on the world of IoT halfway through 2020.
What impact has covid-19 had on IoT? And what lessons can we learn about keeping connected devices secure?
### Covid-19 and its impact on the Internet of Things
Before we’d even heard of the coronavirus, analysts were predicting that 2020 would be a big year for the connected home. Little did they know that we’d be spending quite so much time within our own four walls.
The fact that we are has been a bit of a boon for the growth of connected devices. There was already a trend toward [remote working](https://licelus.com/insights/mobile-security-in-a-zero-trust-world), of course. But the recent period of enforced isolation has the look of a “no going back” moment.
Let’s say we are able to get some way toward the life we knew in the next few months. Will we want it to be exactly how it was before?
Take the following example:
If you live in a big city like London or New York, then commuting for two hours or more each day might have felt fairly normal. But now you have those two hours for yourself.
You’ve got time to go for a run in the morning. You’re getting to spend more time with your kids. And you’ve seen that you can work just as well from home.
Telling you to go back to the old routine for a full five days each week might be a tough sell for your boss.
There are plenty of businesses that could profit from us spending more time at home, too. [Consumer IoT suppliers are re-focusing](https://www.computerweekly.com/news/252481286/Coronavirus-Home-business-opportunity-knocks-for-consumer-IoT-suppliers) on keeping us all connected, entertained and educated. Teleconferencing has been a defining feature of our covid-19 confinement. And Google and Amazon want to take advantage. They’re positioning their smart speakers as the perfect tool for anyone serious about turning their study into a mini office.
Indeed, [the rise of the smart speaker](https://www.thalesgroup.com/en/markets/digital-identity-and-security/iot/magazine/top-5-iot-predictions-2020) was being mooted as one of the key IoT trends for 2020, even before covid-19. Now - in a world where remote working is the norm - an all-in-one speaker and visual display that’s linked to other connected devices seems even more attractive.
Our new routines have changed the evolution of IoT in other ways, too. People are exercising more. Their home has become their gym. And during lockdown, many saw a run outside as an escape. All of this has been great news for producers of fitness wearables.
Sticking with exercise, [the growth in cycling](https://www.theguardian.com/world/2020/may/26/call-to-fast-track-bike-lanes-to-boost-jobs-and-take-advantage-of-lockdown-induced-bicycle-sales) has also got some people re-thinking what the smart city could look like. A lot has been written about the driverless car and its smart sensors contributing to how a city runs. But imagine if the growth in cycling (as a means to avoid public transport) results in smarter, greener cities in the coming years.
Whether your focus is inside or outside the home, there’s one constant that will power the growth of IoT in both settings - 5G.
### 5G and data as power
If you go back and read these end of year trend pieces about IoT in 2020, you’ll see 5G was at the top of almost every list.
[In one such list in Forbes](https://www.forbes.com/sites/danielnewman/2019/07/14/top-10-digital-transformation-trends-for-2020/#580fb32276be), Daniel Newman writes that “the true value of 5G won’t be limited to phones. Just about every industry that touches our daily lives will be transformed – for the better – by the technology evolution that will define 2020.”
5G is seen as being a key player in [transforming the smart city from a dream to reality](https://www.thalesgroup.com/en/markets/digital-identity-and-security/iot/magazine/top-5-iot-predictions-2020). That’s because its increased speed will enable connected environments to more or less run on their own. As they do so, they’ll be able to share valuable data. And that will allow machine learning tools to learn and improve, making cities more efficient.
This increased speed means there’s room for even more devices. More devices means [more business opportunities](https://www.bbvaopenmind.com/en/technology/digital-world/ten-trends-of-internet-of-things-2020/).
So, even more apps will be created in the coming years to profit from this new landscape.
Network providers could be forgiven for switching their attention elsewhere in recent months. But there are signs that they’re more keen than ever to put 5G technology in place. One reason for this is the demand that’s being placed on networks from us all being home so much.
For example, in the US [Verizon has both fixed and mobile 5G live in some areas already](https://advisory.kpmg.us/blog/2020/covid-19-increases-robust-5g-technologies.html). They’ve announced an extra $500 million to speed up the company’s switch to 5G.
The key to 5G is data. More than ever, intelligent use of data is the key to success. It helps cities and states to run more effectively. And it gives companies an advantage over their competitors. The need for data is why edge computing is often mentioned alongside 5G as a key component in the future of IoT. After all, [edge computing helps you to leverage real-time data sets](https://www.bbvaopenmind.com/en/technology/digital-world/ten-trends-of-internet-of-things-2020/) rather than trying to find what you need in a more-centralized cloud.
It’s right that we’re excited about this future for IoT. But the danger is that we’re not the only ones who see a world of opportunities we can profit from.
### The evolution of IoT cyberattacks and how to block them
So, we’ve seen that covid-19 hasn’t stopped the rush toward a world with an ever-increasing number of connected devices. In fact, if anything the effect of the last few months has been to see them as even more essential than before.
There were 2 billion smart devices in the world in 2006. In 2015, there were 15 billion. In 2020, this has jumped to 200 billion.
Or put another way, there are now 26 smart devices for every human being on earth.
But [as we’ve said before on this site](https://licelus.com/insights/why-striking-a-balance-between-speed-and-security-is-key-to-iot-success), the more devices that are connected to the internet, the more opportunities there are for bad actors. The architecture of IoT is typically quite centralized. And that means that if a bad actor can find an unprotected gap somewhere - whether that’s in your connected home or a business - they can squeeze through.
From there, they can access the whole system.
We’ve already said that the data within an IoT network is the key to success. And without this meaningful data, there’s no sense to IoT. But there are signs that bad actors are getting smarter with how they use this data, too.
If a hacker manages to break into your connected home network, then they can learn your daily patterns. They can track your movement. And they can time their attacks for when you’re most vulnerable.
That might be manipulating your alarm system or door lock when you’re on holiday. Or it could be [hacking your connected car](https://licelus.com/insights/why-its-so-important-that-we-protect-the-connected-car) when you’re in a remote area far from home.
In other words, when you’re much more likely [to have no other choice](https://bdtechtalks.com/2016/08/22/the-iot-ransomware-threat-is-more-serious-than-you-think/) but to pay the ransom they’re demanding.
The danger is that security is often an afterthought when people are building their network of connected devices. [But really it should be central to your planning from the outset](https://licelus.com/security-by-design). That means putting end-to-end security solutions in place to protect critical applications. And it means securing the links between these apps and the server. Because that’s where you’re most at risk from [man-in-the-middle attacks](https://licelus.com/insights/how-to-counter-man-in-the-middle-attacks).
Blockchain can help to secure data through the use of a decentralized system. But it’s also important to encrypt and hide the sensitive cryptographic processes that take place inside individual apps.
That way bad actors can’t find a way inside and [can’t tamper with](https://licelus.com/insights/how-to-counter-the-dangers-posed-by-tampering) any of the key material or logic within them.
When we add robust protection to IoT, then we can truly look forward to the world of opportunities that it opens up. After all, IoT has the potential to navigate a route out of the covid-19 crisis. Using data on a large scale (but in a safe way) can help us to learn and be better prepared for other outbreaks in the future.
## Building Trust Through Protection
[All insights](https://licelus.com/insights)
### Follow us
23 Jul 2020
### How in-app protection can help you to build trust
URL: https://licelus.com/insights/how-in-app-protection-can-help-you-to-build-trust
# How in-app protection can help you to build trust
The less there is of something, the more we tend to value it.
And trust seems to be at a premium right now.
After all, we’re living in an age where it’s difficult to get through a day without hearing about fake news. Populist revolts are on the rise across the world. The leaders of these movements plead with those who’ll listen to not trust the elites.
But businesses aren’t immune from the global trust deficit, either. As Andrew Burt brilliantly puts it in the Harvard Business Review, “ [if you’re selling a product, you’re now selling trust.](https://hbr.org/2019/03/cybersecurity-is-putting-customer-trust-at-the-center-of-competition)”
And it’s those companies that learn to sell trust well who we’ll remember in years to come.
The question, then, is simple:
How can businesses become more trustworthy?
Part of it comes down to transparency. Companies have to be genuine and tell it like it is. But of increasing importance is how they look after their customers’ data. And these days a lot of that data can be found inside the apps businesses have created to make life easier for their customers.
In the coming years, [protecting these apps from attacks](https://licelus.com/insights/9-app-security-best-practices-developers-should-follow) is likely to take on an increasingly important role in the wider strategy of building trust.
### The growing demand for transparency
You won’t have struggled to hear the word trust uttered in recent months. During the covid-19 crisis, trust in politicians, scientists, and the media has been put to the test.
Governments have trusted citizens to stay home and self-isolate. And citizens themselves have had to trust the advice of politicians and experts.
But the truth is that trust was being examined long before the coronavirus emerged. The financial crisis had people questioning whether we could ever truly trust banks and big business again, for example.
As a result of this – and a younger generation who value trust more than ever before – another trend has emerged:
Businesses have become more transparent. They’ve started telling it to their customers straight. Without hiding or sugar-coating anything.
It’s a winning tactic, because nothing puts off the modern consumer more than feeling like they’re being misled. These days, almost three quarters of consumers see transparency as being [more important than price](https://www.inc.com/rhett-power/trust-is-as-important-as-price-for-todays-consumer.html).
The importance of taking a transparent approach is underlined by the data we have on trust. [An Ipsos / World Economic Forum study](https://www.ipsos.com/sites/default/files/ct/news/documents/2019-01/ipsos-wef_-_global_consumer_views_on_data_privacy_-_2019-01-25-final.pptx_lecture_seule_0.pdf) from last year showed that less than two fifths of people across the globe trust organizations to look after their personal data.
And a lot of this is due to them having no idea what happens to that data once they share it.
### The link between app protection and trust
So, being honest about what you do with your customers’ data is a key facet of building trust. But it’s not enough on its own. Consumers also expect you to keep that data safe from bad actors.
When you strip trust back to its core, a lot of it comes down to competence and reliability. If you can excel at those two, you’ll go a long way. But it also explains why a security breach can be so devastating for a company’s reputation. It makes them look incompetent and unreliable.
As Neil Bayton from Trustpilot [says](https://www.thedrum.com/news/2019/07/11/the-amazing-power-brand-trust-and-how-it-can-grow-your-profits), “on a fundamental level, a consumer will only buy from a business if they believe they will fulfil their basic promises.”
And a key promise in the modern world is that end users get the benefits of sharing their data without having to look over their shoulder all the time.
In-app protection, then, can help you to build trust with your customers. But it also makes you a safer bet for investors and other stakeholders. It shows them that you care about security. Most investors want to see that security and privacy concerns have been taken into consideration throughout the product development lifecycle. [It can’t just be an afterthought](https://licelus.com/insights/why-the-best-app-development-follows-security-by-design-principles).
It’s also important to communicate how you’re looking after your customers’ data. Again, this comes back to transparency. Customers and stakeholders alike will respect and trust you more if you’re open with them about how you keep your apps secure.
You can also use this communication channel with customers to tell them the ways that you’ll get in touch with them. This helps them to spot suspicious activity, such as [phishing scams](https://licelus.com/insights/why-our-emotions-make-us-more-vulnerable-to-cyber-attacks) and [man-in-the-middle attacks](https://licelus.com/insights/how-to-counter-man-in-the-middle-attacks). And another key facet of the trust chain is tampering. Preventing it means stopping bad actors from modifying apps and attempting to get customers to download fake versions.
### Admit the threat exists, and then defend against it
One of the reasons mobile banks and other FinTech providers have had so much success in recent years is that they’ve combined robust security with transparent comms.
Banks like Monzo, Starling Bank and N26 don’t have physical branches like older, more established banks. There’s no smiling bank manager welcoming you into her office. So there’s no way for them to build up rapport and trust in a traditional sense.
Their only opportunity to build trust is [to show how seriously they take security](https://licelus.com/insights/3-trends-that-make-mobile-app-security-impossible-to-ignore). Their reputation depends on them keeping hackers away from the sensitive logic and data inside their apps.
But they’re also at the forefront when it comes to transparency. They often involve customers in decisions about new product launches and features. And they’re open about customer concerns regarding their privacy and data.
In a sense, they have to be. As we’ve said, this is their only opportunity to build trust with their customers. But this combination of in-app protection and transparency points to the future. It’s raised the bar of what consumers expect from brands.
This isn’t only a challenge for more traditional banks, but to all companies that use apps.
It’s understandable that companies might be hesitant about even talking about the security threats of the modern world. They might not want their customers to think a security breach is even a possibility.
But admitting that there is a threat builds trust.
[Hackers](https://licelus.com/insights/why-we-need-to-understand-the-hacker) aren’t going away anytime soon. So it’s up to businesses to be clear with their customers and investors.
You have to explain that the threat exists. But you also have to show you’re doing everything in your power to defend against it.
### Our latest articles
[View all](https://licelus.com/insights)
- [
**What is a Trusted Application?**
#Threat protection](https://licelus.com/insights/what-is-a-trusted-application)
- [
**How malware spreads: investigating a dangerous infection across India**
#Threat protection](https://licelus.com/insights/malware-spread-india)
- [
**Why virtual trusted execution environments are set to boost mobile payment security**
#Threat protection](https://licelus.com/insights/why-virtual-trusted-execution-environments-are-set-to-boost-mobile-payment-security)
## Stop Cyber Attacks
[All insights](https://licelus.com/insights)
### Follow us
30 Jul 2020
### How threat intelligence can stop the spread of cyber attacks
URL: https://licelus.com/insights/how-threat-intelligence-can-stop-the-spread-of-cyber-attacks
# How threat intelligence can stop the spread of cyber attacks
PSD2 is a regulation that reflects our modern habits.
We’re living in a world where people are used to transferring and trading with a few simple swipes of a smartphone screen. The demand for more innovative financial products and services seems almost endless. And this demand calls for a more open banking system.
That’s what PSD2 provides. The idea behind the regulation is that it encourages more competition in the marketplace. In theory, this translates to lower prices and better quality products for customers.
But it also makes the banking sector a more connected landscape. Customer data will be shared between banks, payment service providers (PSPs), and other third party providers (TPPs).
The vehicle for this sharing is an API (application programming interface). It’s APIs that allow banks to [connect their payment and data services to third parties](https://diginomica.com/psd2-and-the-api-challenge-for-open-banking).
This represents a challenge, though. Not least because it means more attack vectors for hackers to target.
And this in an industry that already receives around 300 times the annual attacks other sectors suffer.
As Pedro Nicolai da Costa [wrote in Forbes earlier this year](https://www.forbes.com/sites/pedrodacosta/2020/01/16/cyber-attack-on-major-bank-could-spread-quickly-new-fed-research-shows/#75603491327e), a well-timed cyber attack can spread quickly throughout the financial system. Part of this is because attacks against APIs are [getting more sophisticated](https://licelus.com/insights/3-trends-that-make-mobile-app-security-impossible-to-ignore). For example, bad actors now study payment system patterns so they can time their attack to cause the most damage.
This is the context of PSD2’s arrival. Banks and PSPs used to only have to worry about defending their own house. But now they have cause to worry about attacks across their whole neighborhood.
One section of the PSD2 regulation sums up the expectations of banks neatly:
“PSPs should ensure that they continuously monitor threats and vulnerabilities and regularly review the risk scenarios impacting their business functions, critical processes and information assets.”
In other words, they need a modern threat intelligence and risk analysis system. A way for them to identify, detect, and respond to threats in the growing, evolving ecosystem.
A smart defense is needed to counter increasingly subtle attacks. That's why threat intelligence is set to become vital to stop the spread of cyber attacks.
### Surveying the threat landscape in the finance industry
PSD2 has changed the threat landscape for banks and other institutions.
Links via APIs to third parties have opened up new attack vectors that they didn’t have to worry about before. But however an attack happens, the damaging effects of a security breach remain the same.
The modern consumer expects to be able to enjoy all the speed and convenience that comes with a more open banking system. [But they also expect banks to keep their personal data safe](https://licelus.com/insights/how-to-secure-a-safer-future-for-mobile-banking). The leaking of valuable data can destroy reputations and break the trust banks have worked so hard to build up.
A threat intelligence and risk analysis system helps banks to keep their reputation intact. To begin with, it can identify the threats that need to be defended.
Banks need to consider the wider ecosystem when scanning for threats. An example of a modern attack is that committed by a group called [APT10](https://www.pwc.co.uk/issues/cyber-security-services/insights/operation-cloud-hopper.html), which targeted Managed IT Service Providers (MSPs). This gave the group potential access to vast quantities of intellectual property and sensitive data. Not only from the MSPs themselves, but from their global clients too.
An attack like this one should have banks and PSPs asking themselves some tough questions that can help them to better understand the threats:
What kind of sensitive customer data (such as bank account information) could an API access?
And what level of access will that API give to a third party?
### Detecting threats
When preparing to counter threats, it’s useful to reference [the most common risks to the sensitive logic and user data that can be found inside APIs](https://owasp.org/www-project-api-security/). But it’s equally important to recognize that the marketplace is shifting and evolving all the time.
Threats can change. Particularly as new players emerge in the industry, offering customers innovative ways to move their money around.
As we’ve said before on this site, [bad actors don’t stand still](https://licelus.com/insights/why-we-need-to-understand-the-hacker). [They’re constantly on the lookout for a gap to squeeze through](https://www.ncsc.gov.uk/information/how-cyber-attacks-work). Somewhere that has been left unprotected.
[That’s why banks need to take a proactive approach to security](https://www.pwc.co.uk/cyber-security/pdf/psd2-and-banks.pdf).
Let’s go back to the Forbes article about hackers tracking payment system patterns to choose the most opportune moment to attack. Well, banks and PSPs can do some tracking of their own. Using a threat intelligence and risk management system, they can study typical API usage. And they can spot when usage is unusually high, which can be a sign of malicious activity.
It can also help them to understand the geography of attacks. Where are they coming from? And what can be learned from the category of the attack?
Information about concrete security incidents even enable banks to link them to individual customers. Then they can make risk-assessments for that customer’s transactions.
Setting up an appropriate security framework for the post-PSD2 world will also involve finding [the right balance between speed and security](https://licelus.com/insights/the-delicate-balance-between-personalization-and-security) - another of our favorite topics here at Licel. The trend is for customers to embrace innovative products and services that provide convenience. But launching a product quickly shouldn’t come at the expense of security.
So, it’s important to test a product’s security [before launch](https://licelus.com/security-by-design), as well as the threats it’s likely to face once it’s live. And a threat intelligence system can help with that, too.
### Modern API protection
In the next few years, forward-thinking banks will come to use threat intelligence systems in tandem with traditional API protection. Security such as hardening capabilities, runtime protection, integrity checks and code obfuscation will continue to be crucial in blocking bad actors. But this protection on its own is a bit of a black box. You can’t see how these defensive measures are keeping APIs safe. You can’t see where attacks are coming from. And you can’t see whether some types of attacks are more common than others.
A threat intelligence system gives you a 360 degree view of the landscape that APIs are operating in.
Take the following example. Imagine an end user has downloaded a trojan app onto her phone. This could represent a real threat to a banking app. But with a robust threat intelligence system operating, a banking app would carry out environment checks when it starts up and would send information to the fraud monitoring system.
It’s this proactive approach that can stop the spread of cyber attacks. A threat intelligence system defends the industry as a whole rather than one single bank or FinTech company. By [reporting attacks to a regulatory body](https://tech.newstatesman.com/security/fca-banks-outages), banks help others like them to learn from attacks and be better prepared to face them.
They protect their house, and they protect the wider neighborhood, too.
PSD2 has fast tracked the need for banks to build a modern security framework. And a threat intelligence system should play a key role in that. It’s a multi-layered approach to security. But it’s also an important statement of intent to hackers that the industry as a whole is prepared to defend against any attack.
### Our latest articles
[View all](https://licelus.com/insights)
- [
**What is a Trusted Application?**
#Threat protection](https://licelus.com/insights/what-is-a-trusted-application)
- [
**How malware spreads: investigating a dangerous infection across India**
#Threat protection](https://licelus.com/insights/malware-spread-india)
- [
**Why virtual trusted execution environments are set to boost mobile payment security**
#Threat protection](https://licelus.com/insights/why-virtual-trusted-execution-environments-are-set-to-boost-mobile-payment-security)
## Virtual Assistant Evolution
[All insights](https://licelus.com/insights)
### Follow us
08 Aug 2020
### The evolution from virtual assistant to virtual companion
URL: https://licelus.com/insights/the-evolution-from-virtual-assistant-to-virtual-companion
# The evolution from virtual assistant to virtual companion
Sometimes a crisis can lead to experimentation, innovation, and evolution.
A good example is the emergence of the sharing economy after the financial crisis. Brands like Uber and Airbnb - which have revolutionized the way that we travel - didn’t exist before the recession.
Some commentators think the covid-19 crisis will have the same kind of impact on our lives.
After all, in some ways the pandemic has already sped up IoT trends this year. As more people work remotely, the need for 5G technology has felt more pressing. And the smart speaker is starting to look like an even better investment when living rooms double up as offices.
However they arrive, all successful innovations have something in common - they appeal to us in an emotional way. The founders of Uber and Airbnb knew this. They were selling freedom as much as they were selling more affordable transport and accommodation.
And fulfilling an emotional need leads us nicely to an app that we read about recently called Woebot. It sounds as if it were designed for the pandemic and the post-covid 19 world. It offers help with mental health in a world that feels more anxious than ever. But it can also be used from home, without having to come into contact with the virus.
We read about Woebot, and we wondered: Could apps like this be a pointer to the future? To a world where virtual assistants like Siri become more like virtual companions that can offer us advice ( [as David Mattin ponders in his New World Same Humans newsletter](https://newworldsamehumans.substack.com/p/new-world-same-humans-22))?
And if so, what would the security implications be of an app that holds so much personal information about us?
### Digital wellbeing
Even before the coronavirus crisis, the digital mental health and wellness market was booming. Take the meditation app, [Headspace](https://www.businesswire.com/news/home/20200212005206/en/Headspace-Announces-Fundraising-Raising-93-Million-Accelerate#:~:text=Over%20the%20past%20nine%20years,Starbucks%2C%20Adobe%2C%20Hyatt%20and%20GE), for example. At the beginning of the year, it had more than 2 million paid subscribers. The app had been downloaded more than 62 million times across 190 countries.
But the global lockdown has put mental health firmly under the microscope. In May, [The Guardian reported](https://www.theguardian.com/society/2020/may/16/uk-lockdown-causing-serious-mental-illness-in-first-time-patients) that psychiatrists were expecting services to be overwhelmed by a ‘tsunami’ of sickness triggered by crisis.
And this makes sense when you think about it. 2020 has seen levels of anxiety and uncertainty far beyond what you’d expect in a typical year.
Even when lockdown measures are eased, it’s unlikely everybody who wanted to would be able to see a therapist as soon as they’d like. Others simply can’t afford one.
In this context, Woebot’s emergence seems particularly timely. It offers free cognitive behavioral therapy to help those suffering from anxiety, depression, and other mental health issues.
Woebot and other apps like it [have been given a boost by the Food and Drug Administration](https://www.wired.com/story/therapist-in-chatbot-app/) (FDA) in the US. In April they suspended some of the rules for digital therapeutic devices so that more people could benefit during the lockdown.
Decisions like this can turn a niche product into a mainstream one. Time will tell whether that happens with Woebot, but there’s no denying that its creators have tapped into an emotional need. Just like Uber and Airbnb before them.
It is a need that might grow in the coming months, too. Remote working was a trend before the pandemic, but it has been fast tracked like others. It’s hard to imagine everybody returning to the old ‘9 til 5’ routine, even after restrictions are eased. Of all the things people miss about the pre-covid-19 world, two hours on the train each day isn’t one of them. But for some people, the social interactions of the office were vital. For those who live alone, a future where we work remotely might sound like a lonelier world.
Could technology fill a void in a more remote, individualistic world?
In the near future, might we be having more meaningful conversations with Alexa and Siri?
Rather than simply switching our Spotify playlist or telling us the weather forecast, could they become more like a virtual companion?
### Your virtual companion
AI might not be there quite yet, but the intention to create virtual assistants that can help in more meaningful ways certainly is.
Although [criticized in some quarters](https://www.theverge.com/2020/1/7/21051390/samsung-artificial-human-neon-digital-avatar-project-star-labs) as mostly hype, the Samsung subsidiary, STAR labs, is investing heavily in its Neon project. According to the company, Neons are being designed to hold conversations with users while displaying “emotions and intelligence.”
But if virtual assistants like Neons or Alexa did evolve to become virtual companions, what would that mean for your personal data?
After all, we’re talking about an AI knowing more about you than your partner does. Perhaps better than you know yourself.
These virtual companions would combine data about your physical wellbeing with insights about your mental health. They’d know all of your most intimate thoughts, beliefs, and desires.
That's some pretty valuable data.
You can get a good sense of how much the virtual companion of the future will know about you from the present. After all, you’re already targeted with ads based on your interests. You talk about coffee with a friend and hours later you see an ad for LA’s best filter coffee on Instagram. That’s not a coincidence.
### A tempting prospect for hackers
For years, commentators have hypothesized about exactly how much big tech companies like Facebook and Amazon know about you. Might [they even know that you’re going to break up with your boyfriend before you do?](https://www.vox.com/the-goods/2019/1/2/18159111/amazon-facebook-big-data-breakup-prediction)
If they did, brands who might hope to profit from your changing lifestyle would be keen to know about it.
But it’s likely that other more malicious actors would be interested in this data, too. [Hackers](https://licelus.com/insights/why-we-need-to-understand-the-hacker) already attack apps with the hope of extracting valuable user information. This might be [bank account information](https://licelus.com/insights/how-to-secure-a-safer-future-for-mobile-banking) from a mobile banking app. Or it could be someone’s [medical records](https://licelus.com/insights/how-to-stop-the-surge-of-cyber-attacks-against-the-healthcare-sector) from a healthcare app.
So, it’s easy to imagine how attractive a target the app that comes with our virtual companions would be.
Hackers could attempt to reverse engineer it and create a fake version that they could try to get people to download. Or they might carry out a [man-in-the-middle attack](https://licelus.com/insights/how-to-counter-man-in-the-middle-attacks). Then they could hijack the communication channel between the end user and the virtual companion. They could ask their own personal questions that would tell them about the end user’s habits and movements for a given week.
It was the threat of an attack just like this that made [Germany’s telecommunications watchdog order the destruction of a toy doll](https://www.theguardian.com/world/2017/feb/17/german-parents-told-to-destroy-my-friend-cayla-doll-spy-on-children) a few years ago. They realized there was a weakness in the design that allowed hackers to speak to a child directly.
Here’s the thing - bad actors like uncertainty. They know that vulnerable, anxious people are [more likely to open a bogus text message](https://licelus.com/insights/why-our-emotions-make-us-more-vulnerable-to-cyber-attacks) or email and download a fake app. That’s one of the reasons there have been [so many cyber attacks during the covid crisis](https://www.theguardian.com/technology/2020/may/24/hacking-attacks-on-home-workers-see-huge-rise-during-lockdown). It’s also why [the apps governments are releasing to track and trace the virus are at risk](https://licelus.com/insights/the-risks-that-threaten-the-success-of-track-and-trace-apps).
And sadly it’s something else that crossed our minds when we read about Woebot.
While apps like it have the potential to help people through challenging periods in their life, they’ll need to be protected robustly from outside threats. Because times of crisis don’t only offer opportunities to innovators and creators.
They also create new avenues for attackers keen for the uncertainty to continue.
## Hybrid App Security Overview
[All insights](https://licelus.com/insights)
### Follow us
18 Aug 2020
### What the transition to hybrid apps means for security
URL: https://licelus.com/insights/what-the-transition-to-hybrid-apps-means-for-security
# What the transition to hybrid apps means for security
People often put privacy concerns to the back of their mind if the perceived benefits are compelling enough.
Think about a time when you’ve wanted to download a specific app. When you’ve spent time imagining how its personalised content is going to improve your life.
How much attention have you really paid to the small print about the permissions you’d have to give to the company that created it?
This reality is especially true of younger app users. [Gen Z customers have grown up with the smartphone](https://blog.hubspot.com/marketing/gen-z-stats). Personalized ads based on location and likes might seem a little creepy to some of us. But not to the consumers of the future.
Brands know this, too. They know that the smartphone is essentially a way of reaching their customers and prospects at any time - and wherever they are.
This puts pressure on businesses to develop an app that puts them in their customer’s pocket.
The thing is, developing an app can take a lot of time. Particularly when you consider it would have to be compatible with both iOS and Android devices. Not to mention a whole host of other, non-mobile versions for devices such as the smart watch.
This is where hybrid apps come in.
A hybrid app can be designed and developed in a fraction of the time it takes for a standard native app to be ready. And for that reason, some analysts now see hybrid apps as the future of app development.
But it’s important to recognize that the many differences between native apps and hybrid apps also extend to security. As hybrid apps are still somewhat of a novelty, bad actors have targeted them for attacks.
So, if you’re in a position where you’re considering taking the hybrid app route, it’s crucial you understand the risks and how to prevent them. It's important to consider hybrid app security.
### Welcome to the future
It’s interesting to look back on a film from 15 or 20 years ago that was set in the future to see what they got right and what they got wrong.
There’s one particular scene in the film Minority Report that got us talking here at the Licel office recently. [Tom Cruise walks into a Gap store](https://www.youtube.com/watch?v=7bXJ_obaiYQ) and is greeted with a personalized message from an avatar asking him how a recent purchase worked out for him.
In the film, it’s an individual’s eyes that are scanned before personalized ads are played to them. We might not be quite there yet with the eye scanning technology, but generally speaking companies can do exactly the same thing today.
If a retail company has an app, then they can place beacons around the store that lock onto the bluetooth LE on your phone. After all, the app has already collected the MAC address of your bluetooth module and sent it to a server. Then, once you’re in the store, the company can use your location, likes, and past purchase history to [send you targeted ads](https://licelus.com/insights/7-trends-that-will-impact-cybersecurity-in-2021).
Imagine there’s a shirt you really like the look of, but you think it’s too expensive and you can’t justify paying for it. A little disappointed, you walk toward the exit. But then, just as you’re about to leave the store, your phone vibrates in your hand. It’s a personalized ad with an offer for 25% off the original price of the shirt.
For a millisecond, you might be slightly perturbed at the realization that the brand knows more about you than you know yourself. But then you’d probably think about the cold facts of taking the shirt home today.
Advertising in the 2020s is likely to look a lot like this. And that’s the reason why lots of brands feel they’ll be left behind if they don’t have an app.
Developing a hybrid app means getting in your customer’s pocket a lot more quickly.
### The evolution of marketing and the rise of hybrid apps
Last year, [Gartner released a press release](https://www.gartner.com/en/newsroom/press-releases/2019-04-04-gartner-says-the-future-of-app-development-is-multiex) in which they predicted that mobile apps would have the biggest impact on business success in 2020.
They suggested the future of app development would be multi experience. In other words, apps would have to fit the changing shape of marketing. In a world of wearables and augmented reality, apps would have to adapt. Gartner also recognized the need for more conversational apps in a marketing landscape set to be transformed by [virtual assistants](https://licelus.com/insights/the-evolution-from-virtual-assistant-to-virtual-companion).
It’s a message that has been repeated by lots of other commentators in recent years.
In [a Drum interview with Ian James of Verve Mobile](https://www.thedrum.com/news/2018/04/17/the-future-mobile-app-the-next-decade), he suggested that the future of apps lies in three core areas. The first is speed - ensuring that users can access content quickly. The second is precision, specifically in terms of accuracy of location and voice search. And the third is trusted access. In other words, the idea that consumers will happily share their data if it means receiving a personalized experience.
Some of these insights help to explain why hybrid apps have been on the rise in recent years.
Developing a hybrid app means getting it to your customers fast. Sometimes people forget just how long it can take to create a quality native app for both iOS and Android. It took Instagram around two years to release their Android version after first launching on iOS.
But would the modern user wait as patiently as they did almost a decade ago?
A culture of now permeates society these days. Younger consumers have grown up in a world of instant gratification. Companies fear that if they don’t get their app out there soon, someone else will take their place.
Hybrid apps also allow you to modify quickly. Not only is there a single code base across platforms, but you also don’t have to update different versions in the app store and wait for approval.
As hybrid apps are web based, it’s generally a much easier process to change content to fit your customer’s evolving needs. And cheaper origination helps to keep costs down.
All of these factors help to explain why hybrid app frameworks such as Ionic, Xamarin, and NativeScript are doing so well at the moment. But there are reasons why there’s still a healthy debate about whether native or hybrid apps are a better bet. And a lot of this debate centers around security.
### Hybrid app security
Firstly, it should be said that there are strong arguments in favor of native apps even without taking security into consideration. There are plenty who would argue that if you truly want to offer your customers a great user experience, [then native is the only way to go](https://ymedialabs.com/hybrid-vs-native-mobile-apps-the-answer-is-clear).
But it’s also true that protecting native apps is a little more straightforward.
Java script-based apps are just set up differently. And that impacts how they can be protected from hackers. They still carry sensitive functions, and store sensitive data just like native apps, but the protection techniques that exist for them aren’t quite as robust.
There’s a virtual machine that executes Java script code, and so there’s more limitation in terms of securing that code. What’s more, environment checks can sometimes be difficult depending on the framework in use.
This isn’t to say that hybrid app security isn’t possible. It’s just that it can be more challenging and require a bit more thought. And that doesn’t always fit well with a business’ goal of getting their app to market quickly.
One specific risk area for hybrid apps is [man-in-the-middle attacks](https://licelus.com/insights/how-to-counter-man-in-the-middle-attacks).
Why? Well, it’s a lot harder to protect web browsers from man-in-the-middle attacks. A browser is a big, complex thing. And that means that it’s very difficult to hook at the system level.
Because of this, we’ve seen examples of bad actors exploiting weak server authentication to hijack the communication channel between hybrid apps and the server. That has enabled them to glean valuable information.
Hybrid apps are also at risk from sensitive data exfiltration. Hackers can squeeze through gaps in the app’s defences to steal personal user data as well as important cryptographic information. And they are exposed to tampering and reverse engineering attempts more than native apps. That’s because bad actors don’t require any special tools like a decompiler.
Despite all of these risks, it is possible to develop a hybrid app safely.
Environment checks before the app starts can help to [detect tampering](https://licelus.com/insights/how-to-counter-the-dangers-posed-by-tampering). Deep communication hardening can stop hackers from carrying out man-in-the-middle attacks. And you can also employ code and content protection designed specifically for hybrid apps. This shields valuable Html, JavaScript, Json, Xml, and media files.
We’ve spoken at length on this site about the need to find [the right balance between speed and security](https://licelus.com/insights/the-delicate-balance-between-personalization-and-security). Hybrid apps are the perfect example of this. They’re attractive to companies because they enable them to get their app to market quickly. But [trust](https://licelus.com/insights/how-in-app-protection-can-help-you-to-build-trust) is going to be just as valuable in the next decade as speed and convenience.
An app that’s liable to be attacked is never going to win you the trust of your customers. That's why [taking some time to plan a security strategy](https://licelus.com/security-by-design) for your hybrid app will be worth it in the long run.
### Our latest articles
[View all](https://licelus.com/insights)
- [
**Investigating iOS security vulnerabilities**
#Technical insights](https://licelus.com/insights/investigating-ios-security-vulnerabilities)
- [
**The push to open up Apple's walled garden**
#Technical insights](https://licelus.com/insights/the-push-to-open-up-apple-s-walled-garden)
- [
**Mobile app development frameworks - a security guide**
#Technical insights](https://licelus.com/insights/mobile-app-development-frameworks-a-security-guide)
## Protecting Virtual Worlds
[All insights](https://licelus.com/insights)
### Follow us
28 Aug 2020
### Protecting the virtual worlds of the future
URL: https://licelus.com/insights/protecting-the-virtual-worlds-of-the-future
# Protecting the virtual worlds of the future
### Pixelated peace in an anxious world
In the open world video game Red Dead Redemption II, you’re given a lot of freedom to play your way. While there are missions to complete if you want to reach the end of the story, these are optional.
You don’t have to join the gang for the next train robbery or bank heist. If you prefer, you can ride out into the plains on your horse and set up camp for the night.
You can even take a boat out into the middle of a lake and spend an hour or two fishing.
As video games become increasingly complex virtual worlds, developers are adding the ability for you to lose yourself within them.
They invite you to do your own thing. To find a few moments of pixelated peace, away from the stresses of the real world.
The Red Dead Redemption II model has been followed by the developers of Ghost of Tsushima - another open world game released on the PS4 just a few weeks ago. Set in Feudal Japan, you control a Samurai called Jin who is tasked with defending his island home from Mongol invaders.
A large part of your time is spent exacting vengeance on these Mongal hordes. But there are also plenty of moments of solitude.
You’re actively encouraged to climb mountains and pay homage to shrines, for example. You can choose to take a bath in a hot spring and contemplate a particular topic. Or you can sit by a lake and compose some Haiku.
Game developers don’t have to add these little side quests to their virtual worlds. But they understand that by doing so they give players more freedom.
One of the consequences of better writing and graphics is that [gamers now feel they can relate more to the character they’re controlling](https://www.forbes.com/sites/mattgardner1/2020/06/11/whats-the-future-of-gaming-industry-professors-tell-us-what-to-expect/#42da77f56c4f). Playing these games increasingly feels like an escape to another world. And in 2020, escaping from the real world has sounded like a pretty attractive idea. Meditative moments within games like Red Dead Redemption II or Ghost of Tsushima have offered relief to millions in recent months.
And here at Licel, we wonder whether this might be a pointer to the future.
In the years to come, it’s likely that we’ll spend even more time in these virtual worlds. Some commentators think that one of the impacts of mass unemployment in the wake of automation and AI improvements will be a widespread loss of meaning.
Complex games with an emotional pull might just offer people a way to recapture this meaning. But just like in the real world, there will be those who operate in the shadows in these new virtual worlds. Those who would look to illegally profit from them and steal from others.
The challenge, then, for developers is not only to create compelling virtual worlds. It’s also to create virtual worlds that are safe for people to get lost in.
### The search for meaning
The covid-19 crisis has had a devastating impact on job security. A global crisis has led to massive job losses and has affected millions.
But the impact has been psychological as well as financial.
Most of us tend to find meaning via our work. Take away our ability to work, and levels of anxiety and depression skyrocket.
The hope is that as we gain more control over the virus, life will return to the way it was before. And that means jobs will return, too. But longer term, there’s a fear that improvements in AI and automation will render human input in many areas obsolete.
This isn’t the first time that technology has threatened jobs, of course. During the Industrial Revolution, some worried that machines would put people out of work, too. [But as Yuval Noah Harari says](https://www.youtube.com/watch?v=nUxuNIqbVPs), in the past, people could more easily switch from one low-skilled job to another. A farm hand could become a factory worker. Technology simply created different kinds of low-skilled work.
The next technological revolution looks like it will be different. Automation will impact the vast majority of low-skilled jobs.
In a world with fewer jobs, some kind of Universal Basic Income would be needed. But what about beyond that financial support? What exactly would people do with all their free time without any work to do?
Some, like Harari, think that virtual worlds might hold the answer. Without tasks to give them meaning in the real world, people would turn to virtual ones.
They’d look for meaning there, instead.
And they wouldn’t be the only ones. Even those lucky enough to keep their jobs in the future might suffer from a crisis of meaning. In the 20th century, it was drummed into us that meaning could be found via consumerism. In other words, buying products that gave us status and made us feel good about ourselves.
[But these days consumerism doesn’t have the power it once did](https://newworldsamehumans.substack.com/p/new-world-same-humans-24). And a lot of people feel guilty about the impact of their buying habits on the environment.
This is another trend that might drive increasing numbers to virtual worlds in the future. Not only to find meaning there, but also to spend time in a place where they can act without worrying about the negative consequences of their actions.
### Losing yourself inside the game
Earlier this year, during the covid-19 lockdown, [Time Magazine published an article](https://time.com/5825214/video-games-screen-time-parenting-coronavirus/) that argued the benefits of gaming for mental health. In it, Michelle Colder Carras, a public health researcher at John Hopkins University, stated that games could offer relief for lots of people.
“When you’re battling yourself with traumatic thoughts, you can lose yourself in a game.” She said.
“What games are able to do for people in mental health recovery, all of society now needs.”
But for gamers to want to lose themselves within a game, there has to be an emotional attachment. That’s a big factor behind the trend of developers creating more meaningful journeys in open world games.
If virtual worlds are to allow us to escape, they have to offer us some kind of meaning that’s missing in our own lives. And at the same time they have to reflect our personal journeys.
This is likely to be a tricky balance for creators in the coming years.
[In an article from The Verge earlier this year](https://www.theverge.com/2020/2/25/21142766/open-world-games-future-tech-gta-zelda-red-dead-cyberpunk-sable), Robin Hunicke, professor of game design at the University of California Santa Cruz, said games have to confront the real world. Hunicke feels that games must tackle the challenges facing young people today, including a loss of control, and increased anxiety about an uncertain future.
It’s easy to imagine the virtual worlds of the future teaching young people valuable lessons that could also help them in the real world. After all, open world games are getting bigger and bigger, [as this video shows](https://www.youtube.com/watch?v=UvFdMax3wlA). As technology improves and virtual worlds become increasingly complex, it will be easier for gamers to forge their own path.
One trend - highlighted by the success of Minecraft and the soon-to-be-released Main Assembly is for gamers to build within worlds. To create their own little virtual worlds within larger ones. A mix of virtual reality and augmented reality will help their experiences there feel ultra realistic.
But there’s a danger to all of this freedom.
The more players are given license to build and contribute to these virtual worlds, the more threats might lurk within them. Not everybody will share the same noble intentions to make our new virtual worlds positive places to be.
The covid-19 crisis has taught us that hackers prey on the vulnerable. There has been a surge in the number of attacks in recent months while people’s defences have been down. At the exact moment people have been more reliant than ever on digital technology. And at a time when [people have been more trusting than ever](https://licelus.com/insights/why-our-emotions-make-us-more-vulnerable-to-cyber-attacks) of emails and SMS messages from authorities.
In the future, a group who have fewer opportunities to earn a living in the real world and who are reliant upon virtual worlds to find meaning would certainly fit the “vulnerable” tag. So it’s not hard to imagine them being targeted by bad actors.
### Protecting the virtual worlds of the future
One of the most anticipated video game releases of 2020 was The Last of Us Part II. For years its developer, Naughty Dog, had worked tirelessly on its storyline. But then, just a few weeks out from its release, [hackers broke into its servers and released key elements of the plot online](https://www.polygon.com/2020/5/4/21246344/the-last-of-us-2-leak-hackers-exploit-naughty-dog).
Apparently the bad actors responsible for the hack were able to take advantage of security vulnerabilities from a previous game the studio had made. This enabled them to download sensitive data from the server.
The hack was a reminder - if it were needed - that the video game industry is constantly at risk from malicious attacks. Intellectual property (IP) theft like the Last of Us Part II example is one of the most common attacks. But it isn’t the only way that hackers can harm individual gamers and developers’ reputations.
For console and mobile games where players can make in-game purchases, individual account and payment information can be stolen.
[Hackers](https://licelus.com/insights/why-we-need-to-understand-the-hacker) can even circumvent the in-app purchase system, benefiting from extra content without paying for it.
They can abuse guest accounts. They can manipulate network traffic. And they can repackage and republish mobile games in the hope unsuspecting players will download their version instead.
For developers, attacks can result in lost revenues, games being pirated, loss of IP, and, perhaps most damaging of all, loss of reputation.
But for individual gamers themselves, the stakes in the future could be equally high.
Imagine a near future where what you do inside a virtual world becomes just as important to your self esteem and mental health as what you do in the real world. Imagine that you’ve invested hundreds of hours as well as money into building up your virtual avatar. Now imagine the impact of a bad actor breaking into the developer’s server and stealing that avatar or wiping its achievements.
As with lots of advances in digital technology - some of which we’ve covered on this site - [it’s a question of getting the balance right](https://licelus.com/insights/the-delicate-balance-between-personalization-and-security). Sometimes the desire to be pioneers comes at a cost. It means that [security isn’t properly thought through](https://licelus.com/security-by-design).
But as the covid-19 crisis has taught us, it’s often the vulnerable within society who stand to lose the most from malicious attacks.
If commentators like Yuval Noah Harari are right and virtual worlds do become a vital escape for people in the future, then we need to start thinking about how to keep them safe.
## Combating Mobile Tampering
[All insights](https://licelus.com/insights)
05 Sep 2020
### How to counter the dangers posed by tampering
URL: https://licelus.com/insights/how-to-counter-the-dangers-posed-by-tampering
# How to counter the dangers posed by tampering
One of the most dangerous things about malware is that you might not even know it’s there.
Take a trojan, for example. It doesn’t come to life straight away. Once it’s installed within your mobile, it can hide there for months, waiting for the most opportune moment.
Like when you open your mobile banking app, for example.
Then the trojan gets to work. In milliseconds it slides a fake login screen over the top of the real one. To you, the login screen looks exactly the same as it always does. So you go ahead and enter your banking details.
This is followed by a barely-perceptible switch back to the login screen for the actual app. And you log in, completely unaware that the trojan is now following your every move and harvesting your details.
A trojan is just one form of tampering attacks - one of the most common threats facing mobile apps today.
Tampering attacks are particularly dangerous because of a fundamental truth - that most consumers simply trust the apps they come across on app stores.
The concept of some of them being fake or containing harmful trojans doesn’t register with the average end user.
A fear of tampering attacks might not keep the typical customer up at night. But if an attack were to succeed, then the company whose app had been compromised would definitely know about it. The impact on a business’s reputation would be almost impossible to recover from.
That’s why it’s so important to know how to prevent this type of attack.
### Defining tampering attacks
Trojans often come into being because an attacker gets hold of the install packages for a legitimate app. Then, once they have them, they can decompile the app, introduce the trojan, and then generate a new install package.
They often find their way onto a user’s device via [a seemingly harmless app](https://www.welivesecurity.com/2020/06/12/fbi-warns-scam-apps-move-to-mobile-banking/) that they’ve downloaded. This might be a weather app, a battery conservation app, or even a game. In other words, something innocent or fun.
But trojans aren’t the only form of tampering attack that can threaten a user’s device.
Tampering often goes as far as a bad actor repackaging an app and publishing it on the app store in the hope that an unsuspecting user will download it. There are more modified versions of apps on app stores than you’d think. So many, in fact, that [there’s an entire industry dedicated to finding and removing them](https://owasp.org/www-project-mobile-top-10/2016-risks/m8-code-tampering) [.](https://owasp.org/www-project-mobile-top-10/2016-risks/m8-code-tampering)
The starting point for creating and then publishing a fake app is to reverse engineer it. And that itself is only possible if a hacker has been able to run a static or dynamic analysis on the original app.
If an app is completely unprotected, then a hacker doesn't even need dynamic tools to carry out an attack.
The goal, then, is to stop hackers from carrying out a static attack (like decompilation, analysis, and injecting malicious code) or a more dynamic attack on your app. Do this and you’ll go a long way to preventing tampering attacks.
As we’ll explore in more detail later, you'll also want to check that nothing has been modified within the app at runtime.
### Who’s at risk from tampering attacks?
The FinTech and Banking industries are particularly vulnerable to tampering attacks. They’re obviously attractive to bad actors because of the financial rewards that come with reverse engineering such apps.
Imagine if a hacker were able to [repackage and then publish a mobile banking app](https://licelus.com/insights/how-to-secure-a-safer-future-for-mobile-banking). From the moment the unsuspecting user logs into this fake app, they’re being watched. Bad actors can harvest their account information. They can even manipulate accounts so that when the end user makes a transfer, it’s the attacker’s account the funds land in.
Typically these fake apps would present the user with an error message after they try to log in. Then they would use smartphone permission requests to bypass the authorization [texted to the user](https://licelus.com/insights/why-our-emotions-make-us-more-vulnerable-to-cyber-attacks).
Research suggests that [around 65,000 such apps were found on app stores in 2018](https://www.techrepublic.com/article/fbi-warns-about-cybercriminals-exploiting-mobile-banking-apps/). Clearly this is bad news for individual customers. But it can also be damaging to the bank itself.
As we’ve said before on this site, the damage to a bank’s reputation can be catastrophic if their defences are breached.
[The video game industry has also been targeted](https://licelus.com/insights/protecting-the-virtual-worlds-of-the-future) with tampering attacks. Hackers sometimes modify the code inside mobile games - especially those with freemium content. That way they’re able to trick the app into thinking they’ve paid for additional content when they haven’t.
Worryingly, we’ve also seen recent examples of [hackers tampering with industrial control systems](https://arstechnica.com/information-technology/2020/02/new-ransomware-intentionally-meddles-with-critical-infrastructure/). This is the type of attack that can put lives at risk as well as livelihoods. One malware attack against the German company Rheinmetall affected plants in the US, Brazil, and Mexico. It took the company almost a month to get its systems running back at normal capacity.
Attacks like this one are a reminder of how high the stakes are for stopping tampering attacks.
### How to prevent tampering attacks
One way businesses are working to stop tampering is to sign their code. It’s now pretty much a requirement for companies to do so whenever they share code, app, or firmware updates. And it’s a solid strategy. Code signing gives businesses the ability to validate the authenticity of the code. It helps to detect if any changes have been made to the code before the app arrives at the end user’s device.
By signing their code, a company is effectively tying its reputation to the product.
Businesses typically use a cryptographic key to sign their code. This could be inside the organization itself or it might be on a developer’s computer for APKs on the Android platform or cloud signing for Android and iOS.
Local signing means you retain full control of the process and the keys you use. But keys can still be accidentally leaked or stolen. Some legacy keys can be weak, too. A huge number of apps on the Google Play Store - particularly the older ones - use weak keys from years ago.
One alternative is cloud signing in an app store itself. Keys are more robust this way, but it means your app will be signed on the servers of Google or Amazon.
App signing is a great start. But it isn’t enough on its own to protect against tampering attacks. That's because there's nothing to stop bad actors from simply signing malicious or tampered-with apps with their own random keys.
A wider issue is that your average app user doesn't pay any attention to the signature under an app. Most wouldn't be able to tell you what it is or how it might protect them from malicious apps. It's similar to a HTTPS certificate. Honestly, when was the last time you checked it on a site where you enter your personal or banking details?
There's a need for more education about these protective measures.
Until then, as we touched on earlier, you also need additional security to counter the dangers posed by tampering. For example, you have to run environment checks and integrity checks at runtime. Do this, and you can spot the most common tools hackers use to reengineer apps. These include hooking, rooting, debugging, and using emulators.
Alongside these checks, you can use code and content protection to harden your app and make it tougher to read and decompile. As a general rule, the harder it is for a bad actor to read your app, the harder it is for them to tamper with its code.
[Threat intelligence](https://licelus.com/products/alice) can help, too. If you have a system in place that keeps you informed of the types of threats in your industry, you can shore up your defenses to meet them.
Tampering threats like trojans can do a lot of damage. But you can defend against them.
And once you do, it frees you up to concentrate on doing what you do best - providing a great experience for your end users.
### Our latest articles
[View all](https://licelus.com/insights)
- [
**What is a Trusted Application?**
#Threat protection](https://licelus.com/insights/what-is-a-trusted-application)
- [
**How malware spreads: investigating a dangerous infection across India**
#Threat protection](https://licelus.com/insights/malware-spread-india)
- [
**Why virtual trusted execution environments are set to boost mobile payment security**
#Threat protection](https://licelus.com/insights/why-virtual-trusted-execution-environments-are-set-to-boost-mobile-payment-security)
## Security by Design
[All insights](https://licelus.com/insights)
### Follow us
14 Sep 2020
### Why the best app development follows security by design principles
URL: https://licelus.com/insights/why-the-best-app-development-follows-security-by-design-principles
# Why the best app development follows security by design principles
For a long time, security was seen as a barrier to innovation.
Designers, developers, QA engineers, and product managers didn’t spend much time on security. In their mind, following the advice of their security teams might have meant pushing back tight deadlines. And that in turn might have meant launching late and missing out on valuable market share.
But things are changing.
High-profile security breaches have led to a stark realization:
It’s better to launch later with a secure app than to launch early with one full of gaps for bad actors to exploit.
After all, a security breach doesn’t only lead to you losing things you can measure easily, like revenue. It can also result in a [permanent erosion of trust](https://licelus.com/insights/how-in-app-protection-can-help-you-to-build-trust) among the very consumers you were aiming to attract in the first place.
That’s why forward-thinking companies now see secure app development as a vital part of innovation rather than a barrier to it. They realize that retrofitting security as an afterthought just doesn’t work. It’s only by [following security by design principles](https://licelus.com/security-by-design) that you can create a great user experience and keep that user’s data safe at the same time.
### Secure app development
In a recent article we spoke about [the rise of hybrid apps](https://licelus.com/insights/what-the-transition-to-hybrid-apps-means-for-security) being, at least in part, down to the pressure to launch apps quickly.
Companies are often under huge strain to get an MVP to market fast. They know that consumers have their mobiles with them at all times. And as such they want their app to be there with them - in their pocket, ready to target them at just the right time.
This pressure helps to explain why lots of companies might have only considered the security of their app at the end of the development process.
“We’ve designed and developed our app.\"
\"Now let’s add some security to it.”
But in practice, it isn’t as simple as that. Vulnerabilities often creep in during design and development. And these weaknesses are often in the code itself.
It’s not a case of flicking a switch and magically securing all of that code afterwards.
That’s why secure app development is so effective.
One of the key principles of security by design is that the responsibility for security is shared across the company. In other words, it isn’t something the head of security alone is thinking about. Instead, the UX team, the product manager, and the developers are thinking about it, too.
And security by design means thinking about security at each stage of the app development process. It’s not something that’s only considered a week before launch. It’s discussed at the very beginning of the design process. And then it’s a constant consideration throughout - even beyond the launch.
As the UK’s National Cyber Security Centre say in [their guide to secure design principles](https://www.ncsc.gov.uk/collection/cyber-security-design-principles), “the very worst outcomes can be avoided if services are designed and operated with security as a core consideration.”
The fact that we’re still seeing high-profile attacks tells us that this is a work in progress for many businesses. Indeed, [EY reported earlier this year](https://www.ey.com/en_gl/consulting/how-to-manage-cyber-risk-with-a-security-by-design-approach) that two-thirds of companies only consider cybersecurity once it’s already too late.
Switching the security mindset from reactive to proactive takes time. It doesn’t happen overnight.
We’ll explore a little later why secure app development is set to be so important in the coming years. But in the here and now, companies are beginning to understand why it makes sense. The impact of mobile logic moving to the client side and the huge hike in attacks during the covid-19 pandemic has shone a light on the need for better mobile security.
You only have to look at [a snapshot of one month of attacks in the UK](https://www.itgovernance.co.uk/blog/list-of-data-breaches-and-cyber-attacks-in-march-2020-832-million-records-breached) from earlier this year to see how pressing the need is.
### How to shift from reactive to proactive security
The attacks listed in the IT Governance piece paint a brutal picture of the current landscape.
And while it’s too simplistic to suggest following security by design principles would put an end to these breaches, they can give you better odds at countering attacks. They can help to make sure that [common vulnerabilities](https://blog.threatpress.com/security-design-principles-owasp/) are avoided.
For example, with security at the forefront of your thinking, you consider how best to securely store sensitive data. You put limits on the number of times a user can attempt to login using their pin or password.
These are fairly simple things. But they’re often overlooked when security is only an afterthought.
Shifting from reactive to proactive security often starts with threat modeling. A threat model is essentially you putting yourself in the hacker’s shoes.
What opportunities exist within your app for them to achieve their goals? And how skilled would they need to be to do so?
Think about security this way - before you even begin to develop your app - and soon you’ll be thinking of a lot more potential attack vectors than you imagined.
You’ll think twice about where and how you’d planned to secure your most sensitive code, data, and other key materials.
You’ll also start thinking about a whole host of other attack vectors that you might not have considered. After all, not all attacks are aimed at stealing sensitive data. Bad actors can also hijack sessions with a server and initiate a rogue transaction. They can send fake data to a server to compromise the client.
Attacks like these happen across industries. But in some sectors such as [healthcare](https://licelus.com/insights/how-to-stop-the-surge-of-cyber-attacks-against-the-healthcare-sector), these attacks can put lives at risk as well as livelihoods and reputations.
The examples of attacks above are a reminder that your threat model shouldn’t just focus on the app itself. A common error is to create a perfectly-secure app, but then forget about server-side security.
This is a bit like making sure you’ve locked the doors to your home but then leaving all of the windows open.
Equally, you need to consider that your app won’t always be used in a secure environment. People use weak wifi connections. They sometimes have another dangerous app or malware installed on their device. We call this the “ [zero trust approach](https://licelus.com/insights/mobile-security-in-a-zero-trust-world)”. Secure app development is often about assuming that your apps will be used in unsafe environments. That's why environment checks are so important.
Security by design is about ongoing security, too. That means carrying out [testing throughout the development process](https://www.globalsign.com/en/blog/3-unique-ways-app-dev-improve-cyber-security-process) and beyond the launch date.
You also have to accept that security incidents will happen.
A system that doesn’t have security incidents is a system that isn’t working. Human error makes it an inevitability. But security by design means you’re prepared to deal with threats. It means you’re monitoring the landscape for risks and are ready to counter them.
### A new way to think about app security
The modern consumer is more demanding than ever before. Social media and the smartphone have created an environment where she wants information in the moment. But she also demands that her data is secure.
This is the delicate dance that all companies are engaged in.
[It’s a fine balance between speed and security](https://licelus.com/insights/the-delicate-balance-between-personalization-and-security). But as we’re fond of saying here at Licel, if you have to choose just one of the two, then security should win out every time.
Trust is vital to winning and keeping customers. And the most 21st century way of waving goodbye to your customer’s trust is by allowing hackers to get hold of their data.
Developing your app securely sends a clear message to your end users - [that you care](https://licelus.com/insights/how-encouraging-empathy-can-help-you-to-develop-safer-apps).
It shows them that you respect their custom enough that you’ll do everything in your power to keep their personal data safe.
This goes hand in hand with transparency, too. You can keep your users aware of security measures by explaining the ways in which you’ll contact them and the kind of information you’ll ask them for. This gives them an active role in their security as they’ll be [better prepared to spot scam emails and texts](https://licelus.com/insights/why-our-emotions-make-us-more-vulnerable-to-cyber-attacks).
In the coming years, 5G technology will usher in an army of connected devices to help us navigate the modern world. Sensors that will help speed up our daily routines. And the old way of thinking about security just won’t cut it anymore.
More connected devices mean more attack vectors for bad actors. If consumers are to trust these devices and the apps that control them - enough to invite them into their homes - then they’ll need to be reassured that security has been considered throughout the design and development process.
Imagine a highly-promising tech company has designed an app that can lock and unlock doors in the homes of the near future. Now imagine that instead of using a secure app development approach, this company dealt with security a bit last-minute. It’s not hard to imagine the catastrophic impact to that business’s reputation if their customers were to suffer burglaries due to a gap in the app’s security.
We’re not quite there yet, but there are signs that companies are getting on board with this new way to think about app security.
They realize that respecting their end users enough to think of their security from the outset will be rewarded in the long run.
### Our latest articles
[View all](https://licelus.com/insights)
- [
**How to incorporate mobile app security testing into your build pipeline**
#Security by design](https://licelus.com/insights/how-to-incorporate-mobile-app-security-testing-into-your-build-pipeline)
- [
**Balancing security and usability**
#Security by design](https://licelus.com/insights/balancing-security-and-usability)
- [
**Ongoing Security: a step-by-step guide to a secure app development process**
#Security by design](https://licelus.com/insights/ongoing-security-a-step-by-step-guide-to-a-secure-app-development-process)
## Java Security Insights
[All insights](https://licelus.com/insights)
### Follow us
25 Sep 2020
### Celebrating 25 years of Java: How to keep Java-based apps safe
URL: https://licelus.com/insights/celebrating-25-years-of-java-how-to-keep-java-based-apps-safe
# Celebrating 25 years of Java: How to keep Java-based apps safe
What do Minecraft and the Mars Rover have in common?
Well, aside from the fact that they both let us explore new worlds, they also have a deep Java footprint.
Earlier this year, Java celebrated its 25th birthday. Since the language was born in 1995, it has influenced and shaped a whole host of projects. From being the language used to create one of the most popular video games of all time, to being the programming language of choice for expanding our knowledge of the red planet.
And many more besides.
One of the reasons for Java’s sustained success is its simplicity. Platform independent, it can run on almost any architecture and operating system.
But this simplicity also makes it an inviting target for bad actors.
Compared to 1995, we’re living in a much more uncertain world, with cyber threats evolving and maturing all the time. In order to be able to celebrate another successful quarter century of Java in 2045, we’ll have to be vigilant of this threat.
We'll have to protect java-based apps with a level of security worthy of the language’s unique influence on our world.
### Still going strong, 25 years on
You only have to listen to [this excellent Oracle Groundbreakers podcast episode](https://www.oracle.com/news/connect/25-years-of-java-technology-community-family.html) to get a sense of how Java has changed people’s lives in the last 25 years.
The interviews with Java champions are revealing. They all mention the strong sense of community. And there’s clearly a confidence that Java can stay relevant for some time yet.
The Java language has evolved since 1995 but, as Venkat Subramaniam says in the same episode, Java hasn’t had the luxury of changing wholesale. That simply isn’t possible when millions rely on it every day. Instead, Java’s evolution has been pragmatic. Steady.
[Write once, run anywhere](https://en.wikipedia.org/wiki/Write_once,_run_anywhere). That was the famous tagline chosen by Sun Microsystems in 1995 to highlight Java’s cross-platform flexibility.
And it turns out that it was a pretty prescient line. Because the language really does run anywhere and everywhere. From old mainframe computers, to IBM. From innovative inventions, to software for the world’s biggest banks. And from big data, to IoT.
Often referred to as the most important language a student could choose to learn, Java runs on 3 billion devices across the globe. And it’s used by more than 12 million developers.
“Write once, run everywhere” helps to explain how Java is still going strong, 25 years on. But it also points to a threat that has the potential to grow in the coming years if it isn’t curbed.
### Why Java’s simplicity is attractive to hackers
As we said earlier, a key factor behind Java’s success is its simplicity.
Its code and API documentation are open source. It has a publicly-available virtual machine and bytecode specification. And compared to other virtual machines or native code, its instructions are relatively easy to understand.
This helps to explain why the language’s reach is so vast. Why it’s created such a huge, supportive community across the globe. But not everybody who’s attracted to Java’s simplicity has good intentions.
[Bad actors](https://licelus.com/insights/why-we-need-to-understand-the-hacker) look at Java’s simplicity as an opportunity. Its openness can leave companies’ critical intellectual property [vulnerable to reverse engineering, manipulation, and theft](https://www3.thalesgroup.com/download/OvercomingJavaVulnerabilities_WP_(A4)_web.pdf).
Because the class format is open source, hackers can easily restore the original source code from the bytecode using decompilers. That allows them to see how the Java program works.
There’s not a lot of effort required for hackers to do this. In fact, there are many free and commercial decompilers on the market for them to choose from.
It’s also easy for them to process and make changes to the bytecode using common tools. And because Java apps typically only have around 200 instructions - around half as many as a native app - it takes bad actors less time to crack the code. Once they do, they can reverse engineer it easily.
Java apps are used so extensively that almost every industry is at risk from these attacks. There are open source libraries in the public sector, in automation, and [in finance](https://licelus.com/insights/how-to-secure-a-safer-future-for-mobile-banking) and taxation.
Businesses across these industries rely on Java code. But they also rely on keeping their sensitive information, algorithms, and intellectual property safe.
Fortunately, there are ways for them to do just that while embracing Java.
### How to protect Java-based apps
Java allows users to add a digital certificate to each class within the JAR archive, which acts as a check that the original files haven’t been modified. But on its own, this isn’t enough to protect companies from IP theft and [tampering](https://licelus.com/insights/how-to-counter-the-dangers-posed-by-tampering).
What’s needed is [a holistic approach to security](https://licelus.com/insights/why-the-best-app-development-follows-security-by-design-principles) that uses code protection and virtualization, content protection, and integrity control.
Code protection and virtualization hides the method calls and logic within Java-based apps. Ideally, it should use a combination of hide access and string encryption features to make sure that hackers aren’t able to decompile the code stored in the app.
Content protection is all about encrypting the resources inside the app. The best kind of resource encryption is transparent and uses strong cryptography to prevent bad actors from locating and accessing valuable assets.
Robust integrity control can identify when binaries have been damaged or deliberately modified. Then it won’t allow the app to function.
This means that hackers aren’t able to tamper with the app by injecting malicious code. It means that they can’t access the end user’s sensitive information, like passwords or account numbers. And it means they can’t disable a licensing subsystem.
Using a combination of these three protective measures keeps user data and company IP safe. It allows people to do their essential work without worrying about attacks.
Another way to mitigate some of the risks of bytecode decompilation is to make use of [Graal VM](https://www.graalvm.org/). It helps applications to run faster and allows developers to compile their app in a compact, native image format. But for optimum security it should be used alongside the measures listed above.
### Let’s celebrate another quarter century of Java
From the very first years under Sun Microsystems, to Oracle’s careful stewardship during the last decade, the Java language [has changed the world around us](https://blogs.oracle.com/javamagazine/the-top-25-greatest-java-apps-ever-written).
25 years on from its inception, we now live in a world of constant change. A world where technology evolves on almost a daily basis.
Java forms an essential part of this evolving technology. But cyber threats are moving at the same fast pace. And the simplicity that makes Java so special can also leave it open to attacks.
If we make sure that we protect Java-based apps, then we can look forward to the language being a big part of our lives for many more years to come.
### Our latest articles
[View all](https://licelus.com/insights)
- [
**Investigating iOS security vulnerabilities**
#Technical insights](https://licelus.com/insights/investigating-ios-security-vulnerabilities)
- [
**The push to open up Apple's walled garden**
#Technical insights](https://licelus.com/insights/the-push-to-open-up-apple-s-walled-garden)
- [
**Mobile app development frameworks - a security guide**
#Technical insights](https://licelus.com/insights/mobile-app-development-frameworks-a-security-guide)
## Mobile Security Insights
[All insights](https://licelus.com/insights)
### Follow us
10 Oct 2020
### Mobile security in a zero trust world
URL: https://licelus.com/insights/mobile-security-in-a-zero-trust-world
# Mobile security in a zero trust world
One interesting impact of the covid-19 crisis is the shift to remote working. It was already gathering pace before the coronavirus arrived. But the lockdown has pushed down on the accelerator pedal.
Several months on, and many people [still aren’t back at the office](https://www.ft.com/content/ac66a7ba-ba32-411f-a7fb-3ee0dde0d1c2).
Beyond the societal impact of this evolution are some pretty important security implications. Away from the office, employees use untrusted devices that might not carry the latest updates. They might also be use less-secure wifi networks.
This shift to remote work led to Microsoft EMEA chief security advisor Cyril Voisin to say recently that he expected more use of zero trust strategies.
The concept of zero trust might be new to some people. But not to those of us working in mobile security. Because the mobile world has been zero trust for some time now.
It’s a world full of malware. A world of rooted and jailbroken devices. A world of out-of-date operating systems and devices that don't receive updates.
And that helps to explain why assuming you’re operating in a zero trust world is the smartest strategy for businesses with sensitive mobile apps.
### The zero trust world
Earlier this year, [a Which study](https://www.which.co.uk/news/2020/03/more-than-one-billion-android-devices-at-risk-of-malware-threats/) revealed that more than a billion Android devices around the world are at risk from attacks by hackers. That’s because those devices are no longer supported by security updates and built-in protection.
The study was a reminder of just how fragmented the mobile landscape is. Particularly for Android. Not that vendors worry too much about this fragmentation. They just want to sell their devices. And so phones and tablets are available to buy that might be affected by malware and other threats.
In an ideal world every Android user would be using the most up-to-date version. But that often isn’t the case.
A single user might have several devices. Their latest Samsung smartphone will most likely run the latest version. But not the tablet they bought seven years ago. And so the apps running on that tablet won’t be covered by Google’s latest protection.
Google themselves announced in May 2019 that more than four in 10 active Android users are running version 6.0 or earlier. Or in other words, devices with protection that’s at least five years old.
Reacting to the Which report, [Zak Doffman wrote in Forbes](https://www.forbes.com/sites/zakdoffman/2020/03/06/android-security-horror-show-new-report-warns-40-of-you-face-this-dangerous-malware-risk/#51345eb32959) that the lack of consistency in update rollouts makes this fragmentation even worse. There’s a different timetable across - and even within - manufacturers. There’s no such thing as a one size fits all solution.
This is a much more complicated issue for Android than for IOS because there are so many manufacturers and vendors. [IOS updates tend to happen without a hitch](https://venturebeat.com/2019/10/17/as-ios-13-hits-50-adoption-android-fragmentation-keeps-getting-worse/) [.](https://venturebeat.com/2019/10/17/as-ios-13-hits-50-adoption-android-fragmentation-keeps-getting-worse/) A new version arrives and most users have it within a day or two.
One solution mooted by Google has been to have [a generic, unified Linux kernel](https://www.androidauthority.com/android-fragmentation-linux-kernel-1057450/) rather than a customized one. But this is tricky because the kernel is the communicator between software and hardware. And different manufacturers have different hardware.
This fragmentation on its own is a pretty good argument for you to take care of the security of your app rather than relying on built-in OS protection.
But there are other compelling reasons, too.
After all, it’s not only the OS that can’t be trusted, but servers and hardware.
In the zero-trust world, people use your app with weak, open wifi connections. People use your app on jailbroken devices. People open their phone up to the risk of hackers getting root with it.
And once they’re root, they can control the device and do whatever they want with it.
### An open door for hackers to walk through
These days, [mobile apps are crucial to business success](https://licelus.com/insights/3-trends-that-make-mobile-app-security-impossible-to-ignore). But if they’re not protected properly, then they can attract threats that can destroy a company’s reputation.
Not applying robust protection to your app in a zero-trust world is a huge risk. It’s a bit like asking a friend to look after your home for a couple of weeks when you know he has a habit of not locking the doors at night.
And if there’s one thing [hackers](https://licelus.com/insights/why-we-need-to-understand-the-hacker) love, it’s an unlocked door.
They’re constantly looking for gaps in security. Places they can squeeze through before stealing sensitive information, user pins and passwords.
This is a threat that almost all businesses face - especially those with apps where you can [buy something or move money around](https://licelus.com/insights/how-to-secure-a-safer-future-for-mobile-banking). Government apps where you can apply for new licenses or passports are also vulnerable.
End users can suffer from the zero trust world as much as businesses can. And some can even make the landscape even more dangerous. Take jailbreaking, for example. Some people are starting to see jailbreaking their device as an attractive option. They might even see it as the only option for them to be able to use their phone with the freedom they’d like.
This is a trend that represents a growing threat for IOS.
You see, Apple are very strict about what can be listed on the App Store. This is largely a smart security measure, of course. But it might be having the effect of driving some users to make their device less safe to get around restrictions. Earlier this year, [the first iPhone jailbreak for four years](https://www.theguardian.com/technology/2020/may/26/first-iphone-jailbreak-in-four-years-released) was reported.
[Epic Games were also making the news this summer](https://www.bbc.co.uk/news/technology-53777379) with their plans to sue Apple and Google over their ban from the App Store and Play Store respectively. Their game, Fortnite, is a global hit. But they were having to share 30% of their takings with Apple and Google. As such they’ve been exploring options to offer the game elsewhere.
The only thing is that by doing so, they might be encouraging users to put their devices at risk.
### How to make apps safe in any environment
The iPhone jailbreak and [Epic Games’ battle with Apple](https://www.youtube.com/watch?v=euiSHuaw6Q4) and Google point to a future where the mobile landscape becomes even more fragmented.
And that means in-app protection and threat intelligence will only become more essential.
Assuming your app is running in a zero trust world means that you reclaim responsibility for its security. You’re not relying on measures Apple and Google put in place alone. After all, oftentimes you can’t rely on those measures because not all of your users are covered by them.
So, how can you make apps safe in any environment?
The first step is to equip your app with detection capabilities. These sweep the app’s surroundings (either the device or the server) to find out whether that environment can be trusted or not.
They also spot debuggers and emulators, which are commonly used by bad actors attempting to reverse engineer an app. And they can find out whether the device is jailbroken or rooted.
Integrity checks are important, too. They can detect if an app or device configuration has been changed in any way. Integrity checks can check the entire app, or just a selection of at-risk libraries and calls.
Then there’s encryption and obfuscation. By encrypting and hiding valuable data within the app, you’re adding an extra layer of protection that frustrates hackers attempting an attack.
Finally, we recommend that businesses with sensitive, high-value apps also make use of [threat intelligence](https://licelus.com/insights/how-threat-intelligence-can-stop-the-spread-of-cyber-attacks).
With a threat intelligence and risk analysis system, you can scan the landscape for common threats and can better plan a defensive strategy.
By using a combination of these measures, you're not left hoping that you can rely on outside protection.
You've designed for the things you can’t control as well as the things that you can.
Your app is ready for the zero trust world.
## Revolutionizing Payments with SoftPOS
[All insights](https://licelus.com/insights)
### Follow us
28 Oct 2020
### Introducing SoftPOS - the fast-tracked financial trend ready to revolutionize payments
URL: https://licelus.com/insights/introducing-softpos-the-fast-tracked-financial-trend-ready-to-revolutionize-payments
# Introducing SoftPOS - the fast-tracked financial trend ready to revolutionize payments
### Fast-tracked trends
Sometimes a trend can be accelerated by a major global event. Think of it like an apple rolling gently down a hillside until it’s given a kick.
Well, the coronavirus pandemic has given several of these apples an almighty boot.
When we look back at 2020 in years to come, our thoughts will naturally be dominated by covid-19. But as we glance through the window into this strangest of years, we’ll see other stories that played out as a side effect of the virus.
We’ll spy [the end of the traditional 9 til 5](https://licelus.com/insights/mobile-security-in-a-zero-trust-world) and long commutes to the office. We’ll hear the death knell for cash ringing out. We’ll witness the rise of the mobile, agile business. And we’ll see the phone cementing its place as our go-to device for, well, pretty much everything.
Cash, of course, was already falling out of favor before we all became much more conscious of cleanliness.
Likewise, businesses were becoming more agile and less static before we all stopped travelling into the center of towns and cities so often.
The apples were rolling. But then came the kick.
And there’s something that links these last two trends in particular - that is the emergence of SoftPOS (software-based point of sale) technology. This turns the phone into a mobile checkout that companies can take with them as they travel to their customers.
It’s a great solution for them and for their customers, who get a simple way to pay while not having to worry about handling cash.
But wait, we hear you cry. What about security?
Is it really safe for us all to just wander around tapping our phones against others to make and receive payments?
Well, yes. It is. But only if you follow certain guidelines and requirements there to protect the apps that make these instant transfers possible.
Read on and we’ll explain how to protect SoftPOS apps.
### The end of the static business
There are two sides to this new payment story. On the one hand, you have the ability to make payments with your phone via a mobile wallet. And then there’s the more recent trend of being able to accept payments via a SoftPOS app on your phone.
Mobile wallets such as Apple Pay and Google Pay have been embraced widely across the globe. Particularly by younger millennial and gen z consumers who have grown up viewing the phone as a payment tool as much as a mode of communication.
But mobile wallet payments look set to gain traction across generations - not just among younger consumers. That’s because they offer convenience and speed alongside associated hygiene benefits that weren’t quite as important before covid-19. After all, NFC technology means you don’t even have to tap your phone against a card reader. It just has to be close to it.
A recent VISA survey highlighted just how much expectations have changed in 2020. [Almost half of the consumers polled](https://www.businesswire.com/news/home/20201021005235/en/Visa-Tap-to-Phone-Transforms-Payment-Acceptance-for-Sellers-Worldwide) said that they wouldn’t visit a store where the default payment method involved handling cash or touching a card reader others had used.
Fortunately for those people, more and more vendors are accepting mobile wallet payments. And the contactless limit has been raised during the pandemic to cater to these changing desires.
So, that’s how buying has changed in recent months. But what about the other side of this story?
Well, the vendors that already accept mobile wallet and chip and pin card payments have typically needed to invest in a dongle to do so. And this dongle has to be paired with a mobile device and needs to be charged intermittently.
SoftPOS technology renders this dongle obsolete.
Its arrival is pretty well timed given that [businesses aren’t as static as they used to be](https://news.samsung.com/global/ifa-2019-presenting-softpos-a-solution-that-turns-smartphones-and-tablets-into-a-contactless-payment-terminal). The days of companies only waiting for their customers to come and buy something from them are over.
We live in a much more fluid world these days. A world of pop up stores and home deliveries.
A couple of months ago, [the Financial Times reported on the demise of Pret A Manger](https://www.ft.com/content/d8eb62ef-a1cb-4597-867b-15a79dbdcd5d) during the covid-19 pandemic. The UK-based sandwich shop is ubiquitous on the high street - particularly in London. Indeed, Londoners often joke that every other store in the capital is a Pret. But as people have stopped commuting to their office in the center of town, Pret’s sales have sunk.
At the end of the Financial Times piece there's a suggestion that might have sounded crazy a few years ago but now somehow seems less outlandish. Namely that Pret could invest in a fleet of vans to drive out of the city center to where their customers live. Then they could play a tune to attract people out of their home office for a coffee or a sandwich.
In this hypothetical scenario, being able to take payments via a mobile device would speed up the process considerably. In difficult times for all businesses - both large and small - the ability to take payments directly via a smartphone could boost flexibility.
SoftPOS could help businesses in remote areas, too. It might be used at pop-up stores and market stalls. And it could be used to take payments [on the spot](https://www.fisglobal.com/en/insights/merchant-solutions-worldpay/article/5-advantages-of-mobile-payment-acceptance), anywhere in the store.
That would cut down on waiting times, which is quite an attractive prospect for the modern customer used to instant gratification.
For a long time businesses have been guilty of [seeing the payment process as an admin task rather than a route to optimization](https://www.gartner.com/doc/reprints?id=1-1ZMCMMXL&ct=200805&st=sb&utm_campaign=2020-08%20Gartner%3A%20Improve%20Customer%20Experiences&utm_medium=email&_hsmi=94298554&_hsenc=p2ANqtz-_fSeVvh1EhCuDx2StKAVn4ltJj0wjGxns2hSORyg4QX1rIAYnoZHw85kI0X0pMP0mXB0DgXaliXbdlwID8fRTw_rpsSw&utm_content=94298554&utm_source=hs_automation). And similarly they’ve often been slow to react to evolving consumer needs. SoftPOS technology is gaining traction because it responds to both of these often-ignored growth opportunities.
### How to protect SoftPOS apps
The benefits of SoftPOS technology are clear. Both for businesses and their customers. But as is the case [with any financial trend moving digital](https://licelus.com/insights/how-to-secure-a-safer-future-for-mobile-banking), the dangers posed by hackers have to be considered.
So, how can we protect SoftPOS apps?
Well, as we’re fond of repeating here at Licel, the best way to make sure your app is safe for your end users is to design and develop it with security top of mind.
Take a look at [our 7 security by design principles](https://licelus.com/security-by-design) for an introduction after you’re done reading this article.
A key theme that runs through those 7 principles is [empathy](https://licelus.com/insights/how-encouraging-empathy-can-help-you-to-develop-safer-apps). A good place to start in keeping SoftPOS apps secure is to first put yourself in your customer’s shoes, and then [imagine yourself as the hacker](https://licelus.com/insights/why-we-need-to-understand-the-hacker). This activity will help you to carry out a threat assessment, as the vulnerabilities of sensitive payment assets and security functions will become clearer to you.
As you might expect, the mobile payment sector is a highly regulated one. Typically these regulations are led by card payment system providers such as Visa and Mastercard. But there are also two standards that have to be met. One is set by EMVCO, and the other by PCI. Their security requirements are extensive and are a must read for any company looking to develop a payment app.
Put simply, the best way to adhere to these requirements is to use a multi-layered and dynamic security model. In other words, one where there’s no single point of failure.
But there are also specific areas that need to be covered.
The first of them is to do with code protection. Valuable code needs to be obfuscated so that hackers aren’t able to make any sense of it. That way they’re denied a base camp within the app from which to launch an attack. Cryptography can also be used to protect calls for sensitive logic.
Another key requirement involves the use of device attestation. This means being able to check that a device isn’t rooted, that it hasn’t been debugged, and that it isn't using an emulator, for example. It’s also there to make sure there are no attempts to hook sensitive methods and exfiltrate valuable data or key material.
These checks are crucial in the modern world as bad actors shift their focus to dynamic analysis - an easier and more efficient way for them to carry out an attack.
That’s why the app itself and the environment it’s operating in [should also be constantly monitored for evolving threats](https://licelus.com/insights/how-threat-intelligence-can-stop-the-spread-of-cyber-attacks).
And it’s important to be able to react to these threats, which is where [risk analysis or threat intelligence systems come in](https://licelus.com/products/alice).
As SoftPOS works with a real payment card, it’s also crucial to secure cryptographic storage for issuer keys. You need a self-defending model that can store cryptography keys securely and perform some cryptographic operations.
Both the EMVCO and PCI standards reference a virtual trusted execution environment (vTEE). A vTEE is vital for transfers to be processed securely without interference from hackers. In practise, this involves moving critical material to a secure, isolated container.
### Is SoftPOS the future of payments?
At the beginning of this article we touched on the idea of [major global events fast-tracking trends](https://licelus.com/insights/7-trends-that-will-impact-cybersecurity-in-2021). Innovative inventions and businesses are often born out of a crisis because specific aspects of our lives - that we might have ignored before - are examined with a sharper focus.
This is how the sharing economy emerged from the last financial crisis, for example.
Companies like Airbnb and Uber are now so entrenched in everyday life that it feels like a trick of the mind that they’ve only been around for a decade or so.
And it's happening again as a result of the covid-19 pandemic.
The phone was already becoming a payment hub thanks to the normalization of challenger banks, mobile wallets, and even the influence of social media companies like WeChat in China.
That said, it was more of a tool for making payments than receiving them. SoftPOS enables the phone to be just as helpful for sellers as it is for buyers.
We can’t say for sure what the economic landscape will look like in the post-coronavirus world. But we have some clues. Businesses will become more mobile as city centers empty of workers. And more people are set to become freelance out of both choice and necessity. These people will need an easy and fast way to sell their products and services.
It’s hard to imagine a scenario where SoftPOS technology doesn’t thrive in this world. Particularly as the signs are that [Apple will soon join Android in allowing users to take payments on their mobile](https://www.finextra.com/newsarticle/36593/eu-could-force-apple-to-open-up-iphone-nfc-functionality), which will open up another huge section of the global market.
Think of it as just one more kick to fast-track the SoftPOS trend.
### Our latest articles
[View all](https://licelus.com/insights)
- [
**Investigating iOS security vulnerabilities**
#Technical insights](https://licelus.com/insights/investigating-ios-security-vulnerabilities)
- [
**The push to open up Apple's walled garden**
#Technical insights](https://licelus.com/insights/the-push-to-open-up-apple-s-walled-garden)
- [
**Mobile app development frameworks - a security guide**
#Technical insights](https://licelus.com/insights/mobile-app-development-frameworks-a-security-guide)
## Cloud App Security Issues
[All insights](https://licelus.com/insights)
### Follow us
12 Nov 2020
### The problem with cloud-based app security
URL: https://licelus.com/insights/the-problem-with-cloud-based-app-security
# The problem with cloud-based app security
As we delegate more and more of our daily tasks to smart devices, so apps are increasing in importance.
We’re at the point now where for some businesses [their app is actually their main asset](https://licelus.com/insights/3-trends-that-make-mobile-app-security-impossible-to-ignore).
Take mobile banks, for example. They don’t have a physical bank for customers to visit. There’s no legacy of conversations with bank managers to build trust. The only way these mobile banks can secure and keep the trust of their customers is through the app itself.
That’s why app security is so vital for business success these days. After all, a data breach can lead to this trust evaporating in an instant.
So, choosing how to protect your app has become a pretty big decision. Different apps need different layers of security.
We had a conversation recently with a potential customer who was making some initial decisions about how to protect their app. And as part of that process they asked us about cloud-based app security. They had heard about it and wanted to know our opinion on it.
We had to be honest. We told them that we don’t recommend cloud-based app security.
In this article we’ll explain why. We’ll touch on why we think local protection is more robust. But we’ll also suggest one way companies might protect their apps online that provides a little bit more security.
### Self isolation for apps
We’re approaching the end of 2020. And as such we’re all pretty well-versed in the concept of self isolation. If we want to limit the spread of covid-19, then we need to keep a safe distance from one another and, where possible, stay home.
As it turns out, self isolation isn’t a bad idea for apps, either.
You see, there’s a principle in cybersecurity that says that [the fewer access areas you have, the better](https://licelus.com/security-by-design/clear-and-simple). This makes sense when you think about it, because what you want to do is limit the opportunities bad actors have to attack.
The more doors you add to your home, the more likely it is you’ll forget to lock one of them.
This is one of the main problems with cloud-based app security in our opinion. Because the first step in the process is typically for you to upload an application container (APK or AAB for Android, and IPA for iOS) to the cloud. But as this application container makes its way from your computer to the cloud, it’s highly vulnerable. You can’t be sure that it won’t be altered or tampered with in some way before it arrives.
On its journey to the cloud, the application container might be intercepted. It could fall victim to a [man-in-the-middle attack](https://licelus.com/insights/how-to-counter-man-in-the-middle-attacks). Hackers might even manipulate it in order to carry out a phishing attack.
Imagine you register on a cloud-based security portal and successfully upload your application container. But later that day [you receive an email or SMS](https://licelus.com/insights/why-our-emotions-make-us-more-vulnerable-to-cyber-attacks) telling you that you need to re-upload it because some vulnerabilities have been detected with the application.
“Just click on the link below to upload it again..”
Except that link is a malicious link. And the message isn’t from the cloud-based security company at all.
So, the initial act of transferring the application container is the first problem with cloud-based app security. But it isn’t the only one.
### Compromising your keys
Another issue arises if your app contains security assets like API keys, security key materials, or login credentials.
You should never share this information with a third party. But by design that’s exactly what you’re doing with a cloud-based app security solution.
You’re technically compromising your keys.
One way to tamper proof your app - [which we’ve written about before on this site](https://licelus.com/insights/how-to-counter-the-dangers-posed-by-tampering) - is to digitally sign under your app to certify it. In an ideal world, this would be enough on its own. But more often than not that isn’t the case, because a bad actor can still re-sign an app and even upload it to stores to mislead people.
That’s not to say that signing isn’t an important part of the process. The signature under an app can be used as an input to calculate cryptographic functions that can then be used for wider protection measures.
However, carrying out this process on the cloud isn’t safe. Unless of course it’s done at the app store itself - whether that’s Google or Amazon.
We’ll come back to that later.
Integration can also be problematic on a cloud-based platform. The build server where you create the app before publishing it should really be offline (or at least in a private, secured segment of the network) so that hackers can’t change something in the server or modify the app. Again, being connected to the cloud means you’re adding more doors for bad actors to open.
This is even more of an issue when you consider that some large organizations have a dozen or more apps designed for different regions that follow specific regulations. What’s more, if your app has cryptographic algorithms that are subject to expert controls in one country, it might not be legally possible to transfer the app across territories.
### Alternatives to cloud-based app security
So, if we don’t think cloud-based app security is the best way to keep your app safe, what do we suggest?
Well, there are two main alternatives. The first of these is to protect your app locally, which is what we would recommend as the best option.
Why?
Local app protection is isolated. It takes place somewhere bad actors - both external and internal - can’t interfere with the process.
At Licel we often refer to the cryptographic puzzle when we talk about robust local protection.
What we’re talking about here is ideal-world security that works with the final containers and keys deep inside your app.
From such a depth, a local protection solution can carry out cryptographic pre-calculations. That means if something has been modified in the protected app, then the cryptographic puzzle won’t be solved correctly. And because of that, the app will become inoperable.
This prevents any kind of tampering, re-signing, and injection of malicious logic.
With a cloud-based security platform, it simply isn’t possible to manage and protect this cryptographic puzzle with anywhere near as much integrity.
That's because the app isn’t isolated - as such it’s exposed to lots of risks. It means you're not in control.
### How to make cloud-based app security safer
But there is a second alternative to cloud-based app security aside from local app protection. In this second scenario, both the signing of the app and the robust protection we’ve mentioned above are carried out by Google or Amazon at their secure servers.
Most app stores use cloud signing to secure apps. The benefit of this approach is that the keys that are used are a lot more robust. The downside is that these companies have their own methodologies for signing and there isn’t anything you can do to influence that. And as the process still involves people, there’s room for mistakes to happen such as cloned apps being approved for uploading.
That said, this option - as yet a slightly hypothetical one - offers a lot of potential to make cloud-based app protection much safer (and more effective) than it is at the moment.
So, what was our final recommendation to our potential client? Put simply, to use local app protection where possible.
In a future scenario where Google or Amazon offer this same level of protection in a cloud-based environment, we might be able to recommend that too. But at the moment, the only robust approach is a local one.
The client in question was developing a highly-critical app. And so we also suggested that they use a Hardware Secure Module (HSM) to store their signing keys. That’s because files stored outside of such a module are open to theft. Just one more reason why an online, cloud-based solution might have been problematic for them.
It's important to remember that we’re all pioneers in this application journey. Apps are now so entrenched in our everyday lives that it's easy to forget they've only been around for a decade or so. But there’s often a disconnect between the importance of an app to business success and the level of security it’s given.
Let’s protect apps in a way that’s worthy of their growing influence on the world.
That way we can make sure that it’s the end users who benefit from them rather than bad actors.
## Empathy in App Security
[All insights](https://licelus.com/insights)
### Follow us
26 Nov 2020
### How encouraging empathy can help you to develop safer apps
URL: https://licelus.com/insights/how-encouraging-empathy-can-help-you-to-develop-safer-apps
# How encouraging empathy can help you to develop safer apps
Empathy probably isn’t the first word that comes to mind when you think about cybersecurity.
But maybe it should be.
After all, having empathy with your customers doesn’t only help you to create a more user-friendly mobile app. It also helps you to make your app more secure.
Imagine yourself as the end user of your app, and you’ll think of lots of different scenarios of where and how it might be used. Attack vectors will come into focus that might have been hidden before.
And speaking of attack vectors, empathy doesn’t end with your customers.
Seeing the world from the hacker’s point of view might sound a bit strange at first, but it’s actually a vital exercise. Put yourself in their shoes and you’ll have a clearer picture of the data and logic most attractive to them. This can lead to game-changing insights you can use to come up with a risk analysis and threat model.
Then there’s the kind of empathy most likely of all to be overlooked - the understanding between different people involved in the app development process itself.
Misunderstandings and miscommunication between developers, designers, product managers, and security engineers is a common way for vulnerabilities to creep in over time. That’s why encouraging inter-team empathy and a wider perspective on app development is so important.
Do so, and you’ll fill gaps before they’re wide enough for hackers to squeeze through.
### The importance of getting a different perspective
The Cambridge Dictionary defines empathy as the ability to share someone else's feelings or experiences by imagining what it would be like to be in that person's situation.
These days, empathy is pretty important in the world of marketing. Most forward-thinking businesses don’t even attempt to attract their prospects until they’ve tried to see things from their perspective.
That isn’t to say there aren’t still some old-school brands around. You might have come across them yourself. They act a bit like a travelling salesman from the 1950s - urging prospects to “step right up” and “buy now”, without knowing anything about them or their daily challenges. But fortunately they’re a dying breed.
If you’ve been involved in a mobile app development process, chances are you’ll have tried to see things from your end user’s point of view, too. You’ll probably have had workshops where you imagine them using your app and interacting with its many features.
Normally, though, this is only done with the objective of improving the UX of the app. Testing and improving usability is crucial, of course. But only empathizing with your customers so you can improve the user experience is a bit of a missed opportunity.
It should also help to shape your security planning.
Not too long ago we wrote about the concept of [the zero trust world](https://licelus.com/insights/mobile-security-in-a-zero-trust-world). We described it as a place full of malware, jailbroken devices, and outdated OS that doesn’t get the latest security updates. In other words, a very different world to the one you tend to picture when you first design your app.
Imagining yourself as the end user in this wild world is a must. Because by doing so, you expect the worst. You prepare yourself for what you can’t control as well as what you can.
Simply assuming that the security measures you have in place will be enough is asking for trouble in the modern world.
So, the process of putting yourself in your end user’s shoes is all about imagining future threats to your app’s security. But that’s just one half of using empathy for threat modelling.
The other half is imagining yourself as the hacker.
Our view of bad actors is often far too simplistic. We tend to think of the classic image of the mysterious hooded character sat behind a computer screen. An image that was already popular before Mr Robot hit our screens several years ago.
[It’s important to demystify the hacker](https://licelus.com/insights/why-we-need-to-understand-the-hacker) if we want to defend against their attacks. And the best way to do that is to see things from their perspective. That means imagining the data and logic they’d be most interested in stealing or tampering with. It also means thinking about parts of the app’s architecture that could allow them a way in.
Do this consistently, and [monitor how the risks in your app’s landscape are evolving](https://licelus.com/products/alice), and you’ll be well-placed to counter threats.
### Encouraging empathy in app development
You can limit the number of routes open to hackers during the app development stage itself. But that relies upon clear communication and empathy across key roles in the business.
This isn’t always a given. Especially when so many of the tasks in app development are siloed.
Let’s take developers as an example. Typically they are assigned specific tasks that will contribute to the overall success of the project. This makes for a speedy, efficient way of working. But it does come with certain risks to security.
A lot of vulnerabilities creep into an app’s code during development because of a lack of clarity about responsibilities.
A developer might be sure of his own personal tasks, but sometimes there are grey areas between those and the ones assigned to a colleague of his.
It’s these grey areas that hackers will attempt to profit from later.
A developer might also fear that he wouldn’t be rewarded for raising a concern that could delay the completion of his own work as well as the wider project.
The best way to eliminate these concerns and misunderstandings about responsibility is to encourage empathy, understanding, and open communication. In practise, this might mean product managers and leadership teams fostering a culture where people communicate clearly with one another. A culture where people feel confident about asking questions.
Developers and security engineers might sometimes get frustrated with one another. But this is often because of a lack of understanding about the daily challenges that each of them face. If you think this might be true of your business, then it could be worth ringfencing some time for these two roles to shadow one another.
You’d be surprised how effective this is at increasing empathy and understanding.
We also recommend that product managers find time to discuss security and the wider project objectives in sprint planning and sprint retrospective sessions. This can help make sure that the goal of protecting the end user’s sensitive data is always top of mind - alongside other, individual objectives.
### Future-proofing your app development
A lot of existing processes that lead to siloed working are there to speed things up. And realistically, more and [more businesses will drive towards speedy digitization](https://licelus.com/insights/7-trends-that-will-impact-cybersecurity-in-2021) in the post-coronavirus world in order to stay competitive.
But as we’ve said on this site several times before, [speed and convenience shouldn’t come at the expense of security](https://licelus.com/insights/the-delicate-balance-between-personalization-and-security).
Security isn’t like wrapping paper. It can’t be neatly sellotaped onto your app at the end of the development process, protecting it from outside threats. It’s a continuous journey that involves close communication and lots of imagined future scenarios.
Only seeing things from your own world view can be dangerous to your long-term success. It ignores other perspectives that might shine a light on potential threats that can be avoided early on.
We’re entering an age where consumers are set to be pretty unforgiving of any kind of data breach. The modern consumer wants to associate with businesses they can trust. Businesses that show that they care.
What better way to position yourself as such a company than by encouraging empathy?
### Our latest articles
[View all](https://licelus.com/insights)
- [
**Beware of mental traps**
#Attack psychology](https://licelus.com/insights/beware-of-mental-traps)
- [
**How to boost your social engineering awareness**
#Attack psychology](https://licelus.com/insights/how-to-boost-your-social-engineering-awareness)
- [
**Creating a company culture for security**
#Attack psychology](https://licelus.com/insights/creating-a-company-culture-for-security)
## Cybersecurity Trends 2021
[All insights](https://licelus.com/insights)
### Follow us
08 Dec 2020
### 7 trends that will impact cybersecurity in 2021
URL: https://licelus.com/insights/7-trends-that-will-impact-cybersecurity-in-2021
# 7 trends that will impact cybersecurity in 2021
Sometime around the end of June, we carried out an interesting exercise in the Licel office.
We looked back at a few technology trend articles for 2020 from around this time last year.
In them, authors wrote confidently about how this year would pan out. About how our lives might be changed by a number of tech innovations.
Reading these articles a few months into a global pandemic that had completely reconfigured daily life was a strange experience.
It was a little like gazing through a window into some kind of alternate dimension. Into a world unscathed by covid-19 where 5G dominates the headlines.
Back in the real world, it was becoming obvious as early as January that this year might be a bit different to the norm. By then, fragments of information were arriving on our phones of a strange virus emerging from a market in Wuhan.
Some people will see 2020 as proof of the futility of guessing what the world will look like more than a few weeks from now. But the truth is we were surprised by how many of the predictions from this time last year held true.
Indeed, if anything [the pandemic actually seemed to have quickened some of these trends](https://licelus.com/insights/the-iot-landscape-in-2020-and-the-need-to-keep-our-connected-devices-secure).
That makes us feel a little calmer about making predictions for trends that will impact cybersecurity in 2021.
Sure, there’s a chance that the world might be a very different place come next summer to the one we imagine today. But we’re pretty confident that the seven trends we’ve outlined below are ones that first sparked before covid-19 and will burn brighter still in the post-coronavirus world.
We predict a more mobile, remote world. Both for individuals and for businesses. A world where bad actors look to profit from new ways of working and from the wider anxieties the pandemic has created.
In other words, we predict a world where robust protection from cyber threats will become more important than ever before.
### SoftPOS set to revolutionize how we receive payments
One trend that we’ve already seen fast-tracked by covid-19 is the ability to take payments via an app on your phone. Soft POS (software-based point of sale) technology is making it easier for businesses to be more mobile.
SoftPOS allows businesses to operate where their customers are. And this has obvious benefits for companies in city centers that have emptied of office workers due to the pandemic.
While the promised vaccines of spring 2021 will no doubt encourage some workers back to their offices, it’s unlikely everyone will go back to the way things were before. Besides, covid-19 has taught businesses that they need to be less static.
Both of these trends mean that a way to take payments easily via your phone - without having to invest in a dongle - will be welcomed.
The coronavirus has also made people much less likely to use cash in 2020. [Visa ran a poll](https://www.businesswire.com/news/home/20201021005235/en/Visa-Tap-to-Phone-Transforms-Payment-Acceptance-for-Sellers-Worldwide) earlier this year that found that almost half of their respondents wouldn’t shop somewhere that required them to handle cash or a card reader others had used. Again, our newfound hygiene habits might be tested by the arrival of a vaccine. But it’s hard to imagine cash making a comeback, which makes the arrival of SoftPOS even more timely.
So, how does the arrival of SoftPOS impact cybersecurity?
Well, any financial transaction that moves digital opens up a potential attack surface for hackers.
EMVCO and PCI both have standards that are a great place to start to find out how to reduce this surface area. But put simply, keeping SoftPOS apps safe for end users involves using a multi-layered approach to protection. This includes obfuscating valuable code, and using cryptography to protect calls for sensitive logic.
Device attestation is also crucial. This is the ability to check that the device isn’t rooted, that it hasn’t been debugged, and that it isn’t using an emulator. It’s also an important check to make sure there haven’t been any attempts to hook sensitive methods and exfiltrate important data or key material.
Read more about [the arrival of SoftPOS](https://licelus.com/insights/introducing-softpos-the-fast-tracked-financial-trend-ready-to-revolutionize-payments) and how to keep it safe.
### Secure elements to control machine-to-machine communication
In recent years, rogue drones entering airport airspace [have caused delays and cancellations](https://www.theguardian.com/uk-news/2018/dec/21/gatwick-airport-reopens-limited-number-of-flights-drone-disruption).
It’s a trend that’s likely to continue. And one that points to other serious security risks in military and retail settings, where drones are taking on more responsibility.
This topic was covered by Daniel Huebner from Infineon during [a great Java Card Forum webinar session in November](https://javacardforum.com/jcf-2020-webinar-series/). In it, he argued the case for moving the most sensitive credentials of an IoT device (like a smart meter) to a dedicated, external secure element.
Daniel explained that an IoT SAFE applet could sit inside a Java Card secure element and make the communication between the device and the cloud much safer.
For one, it would shrink the attack surface, making it tamper resistant. And it would separate the authentication keys and credentials from the main MCU firmware.
But let’s get back to drones.
Infineon have used this secure element in drones to control where they can go. In other words, stopping them from entering no fly zones.
So, how does it work? Well, GPS sensors send data to the IoT safe applet, where it is signed with a key provided by an official authority. This signed key is then sent to a cloud service, where air traffic control decides whether to authorize it or not.
Without authorization, the drone simply wouldn’t function in certain areas. But conversely, permissions could be given for drones to carry out certain tasks in sensitive areas. One example is checking the rotors in a wind farm. A secure space that drones typically aren’t allowed into.
As we delegate more and more tasks to IoT devices and remote controlled drones and driverless cars, this secure element could be vital for cybersecurity and business confidence.
### Virtual companions and more sophisticated AI
Sticking with the IoT theme, 2021 is likely to see us hand over more and more of our daily tasks to intelligent assistants like Alexa.
It could even be the year when the first steps are taken in the move from virtual assistants to virtual companions - an idea referenced by David Mattin in his fascinating [New World Same Humans](https://newworldsamehumans.substack.com/p/new-world-same-humans-22) newsletter.
The rise in anxiety levels during the covid-19 pandemic together with the move to remote working represents something of a perfect storm. There are now millions of people who are physically isolated from friends and colleagues. People in need of guidance, support, organization, and even therapy.
This helps to explain the popularity of mindfulness apps like Headspace and Calm. But for some, these apps on their own aren’t quite enough. Virtual therapy apps like Woebot - where users can get cognitive behavioral therapy - might just be a pointer to the future. Because while a vaccine will go some way to opening up the world again, it is likely to be an increasingly remote world for many.
In a more isolated, lonelier world, we might start to expect more from virtual assistants than simply changing our Spotify playlist and checking the weather forecast.
We might begin to desire more of a conversation. More of a companion.
Sadly, [hackers](https://licelus.com/insights/why-we-need-to-understand-the-hacker) are likely to be happy with this trend, too. They’d see an opportunity to reverse engineer a virtual assistant app and then pass it off as their own. Tricking people into downloading a bogus one before sending them phishing emails or texts.
Or they might try to carry out a [man-in-the-middle attack](https://licelus.com/insights/how-to-counter-man-in-the-middle-attacks). Hijacking the communication channel between the end user and the virtual companion would make them the recipient of the user’s questions. And that would allow them to ask personal questions of their own. Questions to glean information about someone’s habits and movements for a given week.
That’s why the apps that control virtual assistants need to be protected.
They need code obfuscation to defend against dynamic analysis. And they need communication hardening to guard against man-in-the-middle attacks.
You can [find out more about virtual companions](https://licelus.com/insights/the-evolution-from-virtual-assistant-to-virtual-companion) in an article we wrote earlier this year.
### The need for guidance and the danger of social engineering
The widespread uncertainty that has defined 2020 has led people to look to authorities for guidance.
Wherever in the world you’re reading this, you’ll probably remember one specific moment from the spring where you were told by an authority figure to stay home.
This was an entirely unfamiliar scenario for all of us. In no time at all we had to get used to a new way of living and rules to follow. And in this new normal hackers saw an opportunity. Because the more anxious and desperate people are, the more likely they are to trust emails, texts and telephone calls from supposed authorities.
Bad actors figured out fairly early on in the pandemic that they could abuse this vulnerability. They could masquerade as a trusted voice there to guide people.
They knew that people were more emotional and as such were likely to act with less caution than usual.
Social engineering became so rife so quickly that just a few months after covid-19 entered the vernacular, [Google were detecting 18 million malware and phishing messages per day](https://www.theguardian.com/australia-news/2020/jul/14/google-detecting-18m-malware-and-phishing-messages-per-day-related-to-covid-19).
People had to get used to [glancing down at their phone to see another bogus message](https://licelus.com/insights/why-our-emotions-make-us-more-vulnerable-to-cyber-attacks). Their bank telling them that their transaction couldn’t be processed. Or their mobile phone operator letting them know about a way for them to optimize their contract.
“Just click on this link.”
The coronavirus won’t be with us forever. Life will get back to how it was before. But the uncertainty isn’t likely to go away anytime soon. Not in a world full of fake news and conspiracy theories. A world where the truth is harder than ever to pin down.
As a business you can help to even the odds, though. You can prove to your customers that [you care](https://licelus.com/insights/how-encouraging-empathy-can-help-you-to-develop-safer-apps) about safeguarding their personal data.
Make use of in-app protection to counter dynamic analysis. That way hackers can’t reverse engineer your app and then pass off their own version as the real deal.
And make it clear to your customers the ways you will and will not contact them. That way [you educate them about social engineering](https://licelus.com/security-by-design/responsibility) so they can tell what’s real and what isn’t.
### Smart devices will make the customer journey seamless
The integral role the mobile phone has played in plotting a route out of the covid-19 crisis reinforces just how important the device has become.
Track and trace apps were implemented around the world ([with varying levels of success](https://licelus.com/insights/the-risks-that-threaten-the-success-of-track-and-trace-apps)). And when the first lockdown ended and we ventured outside again in the summer, we scanned QR codes and ordered meals with a few swipes of a screen.
This is just one more example of how a crisis can speed up existing trends. It wasn’t like we weren’t already glued to our mobiles before covid-19. But in the aftermath it looks like they - and other smart devices - will play a vital role in the marketing journey.
As [Gartner explains in a great article about strategic tech trends in 2021](https://www.gartner.com/smarterwithgartner/gartner-top-strategic-technology-trends-for-2021/), we could see the emergence of what’s being termed “total experience”, with smart devices at the forefront.
In that article, Gartner cites the example of a forward-thinking telecoms company that changed its approach during the pandemic. When they reopened, they allowed users to book an appointment via their existing app. Then, when the customer came within a certain distance of the store, the app sent them a notification with social distancing guidelines and tips for what to expect inside.
The telecoms company also used a range of digital kiosks and set things up so that employees could use their own tablets to co-browse the customer’s devices. That way the customer didn’t have to physically touch a device other than their own.
This trend is a little like the SoftPOS one. We were already heading in the direction of a more device-driven, less hands-on type of customer service. But the unique social distancing dynamic of the pandemic has given it a kick.
Lots of trends are born of necessity in a certain moment in time. But they stick around because they meet a specific emotional need and make life easier for people.
The idea of utilizing the devices we carry around with us every day to make the customer journey more seamless is the perfect example of this.
Even after the vaccines arrives next year, expect businesses to continue using the tricks they learned during the pandemic. They could use their apps to promote specific events. Or they might use beacons around the store that lock onto the bluetooth LE on your phone, notifying you about a special offer on a nearby item.
This trend will impact cybersecurity in 2021 because more mobile comms between company and customer means more attack vectors for hackers.
Businesses will have to make sure they secure the most sensitive parts of their apps and libraries. And they’ll need to employ communication hardening to stop man-in-the-middle attacks.
### A more remote world is a zero trust world
The world of work is unlikely to ever be the same again.
There’s an acceptance now across industries that bosses might have a hard time convincing employees to go back to commuting for a couple of hours each day.
Not now that people have realised they can work just as well from home.
Some companies like Twitter [have announced that their employees can work remotely indefinitely](https://www.washingtonpost.com/technology/2020/10/01/twitter-work-from-home/?arc404=true).
There are also likely to be more freelancers out of both choice and necessity. Some will have seen the pandemic as the perfect chance to start afresh doing something they love. Others might have lost their job and look upon freelancing more pragmatically.
Either way, we’re predicting a much more remote world in 2021. And a more remote world is likely to equate to a zero trust world.
We’ve written a lot about [the concept of a zero trust world](https://licelus.com/insights/mobile-security-in-a-zero-trust-world) here at Licel. In essence what we mean is that the real world is very different to the one you might imagine your app being used in.
The real world is full of malware, and jailbroken and rooted devices. There are a billion Android devices out there that don’t even receive the latest updates and so are at risk from attacks.
In 2021 the digital landscape will be very different to previous years. More remote working means more fragmentation of devices, OS and networks. Businesses will need to design for the things they can’t control as well as the things they can.
Thriving in a zero trust world is about a mentality shift as much as anything else. It’s about being prepared for the worst rather than assuming existing security measures will be enough.
Knowing that you can’t rely on the security provided by Android and iOS is actually quite liberating. It means that you take ownership for your app’s security and implement protection mechanisms yourself.
That way you get the peace of mind that your app will be safe to use whatever the environment your end user finds herself in.
### The drive to digitize to stay competitive
The companies that seemed to cope the best during the pandemic were those that understood that the static business is a thing of the past. The ones that realized that they had to be more mobile. More digital.
Other trends that we’ve already covered in this article - like the rise of SoftPOS, and the move to a more remote world - seem to reinforce this idea.
But there’s a danger in companies thinking they have to quickly digitize their operations in order to stay competitive.
When the digitization process is rushed and not properly thought through, gaps can appear. And these gaps can become vulnerabilities that hackers can target further down the line.
Let’s take apps as an example. Some businesses might decide that they need an app in the post-coronavirus world so they can stay close to their customers and notify them along the customer journey. But designing and developing an app takes time. Particularly if you want to do so with security as a key consideration - which is a must in a world of increasingly sophisticated cyber attacks.
A company could decide to speed up the process by developing a hybrid app. [But securing hybrid apps is different to securing native apps](https://licelus.com/insights/what-the-transition-to-hybrid-apps-means-for-security). The protection techniques available to do so aren’t quite as robust.
It’s a challenging position that businesses find themselves in. They need to adapt to a changing world and digitize in order to satisfy their customers and stay competitive. But at the same time, digitizing too quickly without proper planning can lead to a security breach. And a security breach can destroy a company’s reputation for good.
For that reason, security should always come before speed.
Your customers will forgive you for delaying the launch of your latest app. They won’t forgive you for misplacing their personal data.
[Find out about our 7 security by design principles](https://licelus.com/security-by-design) to get a steer on how to develop your apps safely.
## Protect Android App Bundles
[All insights](https://licelus.com/insights)
### Follow us
13 Jan 2021
### How to protect Android App Bundles with DexProtector
URL: https://licelus.com/insights/how-to-protect-android-app-bundles-with-dexprotector
# How to protect Android App Bundles with DexProtector
A defining characteristic of the modern consumer is impatience. We don’t like to wait very long for things these days.
It’s as if a decade or so using social media and the smartphone has recalibrated our brains.
A few years ago, commentators were writing about a desire for instant gratification. But nowadays this is more of an expectation than a desire.
After all, you can listen to that album you’ve just read about right away on Spotify. You can binge an entire season of your favorite show in a single weekend on Netflix. You can even find a date in seconds by swiping a few times on a screen.
This evolution towards a culture of now extends to discovering apps. When we find an app we want to download, we expect to be able to use it almost instantly.
And more often than not, this expectation is realized. That’s largely thanks to the [Play Feature Delivery](https://developer.android.com/guide/app-bundle/play-feature-delivery) service enabled by Android App Bundles (AAB). This feature delivers optimized code and resources tailored to an individual user’s request and specific to their device configuration.
In other words, the end user receives on-demand modules. If there are parts of an app that aren’t relevant to their device, then these won’t be present on it. This in turn reduces the size of the download.
In this article we’ll explore how it works from a developer’s point of view. And we’ll explain how to use [DexProtector](https://licelus.com/products/dexprotector) to keep your AABs safe from bad actors.
### Android App Bundles
Speaking of the Play Feature Delivery, app publishers will be required to use it to deliver assets or features that exceed a download size of 150MB from August of this year. They’ll also [have to use Android App Bundles format](https://android-developers.googleblog.com/2020/11/new-android-app-bundle-and-target-api.html) from the same month to upload any new apps and games.
So, with a little over half a year remaining until this deadline, it seems like a good time to step back and understand what led Google to decide to launch Android App Bundles in the first place.
Well, firstly [they saw how larger-sized apps tended to be disadvantaged](https://developer.android.com/guide/app-bundle). They had lower conversion rates, they suffered from slower downloads, people uninstalled them more frequently (often to save space on their phones), and they had lower update rates.
Coming up with a way to reduce the size of apps, then, had some pretty clear benefits. As did delivering an app people expected. An app that worked well and had good UX.
This is vital in Android’s fragmented marketplace. It’s a completely different world to iOS, where there’s relative uniformity across devices and one single vendor.
Of the millions of Android devices in the world, there’s huge variety in manufacturers, vendors, and OS in use. Delivering unique-to-device (or OS) APK files meant that the app would be optimized. Publishers would be able to cover all bases.
If you had a Samsung S11 running the latest version of Android, there was an APK for you. But there was also one for someone with a Huawei phone made several years earlier and running a much older version of Android.
Before Android App Bundles arrived, developers would achieve this by [using a splits block to create APKs](https://developer.android.com/studio/build/configure-apk-splits) for specific device processor architectures, screen resolutions, and so on. But this was a complex process. And it didn’t provide a uniform way to solve the problem of Android’s massive fragmentation.
AABs provide a solution to this complexity. Compared to the split-APK process, it’s a much more streamlined process.
They come with all of Google’s knowledge about the architecture, libraries, and screen size of specific devices. That means that developers can be sure that the AAB will quickly deliver the most optimized version of an app to their end user.
It even enables end users to get an app even more quickly if they’re only interested in using one specific feature of that app.
Another benefit of AABs relates to Google Play signing. Instead of having to sign each individual APK, you only have to sign the bundle before it’s uploaded to the store.
But what about other protection aside from signing?
### How to protect Android App Bundles with DexProtector
You can secure Android App Bundles by using the protection mechanisms available in both DexProtector Standard and DexProtector Enterprise.
You just need to have DexProtector Enterprise or DexProtector Standard activated - with either a full license or a trial license.
The other requirements are to have Android Studio 3.2 or higher and Android Gradle Plugin 3.2.0 or higher.
So, how does it work?
The protection process for AABs is similar to that used for APKs. In fact, if you already have settings (a configuration file) for your APKs, you can go ahead and use the same ones.
The first step is to prepare and build your Android Application Bundle (AAB, .aab) if you use CLI in DexProtector. Then set up DexProtector's configuration as suggested in the [documentation](https://dexprotector.com/docs). Or, alternatively, just use the existing configuration you’ve created for your APK.
You’ll then be ready to launch the protection process via the CLI.
For example:
```text
java -jar dexprotector.jar -configFile dexprotector.xml -keystore upload.keystore -alias android -storepass android -keypass android build/outputs/bundle/release/app.aab protected-app.aab
```
Via Gradle, you can generate and protect both the APK and AAB:
```text
gradlew clean assembleRelease bundleRelease
```
Or you can only generate and protect the AAB:
```text
gradlew clean bundleRelease
```
If you’d like to test the protected AAB without publishing it on Google Play, you can use the latest version of the bundletool. You can find it at [https://github.com/google/bundletool/releases](https://github.com/google/bundletool/releases).
To publish an AAB that’s protected by DexProtector, all you need to do is upload it to Google Play Console.
To generate APKs from the bundle, use the following command (the APK will be built for a connected device):
```text
java -jar bundletool-all-x.x.x.jar build-apks --bundle=protected-app.aab --output protected-apk.apks --ks sample.keystore --ks-key-alias android --connected-device
```
The bundletool can install the APKs that are produced, too:
```text
java -jar bundletool-all-x.x.x.jar install-apks --apks protected-apk.apks
```
When you publish your AAB to Google Play, you’ll need to set the fingerprint of your app signing certificate in your configuration file. There are more details about this at [Google Play App Signing](https://dexprotector.com/docs#google-signing). You also need to use your upload certificate for signing your AABs.
Or, put another way, you need to set the following tags in your DexProtector configuration file:
```text
google
```
Don’t forget to use your upload keystore:
```text
java -jar dexprotector.jar -configFile dexprotector.xml -keystore upload.keystore -alias alias -storepass storepass -keypass keypass build/outputs/bundle/release/app.aab protected-app.aab
```
### Our latest articles
[View all](https://licelus.com/insights)
- [
**What is a Trusted Application?**
#Threat protection](https://licelus.com/insights/what-is-a-trusted-application)
- [
**How malware spreads: investigating a dangerous infection across India**
#Threat protection](https://licelus.com/insights/malware-spread-india)
- [
**Why virtual trusted execution environments are set to boost mobile payment security**
#Threat protection](https://licelus.com/insights/why-virtual-trusted-execution-environments-are-set-to-boost-mobile-payment-security)
## Personalization vs. Security
[All insights](https://licelus.com/insights)
### Follow us
12 Feb 2021
### The delicate balance between personalization and security
URL: https://licelus.com/insights/the-delicate-balance-between-personalization-and-security
# The delicate balance between personalization and security
For most people, personalized products and services have often been out of reach.
That’s because personalization used to mean premium. If you wanted it, you had to pay a high price.
Nowadays things are changing. We live in a digital world full of data where customization is sometimes a simple swipe away.
Chances are you might even take your daily dose of personalization for granted.
Think about the playlists Spotify creates from your liked songs. Or the shows Netflix wants you to watch next based on your recent viewing habits. Even dating apps like Hinge match you up with potential partners according to your past preferences.
The amount of data you share about yourself every day enables you to move in a digital direction that is uniquely yours. And in the coming years it’s a journey that’s likely to take you to some interesting places indeed.
There’s just one potential snag to this easier route toward personalization. By sharing more data about ourselves, we attract the attention of bad actors who are quick to recognize the value of it.
Almost without noticing it, we’re immersing ourselves in a digital landscape that we’ve painted ourselves. And once we’re inside that canvas we’re much less likely to spot an uninvited guest. Somebody who’s pretending to be a permanent feature there.
Recognizing this fact today can help us make sure we maintain a healthy balance between personalization and security.
### The evolution of personalization
For the most fortunate in society, material possessions alone don’t quite cut it anymore. For them, [fulfilment is to be found on a higher plain](https://newworldsamehumans.substack.com/p/new-world-same-humans-45) - namely in meaning and creativity.
They often look to online spaces to satisfy this demand. That might be via a social media app on their smartphone, or a multiplayer game on their Playstation.
The digital worlds where people spend more and more of their free time are full of personalization. Video games are increasingly becoming [virtual escapes for an hour or two](https://licelus.com/insights/protecting-the-virtual-worlds-of-the-future). Players don’t just get to dress and equip their virtual characters anymore. They can even shape their journey in a way that’s unique to them.
We’ve also carved out spaces for ourselves on social media. Apps have made it possible for us to curate the content we consume there.
Whatever your passion, whatever your niche, you can create a digital world that suits you. Your Instagram feed can become a kind of personal gallery. Or you can settle in to follow a modern-day debate on Twitter that appears to have been designed just for you.
All from your fingertips. And all of it thanks to the power of data.
The flood of data in recent years has created a customized world. A world so normalized that it seems hard to believe that it’s only been with us for a decade or so.
Before we were swimming in data, personalization was a lot harder to come by. \"Made to Measure\" is a concept that has existed for hundreds if not thousands of years. But it’s never been as inclusive as it is today.
### From physical to digital personalization (and back again)
The evolution of personalization is being driven by new technologies. From facial recognition to advancements in AI and the semi-invisible sensors that surround us.
In the coming years, this technology won’t only continue to customize our digital experiences. It will enable them in the real world, too.
Physical stores are opening up that use this new technology to provide a more engaging experience for their customers. Take [the flagship CoverGirl store in New York](https://www.springwise.com/covergirl-opens-high-tech-flagship-store-in-new-york-city/), for example. It makes use of augmented reality stations so visitors can try on makeup virtually and see the results before they buy.
Increasing numbers of brands are now using GPS together with their company apps to send notifications to customers when they come near the store.
Something that might previously have reminded us of a scene from Minority Report is becoming standard practice.
Imagine a retail company has data on your previous shopping habits or they know you’ve been browsing a particular item online that is now available and discounted in store. A quick notification when you get within range could be too tempting an offer for you to turn down.
The [covid-19 pandemic was a good testing ground](https://licelus.com/insights/7-trends-that-will-impact-cybersecurity-in-2021) for what’s likely to become the norm for marketing in the 2020s. Socially distant shoppers reliant on their smartphone to make orders and sign into physical locations enabled forward-thinking brands to experiment.
Expect them to learn from it and to communicate differently with customers once the world slowly returns to normality.
Other companies like Affectiva are using [machine learning to develop algorithms that can map facial expressions](https://www.mckinsey.com/business-functions/marketing-and-sales/our-insights/the-future-of-personalization-and-how-to-get-ready-for-it). This opens doors to the possibility of marketers communicating with (and sending promotions to) customers in a specific way based on their mood.
Technologies like these will aid personalization both in store and inside the home.
The end goal for the 2020s - and something we’re already seeing the beginnings of - is an ecosystem of connected devices and sensors working within the home in tandem. Perhaps controlled by a [virtual companion](https://licelus.com/insights/the-evolution-from-virtual-assistant-to-virtual-companion) that can do much more than tell you the weather forecast and change your Spotify playlist.
Your smart home will know when you want your coffee brewing in the morning. It will know when you need to heat up the car, and when to turn off the lights.
The potential of personalization to businesses that get it right is huge. But getting it right involves [having empathy for your customers](https://licelus.com/insights/how-encouraging-empathy-can-help-you-to-develop-safer-apps) and finding the right balance between personalization and security.
Especially in a world where [cybersecurity threats are more varied](https://licelus.com/insights/why-we-need-to-understand-the-hacker) and more subtle than they’ve ever been.
### Finding the right balance between personalization and security
A brand taking an interest in you and treating you like an individual rather than a generic customer is a nice feeling. It can make a real difference to how you see your long-term relationship with that company.
But there’s a fine line between caring and creepy.
Remember that old story about [Target figuring out a girl was pregnant before her father did](https://www.forbes.com/sites/kashmirhill/2012/02/16/how-target-figured-out-a-teen-girl-was-pregnant-before-her-father-did/?sh=67a122296668)?
In [a Gartner survey](https://www.gartner.com/en/newsroom/press-releases/2019-03-11-gartner-survey-shows-brands-risk-losing-38-percent-of)of more than 2,500 customers, almost four in 10 said they’d stop doing business with a company if they found their personalization efforts to be creepy.
The better personalization gets, the greater the potential costs to individual privacy. But there are ways companies can make sure they stay on the caring side of the road.
Smart businesses looking to the long term can take a lead on “[minimum viable data and controls](https://www.mckinsey.com/business-functions/marketing-and-sales/our-insights/consumer-data-privacy-and-personalization-at-scale)” required to empathetically engage their customers at scale. So, that means contacting them at time periods (and intervals) that suit them, rather than overwhelming them and scaring them away.
Academics and industry leaders are also exploring approaches that resolve the natural tension between personalisation and privacy. This includes embracing something called [fully homomorphic encryption](https://www.ft.com/content/e00886f6-ca70-11e9-af46-b09e8bfe60c0). That would allow people to search for products or services online without third parties chasing them around the internet reminding them that they'd done so.
Clear communication is a vital part of the delicate balance between personalization, too. Businesses don’t only have to be clear with their customers about how they use their data. They also need to be upfront about how customers are likely to hear from them.
After all, bad actors often look to exploit the wealth of communication channels that exist. We’ve seen that in the past year during the covid-19 pandemic. A side-effect of the global crisis has been a massive hike in social engineering.
People have sadly had to get used to looking down at their phone to see a bogus text message or email from an individual or group pretending to be their bank. Urging them to click on a link.
We can often spot these phishing messages. [But not always](https://licelus.com/insights/why-our-emotions-make-us-more-vulnerable-to-cyber-attacks). To the untrained eye, a text message from a hacker pretending to be a bank can look just like the real thing.
Suppose your bank tried to personalize your experience with them by suggesting you could receive account updates via text message. Then imagine that shortly after approving this change you receive a bogus message from an opportunistic bad actor.
There’s no easy solution to this problem. The best way for companies to operate is to be completely transparent with their customers while also developing their apps and software by following [security by design principles](https://licelus.com/security-by-design).
A lot of phishing and [man-in-the-middle attacks](https://licelus.com/insights/how-to-counter-man-in-the-middle-attacks) try and trick people into downloading fake applications. Once someone has downloaded it, hackers can glean their valuable personal information such as passwords or even bank account details.
Bad actors also probe genuine applications in order to try and steal sensitive logic and data, or to run a dynamic analysis and reverse engineer the app for their own benefit.
### A convergence of fast-moving trends
The examples above help to explain why the balance between personalization and security is such a delicate one right now.
We’re living at a time of incredible change. A time where trends were already moving at a rapid pace before they were given a push by the covid-19 pandemic.
Personalization is one of these trends. And it’s converging on another one - [the increasing importance of applications to business success](https://licelus.com/insights/3-trends-that-make-mobile-app-security-impossible-to-ignore).
The very same apps that will play a vital role in the customization of customer experiences.
Mobile apps were already an attractive target for bad actors before they collected a mountain of valuable data about customer preferences and desires.
Part of finding the right balance between personalization and security will be protecting these applications properly.
Companies will have to invest in threat intelligence systems to understand the evolving threats their app is up against. And once these risks are recognized, they’ll have to make sure their app is equipped with robust security. This includes environment checks and integrity checks to spot emulators as well as debugging and hooking attempts.
The fact that customized products and services are available to the masses is a wonderful thing. For both businesses and their customers, the potential benefits of personalization are huge.
But so are the risks of getting it wrong.
The companies most likely to succeed in the next few years are those who are already thinking about this fine balance.
## Cybersecurity in Healthcare
[All insights](https://licelus.com/insights)
### Follow us
12 Mar 2021
### How to stop the surge of cyber attacks against the healthcare sector
URL: https://licelus.com/insights/how-to-stop-the-surge-of-cyber-attacks-against-the-healthcare-sector
# How to stop the surge of cyber attacks against the healthcare sector
In the UK, the government’s covid-19 campaign message sits on a deliberately garish sign. The type of sign that would normally warn you of an accident up ahead on a highway.
**Stay Home. Protect the NHS. Save Lives.**
It’s the second of these three statements that is given the most prominent font. The one that jumps out at you the most as you read it.
Protect the NHS.
It speaks to a fear the UK government has - and they’re not alone - of their healthcare system becoming overwhelmed by the virus.
But not everyone worries about a stretched healthcare sector. Cybercriminals see it as an opportunity. Something they can exploit.
Because while attention is focused on fighting fires, doors can be left ajar. And longer-term protection measures tend to be ignored.
In a way, the covid-19 pandemic has provided the perfect distraction for bad actors. It has given them a helping hand to break through security systems and steal priceless personal medical records.
As we approach the first anniversary of a world living with covid-19, it seems like a good time to take stock. To assess the surge of cyber attacks in healthcare, and to ask some important questions.
What has covid-19 taught us about the kind of threats the industry is likely to be up against in the coming years?
And crucially, what can we do to protect it from these threats?
### A wave of lost medical records
The healthcare sector is sometimes compared to the financial industry because both are prime targets for bad actors. If anything, though, attacks against hospitals are much more dangerous than those against banks.
Imagine you were the victim of a hack on your bank account. Awful as that scenario sounds, you’d be likely to get the money back that was stolen from you.
But that isn’t the case with your medical records.
Once they’re gone, they’re gone.
If you’re in the public eye, a bad actor might try to use your records against you as blackmail. Otherwise, they would likely end up on [the dark web](https://www.cbsnews.com/news/hackers-steal-medical-records-sell-them-on-dark-web/), packaged together with thousands of others for a fee. And these medical records command a high price because of the personally-identifiable information like addresses and bank account details that they contain.
Or, in other words, everything a fraudster needs to pretend to be you.
A glance at some of the most noteworthy cyber attacks in healthcare in the last 12 months highlights [the scale of this problem](https://healthitsecurity.com/news/the-10-biggest-healthcare-data-breaches-of-2020-so-far).
640,000 patient records in Florida, 288,000 in Missouri, and another 166,000 in Georgia. All lost to successful ransomware and phishing attacks.
But it isn’t only medical records that are being stolen and then listed for sale on the dark web. You can also find fake insurance cards and health IDs.
The idea of [vaccination certificates or passports](https://www.theguardian.com/world/2021/feb/24/four-key-questions-on-a-covid-certification-scheme-in-england) has been mooted in recent weeks. But imagine the danger of these details being stolen and sold on the dark web alongside medical records and health IDs. People could pretend to be vaccinated against covid-19 when they’re not, leading to more chaos and a lack of trust in policies to leave the virus behind.
### When cyber attacks risk lives as well as livelihoods
The healthcare industry - like all others - is rapidly digitizing. Wider trends were already pointing towards increased use and uptake of connected devices, apps, and virtual doctor’s appointments. But the necessity of self isolation brought about by the covid-19 pandemic has given all of them a push.
As we’ve mentioned before on this site, crises have a habit of doing this. [Of moving us beyond a threshold](https://licelus.com/insights/7-trends-that-will-impact-cybersecurity-in-2021). And the last year or so has a strong “no going back” feel to it. Especially in the healthcare sector.
The risk, of course, is that this [rush to digitize](https://licelus.com/insights/the-delicate-balance-between-personalization-and-security) happens without the appropriate protection in place to ward off a new kind of threat. That we end up in a situation where citizens desperate for medical advice are willing to take their chances with dangerous adware and spyware on apps.
After all, wellness and health apps and their associated smart devices are already completely normalized. People don’t only use them for guided meditations and to track their fitness goals. They’re also used by those suffering from diabetes to get advice and to track glucose levels, for example.
But without proper security, these health apps can be at risk from bad actors. Hackers can perform a dynamic analysis on apps and then reverse engineer them - perhaps later passing them off as the real thing via a phishing campaign. They can inject an app with malware. And they can leak unprotected personal data - together with app logic - to their own private server.
It’s almost as if the relative novelty of healthcare apps is giving hackers a head start.
Until developers [start thinking like a cyber criminal](https://licelus.com/insights/why-we-need-to-understand-the-hacker) and locking doors as they’re added to app infrastructure, bad actors will continue to profit from people who place their trust in apps to help them get better.
Unlike [the financial industry](https://licelus.com/insights/how-to-secure-a-safer-future-for-mobile-banking), cyber attacks in healthcare can risk lives as well as livelihoods. Devices like pacemakers are hackable. As are a range of devices commonly used inside hospitals that doctors and patients rely on every day.
Attacks on hospitals can divert attention away from life-saving procedures and can cause critical delays. They can deliberately mislead medical professionals, resulting in potentially catastrophic decisions being taken.
To most of us, the idea of attacks like these that put people’s lives at risk sounds too hideous to be true. But sadly they do happen, because cybercriminals don’t care about the impact of their attacks on individuals.
They only care about what they stand to gain.
### Balancing cybersecurity with patient care
The fact that hackers won’t stop to consider the consequences of their attacks on individuals is a truth healthcare professionals are slowly coming to terms with.
But doctors and nurses aren’t trained in cybersecurity. They’re trained at providing care for patients and saving their lives. Even before covid-19 arrived, medical personnel often struggled to prioritize cybersecurity when there was a backlog of other urgent tasks requiring their attention.
Cancer patients have complained of delays to their surgery in the last year. And other operations seen as non-urgent have been put on hold. In a climate of urgency to deal with a steady tide of covid-19 patients, it stands to reason that [cybersecurity measures might also have been put to one side](https://www.computerweekly.com/feature/How-can-healthcare-organisations-fight-increased-cyber-crime-in-2021).
Bad actors know this too, of course. In the same way that [they’ve preyed on the general anxiety of citizens](https://licelus.com/insights/why-our-emotions-make-us-more-vulnerable-to-cyber-attacks) with phishing emails and text messages ([including about covid-19 vaccines](https://www.bbc.co.uk/news/uk-england-hampshire-55840397)), they’ve also exploited this weakness at hospitals.
The coronavirus will eventually become a more manageable problem like the flu - perhaps later this year. But even when that happens, it will still be a challenge to balance patient care with protecting the very data that helps hospitals provide that care.
Compared to other industries like finance, [healthcare is much less well prepared](https://www.theverge.com/2019/4/4/18293817/cybersecurity-hospitals-health-care-scan-simulation) to deal with modern, sophisticated cyber attacks. Not only do most hospitals not have the resources to monitor threats, but they might not even know what these threats are - or how to spot them.
Another issue is the level of fragmentation of devices and software in use across a typical hospital.
This fragmentation can act as an invitation to cybercriminals.
They will scope out the software or app that has the most obvious security hole and will then use that as their way into the wider system.
This problem is exacerbated by a common reliance on legacy systems which can lag behind compared with the safest tech architecture.
### Where are the regulations?
If we continue with the comparison between the healthcare and financial industries, another key difference relates to regulations.
The financial industry has long recognized the importance of regulations to make sure that all banks and payment providers are on the same page when it comes to cybersecurity.
This isn’t really true of the healthcare industry. In fact, some developers of healthcare applications actually use financial regulations as a best practice guide for protecting their own app.
A lack of app security regulations in particular might be down to the fact that the focus in healthcare has often been around data protection rather than securing the apps and devices that collect that data. But this system is flawed because apps are one of the first places a bad actor would target in order to eventually access valuable personal data.
A hospital can be fined by a regulatory body like HIPPA for misplacing personal medical information. They can also be [sued by the patients whose data has been lost](https://healthitsecurity.com/news/patients-sue-wilmington-surgical-for-netwalker-ransomware-data-leak). Currently, though, there isn’t as much incentive for them to protect software and applications.
More robust regulations might be needed as a push for the healthcare sector to take cybersecurity as seriously as the financial industry.
Especially in the near future when technological advancements will naturally lead to the use of even more mobile applications. Not only in hospitals but in the home, too.
There are signs that [more legislation is on the horizon](https://healthitsecurity.com/news/hipaa-safe-harbor-bill-becomes-law-requires-hhs-to-incentivize-best-practice-security). But there clearly needs to be a bit more urgency.
## **Securing the future of the healthcare sector**
There’s no use denying it. The healthcare industry is going to have a tough time in the coming years. Cyber threats are becoming more complex and now arrive from multiple angles and sources. The sector will have to defend against these threats at the same time that it counts the cost - both financial and mental - of the covid-19 pandemic.
But unfortunately cyber attacks in healthcare aren’t going away. Bad actors are unlikely to suddenly develop a conscience and think twice before targeting hospitals and the developers of medical apps.
It’s probably only a matter of time before an attack leads to a serious event that brings worldwide attention to this threat.
So, what can we do to stem the tide of these attacks?
As we’ve said, regulation can help players across the sector ensure they’re following security best practices. Until that regulation exists, it’s a good idea to review respected cybersecurity guidelines such as those at [OWASP](https://owasp.org/).
If you’re a developer of medical applications for use in hospitals and the home, you can use guidelines like these to develop applications with security in mind.
Speaking of which, [security by design principles](https://licelus.com/security-by-design) can help you to see the bigger picture of who is responsible for protecting applications. Not to mention putting yourself in the shoes of both your end user and the hacker in order to spot potential weaknesses and threats. This is vital if you’re to carry out a proper risk model.
You should also invest in robust in-app protection that stops hackers from performing a static or dynamic analysis on an application. This protection should ideally use multiple layers of security that keep strings, resources, classes, and logic encrypted and securely out of reach.
Quality in-app protection also comes with environment checks that are able to [spot signs of tampering](https://licelus.com/insights/how-to-counter-the-dangers-posed-by-tampering) as well as hooking attempts, rooted devices, debuggers, and emulators.
In the coming years the ecosystem of medical applications will grow. And people will become increasingly reliant on them to recover from home. As such this protection will be vital. But so too will threat intelligence systems that paint a detailed picture of the types of threats apps are up against.
In the financial industry, banks are now sharing this intelligence with one another [to collectively arm themselves against the growing cyber threat](https://licelus.com/insights/how-threat-intelligence-can-stop-the-spread-of-cyber-attacks). This is something that healthcare providers can learn from.
Within hospitals and other treatment centres, education is going to be crucial, too. There has been a recognition of cybersecurity being important, but it hasn’t been seen as a priority. Clearly it will still come second to patient care, but doctors and nurses will need at least a basic understanding of threats in the near future. That way they’ll get better at spotting phishing attempts and will understand where the typical malware entry points are.
It’s also likely that more cybersecurity experts will be hired into the healthcare sector. And one of their most important tasks will be to tell a story that resonates with doctors and nurses. To make a clear link between cybersecurity and patient care and explain how one benefits the other.
In recent months it has often felt like there’s little hope in the defence against hackers. But a combination of the measures outlined above can help us to alter the landscape.
They can stop the surge of cyber attacks in healthcare.
## App Security Best Practices
[All insights](https://licelus.com/insights)
### Follow us
16 Apr 2021
### 9 App Security Best Practices Developers Should Follow
URL: https://licelus.com/insights/9-app-security-best-practices-developers-should-follow
# 9 App Security Best Practices Developers Should Follow
It’s not an exaggeration to say that applications have revolutionized our world.
Their influence has been so vast that it’s hard to believe that mobile apps didn’t exist a little over a decade ago. Today we turn to apps as soon as we wake up and tend to use them right up until we go to sleep at night.
Apps aren’t only integral to our everyday lives, though. They’re also vital for business success. After all, for some companies their app is everything. Think about mobile banks and payment solution vendors. There’s no physical store for people to visit - it’s just the app.
That’s why application security is so important.
A more remote post-pandemic world is likely to make us even more reliant on apps. And businesses will grow to realize that their livelihoods and reputations simply depend on robust in-app security.
The 9 app security best practices below are a guide for you to safely navigate this new reality.
### Think about security right from the start
Most forward-thinking companies now accept that app security cannot be an afterthought.
Not least because it simply isn’t efficient to think this way. Attempting to plug gaps after they’ve been spotted doesn’t make any sense because they might not have only been detected by your SecOps team. Hackers might also be aware of them already.
It’s a much better idea to use [security by design principles](https://licelus.com/security-by-design) from the outset - before a single line of code has even been written.
Your end users will happily allow your app access to their data - but only if you can prove to them that you’ll look after it safely.
The best way to do so is to put yourself in their shoes and show a little [empathy](https://licelus.com/insights/how-encouraging-empathy-can-help-you-to-develop-safer-apps).
A proper threat model should involve thinking about all of the ways these end users will use your app in the real world. And it’s worth bearing in mind that the real world increasingly means a [zero trust world](https://licelus.com/insights/mobile-security-in-a-zero-trust-world) full of outdated OS, malware, and rooted devices.
Another useful exercise is to [look at your app from a bad actor’s perspective](https://licelus.com/insights/why-we-need-to-understand-the-hacker). What are the potential attack vectors of your application? What kind of sensitive data or logic would they be most interested in stealing?
Answering these questions can help prevent vulnerabilities from creeping into your code at different points along the development journey.
### Obfuscate and harden your apps and SDKs
Embracing security by design principles from the outset is a smart idea because it makes it less likely that hackers will be able to spot weaknesses in your code.
It means that doors aren’t left ajar for attackers to squeeze through.
These are the places bad actors look for in order to start an attack that could later lead them to reverse engineer your app or tamper with it.
One way to stop them achieving this goal is to harden and obfuscate your code.
Hardening code makes it tougher for a would-be attacker to read it and can help prevent real-time attacks. Obfuscation, on the other hand, is all about hiding implicit values and concealing logic. Ideally this obfuscated code can then be moved to an isolated, secure container (more on this later).
It’s also worth testing and reviewing your code from time to time to make sure that it’s as robust as it needs to be. That way you’ll be sure you’re ready to deflect the most current threats.
### Encrypt your data
Done well, encryption is like some kind of [steampunk puzzle](https://www.youtube.com/watch?v=Ewng3j0iO8E). It hides the assets you value most in your app behind a scrambled, impossible-to-decipher code.
Even if a cybercriminal were to find it, they’d have no way of making sense of it as they wouldn’t have the key required to crack it.
It’s for that reason that hardy encryption should form the bedrock of your app security strategy.
Because with context-sensitive encryption keys, it isn’t possible for a bad actor to carry out a static analysis on your application. And that’s typically their first step before carrying out follow-up attacks.
Encryption can be performed on strings, classes, native libraries, and other assets such as media files, text files, and HTML files. This is important, because even seemingly insignificant assets inside your app’s code can be attractive to bad actors. These assets can offer clues about how your app has been put together and where the most valuable data might be kept. That’s why it’s vital that as many of them as possible get encrypted.
The end goal you’re aiming for is for a hacker to be put off carrying out an attack. For them to realise that it simply isn’t worth a massive investment in their time to attempt to decipher your app’s encryption.
More often than not, that’s exactly what they’ll decide.
### Sophisticated cryptography and secure containers
The best kind of security uses interconnected layers of protection to safeguard apps and SDKs. This is particularly vital for sensitive apps in FinTech or MedTech that carry critical logic that relies on cryptography.
If you have one of these apps, code hardening and encryption alone might not be enough. You’ll also need somewhere safe to store your cryptographic keys.
Think about payment apps, for example. They tend to use a secure, isolated container to process transactions and store key material.
This container acts as a safe environment - much like a smart card or HSM. It’s a place hackers aren’t able to gain access to.
As [this article](https://security.googleblog.com/2021/03/announcing-android-ready-se-alliance.html) explains, Google recognizes the need for secure environments to perform cryptographic operations and store sensitive key material and different types of credentials.
That’s because the beauty of clever cryptography like this is that it provides protection not just within your app but around it, too. It’s security that can operate between your app and the operating system.
In much the same way as robust encryption, these layers of protection act to put off cybercriminals. They find themselves up against a solid steel chain rather than individual weaker elements they can knock over one after the other.
### Use tamper detection
A common attack employed by hackers is to attempt to tamper with the code inside your app. They might try to modify it, or inject their own malicious code in the form of malware.
An attacker might even tamper with an app and then try to pass off a fake version they’ve repackaged as the real thing.
There are a lot more of these bogus modified apps available to download than you’d think.
Code signing with cryptographic keys goes some way toward curbing tampering attempts. By signing their code, companies are validating the authenticity of that code and are tying their reputation to it. But sadly there’s nothing to stop a bad actor from using their own random keys to sign a modified app.
That’s [why tamper detection is such a vital part of app security](https://licelus.com/insights/how-to-counter-the-dangers-posed-by-tampering). It can tell you when your code has been modified and prevent any of that code from functioning if it has.
In practice this is done via environment checks and integrity checks at runtime. These checks spot the most common tools used by cybercriminals to reverse engineer your application. These include emulators and debuggers as well as hooking and rooting attempts.
### Educate your end users
The covid-19 crisis proved that hackers are skilled at exploiting vulnerabilities. They witnessed the collective anxiety around the virus and our eagerness to trust authorities. So, they decided that they’d pretend to be those authorities.
The pandemic has been defined by staying indoors and a shrunken world. But with it has come a soundtrack of bogus text messages arriving at our phone. Bad actors pretending to be a healthcare provider offering a vaccine or a bank sending a monthly statement. All of these messages are bookended with a grim call to action that [many have sadly fallen for](https://licelus.com/insights/why-our-emotions-make-us-more-vulnerable-to-cyber-attacks):
**“Just click on this link.”**
The lesson from all of this is how vital it is to educate your end users.
That might be making them aware of how and when you’ll contact them, so they’re more likely to ignore phishing campaigns like these. It could be asking them for a strong password or biometric credentials. Or it might be making them aware of how they can use the app safely - such as being aware of open wifi connections.
### Be wary of third party code and libraries
You shouldn’t feel like you have to reinvent the wheel with your app development. That said, it’s important to strike a good balance between using your own code and libraries and those created by third parties.
As we’ve said [elsewhere on this site](https://licelus.com/security-by-design/clear-and-simple), a key cybersecurity principle is that the fewer links and access areas you create, the better.
It’s not the case that all outside libraries and frameworks are dangerous. In fact some respected frameworks are probably safer than using your own code. It’s just that the more of them that you use, the greater the chance that you’ll come across one that has been infected with malware.
And if you use a lot of them, you might also be unsure as to where that malware has come from.
When you do come across third party code and libraries, make sure that you test them thoroughly before they become a permanent feature of your app. And always check that you’re using the most up to date version of them.
### Defend against man-in-the-middle attacks
A common mistake is to assume that app security is limited to protecting what is happening inside your application alone. Actually, it extends to the channels of communication that flow between it and the server.
Cybercriminals can try to trick an application into communicating with their private server rather than the genuine one used by a banking app, for example. This is called [a man-in-the-middle attack](https://licelus.com/insights/how-to-counter-man-in-the-middle-attacks).
And if the app doesn’t have any defence against fake server certificates, hackers can intercept messages with sensitive information like bank account information. They can even modify that information.
Man-in-the-middle attacks often start out as the phishing scams we mentioned earlier.
Someone is targeted with a text or email - supposedly a genuine one from their bank - and then they’re redirected to a page where they’re asked to share personal information.
Google’s [Certificate Transparency](https://certificate.transparency.dev/) project helps to stop man-in-the-middle attacks by fixing some of the structural flaws in the SSL certificate system. It also identifies those SSL certificates that have been issued maliciously.
Another key defensive tool is called public key pinning implementation. This secures the SSL certificate pin which often acts as the base for hackers trying to intercept your communication channels.
### Security never stops
Technology is always changing. The way we interact with our phones and other smart devices evolves from one year to the next.
[Risks and threats change almost as quickly as technology trends](https://licelus.com/insights/3-trends-that-make-mobile-app-security-impossible-to-ignore), which means that the security mechanisms you had in place last year might not offer complete protection this year.
That’s why it’s so important to understand the threat landscape of your application and to revise your threat model accordingly.
By employing what we call threat intelligence you’re effectively turning the table on the cybercriminals. You open a curtain and are able to look out and survey your app’s neighbourhood.
This view can give you all the insights you need to carry out a proper risk analysis.
In practice this might mean spotting some unusually-high API usage which can be a sign of malicious activity. With a sophisticated risk analysis system, [a bank could even link security incidents to individual customers](https://licelus.com/insights/how-threat-intelligence-can-stop-the-spread-of-cyber-attacks) and take actions there and then.
Hackers don’t stand still. They’re constantly monitoring trends to get a better understanding of where they can get an edge. As developers you need to do exactly the same thing.
Because in the coming years the success of applications - which increasingly translates to overall business success - will not only be defined by cool features and smart UX.
More than anything else, they will be judged by how well they protect end users’ sensitive data.
### Our latest articles
[View all](https://licelus.com/insights)
- [
**How to incorporate mobile app security testing into your build pipeline**
#Security by design](https://licelus.com/insights/how-to-incorporate-mobile-app-security-testing-into-your-build-pipeline)
- [
**Balancing security and usability**
#Security by design](https://licelus.com/insights/balancing-security-and-usability)
- [
**Ongoing Security: a step-by-step guide to a secure app development process**
#Security by design](https://licelus.com/insights/ongoing-security-a-step-by-step-guide-to-a-secure-app-development-process)
## Understanding Hackers
[All insights](https://licelus.com/insights)
### Follow us
25 May 2021
### Why we need to understand the hacker
URL: https://licelus.com/insights/why-we-need-to-understand-the-hacker
# Why we need to understand the hacker
There’s an image that’s commonly used to portray cybercriminals.
A hooded character with a Guy Fawkes mask sits behind a laptop and looks out toward the viewer. It’s become the go-to image to accompany any article about bad actors - or even any article about cybercrime in general.
Type the word “hacker” into a Google image search and you’ll see about a hundred different variations of it.
You might think this is just a helpful representation of a mysterious, faceless entity. But actually this generic image speaks to our collective reluctance to understand the hacker.
And this is a problem when we’re living in a world full of sophisticated cyber threats. A world where attacks are arriving from all angles and are becoming more and more brazen.
In such a world, wouldn’t it be better to try to understand who the hacker really is instead of simply assuming that they’re all the same?
Forward-thinking companies are beginning to realize that by doing just that, they can create a much more robust risk analysis.
They’re starting to see empathy for the hacker as a key pillar of a successful cybersecurity strategy.
### Just click on this link
In an attempt to summarize the impact of the Covid-19 pandemic, [Yuval Noah Harari offered a stark warning](https://www.ft.com/content/f1b30f2c-84aa-4595-84f2-7816796d6841). He said that while information technology has made us more resilient against the threat of organic viruses, it has also made us much more vulnerable to the threat of cyber warfare.
When he pondered what the next Covid-19 might look like, the growing number of headlines describing damaging cyber attacks came to his mind.
[One of these headlines](https://www.nytimes.com/2021/05/09/business/energy-environment/colonial-pipeline-shutdown-gasoline.html?campaign_id=158&emc=edit_ot_20210510&instance_id=30547&nl=on-tech-with-shira-ovide®i_id=124987873&segment_id=57694&te=1&user_id=aa941bcb44db0d2d61ff3ca77355d578) filled our Twitter feeds recently. It told of the forced shutdown of a vital petroleum pipeline in the US after a ransomware attack. The article warned of the potential impact of such an attack on people’s day-to-day lives. Most notably at the fuel pumps.
As it turns out, it was a pretty astute prediction. Because just a few days later, cybercrime journalist Brian Krebs tweeted the following:
\"Incredible\" seems like an appropriate word today. But will it continue to be in a few years? Perhaps in the near future inconveniences like this will just be part of our daily lives.
At least that is if the current trends continue in the same direction. With the pandemic as a backdrop, life has been punctuated by phishing emails and [texts pinging to our phones](https://licelus.com/insights/why-our-emotions-make-us-more-vulnerable-to-cyber-attacks). It might have been an issue with your bank account. Or perhaps it was an offer to [go and get your first Covid vaccine](https://www.bbc.co.uk/news/uk-england-hampshire-55840397). Whatever the ruse, the call to action was a grim one laced with malware.
In many ways, a result of all of these attacks has been to bring hackers to the public consciousness more than ever before. But the profile of bad actors is still largely a mystery. It’s the same masked figure staring back at us, offering us nothing.
So, why is it that the default position is still to keep cybercriminals masked and hidden from view?
### Who’s really behind the mask?
One answer to the question of why the hacker is deliberately mystified is that investigating who the hacker really is can result in some troubling findings. In many ways it’s far simpler to assume the hacker is some kind of dark, malevolent force who’s interested only in spreading chaos and pain.
The reality, of course, is much more nuanced.
A lot of hackers end up doing what they do almost by accident. Others might be misled or even controlled by those at the head of the criminal gang they work for. Realistically they might have very little option but to continue doing what they’re doing. What’s more, the big picture of how their role is causing damage to lives and livelihoods might be hidden from them.
This isn’t to somehow reduce the significance of the damaging attacks we’ve seen over the course of the last year or so. The intention here isn’t to excuse cybercriminals. After all, [hospitals have been attacked](https://licelus.com/insights/how-to-stop-the-surge-of-cyber-attacks-against-the-healthcare-sector), resulting in vulnerable people having vital treatment delayed. Others already impacted by the effects of Covid-19 have had money stolen from their bank accounts.
Instead, what we’re suggesting is that all of us who work in cybersecurity have a responsibility to better understand how somebody becomes a cybercriminal in the first place.
By doing so, we might be able to offer an alternative, more positive path for these people. That should be the end goal.
Until then, the watchword should be [empathy](https://licelus.com/insights/how-encouraging-empathy-can-help-you-to-develop-safer-apps) rather than ignorance. App developers are quite used to putting themselves in their end user’s shoes, but imagining themselves as a cybercriminal is a much less common exercise.
The first step on this journey is to realize that not all hackers are the same. Some are part of state sponsored groups, while others are individuals who want to test their skills. Most attacks that target businesses come from outside, but some are carried out by employees who feel wronged in some way.
### Evolving attacks
Tillie Kottmann, a Swiss hacker who’s part of a group responsible for hacking into the Verkada security camera system, [doesn’t fit the typical cybercriminal profile](https://www.theverge.com/2021/3/19/22339625/tillie-kottmann-swiss-hacker-verkada-charged-us-government-verkada). When asked about the group’s motivations, Kottmann replied:
“Curiosity, fighting for freedom of information and against intellectual property, a huge dose of anti-capitalism, a hint of anarchism — and it’s also just too much fun not to do it.”
Obviously not all cybercriminals are as politically motivated as Tillie. As we’ve said, some have much less agency over their actions. But it’s important to understand that for some groups, motivators aren’t only financial.
For those hackers who are financially motivated - still by far the majority of them - we’ve seen hints in recent months that they’re changing their approach and becoming much more brazen.
A good example of this comes in [an article](https://www.forbes.com/sites/leemathews/2021/03/28/a-ransomware-gang-is-asking-victims-customers-to-aid-in-extortion-efforts/?sh=3b2bb8c20022) that caught our attention earlier this year. It is about a cyber gang that has taken to reaching out to the customers of their ransomware victims with a view to getting those customers to help with their extortion efforts.
The email the gang would send goes something like this:
“Company X clearly doesn’t care about your data because they haven’t invested in robust cybersecurity. So, do us a favor and tell them how angry you are. And encourage them to pay the ransom we’ve asked for. If you don’t, your personal information might end up on the dark web for a price.”
While cybercriminals attempting to make you complicit in their extortion efforts is a worrying trend, there’s a painful truth here that needs to be acknowledged. In the coming years the effort that a company goes to in order to keep their customer’s data safe will be a key metric.
Alongside the reliability of their product or service and its value for money, a brand will be judged by how seriously they take cybersecurity.
And the modern hacker understands this reality. Like the gang mentioned above, they’ll frame the business that has been lax with its security as the bad guy. The cybercriminal, on the other hand, is simply performing a public duty by highlighting that company’s incompetence.
Keeping on top of evolving trends like this one will be vital to your cybersecurity efforts in the coming years.
### Empathy for the hacker
One of the main benefits to app developers of investing time to understand the hacker from the beginning of the development journey is that it results in a much more detailed risk analysis.
Understand the hacker - not only their different profiles, but how their attacks are evolving - and your defensive capability can be vastly improved.
It means you can imagine the parts of your mobile application that might become attack vectors for bad actors further down the line. It makes you think twice about how and where you store your end user’s personal information. And it enables you to empathize even more with that end user by considering how you might educate them about cybersecurity.
For example, by knowing more about the latest phishing trends, you can make it easier for your end users to spot them, too.
Imagine two mobile banks. One of them decides to spend some time in their attacker’s shoes, while the other one thinks it’s a waste of time to think about hackers.
Which of the two would you rather entrust with your priceless personal data and the contents of your bank account?
Empathy for the hacker matters more right now than ever before. Because, as we mentioned earlier, businesses are now judged by how well they protect their end user’s data. We really can’t stress this enough. The modern consumer has so much choice that any kind of security breach simply wouldn't be tolerated by them. They’d take their business to a competitor and their complaints to social media.
The risk for companies is that they lose the trust of their customers before they’ve even had the chance to properly build their reputation.
Fortunately, understanding how threats are evolving doesn’t rely on profiling hackers alone. It can be boosted with threat intelligence.
A lot of businesses are in the dark about the attacks their application is up against in the real world. Threat intelligence is a bit like throwing open the curtains. It allows you to look out at the attacks taking place in your app’s neighborhood.
A [threat intelligence system](https://licelus.com/products/alice) gives you the insights you need to better understand the type of attacks your app might be up against. And this too helps in your risk analysis.
But it also enables you to act on those insights. You can make individual decisions such as blocking access to a user whose activity looks suspicious, for example.
In the financial industry, businesses are already using systems like this [to share information about bad actors](https://licelus.com/insights/how-threat-intelligence-can-stop-the-spread-of-cyber-attacks) and paint a more detailed picture of them. It’s an approach that will have to be mirrored in other sectors like healthcare which historically have had more gaps for hackers to exploit.
### Really understanding the hacker
When we were deciding on our [security by design principles](https://licelus.com/security-by-design) several months ago, we were clear that empathy should play a key role throughout the application development process.
We also knew that what we meant by empathy wasn’t only that designers and developers should understand each other’s challenges. Rather it had to mean everyone on the development team having a keen interest in the potential attacker of the app they were creating.
In a more remote world where mobile apps are [becoming key assets in a business' search for success](https://licelus.com/insights/3-trends-that-make-mobile-app-security-impossible-to-ignore), not to mention being vital to our everyday lives, this has never been more important.
The stakes are simply too high to ignore the hacker or generalize them into a homogeneous entity.
Really understanding the hacker can provide us with two benefits. The first of them is a longer-term aim and infinitely more difficult. That is to better understand what it is about the modern world that is encouraging so many people to become cybercriminals in the first place.
We don’t have the answer to this question yet. But we hope that by continuing to write about this theme and communicating openly with others in the industry, we can get closer to finding one.
The second benefit is much more achievable:
By understanding hackers, you naturally have a better chance of defending against them.
So, it’s time to encourage one another to look under the mask. To find out who that hooded figure really is.
It doesn’t have to be such a mystery anymore.
### Our latest articles
[View all](https://licelus.com/insights)
- [
**Beware of mental traps**
#Attack psychology](https://licelus.com/insights/beware-of-mental-traps)
- [
**How to boost your social engineering awareness**
#Attack psychology](https://licelus.com/insights/how-to-boost-your-social-engineering-awareness)
- [
**Creating a company culture for security**
#Attack psychology](https://licelus.com/insights/creating-a-company-culture-for-security)
## Mobile App Security Trends
[All insights](https://licelus.com/insights)
### Follow us
23 Jun 2021
### 3 trends that make mobile app security impossible to ignore
URL: https://licelus.com/insights/3-trends-that-make-mobile-app-security-impossible-to-ignore
# 3 trends that make mobile app security impossible to ignore
Three trends have emerged during the last year or so that make reliable mobile app security impossible to ignore.
So, if you have a mobile app that’s vital to your growth strategy, read on.
We’ll explain what’s at stake and what you can do about it.
### Mobile apps for everything, everywhere
According to [App Annie](https://www.appannie.com/en/go/state-of-mobile-2021), mobile adoption grew in 2020 at a rate you’d typically expect in a 2-3 year period. Covid-19 played a key role of course - more on this later - but it’s still a striking statistic.
And we’re not only talking about Millenials or Gen Z app users here. Baby Boomers have been increasing their usage, too. The type of app might be different - think Nextdoor rather than TikTok - but eyes have been glued to smartphone screens regardless of the user’s age.
This is the first of our 3 trends. An insatiable appetite for mobile apps that shows no signs of slowing. Indeed, when you consider that the [more remote world](https://licelus.com/insights/mobile-security-in-a-zero-trust-world) that Covid-19 has created is likely to be a permanent rather than temporary feature of our lives, the collective demand for apps is only going to increase. Especially when you see how well this desire aligns with other trends that were already in motion such as [the internet of things.](https://licelus.com/insights/why-striking-a-balance-between-speed-and-security-is-key-to-iot-success)
But it isn’t only consumers who are becoming reliant on mobile apps. And this brings us to trend number two - the increasing importance of apps to business success.
### When a mobile app is the whole business
Companies have seen how much we love using mobile apps and have decided we might like to carry out even more of our daily activities there. So now it’s perfectly normal to [bank via apps](https://licelus.com/insights/how-to-secure-a-safer-future-for-mobile-banking). We have virtual doctor’s appointments on them. And we get notifications from our favourite stores when we’re nearby so they can tell us about a relevant offer.
This enables us to better manage our increasingly hectic lives with a few simple swipes of our fingertips. But a lingering doubt remains. Are businesses and end users alike still feeling their way into their more digital relationship?
Mobile banks are a perfect example of this uneasy shift. In the past, people had a more personal relationship with their bank. Their loyalty might have been based on years of reliable service or even in-person conversations with a trusted bank manager. For the modern day mobile bank it’s a very different dynamic. Not least because the human face has been replaced by an interface.
And that means the more traditional ways a company would build trust simply aren’t there anymore.
The mobile bank’s entire success depends on the app itself. Specifically, how secure it is against sophisticated cyber attacks.
Most mobile banks are relatively small, scaleup companies. [Some of them are barely breaking even](https://www.theguardian.com/technology/2021/jun/21/cryptocurrency-boom-fails-stem-losses-uk-fintech-firm-revolut). In other words, they’re not the established, super-profitable and powerful banks of old that boasted deep roots across society. If a mobile bank were to suffer a security breach, they’d be very much alone.
This only adds to the sense that the end result of such a breach would likely be catastrophic to their future growth.
Yet despite the risk, studies have shown that mobile banking apps are still highly vulnerable to attacks. [One such study](https://www.techrepublic.com/article/popular-mobile-banking-apps-are-riddled-with-security-flaws-and-android-users-are-more-at-risk/) from 2020 highlighted that most mobile banking apps weren’t hardened robustly enough. They had little protection against malicious code injection and repackaging, and they had neither protection against decompilation nor name obfuscation for methods and classes.
If you imagine a mobile banking app as a house, this is akin to you leaving your windows open while you’re away for the weekend.
To some passersby with bad intentions, that’s far too good an opportunity to miss.
### The evolution of the hacker
Speaking of bad intentions, enter the hacker from stage left. The evolution of the cybercriminal during the coronavirus pandemic is the third of our converging trends.
We mentioned earlier that the increase in mobile app usage in the past year is linked to Covid-19. Well, it’s safe to say the pandemic has secured our phone’s role as a kind of second brain. Not only has it fulfilled our need to find answers about the pandemic, but also our desire to escape it.
Hackers understood pretty early on that if the mobile phone was where we were spending all of our time, then that’s where they’d be.
If we were seeking the advice of authorities, then they’d use [social engineering tactics](https://licelus.com/insights/why-our-emotions-make-us-more-vulnerable-to-cyber-attacks) to imitate those authorities.
And so a flood of messages began pinging on our phones. Cybercriminals pretending to be our bank, our energy supplier, or even a healthcare authority offering Covid-19 tests and vaccinations. The aim of these messages was to get us to click on a link laced with malware.
Sadly, a lot of people did just that. According to [a Deloitte study](https://www2.deloitte.com/ch/en/pages/risk/articles/impact-covid-cybersecurity.html), almost half of us fell for a phishing scam while working from home during the pandemic.
But threats are everywhere - not only inside the home. When societies tentatively opened up again in late summer of 2020, the mobile somehow became even more central to our lives. Before we knew it we were scanning QR codes and downloading apps that enabled us to order in bars and restaurants. In other words, there were even more opportunities for an uninvited guest to slip through the net.
The [healthcare industry](https://licelus.com/insights/how-to-stop-the-surge-of-cyber-attacks-against-the-healthcare-sector) began to be targeted, too. This is yet another example of cybercriminals being skilled at spotting vulnerabilities and taking advantage of them. In this case a sector overwhelmed and too busy fighting fires to invest in cybersecurity.
### What you can do to counter the threat
Combined, these three trends should set the scene for any business with a critical mobile application.
This is the landscape that you’re operating in. This is what’s at stake.
Your customers will assume that your app is safe to use. If it isn’t and you suffer a breach, then any trust they did have in you would vanish overnight.
But while we feel it’s vital you understand the risks your app is up against, it is possible to take actions to keep them at bay. The key is to accept that it’s a wild world out there and then take the appropriate steps.
Regulations are now commonplace - [particularly in the financial industry](https://www.bbva.com/en/everything-need-know-psd2/) - that encourage developers of applications to apply robust protection to prevent cyber attacks.
And this is the most important step you can take. Mobile app protection can secure your application against static and dynamic analysis. It can [prevent tampering](https://licelus.com/insights/how-to-counter-the-dangers-posed-by-tampering). It can check for signs of rooting, jailbreaking, hooking and debugging. And it can help to [stop man-in-the-middle attacks](https://licelus.com/insights/how-to-counter-man-in-the-middle-attacks).
But mobile app protection is just one natural conclusion that comes from thinking about security from the beginning of the development process and using [security by design principles](https://licelus.com/security-by-design). When we speak with companies who are starting to think about security for their app, this is what we tell them to do.
We also tell them to create a sturdy risk model. This involves putting yourself in your end user’s shoes. It even means [imagining yourself as the hacker](https://licelus.com/insights/why-we-need-to-understand-the-hacker) so you can spot security vulnerabilities they might target.
In other words, security is often about [having empathy](https://licelus.com/insights/how-encouraging-empathy-can-help-you-to-develop-safer-apps).
There’s a reason why people have embraced mobile apps so readily. You just have to make sure that your end users can continue to do so safely.
Get your security right and you’re all set to build your reputation and grow your business.
## Emotional Vulnerability in Cybersecurity
[All insights](https://licelus.com/insights)
### Follow us
23 Jul 2021
### Why our emotions make us more vulnerable to cyber attacks
URL: https://licelus.com/insights/why-our-emotions-make-us-more-vulnerable-to-cyber-attacks
# Why our emotions make us more vulnerable to cyber attacks
“Look at this.”
“I think it’s another spam message.”
A friend in London had just received an SMS asking her to move the date of her second Moderna vaccine forward a few weeks due to supply issues.
Since the beginning of this year, Sarah explained, she’d received an average of 2-3 texts per week just like this one. Some told her a package she’d been expecting wouldn’t be delivered until she paid a small fee. Others were from the tax office, reminding her about a return that was due. And more recently, she’d been seeing lots of messages about Covid-19 tests and vaccines.
“I’ve been really close to clicking on these links before. After all, I am normally waiting for a package of some kind - I shop quite a lot when I work from home! I also work freelance, so the tax return one nearly got me, too. And now I’m getting all these messages about the vaccine just when I’m super keen to be fully vaccinated.”
In the end Sarah went directly to the NHS website and realised that the text she’d received probably was genuine. But she’s not alone in being sceptical of messages that ping on her phone. Especially those that follow the now familiar template:
“There’s something urgent you need to do to solve a problem - click on this link now to fix it.”
Sarah hasn’t fallen for one of these scams, but two of her friends have. And in both cases one moment of distraction caused a month or so of distress.
### When the phone was our safe place
According to [Deloitte](https://www2.deloitte.com/ch/en/pages/risk/articles/impact-covid-cybersecurity.html), almost half of us have been scammed by a phishing message while working from home during the pandemic.
And when you consider the history of the smartphone and the way we feel about our phones in general, it’s easy to understand why we’re more vulnerable to cyber attacks that target us there.
In just a decade the smartphone has completely changed our behaviour. In that time it has almost become an extension of our bodies. A kind of second brain at the tip of our fingers that both connects us to the world and allows us to detach ourselves from it.
Notifications informing us of messages, likes, and comments elicit strong emotions that can change our mood if only for a minute or two. It’s not the same as receiving an email on your laptop.
That’s because for a long time we’ve associated our phones with our friends and family. The people we care about and trust.
The phone has been a safe place for people to joke with one another, take a selfie, send photos from an old holiday, or share a link to an album they can’t stop listening to. This is the subconscious association we have when we think of our phones.
Psychologically this is important because it helps to explain why so many phishing campaigns are sent via SMS. It also tells us why so many of them succeed.
We’ve associated emails with scams for a lot longer. We feel like we can spot them there more easily. Lots of them automatically land in our junk folder anyway.
With text messages it’s different. There is no junk folder.
Because our phones are where we tend to hear from people we trust, a hacker who tries to get our attention there is already at an advantage compared with one who interrupts us on our laptop.
What’s more, we tend to be more alert when we’re on our laptop. Whether we’re working or we’re booking a night in a hotel, we typically have a more focused mindset. So we’re less likely to let a bogus email catch us out.
When we’re on our mobile, we’re often doing other things at the same time. We might be checking the weather forecast on the way out of the house. Or maybe we’re commuting into the office and receive a message just before the train reaches our stop.
### Deferring to authoritative voices
If you're distracted and you’re not concentrating fully, then it’s very easy to mistake a phishing message for the real thing. You click on a link and before you know it you’ve filled out a form with some sensitive personal information. Then you forget about it and get on with your day.
This is exactly what happened to Emmeline Hartley, who made the brave decision to admit to falling for a phishing scam earlier this year in[a Twitter post](https://twitter.com/EmmelineHartley/status/1373649332747046914). The day after entering her details via a link in a bogus text, she received a call - apparently from her bank - telling her that her account had been compromised and advising her to move her money into a safe account.
Though she was suspicious at the time, she just about believed the person at the other end of the line. The money that she transferred was lost.
Some might be critical of Emmeline for trusting the caller. Indeed many have been in the replies to her tweet. But we’re all capable of a lapse of judgement like this. Especially after what has been the most stressful year many of us have ever lived through.
We’ve deferred to authorities more than ever during the Covid-19 crisis to give us some clarity and direction in a very strange time.
Cybercriminals know this. They know that our emotional attachment to our phones and our habit of multitasking makes us more likely to respond to an SMS. And they know that many of us are constantly expecting parcels and are keen to return to the lives we knew before the coronavirus arrived.
This knowledge forms the core pillar of their social engineering strategy.
### Mobile attacks are getting more sophisticated
In Emmeline’s case, the link she clicked on led to a fake call from her bank the following day. But often the act of clicking the link in an SMS phishing message can [result in malware spreading throughout your phone](https://www.kaspersky.com/resource-center/threats/sms-attacks) and potentially outwards to your contacts.
This malware is designed to give the attacker access to your private accounts and services. It can allow an intruder to use your mobile for unauthorized purposes or to disclose personal data. And it can even erase and change information on your phone.
At the time of writing this article, [news of the Pegasus hack is dominating newspaper headlines](https://www.theguardian.com/news/2021/jul/18/what-is-pegasus-spyware-and-how-does-it-hack-phones?utm_source=pocket-newtab-global-en-GB). Pegasus is being called the most powerful piece of spyware ever developed. It can turn your phone into a 24 hour surveillance device.
The Pegasus hack is yet another example of a sad shift. The phone used to be a vital form of escape and communication for persecuted people, but now it’s often becoming a silent spy in the palm of their hands.
Pegasus is also a reminder that cyberattacks that target our phones are getting more sophisticated by the day.
Earlier this year we read [an article in Vice Magazine](https://www.vice.com/en/article/y3g8wb/hacker-got-my-texts-16-dollars-sakari-netnumber?campaign_id=158&emc=edit_ot_20210316&instance_id=28113&nl=on-tech-with-shira-ovide®i_id=124987873&segment_id=53518&te=1&user_id=aa941bcb44db0d2d61ff3ca77355d578) about a hacker using a service called Sakari, which helps businesses do SMS marketing and mass messaging. The article revealed that a security hole at Sakari allowed an attacker using the service to reroute messages from a victim’s phone to their own.
From there it was quite simple for them to hack into other accounts associated with that phone number. The bad actor sent login requests to apps like Bumble and WhatsApp and could easily access the accounts by getting a password change message sent to their phone.
### Is it time we stopped using SMS for two-factor authentication?
The article in Vice seemed to spark a wider debate among cybersecurity analysts about whether it’s time to rethink our relationship with our phone number and what we use it for.
Brian Krebs certainly thinks so. In [a blog](https://krebsonsecurity.com/2021/03/can-we-stop-pretending-sms-is-secure-now/) responding to the Vice piece, he said that phone numbers were never designed to be identity documents. Yet somehow that’s exactly what they’ve become.
He used the blog to advise his readers to remove their mobile numbers from their online accounts where possible. And not to use them for multi-factor authentication.
This is advice that is repeated in a number of publications from recent years. The UK’s National Cyber Security Centre (NCSC) also [says](https://www.ncsc.gov.uk/guidance/protecting-sms-messages-used-in-critical-business-processes) that while there are lots of reasons why SMS might be useful for businesses - not least its convenience - it isn’t the most secure of ecosystems.
One of the NCSC’s suggestions is to use iOS and Android push notifications for authentication instead. Indeed, Apple and Google have both recently [shifted to making phone verification their go-to approach](https://www.forbes.com/sites/zakdoffman/2020/10/11/apple-iphone-imessage-and-android-messages-sms-passcode-security-update/) rather than SMS and voice calls.
Clearly it was a challenge to get people on board to set up two-step verification in the first place. And that probably helps to explain why SMS was chosen as the default channel for it. People are familiar with SMS. We’ve been using it for 20 years or so.
This, then, is a key challenge for the coming years. Yes, we almost certainly do need to transition away from a reliance on SMS. But not if it means putting people off setting up their accounts securely altogether.
### What mobile app developers can do to ease end user anxiety
Perhaps an even greater challenge is for us to collectively reclaim the mobile phone as a device of fun and convenience rather than one that makes us tense up when we hear it ping.
[Hackers prey on vulnerability](https://licelus.com/insights/why-we-need-to-understand-the-hacker). And there’s a lot of that going spare these days. We’re living through a pandemic that has caused a global [mental health crisis](https://licelus.com/insights/the-evolution-from-virtual-assistant-to-virtual-companion). Pretty much the last thing people need on top of everything else is to feel anxious whenever they receive an SMS.
Here at Licel we’ve written a lot about the value of embracing [security by design principles](https://licelus.com/security-by-design). And we think the bedrock of working this way is to have [empathy for your end user](https://licelus.com/insights/how-encouraging-empathy-can-help-you-to-develop-safer-apps).
If you’re involved in mobile app development, then now more than ever it’s vital that you put yourself in your end user’s shoes.
Think about their day to day. How are they going to use your app? And where? This is quite a common consideration when trying to get the UX just right. But it’s much less common to do so with a view to making the end user’s experience more secure.
Can you educate your end users about how you’ll communicate with them? If they know that you’ll never send them an SMS and ask them to click on a link, then they can safely ignore any bogus messages from people pretending to be you.
Also have a think about how you use SMS as a business. Is it appropriate for you to use it as part of a two-factor authentication procedure? Could you use push notifications instead?
Do you need your users to create a password or can they log into your app with biometrics?
And finally, do you even need to collect your end user’s mobile number? Ask yourself: Why do you really need it?
Chances are that your competitors probably aren’t asking themselves these important questions from the beginning of app development. If you do, then your end users will appreciate it. They might even tell their friends about how cool and transparent you are.
### Let’s teach people to recognize the threat
We’re at a bit of a turning point in our relationship with our mobile phones. Don’t get us wrong, they can still be a fun place to be. The millions of people dancing on TikTok each day and sharing memes of cats is testament to that.
But somewhere in the distance - right in the periphery of our vision - there’s a bad actor waving at us. Trying to get us to look in his direction instead.
At the very least we think it’s worth having a conversation about how to make sure people can recognise him.
When they can, they’ll ignore him and turn the other way.
### Our latest articles
[View all](https://licelus.com/insights)
- [
**Beware of mental traps**
#Attack psychology](https://licelus.com/insights/beware-of-mental-traps)
- [
**How to boost your social engineering awareness**
#Attack psychology](https://licelus.com/insights/how-to-boost-your-social-engineering-awareness)
- [
**Creating a company culture for security**
#Attack psychology](https://licelus.com/insights/creating-a-company-culture-for-security)
## Android App Bundles Debate
[All insights](https://licelus.com/insights)
### Follow us
28 Aug 2021
### Why making Android App Bundles mandatory has sparked a debate about trust
URL: https://licelus.com/insights/why-the-shift-to-making-android-app-bundles-mandatory-has-sparked-a-debate-about-trust
# Why making Android App Bundles mandatory has sparked a debate about trust
From this month, mobile app developers uploading a new app to Google Play have to switch to Android App Bundles for distribution.
And it’s fair to say not everybody is happy about it.
Because while App Bundles do make life easier - particularly for end users - there’s a growing concern among app developers about security.
Most of the worry is centered around Google Play Signing. Developers could sign using their own private keys when using the old APK upload method. But with App Bundles, Google manages the signing.
This has led some developers to question whether their app’s code might be tampered with or extra classes added.
Google has sought to reassure them. The company has even introduced an initiative called Code Transparency - itself not without its detractors - to tighten up the signing process.
Yet a steady hum of reservation remains.
Dig a little deeper, beyond the controversy around Google Play Signing, and some wider issues linked to trust emerge.
In this article, we’ll bring those issues to the surface. And we’ll ponder what the ideal Play Store security ecosystem might look like.
So, let’s get started.
### The main App Bundles controversy is Google Play Signing
First things first - Google has got a lot right with App Bundles.
There was a genuine problem to be solved in the shape of thousands of different Android devices and configurations. Many of the resources that come in a typical APK are redundant for some people. And these resources take up lots of space on a device.
The great thing about Android App Bundles is that it means each APK is tailored to a specific configuration. So, storage space is saved. What’s more, downloads are faster - an important benefit when you bear in mind that not everyone enjoys superfast internet connections.
If the App Bundle initiative stopped there, you suspect there would be widespread support for it. It’s the insistence on using Google Play Signing that has caused the controversy.
Before Android App Bundles, mobile app developers would sign their APK with a private key that they were responsible for looking after. Though a flexible approach, it wasn’t without its pitfalls. Developers sometimes lost their keys or checked a private key into a public repository. Keys could even be stolen.
With Google Play Signing, Google is taking this responsibility away from developers. Instead it is they who will manage the distribution key used to sign the APKs end users receive. This key will be kept private from the developer.
In [an article](https://medium.com/androiddevelopers/answers-to-common-questions-about-app-signing-by-google-play-b28fef836af0) published on Medium last year, Google Android Developer Advocate Wojtek Kaliciński acknowledged that this is a departure from the norm. He said he understood that developers might feel they’re relinquishing too much control over their app. This wider idea of a loss of control is an interesting one that we’ll come back to later in this article. But if we focus on the Google Play Signing controversy for now, the main point of contention relates to security.
Google is clearly a highly reputable company that cares about protecting mobile apps. But if the last year has taught us anything it’s that anyone can suffer a security breach.
Furthermore, as Google will be looking after the keys for all apps uploaded to the Play Store, bad actors know [they only have to attack one place](https://www.xda-developers.com/google-play-apk-replacement-pros-cons/) to steal thousands of keys.
Another issue that developers have raised is that the Play Signing method means that somebody at Google could potentially inject or modify code in the app. This is something that simply wasn’t possible with the old APK model. Then, if a change was made at Google, this would alter the signature so people would notice. With Play Signing, Google owns the signing key so only they would know if changes were made.
Google has insisted they won’t modify code within apps. But what seems to be bothering people is the simple fact that they can do so.
### Questions around Code Transparency
We should make it clear here that this isn’t only a Google issue. If you publish an APK file on the Amazon App Store, they also inject classes that alter the way it will work on someone’s device. Apple regularly modifies the code of your app on the Apple Store, too.
As for Google, they’ve announced [Code Transparency](https://developer.android.com/guide/app-bundle/code-transparency) partly as a response to concerns about Play Signing. Code Transparency uses a second signing key to make sure the APK delivered by the Play Store matches the one the developer built. The difference is that this key is held only by the developer.
But Code Transparency has only quietened some of the noise around Play Signing. Indeed, in some cases it has resulted in more questions than answers.
One of these questions is focused on the fact that the Android OS currently has no way of verifying the Code Transparency file upon installation. It is the developer's responsibility to make sure that all DEX and native code files in the downloaded APKs have the correct corresponding hashes in the Code Transparency file. And since Android doesn't provide any built-in functions to verify that Code Transparency file during runtime, developers have to do the checks themselves. They have to download the APKs from the Play Store and test them using Bundletool.
There is of course a risk here that integrity checks will just not be done. No checks at install time, no checks during runtime, and quite possibly none in the developers' own time. And so the app is left vulnerable to tampering.
But even if the developer takes their responsibility seriously and does everything right, the app will ultimately be out of their hands. This is the deeper concern for many. Whoever has signing authority (be it legitimately or illegitimately) over the Android App Bundle uploaded to the Play Store has the power to remove the Code Transparency file and then re-sign the app. If this were done, there would be no way for the original developer to verify its integrity anyway.
Additional layers of security are therefore needed to protect both developers and users from possible interference. These layers include a signing key held solely by the developer (as with Code Transparency). But on top of this, adequate encryption of both code and resources is needed, as well as integrity checks performed automatically during runtime. That way both developers and users get peace of mind that the app is exactly as it was intended to be. This is a crucial feature of RASP: Runtime Application Self-Protection. With these checks, the app itself routinely verifies that none of its code and resources have been modified since the developer signed it off.
And it is possible to combine all of this with the Code Transparency approach, by using the Code Transparency file as another block in the structure of integrity control. Code Transparency, in other words, can be part of a solution to potential problems with Google Play Signing. Even if it is not the whole solution.
For that, what is needed is a more complete approach to app distribution, where the security and integrity of the app can be checked and proven at every stage. So, when the developer uploads it to the app store, when the app store publishes it, when the end user downloads and installs it, and of course routinely on start-up and during runtime. This creates a full chain of trust. A coherent system of verification with real transparency for developers and users.
### Why the Android App Bundles controversy matters so much to developers
Speaking of trust, it seems appropriate to talk about a theme we’ve covered a lot here at Licel in recent months: [the growing importance of mobile apps to business success](https://licelus.com/insights/3-trends-that-make-mobile-app-security-impossible-to-ignore).
The more you read about Android App Bundles and Code Transparency, the more you can’t help noticing a disconnect. Mobile apps can be deeply emotional things for developers. After all, we’re talking about a project that might have taken them months or even years to complete. The end result is an app that could become critical to their hopes and dreams for the future.
Many businesses exist now that have forgone a physical store in favor of an app.
Think about challenger banks like Starling and Monzo, for example. In other words, mobile apps are now sometimes the most important asset a business has.
[Put yourself in the shoes of a developer](https://licelus.com/insights/how-encouraging-empathy-can-help-you-to-develop-safer-apps) at one of these businesses and it’s easy to understand why they might be reluctant to give up so much control. Yes, there were some downsides to looking after their own private key. But at the end of the day it was their responsibility. They were accountable.
To some developers the shift to App Bundles and Play Signing is akin to dropping off a parcel at Google that contains information integral to everything they want to achieve as a business. It stands to reason that they might feel anxious on the way home, wondering what will happen to it and whether it’s in safe hands.
As we said earlier, the chances of any kind of breach at a company like Google or Apple are remote. Yet when the asset being protected is so vital, even a minuscule possibility is hard for developers to accept.
### The undercurrent driving the waves
This is the disconnect that is so hard to ignore. Namely the gap between the emotional, financial, and reputational value invested in an app by an individual developer and the security measures in place in Silicon Valley. It’s a disconnect that leads us to ask an important question:
Is it reasonable or right to delegate your cybersecurity needs to businesses like Google, Apple, and Amazon?
This is a particularly pertinent question when you bear in mind that when these companies talk about security what they tend to be referring to is user privacy. But protecting user privacy by only using built-in OS protection is impossible. Robust protection should incorporate many different security layers, from Integrity Control through to Device Attestation.
Another topic we’re fond of exploring here at Licel is [the balance between convenience and security](https://licelus.com/insights/the-delicate-balance-between-personalization-and-security). Oftentimes it feels like the scales swing in favor of the former rather than the latter. Might this also be the case with Android App Bundles? The suspicion is that a more seamless user experience has been prioritized at the expense of Integrity Control.
All this helps to explain why there is a wider conversation about trust right now. After all, at the same time that developers are debating the merits of the shift to App Bundles, [Fortnite creator Epic Games’ battle with Google and Apple](https://www.theguardian.com/technology/2021/aug/19/australian-watchdog-considers-regulating-apple-and-google-to-boost-app-store-competition?CMP=fb_a-technology_b-gdntech) is making headlines.
The undercurrent driving the more obvious waves we’ve covered so far in this article might be a growing resentment of the power and control that the Silicon Valley giants wield. From the outside it can appear they’re writing the rulebook on mobile apps. Not only where they must be downloaded from, but also how they must be protected.
### A commitment to security
It’s often forgotten that smartphone apps have only been with us for around a decade or so. To some extent we’ve all had to set the rules as we go.
But the sense you get from reading [blogs from developers](https://commonsware.com/blog/2021/06/29/initial-thoughts-code-transparency.html) who challenge the App Bundles and Play Signing requirement is that they feel sidelined. Impotent.
This seems like a bit of a missed opportunity for big players like Google, Apple, and Amazon. All of whom have a chance to play a key role as educators in cybersecurity in the coming years.
The mobile phone has become even more important to people’s everyday lives during the covid-19 pandemic. It’s a trend that hasn’t gone unnoticed by cybercriminals, which explains why [they’ve flooded people’s phones](https://licelus.com/insights/why-our-emotions-make-us-more-vulnerable-to-cyber-attacks) with social engineering attacks.
This has brought an increased awareness of cybersecurity to ordinary people. But at the same time we’re not about to pack our phones away under our beds and go back to how life was before. Instead, we’ll simply expect the businesses that develop the apps we rely on to secure that app thoroughly.
In the near future a commitment to security is likely to be a key metric for consumers alongside value for money and trust.
Truly caring about security is a cultural thing. Forward-thinking businesses are now starting to realize the benefits that come from embracing [security by design principles](https://licelus.com/security-by-design). From thinking about security first and functionality second.
But we’re not there yet. If the majority of developers don’t take security seriously enough, then perhaps we shouldn’t expect Apple and Google to do so, either.
### Making app store processes more secure
Our goal with this article isn’t to lambast businesses like Google, Apple, and Amazon. Far from it. Instead, it’s to start an open conversation about whether we’re collectively taking mobile security seriously enough. To ponder ways we might be able to work together to [make sure bad actors don’t gain even more ground](https://licelus.com/insights/why-we-need-to-understand-the-hacker).
So, with that in mind, what do we see as the ideal approach to security for app stores?
At Licel we often speak with our clients about creating a chain of trust. That means across all steps in app development and distribution. From the developer, to the app store, to the end user.
What does that mean in practice?
Well, to start with there should be full PKI infrastructure in place to be able to verify the certificate is genuine and that it hasn’t expired. Much as you can verify the full chain with SSL pinning. This should be the base for any kind of signing. If you can’t verify the original certificate or the full chain, you can’t trust it.
Ideally, a developer should also be able to verify app integrity at each stage of distribution with her public key certificate. So, after the app store processes the application, once it’s downloaded to the device, and later when it’s running on the device.
To really build trust, companies like Google or Apple need to note any modifications they make to files and classes. And developers should be able to verify these with the app store public key. Code Transparency is a good start, but the fact that it isn’t a mandatory measure right now means some developers won’t be aware of it.
Finally, to combat the threat of tampering and reverse engineering, we recommend that the app be uploaded in an encrypted format.
## Mobile Device Security Tips
[All insights](https://licelus.com/insights)
### Follow us
29 Sep 2021
### 5 tips for securing your mobile device in the post-pandemic world
URL: https://licelus.com/insights/5-tips-for-securing-your-mobile-device-in-the-post-pandemic-world
# 5 tips for securing your mobile device in the post-pandemic world
Our smartphone habits have changed dramatically in the last year or so. And many of these shifts are a direct result of the covid-19 pandemic. For example, we’re now scanning QR codes at bars, we’re sharing our vaccination status on our phones when we travel, and we’re using mobile devices to help us work remotely.
While we might not have been consciously aware of all of these changes, [bad actors certainly have been](https://licelus.com/insights/why-we-need-to-understand-the-hacker). As a result, mobile devices and the apps loaded onto them have become key targets for their attacks.
Sadly this is a trend that looks set to continue.
So, how can you secure your mobile device in the post-covid-19 world?
In this article we’ll share our top 5 tips.
### Be more suspicious
This is tricky, because we’re not used to being sceptical on our mobile devices. For a long time we saw our phones as safe places. Somewhere to laugh with friends, share funny videos, and swipe through photos on social media.
But this is precisely why cybercriminals have begun to target us there. They know that compared with how we behave on our laptops, we’re more at ease. [Our guard is down](https://licelus.com/insights/why-our-emotions-make-us-more-vulnerable-to-cyber-attacks).
Ask yourself; where do you use your mobile device? Chances are the answer is everywhere. You use it walking down the street, you use it on the train, and you use it on the way out of the house. In all of these scenarios, you’re typically doing something else at the same time. You’re not 100% focused. And so it’s easy to be distracted and click on a link in a text message that at first glance looks legitimate.
You might have noticed a rise in the number of bogus text messages you’ve received this last year. Cybercriminals have pretended to be banks, energy suppliers, and even health centers offering covid vaccinations. All of these phishing messages have two things in common. Firstly, they ask you to click on a link. And secondly, that link is laced with malware that can spread quickly through your phone (and even to your contacts).
In the last 18 months we’ve been about as wary as we’ve ever been in physical spaces. From now onwards it will serve us well to be just as cautious in digital spaces, too. Especially on our phones.
### Use multifactor authentication
It’s harder for a bad actor to hack into your account when they have to do more than guess - or illegally access - your password. Multi-factor authentication provides a second layer of protection by verifying that it is you who is trying to access your account.
Typically this is done via a mobile device. Say you’re trying to log into your online bank - after you enter your login details, you’ll receive a code via SMS as a final step to log in.
Any form of multi-factor authentication is better than none. But as our previous tip covers, SMS isn’t the safest of ecosystems. Like cybersecurity journalist Brian Krebs said in a [blog](https://krebsonsecurity.com/2021/03/can-we-stop-pretending-sms-is-secure-now/) earlier this year, our phone numbers were never designed to be identity documents. But they’ve become just that out of convenience. Krebs used his blog to encourage people to actually remove their phone numbers from their online accounts.
If you do so, then you can use iOS and Android push notifications as the second authentication step, instead. Both Apple and Google now recommend this rather than receiving a text message or a phone call.
### Make sure you’re using the latest OS version
A lot of people assume that when Apple or Google release new versions of iOS and Android, the changes are mainly cosmetic. But actually each release also comes with important security patches. Ignore them and [your phone becomes more susceptible](https://www.verizon.com/business/resources/reports/mobile-security-index/2021/mobile-threat-landscape/people-and-behaviors/) to attacks against its data and systems.
If you’re using an iPhone, it’s much more likely you’re using the latest version of iOS. The nature of Apple being the only manufacturer of iOS devices makes things much simpler. A new OS version is released and users typically have it installed on their phone a day or two later.
This isn’t the case with Android - there are so many manufacturers of Android devices that things take a lot longer. And it’s easier for people to miss an update. According to NetMarketShare, 83% of Android users weren’t using the latest OS version in 2020.
The security offered by Apple and Google isn’t enough to protect mobile applications from more sophisticated attacks. The developers of the apps that you use should also use robust in-app protection to secure the dark spaces between the app and the OS. But you’re still helping to secure your mobile device by making sure it’s running the latest OS version.
### Be wary of untrusted networks
One trend that has been fast tracked by the pandemic is the growth in remote working. These days your office can be your living room, the cafe down the street, or even an airport departure lounge. But this shift is quite significant from a security perspective. Because it means you’re no longer operating under the protective bubble of the office network.
You should be particularly cautious of public WiFi. If a network is compromised and a bad actor has gained access to it, then connecting to it can expose your mobile device - as well as other devices it’s linked to - to malicious code.
Cybercriminals can also carry out a [man-in-the-middle attack](https://licelus.com/insights/how-to-counter-man-in-the-middle-attacks) via public WiFi networks. This is where they intercept the line of communication between your mobile device and the network. By doing so, they can see the information you send (like an email) and can even alter that information before it gets sent on.
While the safest option is to avoid public WiFi altogether, you might find that you have to connect as your work becomes more remote. If that’s the case, then make sure the connection is secured before connecting to sensitive apps like mobile banking.
### Know the kind of data you’re sharing
How often have you downloaded an app and just accepted all of the permissions it is asking for?
We’ve all been there. We want the app and so we don’t really dwell too much on the data about ourselves that we’re handing over. But in the post-pandemic world where mobile apps are a more tempting target for attacks, it might be that we need to be a little more aware.
As Verizon rightly points out in their [2021 Mobile Security Index](https://www.verizon.com/business/resources/reports/mobile-security-index/2021/mobile-threat-landscape/people-and-behaviors/), something like location data might not seem particularly sensitive at first, but it can be. When you think about it, someone’s location data can hint at all kinds of aspects of their personal life. It can tell someone when they’re at home and when they’re out, what their hobbies are, and their sexual orientation. If a bad actor had this data, they might be able to use it for extortion. Or they could craft a more believable phishing message.
There’s another good example of this in a recent New York Times article about [living a safer digital life](https://www.nytimes.com/2021/03/24/technology/personaltech/online-data-privacy.html). When you take a photo on your phone, it often comes with the location of where that photo was snapped. Again, you wouldn’t want that information to fall into the wrong hands. There are instructions in the same article for disabling this in-built feature.
The last year or two has proved to us that cybercriminals are skilled at exploiting wider anxieties. During the covid-19 pandemic our gaze has often been elsewhere and we’ve relied on our phones for some distraction. A little light relief.
We should feel able to continue seeing our phones this way. But at the same time we need to be a little more skeptical sometimes. This caution can go a long way to securing your mobile device in the post-pandemic world.
## Smartphone Usage and Cybersecurity
[All insights](https://licelus.com/insights)
### Follow us
29 Sep 2021
### What our covid-19 smartphone usage means for cybersecurity
URL: https://licelus.com/insights/what-our-covid-19-smartphone-usage-means-for-cybersecurity
# What our covid-19 smartphone usage means for cybersecurity
The world before covid-19 is a familiar yet strange place.
Reading technology trend articles from just before the pandemic can be an odd experience. It’s a little like glancing through the window into a more innocent parallel universe.
Many of these articles focus on the amount of time spent on mobile devices. In late 2019 and early 2020 it seems it was hard to imagine how we might use them more frequently.
According to some we were already at something of a crisis point. Pedestrians [distracted by their phone](https://www.reuters.com/article/us-health-texting-pedestrians-idUSKBN1ZY2OA) were having accidents. And etiquette experts were weighing in on excessive [mobile phone use at the dinner table](https://www.washingtonpost.com/lifestyle/home/cellphones-at-the-dinner-table-silence-please/2019/02/11/7a5e00b0-20ca-11e9-8e21-59a09ff1e2a1_story.html).
Little did we know that the phone was about to take on even more of our day-to-day tasks.
In this article we’ll explore how the pandemic has transformed the way we use our phones. And we’ll examine what our covid-19 smartphone usage means for cybersecurity.
### The evolution of smartphone usage during the pandemic
In the middle of March 2020, Yuval Noah Harari penned [an article for the Financial Times](https://www.ft.com/content/19d90308-6858-11ea-a3c9-1fe6fedcca75).
In it, he wondered - and worried - about the paths the pandemic might lead us down. One paragraph in particular appears quite prophetic 18 months on:
**\"** Many short-term emergency measures will become a fixture of life. That is the nature of emergencies. They fast-forward historical processes. Decisions that in normal times could take years of deliberation are passed in a matter of hours. Immature and even dangerous technologies are pressed into service, because the risks of doing nothing are bigger. Entire countries serve as guinea-pigs in large-scale social experiments. What happens when everybody works from home and communicates only at a distance? What happens when entire schools and universities go online? In normal times, governments, businesses and educational boards would never agree to conduct such experiments. But these aren’t normal times. **\"**
Even before covid, there was a sense that the smartphone and social media were changing the world more quickly than we could write the rules to keep people safe. We were so quick to embrace a culture of convenience that important questions about privacy and ethics were often ignored.
And the pandemic has only sped up this process.
Before we knew it we were downloading [covid-19 apps](https://licelus.com/insights/protecting-tracking-apps-in-the-post-coronavirus-world) designed to keep track of how many people were falling ill and to stop the spread of the virus.
Analysts questioned the security of these apps. But, as Harari said, the risks of doing nothing were bigger.
As the months passed and the impact of the pandemic shifted like the sands of a desert, so did the way we used our phones.
A device that was for so long used mainly for communication or leisure was fast transforming into something quite different.
As we started to [work remotely](https://licelus.com/insights/mobile-security-in-a-zero-trust-world), the phone became more important for work-related tasks. For example, it often became a second screen used for video calls while we continued to work on our laptops.
Authorities increasingly preached the importance of keeping a safe social distance from one another. And it turned out that the device in our pockets allowed us to do just that.
Instead of queuing to order at a bar we could use our phones to scan QR codes. Instead of crowding into a shop at the same time, a business could send us a notification via an app when it was our turn to enter. And while some of us had already ditched cash before covid, the pandemic acted as the final death knell. Cash was seen as unclean, so more than ever we left our wallets at home and used the [digital wallets](https://licelus.com/insights/introducing-softpos-the-fast-tracked-financial-trend-ready-to-revolutionize-payments) on our phones instead.
In recent months mobile devices have also become de facto passports. We now use them to check into venues. We use them to store proof of our vaccination status or of a negative covid test. We hold them up for inspection at airports.
On the surface, these changes seem positive. An example of a crisis forcing us to become more efficient.
But there’s an alternative way to look at how covid-19 has transformed the way we use our phones. That is that they’re now being used in a way they were never designed to be used. A way that makes them a more tempting target for cybercriminals.
### The emergence of new attack vectors
After all, when we look back at how we used our phones during the pandemic, another trend will likely come to mind:
The amount of bogus text messages we received from bad actors claiming to be banks or health care providers.
In some ways the pandemic marks the end of a more innocent relationship with the smartphone. It used to be a safe place - somewhere to laugh with friends or share silly videos of cats. Yes, there were a few reminders of creepy privacy issues and brands wanting more permissions than they really needed. But when people thought about the darker side of the internet - like phishing and scams - they tended to think of laptops and email.
[Cybercriminals, though, are smart](https://licelus.com/insights/why-we-need-to-understand-the-hacker). During the pandemic they not only saw how much more time we were spending on our phones. They also realized that [we act differently on them](https://licelus.com/insights/why-our-emotions-make-us-more-vulnerable-to-cyber-attacks) compared to when we’re on our computers.
We’re more relaxed on mobile devices, which means we’re more distracted and more likely to click on a malicious link in an SMS.
[Phishing and malware attacks jumped](https://www.nbcnews.com/tech/security/work-home-fueling-cyberattacks-says-global-financial-watchdog-rcna1395) from 5,000 per week in February 2020 to 200,000 per week in April 2020. Such a hike isn’t a coincidence.
Hackers have also targeted mobile applications more than ever before during the pandemic. They recognize that because apps are taking on an increasing number of daily tasks, that means they’re collecting more and more valuable personal information. They also know that not all apps use robust protection and that some rely on platform security alone.
But iOS and Android security doesn’t stop [tampering](https://licelus.com/insights/how-to-counter-the-dangers-posed-by-tampering), [man-in-the-middle attacks](https://licelus.com/insights/how-to-counter-man-in-the-middle-attacks), or static and dynamic analysis. And it doesn’t allow developers to check the environment their application is run in. For modern mobile apps in industries such as finance, healthcare, and the public sector, this kind of protection is a must.
The pandemic has proved to us that cyber threats are getting more subtle and more sophisticated. They’re also evolving all the time. This is the main source of fear about the rapid shift in smartphone usage during covid-19. Could it be that new attack vectors have opened up without us knowing?
Take our current habit of constantly scanning QR codes, for example. Something we now do without thinking.
In theory, a bad actor could use a QR code to [direct people to a malicious link](https://www.verizon.com/business/resources/reports/mobile-security-index/2021/mobile-threat-landscape/people-and-behaviors/). QR codes can also add a new network to a device’s list of trusted networks, make a payment, add a new contact, or send a user’s location to an app.
### Securing our new habits
So, yes, many of the ways smartphone usage has evolved during covid-19 are positive. But only if we make sure people can carry out these new daily tasks securely.
We have to be aware that when we open a door into a new way of using our phone, that door doesn’t always lock behind us. And when it doesn’t, cybercriminals can follow us inside.
We’ve spent a lot of time this last year or two being wary. Mainly, though, this has been in the physical spaces we inhabit. We’ve got used to keeping our distance, wearing masks, and using hand sanitizer. But our phones have been somewhere to escape from covid-19. A place to let our guard down and relax.
It might be that we’ll need to be more cautious in digital spaces too - including on our phones - from now on if we want to avoid falling victim to a phishing attack.
Sad though it sounds, we could probably all benefit from being a little more suspicious. If you receive a message from your bank when you normally don’t - or if it’s asking you to do something different to the norm - then it’s a good idea to stop and think. Could it be a scam?
And the responsibility here doesn’t only fall on the end user. After all, the stakes are just as high for the businesses developing the apps we rely on. As we’ve said many times on this site, it only takes one security breach for a company to lose its hard-earned reputation. The more people are exposed to cyber attacks in the press, the more likely they are to see security as a key metric. In the near future consumers are unlikely to trust a company that doesn’t take cybersecurity seriously.
That’s why another mentality shift is required in the post-covid-19 world. Developers have to start thinking about security throughout the whole development process. Only by embracing [security by design processes](https://licelus.com/security-by-design) can they be sure of combatting ever-changing cybersecurity threats.
That means having the [empathy](https://licelus.com/insights/how-encouraging-empathy-can-help-you-to-develop-safer-apps) to step into the end user’s shoes and thinking about attack vectors they might be exposed to. Beyond that, developers of critical apps will also want to protect where platform security cannot. This includes implementing code hardening, runtime application self-protection mechanisms, and integrity checks - before an application is published.
### How we use our phones has changed for good
Global crises have a habit of changing our habits and behaviours. The same thing happened after the global financial crisis earlier this century. When the smoke cleared, we were suddenly riding Ubers to work and staying at Airbnbs on vacation.
In years to come, we might look back on the pandemic as a time when the phone ceased to be only a leisure and communication tool. We’ll see this as the time the device also became a way to gather data on a massive scale.
This rapid increase in mobile phone usage is also happening at the same time as the arrival of 5G. So, everything points to even more usage possibilities.
But let’s not forget that the phone was originally designed to be a phone. It wasn’t designed to be a passport. Nobody foresaw us using a stream of apps that would collect data that could tell a bad actor more about us than we even know ourselves.
The way we use the phone has fundamentally changed. And that means our attitude to security needs to change with it.
## Future UI Security
[All insights](https://licelus.com/insights)
20 Oct 2021
### Securing the user interfaces of the future
URL: https://licelus.com/insights/securing-the-user-interfaces-of-the-future
# Securing the user interfaces of the future
How many times today have you entered a passcode or password on your phone?
These are the kind of everyday digital tasks we tend to do without thinking. But they aren’t always as secure as we think they are.
In recent years the Trusted User Interface (TUI) has emerged as a security concept designed to protect us as we perform these tasks. It operates within what is called a Trusted Execution Environment (TEE), outside of the main OS. It’s there to stop bad actors from spying on us as we enter our personal details or perform critical tasks.
The Trusted User Interface has been a helpful concept. But there’s a danger that it won’t be enough to protect us from cybercriminals in years to come.
Attacks are getting ever more sophisticated. And the user interface itself is evolving and blurring as augmented reality takes root in our lives.
So, it seems like the right time to ask:
Are we ready to secure the user interfaces of the future?
### What exactly is a user interface?
For a long time the answer to the question above was obvious: a space where users interact with their device. Input has often been through touch (a keyboard, a mouse, or a touchscreen). And output has mainly been via a screen and speakers.
But augmented reality will soon blur the senses we use to connect to our phones.
User interfaces in the coming years might involve a combination of voice, visual display, and touch. That’s why we need to start preparing for this future now instead of only focusing on finding security solutions for the user interfaces of the present.
We’ll explore this in more detail later in this piece. But before that, let’s come back to the here and now.
You only have to look at the last year or so to find examples of just [how quickly the landscape can change](https://licelus.com/insights/what-our-covid-19-smartphone-usage-means-for-cybersecurity). In no time at all we’ve all got completely used to scanning QR codes in bars and restaurants. The mobile device has also transformed into a de-facto covid-19 passport that we present to officials in airports and outside venues.
These aren’t the only changes influenced by the pandemic. The growth in mobile payments - [both making and receiving](https://licelus.com/insights/introducing-softpos-the-fast-tracked-financial-trend-ready-to-revolutionize-payments) - has sped up the demise of cash. And this in turn has normalized yet another user interface.
We tend to get used to these shifts quickly. [But the problem is that cybercriminals do, too](https://licelus.com/insights/why-our-emotions-make-us-more-vulnerable-to-cyber-attacks). They see a new way of sharing sensitive data with a swipe or a simple voice command as a vulnerability to exploit.
### The need for a Trusted User Interface
Hackers know our usage habits evolve more quickly than businesses put in place the necessary security measures. And this knowledge is boosting their confidence.
The last few months have provided us with plenty of examples to prove the point. This summer, the security researchers, Threat Fabric, reported [a new Android malware](https://www.businessinsider.in/tech/news/vultur-android-banking-malware-can-screen-record-everything-on-your-phone/articleshow/85002118.cms) that can record everything that happens on your phone. The banking trojan, Vultur, carries out screen recording and keylogging to capture users’ login details.
These are two of the most common spying methods right now. Keylogging is where a bad actor captures the keys you stroke on a keypad. Screen recording (also known as screen capping) records a video or takes a screenshot of what’s on your smartphone screen.
Vultur uses Virtual Network Computing (VNC) to remotely control - and record - a victim’s device.
Perhaps the most frightening aspect of Vultur reported by Threat Fabric is that the malware is able to detect when someone is using an app on a ‘target’ list.
That means that if a bad actor were interested in logging sensitive data from a particular banking app, they’d be notified of exactly when to record.
We also read recently about the malware family, [TeaPot](https://blog.nviso.eu/2021/05/11/new-malware-family-now-also-targets-belgian-financial-apps/), which uses different types of overlay attacks to target Belgian banks. It can create a fake UI on top of the real app, tricking the user to touch specific parts of the screen. It can create interactive fields to sit on top of key fields. And it can even overlay the entire app and pretend to be the app. This is what’s called a full overlay attack.
These attacks tell us that there’s already a need for the Trusted User Interface as we currently recognize it. Trojans like Vultur and TeaPot have helped to usher in [regulations from bodies such as PCI](https://www.pcisecuritystandards.org/document_library?category=SPoC&document=pin_cots_sec_req). In the next year or two, they will likely act as an extra push for app developers.
### Is the current Trusted UI specification too limited?
However, right now Trusted UI is used mainly with a view to stopping cybercriminals from spying on our login details, passwords, and two-factor verifications.
The scope is typically confined to screen and touch protection.
Is this a limited view?
[The GlobalPlatform specification of a Trusted User Interface](https://globalplatform.org/wp-content/uploads/2013/06/GlobalPlatform_Trusted_User_Interface_API_v1.0.pdf) was devised in 2013 and, at the time, it was a totally sound specification. Some functions were deliberately left out of it as they were seen as being either not realistic technically, could not be standardized easily due to fragmentation, or were not considered to be of sufficient importance.
But eight years on, our mobile usage habits - and the threat landscape as a whole - has changed.
And so it’s worth asking whether it would be more helpful to consider a “secure user interface” that covers much more of our day-to-day interactions on mobile devices.
Let’s use a couple of examples from the present before we look to the near future.
We currently spend a lot of time on video calls that, if recorded, could provide an intimate view into our daily lives. Images or video footage of family members or of our homes and offices could tell attackers a lot about us. If they were able to capture them, then these shots could aid their extortion efforts.
What’s more, other screenshots of apps - outside of a payment or transaction screen - could also help bad actors to craft a more believable phishing campaign.
Say you bank with Chase and you get a phishing message from Bank of America. You’d be able to safely ignore that. But if you received what looked like a legitimate message from Chase with references to your usage habits, you’d be much more likely to engage with it in the moment.
### Securing the user interfaces of the future
We recently read a couple of articles that help to illustrate how a new specification for a wider secure user interface might be made ready for the near future.
The first one was about fraudsters [cloning a company director’s voice](https://www.forbes.com/sites/thomasbrewster/2021/10/14/huge-bank-fraud-uses-deep-fake-voice-tech-to-steal-millions/?utm_campaign=forbes&utm_source=twitter&utm_medium=social&utm_term=Carrie) to carry out a $35m bank heist in the UAE. And the second was about [some malware called PixStealer](https://research.checkpoint.com/2021/pixstealer-a-new-wave-of-android-banking-trojans-abusing-accessibility-services/) that abused Android’s Accessibility Service to target users of the Brazilian bank, PagBank.
The idea of cloning someone’s voice to carry out fraud sounds pretty incredible to us today. But this is a pointer to the kind of cyber attack we’ll read about a lot more in 2-3 years.
As long as recordings of our voice and videos of us exist online, then the opportunity will also exist for hackers to use technology to pretend to be us.
There are already some worrying stories about [people using deepfakes with bad intentions](https://www.washingtonpost.com/technology/2021/03/25/deepfake-video-apps/). And it only feels like a matter of time before one is used to carry out a serious cyber attack.
Imagine a world where it’s normal to use augmented reality - [or even smart glasses](https://thenextweb.com/news/facebook-smart-glasses-black-mirror-privacy-concerns-syndication?utm_campaign=updog%26utm_content=tweet1%26utm_medium=social%26utm_source=twitter) - to log into the most secure applications. Even an action as personal and unique as this might be at risk from fraud in the future.
This is why we think the concept of Trusted UI needs a rethink. Because while it’s hard to predict exactly how our changing tech habits might lead to new attack vectors opening up, one thing is certain - they almost always do so. We can’t assume that the way we carry out transactions and other critical tasks today will stay the same.
The PixStealer malware is a different kind of attack. It proves [just how adept cybercriminals are](https://licelus.com/insights/why-we-need-to-understand-the-hacker) at profiting from a new kind of user interface. In this case, one that was designed to help people with disabilities to access their phone.
Again, it’s impossible to read about this attack and not hypothesize about future attack vectors. After all, the more smart devices and sensors surround us, the easier it will be for all of us to connect to the digital world. But bad actors will see each of them as a window.
In a recent article we shared [5 tips for securing your mobile device in the post-pandemic world](https://licelus.com/insights/5-tips-for-securing-your-mobile-device-in-the-post-pandemic-world). And the first tip was obvious to us:
Be more suspicious.
This advice was for end users, but it’s just as vital for developers, too. Yes, being wary is a sad suggestion, but as long as bad actors are able to spy on our activity, it’s very necessary.
This helps to explain why Google’s Pixel 6 device - announced last week - will come with a privacy dashboard. It’s there to enable users to set camera and microphone access for all of their apps.
Becoming more aware of these permissions is just one step in creating a secure user interface that will benefit us all.
## Smartphone Security Tips
[All insights](https://licelus.com/insights)
### Follow us
27 Oct 2021
### 5 bonus tips for securing your smartphone
URL: https://licelus.com/insights/5-bonus-tips-for-securing-your-smartphone
# 5 bonus tips for securing your smartphone
Last month we shared our [5 tips for securing your mobile device in the post-pandemic world](https://licelus.com/insights/5-tips-for-securing-your-mobile-device-in-the-post-pandemic-world).
The inspiration for writing this article came from witnessing all the ways the covid-19 pandemic [had altered our mobile usage habits](https://licelus.com/insights/what-our-covid-19-smartphone-usage-means-for-cybersecurity). We saw that the threat landscape had changed and that new gaps had opened up.
But the process of writing that article led us to think about even more ways to secure your phone from hackers.
In fact, we decided we needed to share a sequel. So, here it is - introducing 5 bonus tips for securing your smartphone.
### Don’t install mobile apps from untrusted places
As a general rule, you should only download apps from the Play Store (if you have an Android phone) or the App Store (if you have an iPhone). In the last year or so, cybercriminals have exploited our anxieties about the covid-19 pandemic [to trick people](https://licelus.com/insights/why-our-emotions-make-us-more-vulnerable-to-cyber-attacks) into downloading apps from elsewhere.
Phishing emails or text messages use social engineering techniques to convince you to click on a link.
And the act of clicking on that link can sometimes enable a malicious app to be downloaded onto your device.
This is how [the Flubot phishing scam](https://www.bbc.co.uk/news/technology-56859091) worked and spread around the globe earlier this year. Android users who clicked on the link within the SMS message were shown instructions for how to install a parcel tracking app via an APK. It’s not easy to download apps outside of official app stores (as we’ll explain in our next tip), but there was an explanation within the message for how it could be done. Those who did download it saw spyware spread throughout their phone.
You might think people would be naturally cautious of downloading an app outside of Google Play. But hackers are skilled at playing on our emotions. Phishing messages make it clear that you have to do something urgently to fix a problem. That could be an issue with your bank account or getting an expected parcel delivered on time. Often people will panic and decide they simply have to take action.
[Recent Ofcom research](https://www.theguardian.com/uk-news/2021/oct/20/45-million-people-in-uk-received-scam-texts-or-calls-in-last-three-months?CMP=Share_AndroidApp_Other) found that 45m people in the UK have received at least one fraudulent message in the last three months. If you receive an SMS asking you to click on a link to download an app, think twice. Contact the company in question directly instead.
It’s also worth exercising caution when scanning QR codes. Do you really trust the place you’re being asked to scan the code and download an app?
### Don’t root or jailbreak your phone
Phishing attacks like Flubot are often aimed at people who are unaware of the dangers of downloading apps outside of official app stores. But some people actually choose to alter their phones so it’s easier for them to do just that.
Rooting is the term more commonly associated with Android devices. This is where you hack your Android phone to take it outside of Google’s in-built restrictions. Jailbreaking is similar but [sounds more severe because it’s associated with Apple devices](https://www.kaspersky.com/resource-center/definitions/what-is-jailbreaking). And Apple’s famed walled garden approach to security means it’s generally a lot more difficult to break free of the protective measures the company has put in place.
But these very measures are what encourage some users to jailbreak their device. They want the freedom of being able to download apps that can’t be found on the App Store. The thing is, there are often very good reasons for those apps not being listed there.
Downloading apps from random websites can significantly increase your chances of ending up with malware on your device.
One of the reasons we were eagerly following [the Apple vs. Epic Games legal case](https://www.theverge.com/2021/9/12/22667694/epic-v-apple-trial-fortnite-judge-yvonne-gonzalez-rogers-final-ruling-injunction-breakdown?mc_cid=0c6afe1b5e&mc_eid=cd2e025be4) is that it set an interesting security precedent. By encouraging gamers to download Fortnite outside of the App Store (and Android Play Store) bubble, might Epic Games have been putting their users at risk?
There are legitimate arguments for both end users and developers to question the power of Silicon Valley giants like Apple and Google. We explored this ourselves in a recent article about Google’s [shift to using Android App Bundles to upload apps](https://licelus.com/insights/why-the-shift-to-making-android-app-bundles-mandatory-has-sparked-a-debate-about-trust) to the Play Store.
But right now the landscape outside official app stores is murky and dangerous. It’s much safer to stay within the protective bubble.
### Use strong passwords and biometric data
If we go back to phishing scams for a second, not all of them are sent with the goal of getting you to download an app. Some want you to fill out your login details in a form - including your password - so those details can be recorded. Again, the ruse here is typically that there’s something wrong with your account that needs to be fixed urgently.
This is one way [cybercriminals](https://licelus.com/insights/why-we-need-to-understand-the-hacker) try to get your password. Other methods [use software to guess your password](https://blog.avast.com/strong-password-ideas). One is called a brute force attack - here the attacker tries a variety of combinations until they hit on yours. Another, called a dictionary attack, is where a prearranged list of words is used.
The best way to avoid falling victim to these two attacks is to come up with longer, more obscure passwords.
But obviously you also need to be able to remember them. A password manager is one solution. It means you don’t have to create or remember a password at all. But if you’d rather not use one, here are some ideas for how to create more complicated passwords that still mean something to you:
- Use a series of unconnected words that have some kind of meaning to you
- Create a password with some of your favorite song lyrics, or a favorite line from a movie or book
- Try the Bruce Schneier Method - here, you think of a random sentence and then transform it into a password by applying a rule to it. One example is to take the first two letters from each word. So, “Gracia is my favorite neighborhood in Barcelona” would become GrismyfaneinBa.
If certain apps allow it, then it’s also a good idea to use biometric logins (your fingerprint or face). While these aren’t completely invulnerable and might face challenges in an age of augmented reality and deep fakes, they’re still pretty secure. And as we said in our first tips article, make sure you set up multifactor authentication.
### Always keep your apps up to date
We stressed the importance of updating the OS on your phone [in part one](https://licelus.com/insights/5-tips-for-securing-your-mobile-device-in-the-post-pandemic-world) of our tips for securing your smartphone. But updating the individual apps on your device is just as important.
That’s because in the same way that OS updates fix bugs and security issues, so too do individual app updates.
As the threat landscape evolves, app developers become more aware of gaps that need to be plugged.
Updates are there for a reason, then - to counter the latest cyber attacks.
And so having old apps on your phone that haven’t been updated in a while can be dangerous. They might only have protection that was acceptable two or three years ago but now isn’t up to the task.
It’s worth doing a regular audit of your device to understand which apps need to be updated. You can decide whether or not to set up automatic updates or whether you’d prefer to manage the process manually, as well as whether to wait until you’re connected to wifi.
If there are some very old apps on your device that haven’t been updated in a long time and which you don’t use, it might be worth deleting them. One app with weak security can be like an open window an attacker can climb through to access the rest of the house.
### Make use of anti-malware solutions
There’s a common assumption that you don’t need to install anti-malware on your smartphone - that in-built platform security alone is enough. While this is largely true if you own an iPhone (owing to the walled garden approach to security we mentioned earlier), it isn’t the case for Android.
The open-source nature of Android means that it’s easier for bad actors to exploit gaps in security there compared to iOS.
And so it’s more important for Android device owners to consider adding an extra layer of security on top of standard OS security (and the protection developers apply to their apps).
Something else to bear in mind is that if you have an older Android device, then it might not actually receive Android security updates. Last year, [Which? reported](https://press.which.co.uk/whichpressreleases/void-android-more-than-one-billion-android-devices-at-risk-of-hacking-attacks/) that a billion Android devices around the world weren’t supported by security updates.
Anti-malware solutions can analyze installed apps and downloaded files. Google Chrome and other web browsers do checks to analyze whether files and webpages are dangerous or not, but they can’t help if another app downloads a file. That’s where an anti-malware solution can help.
These days anti-malware products are pretty sophisticated. [Most use machine learning to develop artificial intelligence algorithms](https://insights.samsung.com/2021/04/12/do-i-need-antivirus-software-on-my-smartphone-3/). These can recognize and quarantine malicious code before it has the chance to run on your device.
So, there we have it. 5 bonus tips for blocking hackers from your cell phone. Use the recommendations here - together with those in [Part I](https://licelus.com/insights/5-tips-for-securing-your-mobile-device-in-the-post-pandemic-world) of this series - and you’ll make it much more difficult for attackers to access your personal data.
## Stop Software Attacks
[All insights](https://licelus.com/insights)
### Follow us
23 Feb 2022
### How to stop software supply chain attacks
URL: https://licelus.com/insights/how-to-stop-software-supply-chain-attacks
# How to stop software supply chain attacks
Looking back to the end of last year, a lot was made of the security community being caught off-guard by the Log4J vulnerability.
But should an attack like this have come as such a surprise?
For a while now the fast-paced nature of software and app development has meant that using existing libraries and frameworks is a must.
The big question, though, is whether they can all be trusted.
Clearly the answer right now is no - Log4J has proved as much. And in an age where your mobile app might be your most valuable asset, there’s no denying that this is a concern.
In this article we’ll take a look at how we got to the current status quo. And we’ll explore two key ways of stopping software supply chain attacks in the future.
### How a developer builds a house
Imagine you were working with an architect to design and build a house from scratch.
It’s unlikely that you’d make all the materials yourself. Instead, you’d source them from independent suppliers. One for the doors, one for the windows, and another for the floors.
It’s a similar situation in software and app development. Why reinvent the wheel when there’s already a perfectly good library or framework you can use? Someone else has done the hard work so you don’t have to.
This is how a lot of development works. Much of the code that makes up our everyday digital interactions comes from existing libraries. Software and app development is often a high-pressured environment - there’s a demand for products to launch quickly to maintain competitive advantage.
And often this approach of taking ready-made building blocks works just fine. It speeds up the development process and results in a successful application.
Sometimes, though, things can go wrong. After all, the libraries themselves often contain dependencies. So, while you might think that you’re using 10 libraries to build your application, you could actually end up with around 150 dependencies.
It’s one thing to know and trust the publishers of the libraries. But what about the publishers of the dependencies within those libraries? Do you know them? Can you trust them?
A seemingly innocuous line of code in just one of those dependencies could offer bad actors a route into your application.
If we go back to the house analogy, it’s a little bit like buying a door from a supplier you trust, only to realize later that they don’t actually manufacture the locks themselves. And the metal used in those locks corrodes and weakens easily.
It’s the “one-to-many” concept that makes software supply chain vulnerabilities like Log4J so attractive to attackers. Imagine you created a vulnerability in a dependency that sits within a popular library. That library could end up being used in some of the biggest applications in the world. The attack surface grows without having to repeat the initial effort.
That was the major worry around Log4J.
### Is a reliance on open-source software sustainable?
In essence, the approach above mirrors supply chain attacks in other industries. Find your way into a large company by hacking a smaller one (which has a fraction of the security budget) higher up the supply chain.
In the tech world, the equivalent goes something like this:
It’s extremely difficult to hack tech giants like Google and Facebook directly. It’s much easier to hack a line of code within a dependency of a library that they rely on.
Log4J isn’t the only recent example of such an attack, either. There have been plenty that use typosquatting - an attack that leverages misspelled versions of popular package names to gain access to systems.
Studies have shown that this technique is [a great way of getting into the networks of some of the world’s biggest tech companies](https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610). Once inside, attackers can gain remote code execution or potentially add a backdoor during the build.
Earlier last year, before Log4J, we read about the [Codecov](https://about.codecov.io/security-update/) attack. A bad actor was able to gain access to Codecov’s Bash Uploader script and modify it. This was possible because of an error in Codecov’s Docker image creation process.
A lot of software supply chain attacks target free, open-source libraries. Log4J is a perfect example of this. In the immediate aftermath of the attack, there were obvious recriminations - chief among them being “how could they have allowed such a vulnerability in their code?”
But who are “they”, exactly?
Scratch beneath the surface, as Patrick Howell O’Neill did in his brilliant [MIT Tech Review piece](https://www.technologyreview.com/2021/12/17/1042692/log4j-internet-open-source-hacking/), and a shocking story emerges.
Log4J had become a vital piece of internet infrastructure, relied on by million and billion dollar companies. But it was maintained by a tiny team of unpaid volunteers who were then expected to work 22-hour days to fix the vulnerability.
The underfunding of open-source software seems unsustainable. Particularly at a time when all the trends point toward more attacks of this nature. Indeed, if hackers know that the library or framework they’re targeting is poorly funded or supported, they also know that they’ll have more time to profit from an attack.
### What can we do to stop software supply chain attacks?
It stands to reason, then, that the first way to counter this growing threat is to collectively show our appreciation for the frameworks we depend on.
We’ve released some open-source software ourselves. And as a result we’ve always felt a close connection with the developer community. We feel immense satisfaction and pride whenever we read about the different ways [JCardSim](https://licelus.com/products/jcardsim) is being used around the world.
But we’re also in the fortunate position of having other app protection products that we do charge for. Some developers of open-source software can’t say the same.
If you’re in a position to support open-source projects - be it financially or by sharing tools you’ve created that can help to secure them - that’s a great start.
Because protecting libraries is going to be increasingly important in the next few years as the process of mobile app development changes.
We’re seeing big growth in the popularity of no-code applications already and we expect that trend to continue. That means that the use of a variety of building block frameworks will become completely normalized. But it also means that developers might lose any kind of control that they once had over libraries and dependencies.
And this leads us to our second tip for stopping software supply chain attacks - [shifting how we think about security in general](https://licelus.com/security-by-design).
We mentioned at the outset of this article that the use of existing libraries and frameworks is pretty much essential in the fast-paced world of app development. But in a future where developers potentially have less control over their dependencies and the apps they’re developing are [more vital than ever to a business’ success](https://licelus.com/insights/3-trends-that-make-mobile-app-security-impossible-to-ignore), is there an argument for slowing down?
After all, when you read about the use of software dependencies, one word jumps off the page more than any other: [convenience](https://licelus.com/insights/the-delicate-balance-between-personalization-and-security).
In a way it’s reminiscent of the height of consumerism when people didn’t care so much where their food came from and the impact on the planet so long as they could get it easily.
The slow food movement used to be a niche one. But these days there are lots of people who would at least claim to care about the sustainability of the food on their table.
Nicolas Fränkel recently wrote [a blog](https://blog.frankel.ch/running-untrusted-code/) in response to Log4J. In it, he noted that users of third-party code should carefully audit it for bugs and vulnerabilities. But he also said that in 20 years in the industry he was yet to see such an audit take place.
This reality probably speaks to the time pressure developers and product owners find themselves under. The balance naturally tends to swing towards speed rather than security. But this imbalance would right itself pretty quickly once companies suffered the trust and reputational fallout of a damaging attack.
Later in Fränkel’s article he suggests that we should handle security through the lenses of risk assessment. But, he said, to do so requires you to first list all of the possible risks.
Fortunately, we can help with that. You can find out how below.
## Endpoint Security Insights
[All insights](https://licelus.com/insights)
### Follow us
29 Mar 2022
### The Ocean's Eleven scene that hints at the need for strong endpoint security
URL: https://licelus.com/insights/the-ocean-s-eleven-scene-that-hints-at-the-need-for-strong-endpoint-security
# The Ocean's Eleven scene that hints at the need for strong endpoint security
In Steven Soderbergh’s 2001 movie, Ocean’s Eleven, there’s one specific moment when the head of the Bellagio Casino, Benedict, realizes he has no way of stopping the heist.
When he goes down to inspect the vault in person, Benedict glances down at the floor and notices a crucial detail. The Bellagio logo is imprinted there. But on the camera footage of the robbery the attackers had shared with him earlier, there was no logo.
He suddenly understands that the attackers have manipulated the camera feed. Instead of seeing the true live feed of the casino vault, he was seeing what Ocean’s team wanted him to see. A tape of a staged robbery recorded in a duplicate of the Bellagio vault.
It’s a classic scene that has been repeated in various bank heist movies over the years.
And, as it turns out, it’s also the perfect metaphor to explain how some modern-day cyber attacks happen in the financial sector.
In this article we’ll explore one attack scenario in fraud detection and protection services. And we’ll explain why it hints at the need for strong endpoint security.
### The changing face of financial fraud
Financial fraud detection and protection services were already hugely important in banking. But regulations such as [PSD2](https://www.finextra.com/blogposting/17438/psd2-what-is-it-and-what-does-it-mean-for-fraud) have made them a necessary requirement.
The only problem is that fraud detection is a lot more complicated today than it used to be. 10 or 15 years ago, it was centered around an individual’s location. In other words, where the card was used - such as at an ATM, a hotel, or a restaurant. A classic red flag moment back then would have been if a bank account was accessed once in London, and then again in New York three hours later. This operation would have been physically impossible for the same person to carry out. And so a bank would be immediately informed that something untoward had occurred.
These days, it’s different. The proliferation of digital mobile payments and the use of virtual cards has somewhat blurred the view of what banking fraud looks like. It’s a lot trickier to know for sure what is genuine and what is bogus.
A user’s location is a guaranteed and trusted metric. It’s something that can be confirmed accurately. But with mobile payments, a user might use a VPN proxy to make it look like they’re somewhere they’re not. And there are examples in recent years involving Tinder and Pokemon Go where users have manipulated their device’s location using rooting tools.
If location used to be a stationary data point that a bank could lock onto, there are now thousands of data points dancing around in the ether. That’s why there’s now a recognition in banking that humans alone probably can’t monitor so many of these moving parts.
That’s where AI comes in.
### How AI can help
AI can help banking systems to analyze big data points and improve - or even generate new - fraud detection algorithms.
But to collect the data in the first place, fraud systems need to use sensors that are connected to mobile apps. Typically these sensors are included in mobile SDKs that are integrated into applications. These can identify and verify transactions linked to a specific account.
The danger with relying on SDKs for this task, though, is that you don’t always know how secure they are. As we covered in a recent article about [stopping software supply chain attacks](https://licelus.com/insights/how-to-stop-software-supply-chain-attacks), there have been plenty of examples recently of malicious code within libraries and dependencies helping hackers to infiltrate some of the world’s biggest tech companies.
Then there’s the threat of an attacker using a banking application with a rooted device, or using social engineering to get end users to install a fraudulent app.
### Strong endpoint security secures the vault
Let’s go back to the Ocean’s Eleven comparison at the beginning of this piece for a second. If you were planning an attack on a bank or a casino, then the security cameras would be a logical target. After all, your main goal would be to trick security staff into thinking an attack wasn’t happening.
Now imagine that instead of a physical bank, your target was a bank’s mobile app. In this case, the SDK is the sensor (or the camera).
In the same way that a bank’s security would be categorized as circumspect if its cameras were easily manipulated without the security team knowing, a mobile banking app’s security would fall well short if it wasn’t able to recognize a fraudulent SDK.
It’s for that reason that strong endpoint security is so important. A bank can choose to invest in smart cameras that recognise someone moving close to them. And they can also choose to invest in user interface protection, anti-tampering technology, and the ability to check for existing vulnerabilities in SDKs for their mobile banking app.
## QR Code Safety Guide
[All insights](https://licelus.com/insights)
### Follow us
28 Apr 2022
### Are QR codes safe?
URL: https://licelus.com/insights/are-qr-codes-safe
# Are QR codes safe?
Wait a second. Did you arrive at this article by scanning one of our QR codes?
If so, you might be a little uneasy with the headline of this article. But don't worry, you can trust us - we're a mobile app security company after all.
But not all QR codes are safe. Read on and we'll explain why you probably shouldn't scan every QR code you come across.
### Covid, Coinbase, and the QR code
Some bemoan the use of words like “renaissance” or “comeback” when they read about the QR code given that it [never really went away in many places](https://www.nytimes.com/2021/01/28/style/qr-codes.html).
In China, for example, more than 90% of digital payments are made on WeChat and AliPay which depend on digital wallets and QR codes.
But there’s no denying that in the West the boom in QR code usage coincided with the pandemic.
In the spring and summer of 2020, they sprang up outside bars and restaurants to help us order while maintaining a safe social distance. Since then they’ve appeared almost everywhere - on digital tickets, promotions, and community event sign ups.
[e-Marketer predicts](https://www.emarketer.com/content/qr-codes-forecast-trends-2022#page-report) that the number of US smartphone users scanning a QR code will increase from 83.4 million in 2022 to 99.5 million in 2025.
It’s easy to believe stats like this when you see QR codes on leaflets in cafes and even pinned to walls and lampposts. The QR code has definitely gone mainstream.
And because the pandemic trained us into thinking that scanning them is perfectly normal, people are now happy to do so in a variety of settings. Mostly without thinking about the security implications whatsoever.
As with most interactions and transactions people carry out on their phones, there’s an assumption that QR code scanning must be safe.
This was aptly demonstrated during the 2022 SuperBowl, when the cryptocurrency exchange company, Coinbase, [ran an advert](https://youtu.be/1zLsUhOCqyU). In it, a QR code floated around viewers’ TV screens and, without thinking much about it, millions of people reached for their phones.
Many lauded the ad as a great success. Coinbase themselves claimed that they received 20 million hits in a single minute.
But others expressed caution.
[In an article in The Next Web](https://thenextweb.com/news/do-not-scan-random-qr-codes), Callum Booth argues the ad might have set a dangerous precedent. The lack of context could potentially have furthered the belief that it’s perfectly normal for us to go around scanning every random QR code that we come across.
### What makes QR codes unsafe?
Around the same time the QR code began to be seen more widely, people were also getting used to phishing texts pinging on their phones. Fake messages claiming to be from banks, energy suppliers, and even health centers offering covid tests.
While it isn’t always possible to tell whether the links in these messages are genuine or not, sometimes it is. A company name might be misspelt, for example. The kind of thing that you could miss at first glance (hence why a lot of these phishing messages succeed) but not the second time.
With a QR code, on the other hand, it’s much harder to know whether you’re about to be taken to a genuine website or a fraudulent one. All you see to begin with is a jumbled pattern of black and white blocks. Once you scan it, a message does pop up telling you where the QR code is sending you, but most people simply click through without reading this.
And so even more than with normal links - which we’re still getting used to being sceptical of - you’re completely putting your trust in the people behind the code.
As we wrote in an article about the rise of phishing messages, [we tend to be a lot more vulnerable on our phones](https://licelus.com/insights/why-our-emotions-make-us-more-vulnerable-to-cyber-attacks). There are a number of reasons for this, but perhaps the most important one is that we’re more relaxed while we use them. In recent years the device has become a kind of second home we can escape to occasionally. A place to catch up with friends and family.
In the case of QR codes, examples of when you’ve used one could include buying a round of drinks for friends, or arriving at a concert venue to see your favorite band. In other words, innocent, fun, happy memories.
This psychology matters because it matters to bad actors, too. It’s for precisely this reason that the mobile device has become such a hot target for attacks.
They also know that we act in the moment on our phones and don’t question things as much as we might when we sit with our laptops.
Hackers have quickly identified the cryptocurrency space as a key industry to exploit the vulnerabilities of the QR code. That’s because they’re commonly used to help mobile devices to quickly locate virtual wallet addresses to transfer currencies. But as QR codes are easy to create, [attackers can trick people](https://www.techradar.com/uk/news/are-you-sure-about-the-safety-of-that-qr-code) into transferring funds to their wallet, instead.
A QR code can also provide instructions to automatically order a phone to connect to a wifi connection. This is dangerous because it might be a very insecure network with sniffing tools set up so that all the traffic between the phone and a server can be recorded.
There are also privacy concerns with QR codes that the average user is unaware of. After scanning one, people are often asked to enter their personal details either on a website or in an app. [This makes it a lot easier for businesses to track and target customers](https://www.nytimes.com/2021/07/26/technology/qr-codes-tracking.html?utm_source=General&utm_campaign=1ea3edf262-EMAIL_CAMPAIGN_2021_08_30_10_44&utm_medium=email&utm_term=0_a3ff3de473-1ea3edf262-412417594) with personalized offers further down the line.
But as we often say here at Licel, privacy and security are connected. If you get into the habit of scanning QR codes and sharing your personal credentials, you can’t always be sure how robustly those details will be protected by third parties.
### How to practice QR code safety
To conclude, we’re not saying you should never scan a QR code. But you should definitely be cautious about scanning them. As with many of your daily smartphone interactions, there are risks lurking under the surface.
A lot of the advice you hear about phishing scams hold true for QR code offers that look too good to be true. Remember, you can always go directly to the company’s website yourself rather than scanning through the QR code.
Here are our tips for safe QR code scanning:
- make sure that the link within the QR code starts with https://
- don't install third party apps to scan QR codes - use the one already embedded in your photo app
- try to avoid scanning QR code stickers on printed materials
- avoid scanning QR codes from unknown sites in your web browser or on popup adverts
- don’t download apps from third-party app stores or websites
- don’t use QR codes to access public wifi
## Risks of Rooted Apps
[All insights](https://licelus.com/insights)
20 May 2022
### The risks of letting your app run on a rooted device
URL: https://licelus.com/insights/the-risks-of-letting-your-app-run-on-rooted-devices
# The risks of letting your app run on a rooted device
There are a lot of reasons why users might want to root - or ‘jailbreak’ - their devices. Some are not happy to have their phones and tablets pre-loaded with apps that they never asked for and may never want -- that might be just bloatware or, in more sinister cases, spyware.
Others might simply want more control over their own device and its functionalities: to install ad blockers, to play music videos with the screen locked, or to [tweak Android Auto](https://ipoki.com/android-auto-hack/). Apple users jailbreak their devices to install unapproved applications via Cydia or to run OpenSSH.
Indeed, there are estimates that some [8.5% of Apple users](https://www.pingdom.com/blog/where-jailbreaking-iphones-is-most-common/#:~:text=There%20are%20a%20lot%20of,app%20store%20for%20jailbroken%20iPhones.) and around [7.6% of Android](https://www.kaspersky.com/blog/android-root-faq/17135/) users take such steps. But this comes with risks for both users and app developers.
In this piece we’ll cover the risks with Android in particular.
### Why getting root is risky
The Android security model is based on the Linux user model. Each application (with one exception) is assigned a Linux user ID and its own sandbox. That means the app runs in a separate process (or group of processes, in some cases) and has its own part of the file system. There is no shared access to other apps’ process memory, and no access to the system folders whatsoever.
Apps are granted permissions both at install time and at runtime. The sandbox model should guarantee that app data is not accessible to any other application on the device.
But the ‘user’ (i.e. the application) with maximum privilege - with root privilege - is able to read all other applications’ data and modify it freely.
So the owner of a phone or tablet decides to root their device, and they have the power to make all the modifications that they want. But this power can also be abused by malicious actors and malicious software.
Let’s explore three different risk scenarios.
##### Risk Scenario 1 - Malware Infiltrating Sandboxes
The device gets infected with a malicious application (and there are plenty of ways for that to happen). Suddenly, the trojan in this malicious app can take advantage of the root privileges that the user enabled, allowing it to access every folder on the device, including for every other application.
Since the sandbox rule of no shared access no longer applies, the trojan app can now exfiltrate whatever is stored in /data/data/Famous-Banking-App, or in /proc/maps -- runtime data, cached balances, lists of accounts, transaction history -- and report it all to some unknown server. And if security wasn’t a priority for the developers of the Famous Banking App - if they left secrets unencrypted, for example, and chose to store sensitive data on the device - then the consequences for the user (and their bank) could be even more severe.
Without the hijacked root privileges, on the other hand, the trojan app would be left trapped in its own sandbox, unable to access the data in the Famous Banking App’s private folders.
##### Risk Scenario 2 - Fraudulent Certificates, Man-in-the-Middle Attacks
The same principle applies to network traffic. Almost every app relies on HTTPS certificates to confirm that the server it is communicating with is the legitimate, expected one. The system stores the certificate data and checks that it matches the certificate presented by the server. But on a rooted device, the folders containing the certificate data can be modified, just the same as any other folder.
If a bad actor can create a situation where a new, fraudulent certificate is installed on the user’s device to replace the legitimate one -- for example by using social engineering techniques to get the user to click on a certain link - then any HTTPS checks are pointless. And once the certificate is in place, traffic from the device can be redirected to any server in the world, intercepting all requests and replacing all responses. To the end user everything seems to be working as expected as they unwittingly send off their data - and it is sensitive data above all that is shared like this - to be harvested from a mysterious server.
This type of malicious certificate installation is much simpler on a rooted device: the user’s only involvement is clicking the link to download the fraudulent certificate.
##### **Risk Scenario 3 - System API Hijacking**
Apps rely on System APIs to make use of a device’s inbuilt functionalities. Root privileges allow the user to modify any system component, and even to replace the entire system with a custom one. The risks to apps and app users are clear; nothing on the device is off limits.
For example: imagine you have a corporate mail application installed on your rooted device. You have a list of contacts there and your emails as well, including contracts and financial reports. Such apps typically cache the emails and files to the disk. If the Android Filesystem API itself is modified, then it’s possible to intercept every bit the app writes to the disk and write them to other locations as well; to send them over the network; or to upload them to a file sharing service.
Without root, and the custom modifications to the System APIs that it enables, this type of behaviour would be simply impossible: if it is not written into the particular System API, it cannot be done.
### Why allowing root is risky
So far, we have focused mainly on the risks to the owner of the device. Many of these risks also apply, though, to mobile apps themselves and the organizations who publish them.
Essentially, as the examples above make clear, any security guarantees simply disappear once the user decides to root the device. User behaviour cannot be restricted in the same way either.
Rooted devices increase the risks for apps running on them of:
1. Spoofing, cheating, and abuse of core functionalities
2. User data theft
3. Financial theft
4. IP theft
5. Piracy, and DRM violations
Scenarios and examples are endless, but here are a few:
If you are the developer of a mobile game, you might offer users the chance to make in-app purchases to unlock some bonus features. But root may enable them to pick up those same bonuses without paying.
For a financial app, any successful attempt by an attacker to intercept a network call and change the addressee, for example, could come at a substantial cost for the victim. And it would also be bad news for the company behind the app, in reputational terms at the very least.
Any of the risk scenarios above (Malware, Man-in-the-Middle Attacks, System API Hijacking) might also easily lead to user data exfiltration, with attacks specifically targeting users who have rooted their devices.
### How app developers can manage the risks of a rooted device
There are broadly only three options:
1. Accept
2. Prevent
3. Mitigate
Which approach you choose as an app developer will depend on a number of factors. But it will always be necessary to consider what the risks are of your app running on a rooted device, and whether those risks are acceptable to you.
At the light end of the risk spectrum, there are content-only applications - a museum exhibition app, for example. The user may not need to enter any personal data, and the app may not contain any highly sensitive IP or process any cryptographic functions. The organization and developers behind such an app may choose simply to **accept** the low-level risks.
At the other extreme, healthcare apps managing Personal Health Information (PHI), governed as it is by strict legislation in many countries, may consider the risks too great. In this case, the simplest solution is to implement a root detection mechanism and to **prevent** the app from running on a rooted device. We will look into the practicalities of this later in the article, too.
Financial app developers may be in a trickier situation. Mobile banking is now a necessity for most customers, and having a user-friendly app to manage your finances is a major deciding factor when choosing a bank. Financial institutions therefore have a tough decision: whether to allow their app - with payment functionalities and highly sensitive data - to run on rooted/jail-broken devices, or to risk losing almost 10% of their target audience. For them, a middle ground might therefore be to **mitigate** the risks entailed by the app running on rooted devices.
There are a few methods for this, and it is worth combining them all to create the most comprehensive approach.
One is implementing a root detection mechanism and using the results not simply to block the app from running, but to introduce certain restrictions on end users whose devices are rooted. So, to block certain actions, to require additional authentication, to limit all files to readonly, or just to allow the user to explicitly accept the risks (and liability) for running the app on a rooted device.
How can this be done? Well, some techniques for root detection are quite well known: for Android the heuristics for detecting root include checking the buildtags, searching for the superuser.apk, trying to invoke ‘su’, or checking permissions for the /data folder.
But even detecting root - let alone implementing comprehensive anti-root measures - is not as simple as it may seem. Especially when you consider the risk of dynamic root access, the changing nature of the operating systems themselves (for example, direct file access has been managed much more strictly since Android 10), and constant updates to root and system customization tools, including innumerable root hiding mechanisms. It can be almost a full-time development job to keep anti-root measures up-to-date.
Another method involves directly preventing the specific risks that we have discussed above. For example, to prevent man-in-the-middle attacks, app developers may take the responsibility for checking certificates away from the system (which is vulnerable to root-based modifications). Instead they can pre-specify the legitimate certificates within the app itself, and implement checks which block any connections to domains that do not bear the ‘pinned’ certificate. This is SSL Pinning.
A simple diagram may be useful here:
When the device first attempts to establish a secure connection, the backend will reply with its certificate to prove that it is the expected, legitimate server. The mobile app then makes a cryptographic check against the certificate that is embedded into the mobile app itself. This overcomes the need to leave such checks to the system, since the system itself may be compromised.
And the same principle - of not allowing the app to fully trust an execution environment that may be insecure - should be applied to blocking other attack vectors that may exploit root privileges.
### But what about trusting the app itself?
We have talked about not trusting the operating system, of not trusting the app’s execution environment. But what about trusting the app itself?
Root detection, enhanced authentication procedures, restrictive security policies, SSL Pinning -- all of these defense mechanisms are based on functionalities within the app. But an app can be tampered with and modified just as well the system; what then becomes of the defense mechanisms?
The tampering process can be relatively simple. The attacker downloads a target APK and unzips it (yes, an Android app is just a signed zip archive), decompiles the dex files into bytecode (the SMALI format, which can be relatively easy read and modified), and then using much the same tools recompiles the app and signs it with their own certificates.
This is why it is so important to guarantee that two fundamental principles of application security are upheld:
##### **Application Hardening**
Mobile app hardening means not just obfuscating, but also encrypting, virtualizing, and isolating the code and resources within your app. This makes them much more difficult to reverse-engineer and exploit.
##### Application Integrity
The integrity of your app needs to be checked and guaranteed during runtime. Without integrity, other security measures can be removed or overridden, and the application’s core functionalities can be tampered with. When we refer to mobile app integrity, we mean that users are able to trust that the application is the one it purports to be. So, integrity needs to be verified from your app being uploaded to an app store through to it being downloaded to the user’s device, right up to launch and during runtime.
That means integrated checksum and hash verifications based on all of the contents of the app (to ensure that the bits on an end user’s device are identical to those that the developer published), combined with checks on signing certificates, and guarantees that the app was installed from a trusted platform. If the app doesn’t comply with any of these requirements, it shouldn’t be able to run.
### Conclusion
So, to return finally to the merits of **accepting**, **preventing**, and **mitigating** the risks of allowing an app to run on a rooted device, which is the best approach for you?
Moral, legal, and technical considerations will all have to play a role in your decision.
Firstly, it is reasonable to think that the user should be free to do whatever they like with their own piece of hardware. In some jurisdictions, though, it may be a legal requirement not to allow the app to run on rooted devices. In others, it may be the developer's responsibility to make clear the risks and potential consequences of particular actions.
Other cases are not so clear cut; who is responsible if the personal health information from a rooted device ends up in the hands of bad actors? What happens if the user loses money due to a virus operating on a rooted device?
These questions do not have easy answers, and every case is different.
Nevertheless, if security is a top priority for your app (and your users), there is every reason to prevent it from running on a rooted device.
If you would prefer to mitigate the risks, then we have seen some approaches to doing so -- the combinations of root detection, enhanced authentication procedures, restrictive security policies, and SSL Pinning -- which can be highly effective.
Whichever path you choose, though, you will need to take a holistic approach to security, taking measures to ensure that your app itself is trustworthy enough to run in an untrusted environment, and exist in a zero-trust world.
17 Jun 2022
### How can you protect yourself from social engineering?
URL: https://licelus.com/insights/how-can-you-protect-yourself-from-social-engineering
# How can you protect yourself from social engineering?
Early in his book **Influence, The Psychology of Persuasion**, Robert Cialdini explains how the “cheep-cheep” sound of a turkey chick causes its mother to whirr into action. Upon hearing the distinctive sound, the turkey’s maternal instincts kick in without thinking.
Humans, of course, use much more complex mechanisms when it comes to decision making. Our brains have evolved to process countless eventualities before coming to a conclusion.
But in the epilogue of **Influence**, Cialdini poses an intriguing question:
Could it be that our superior mental ability has enabled us to create a world so complex, so fast paced, and so data heavy that often the only way to cope is by relying on immediate, impulsive decision making?
We’ve always had the ability to make in-the-moment decisions, of course. Yet might there be a danger that this kind of response is now becoming our default setting?
Cybercriminals for one have bet big on this being the case. And the fact that their phishing attacks are currently so successful seems to be reinforcing their confidence.
In this article we’ll explore the ways hackers are profiting from our evolving digital behaviors. And we’ll explain how you can protect yourself from social engineering.
### Persuasion principles
In December last year, [a man in Singapore received a text message](https://www.straitstimes.com/singapore/courts-crime/ocbc-bank-customer-lost-120k-in-fake-text-message-scam-another-had-250k-stolen) that he thought was from his bank.
The sender of the message informed him that an unknown payee had been added to his account and that if he hadn’t added this person himself, then he should click on the link in the message to look into it.
After clicking on the link, the man landed on a website that looked identical to his bank’s. He entered his account details, thinking that by doing so he would resolve the unknown payee issue. Instead, he unwittingly handed over control of his bank account to bad actors.
For five years, he and his wife had been saving to start a family. In a matter of hours, all of their savings were lost.
Individual stories like this one highlight the true cost of cyber attacks. People’s lives and their plans to enrich those lives can be devastated in no time.
The story is also a good example of a social engineering attack.
When people think about cyber attacks they tend to think about complicated technology:
Attackers cracking cryptographic keys, for example, or reverse engineering an application and then releasing a fake version.
While these more technical attacks do happen, they still tend to need some kind of human interaction to succeed.
The bad actor has to convince his victim that what he’s asking of them is perfectly normal and fits neatly atop the foundational beliefs they use to guide their everyday actions.
**This** is social engineering.
In Cialdini’s **Influence**, he refers to six principles of persuasion that can be used to convince someone to do something. When he wrote the book he was thinking more about the tricks used in marketing and advertising than cyber attacks. But it turns out that these principles work just as well for hackers as a go-to guide for social engineering.
So, what are they?
The first is **reciprocity**. The idea here is that if someone offers you something or acts in a kind way, then you’ll feel compelled to do the same for them. In social engineering, this could be a bad actor offering something for free or making it look like they’re solving a problem for you, such as in the example from Singapore above.
Next comes **consistency**. Have you ever told someone that a particular belief or value is important to you? Chances are that after sharing this information with them, you’ll want to make sure your actions are consistent with those beliefs. Social engineers can tap into this trait by asking you to do something small to begin with and then following that up with a more substantial request later.
Another principle is **consensus**. As much as we might not like to admit it, we often tend to follow the crowd - that’s why reviews are so important on sites like Amazon. Bad actors can exploit this principle by tagging onto wider cultural and societal trends. The more everyone around you is behaving in a certain way, the less suspicious you’ll be of a text message that tells a similar story.
**Liking** is also an important factor when it comes to persuading somebody. You’re more likely to agree to a request if you’re fond of the person making it. This is why malware often hijacks the contact list on your phone. The thinking is you’d be less likely to scrutinize a message that comes from a friend and would simply click on the link without thinking.
During the early days of the pandemic, people felt a bit lost. They were reliant on advice from experts. Hackers were aware of this reality and looked to exploit the next persuasion principle - **authority**. We’re more likely to believe people in positions of authority on a subject. This is why we started seeing fake phishing messages pinging on our phones - supposedly from healthcare facilities - urging us to book a covid vaccine appointment.
The final principle is **scarcity**. It’s human nature to value something more when there’s less of it around. Attackers often try to exploit this in phishing messages by making it sound like you have to do something quickly before it’s too late. So, warning you that you’ll be locked out of your account in 24 hours if you don’t click on the link to fix the problem. This is a really common approach these days - [hackers want you to make a decision in the moment without thinking seriously about it](https://orangecyberdefense.com/no/blog/cybersecurity/the-psychology-behind-social-engineering/).
### It’s easier to be tricked in a fast-paced world
Attackers use these persuasion principles to exploit the normal - and mostly decent - way that we live our lives. It’s the digital equivalent of you holding the door open for a tailgater. More often than not your automatic, unthinking belief that holding the door open for somebody is the right thing to do will supersede any suspicion you might have that the person following you through the door doesn’t work at your office.
Remember, all of this happens in a matter of seconds. But in the digital worlds we dip into each day, many of our reactions are even quicker. They can be measured in milliseconds.
In the epilogue of Influence, Cialdini suggests that the faster the world becomes - and the more information we consume - the more reliant we’ll be on immediate, shortcut responses. And as a result, he says, the number of attempts to trick us will also increase.
One can’t help but be reminded of his words when reading about modern social engineering attacks.
The thing is, Cialdini made his prediction in 2009. In other words, before the smartphone and social media had truly cemented themselves in our everyday lives and changed our behaviors so completely.
If we were coasting along a fast-flowing stream of data in 2009, then in 2022 it can sometimes feel like we’re trying to right ourselves underwater having been hit by a whitewater wave.
In the decade or so since Cialdini’s prediction, we’ve gradually come to associate the mobile phone with immediate responses. You make a quick retweet here, you like your friend’s Instagram story there.
You move from one in-the-moment, unthinking response to the next, while simultaneously doing other things - pouring a cup of coffee, walking to meet a friend, or jumping off at your metro stop.
These distracted moments are precisely when you might receive a text message that looks genuine at first glance.
In circumstances like these, it’s hardly surprising that [attackers often seem to have the upper hand](https://licelus.com/insights/why-we-need-to-understand-the-hacker).
That’s certainly how Brenda K. Wiederhold - president of the Virtual Reality Medical Center - sees it in her paper, The Role of Psychology in Enhancing Cybersecurity. She thinks [people are at a psychological disadvantage](https://www.techrepublic.com/article/cybercriminals-use-psychology-cybersecurity-pros-should-too/) when faced with cybercrime. While this is sometimes due to a lack of information, Wiederhold also suggests that even when people do have sufficient information to recognize the risks, they can still be enticed by the prospect of instant gratification.
It’s as if thousands of likes and other social interactions over the years have given us [a false sense of security](https://licelus.com/insights/why-our-emotions-make-us-more-vulnerable-to-cyber-attacks) on the device.
### How can you protect yourself from social engineering?
Fresh examples of social engineering attacks appear almost daily.
There’s the employee at a water treatment plant being tricked into [allowing an attacker to use TeamViewer](https://www.zdnet.com/article/following-oldsmar-attack-fbi-warns-about-using-teamviewer-and-windows-7/) to access the internal network and modify the chemical levels.
Then there’s the hacker [conning a man into ceding control of a digital wallet](https://www.vice.com/en/article/pkp7pm/hacker-steals-dollar14-million-in-nfts-from-collector-in-one-sweep) and then stealing $1.4 million worth of NFTs.
The second example is simply [one of many involving cryptocurrencies and NFTs](https://www.latimes.com/business/technology/story/2022-05-04/crypto-scammers-find-social-media-a-rich-hunting-ground), where it often feels like nobody is in charge and the rules are being made on the fly. It also aligns perfectly with Cialdini’s prediction about a faster, more distracted world being a world where we’re more likely to act impulsively and open ourselves up to being duped.
So, what’s the answer?
There’s no hitting the pause button (let alone rewind) on technological trends. Unless you plan to throw your phone off the nearest bridge, the only answer is to accept that there are people out there who are waiting for you to slip up.
This isn’t the first article we’ve written where we’ve advised you to be suspicious. And no matter how often we say so, it will always feel like a sad piece of advice to give. But it’s an absolutely essential trait for the modern world.
So yes, be suspicious. And if possible, try to slow down sometimes too. Whenever a text message pings on your phone, read the contents of it in the notification preview, and then put your phone down for a few seconds. Focus on the world outside of your smartphone screen - the wind blowing through the trees perhaps - and ask yourself: could that message be fake? Do I have a relationship with the company in question? If so, could I contact them directly to verify that what the message says is true?
The advice above is for individual mobile device users. But businesses also have a big role to play in educating users of their mobile apps. Banks are doing a pretty good job at this - especially neobanks - by telling their customers about social engineering scams to look out for.
But they can still do more. Offering this advice will appear hollow, for example, if banks don’t also [secure their mobile banking application](https://licelus.com/proven-protection-for-financial-apps) as robustly as possible to prevent other types of attacks.
The messaging about risks has to be consistent as well. Epic Games have their own - arguably valid - reasons for encouraging people to download Fortnite outside of the two big app stores. But this kind of advice can also lead to bad habits. After all, social engineering messages often try to get people to download a bogus app from a malicious website.
More than anything else, our advice for banks and other businesses would be to have empathy for your end users. Remember that in no time at all your end users have got used to managing a large part of their everyday lives by scanning, swiping, and scrolling a smartphone screen.
So, when you set out to design and develop a mobile app, don’t only think about the user experience. Think instead about [how you can make sure their security is considered](https://licelus.com/security-by-design) from when they download the app through to everyday use.
28 Jul 2022
### How to keep integrity control when publishing apps on third-party platforms
URL: https://licelus.com/insights/how-to-keep-integrity-control-when-publishing-apps-on-third-party-platforms
# How to keep integrity control when publishing apps on third-party platforms
### The balance between security and competition
In recent months a battle has been playing out that has the potential to shape the future of the tech world.
On one side you have those who are trying to curb the power and dominance of Apple and Google and introduce a more competitive landscape. And on the other side you have the two Silicon Valley giants themselves, claiming that such a move would put end users of applications at risk.
As you know, Google Play and Apple App Store are the official markets to publish mobile apps for Android and iOS devices respectively. These are two incredibly convenient distribution channels. Not only because the stores are already installed on the devices, but because they’re fully integrated natively into the OS and they provide lots of tools from marketing through to security controls.
But publishing on these two official stores comes at a cost - literally. They both charge 30% of the application price or in-app purchase transaction as a service fee (with some exemptions during the first year). Almost a third of the app cost is a hefty margin, which helps to explain why developers are exploring the possibility of publishing via third-party stores and distribution channels.
Some companies’ battles to escape the reality of what they see as an extortionate model have made newspaper headlines. We’ve written before, for example, about Epic Games (the developer of the hugely popular Fortnite) [railing against Apple and Google’s hegemony](https://www.theverge.com/2021/9/12/22667694/epic-v-apple-trial-fortnite-judge-yvonne-gonzalez-rogers-final-ruling-injunction-breakdown).
At the same time, legislation is also emerging - [such as the EU’s Digital Markets Act](https://fortune.com/2022/03/25/apple-google-criticize-eu-digital-markets-act/) - which piles even more pressure on the tech giants to allow end users to install apps from third-party platforms.
And while some might celebrate this move to encourage increased competition, Apple and Google do have a point when they suggest that it might be at the detriment of security. This is particularly true if we focus on integrity control - the act of ensuring that an application hasn’t been tampered with and remains the same as the one developers handed over at the time of launch.
**Publishing apps on third-party platforms would almost certainly lead to a loss of integrity control** - at least in the short term.
In this article, we’ll take a look at some of the measures Apple and Google have in place to maintain application integrity. We’ll also explore the protection tools you as a developer would need to equip your app with to keep integrity control if it were to be published on another platform that doesn’t have these measures in place.
### What do the two big app stores currently provide?
##### **Secure application delivery**
The industry standard of application distribution today is rather complex. **Access to the Google Play/App Store management console is protected by a multifactor sign-in experience**. Each application you create is required to be digitally signed, with the public certificate being managed through the same console.
These measures make sure that, once created, the new version of the application can only be updated by [the same entity that created it](https://licelus.com/insights/how-to-counter-the-dangers-posed-by-tampering), so long as you haven’t published your certificates and password on the Internet.
These days both of the two big stores support a double signature scheme: one which is used to upload an app to the store, and another to sign the app itself. This scheme mitigates the risk of losing the original certificate and thus being unable to update the app - something which used to happen quite often.
The next step is a secure delivery system to the end user’s device, which happens via a protected communication channel. Also, the device itself checks the application signature against a previous signature and a version created in the store. Something that is especially common with iOS applications, where the signature can expire or be revoked. This multi-layered approach to secure application delivery and updates is the industry standard. And it has taken years of effort to reach this point.
##### **Device and app attestation**
It’s important to remember that applications run on devices which are fully controlled by their owners. And this can be such a risky environment at times that you’d be forgiven for wondering whether it might be better [not to operate there at all](https://licelus.com/insights/the-risks-of-letting-your-app-run-on-rooted-devices). Thus there needs to be a mechanism to assess the device your app is running on and to determine whether it’s safe.
Both stores (Apple and Google) provide APIs that do just that. Google Play has SafetyNet API, which was recently complemented with [Play Integrity API](https://developer.android.com/google/play/integrity/overview) to make an application integrity verification for critical actions. iOS offers the [App Attestation Service](https://developer.apple.com/documentation/devicecheck/preparing_to_use_the_app_attest_service) to make sure the device is safe and hasn’t been jailbroken. It’s also able to verify that the application itself wasn’t tampered with using cryptographic tokens. These APIs are an integral part of the two respected ecosystems.
##### **Application monitoring**
Visibility is a critical aspect of any solution. Application developers expect to be able to monitor their applications. But this is a more difficult task compared to server components because you don’t control the device itself. To monitor the application in terms of performance, memory consumption and general health, additional steps have to be taken.
And application stores help with that in various ways. You can see the distribution of your user's device's OS versions, the fatal errors of your app, and the number of app crashes, for example.
### An integrity control checklist for third-party publishing
So we’ve explored how the Google Play Store and the App Store help to maintain app integrity. Away from this in-built protection, though, applications must fight threats on their own.
It’s vital that developers understand this. Because while there may be some justifiable resentment at the cost Apple and Google charge, as the paragraphs above set out, there is a protection payoff benefit that comes with that fee.
If you’re considering shifting to third party publishing platforms for your app, it’s important to consider the threats it might be up against. Clearly threat models differ considerably for applications with a variety of purposes. The risks an app game faces might be very different to a banking application, for example. But determining this threat model is a crucial first step for you to know which steps to take to protect your app.
Some of these steps - from the development, delivery and operation perspective - are listed below.
##### **Reliable and secure delivery**
As we learned earlier, we as developers want to make sure the application we publish reaches the user’s device intact and untouched. To do so we first need to cryptographically sign the package using the same keystore. This file should be stored safely: ideally so that only a delivery pipeline can access it. It should also be properly backed up. And the transmission should happen over a secured communication channel - both from the development infrastructure to a distribution service and from a service to an end device.
The security controls include encrypted traffic, client and server certificates and certificate rotation. The delivery channel should also be reliable and support upload/download resume, checksum verification, and monitoring upload status. The access to the upload mechanism should also be protected by authentications like login/password pairs (as Apple does), a token (like MS App Center), or a certificate (as per Google Play).
##### **Cryptographically-ensured application integrity**
Once the application is installed on the device, we want to clarify the integrity of the package in case it was altered by agents on the device. The first step to do so is calculating a checksum. However while the checksum can verify the integrity, the authenticity is another matter entirely. If the app transfer were intercepted, likely the checksum would be replaced and the hashing function could easily be guessed.
A more sophisticated approach is [Key-Hashed Message Authentication](https://www.jscape.com/blog/what-is-hmac-and-how-does-it-secure-file-transfers), where a common private key is used as part of the hashing algorithm. The advantage gained here is that such a hash cannot be recreated without knowing the private key which only resides on the application server. So, if the application were compromised it would be impossible to create a proper hash for it.
##### Application-level mechanism of device and self-assessment
Another threat you might want to protect against is running the app on a compromised device. Once the device is rooted or jailbroken there are indirect signs it has happened. It’s possible, for example, to call su, have a /data/data folder readable, have a superuser.apk somewhere on the filesystem, and so on.
For iOS, such checks include searching for Cydia app installation or having a \"cydia\" scheme available. Those heuristics are not permanent and vary from version to version of the OS and from one jailbreak to another. You might want to implement those checks as well.
Also, in the case of popular applications with hundreds of thousands of users (or even millions of them), another problem arises when the application is used by a bot for spam purposes, multi-account registration, and so on. Some tactics are purely server-side, like a limitation of particular requests per second, per device. But the application itself can try to fingerprint the user behaviour and make a guess if it is used by the automated script.
##### Server-side application attestation
Applications and games can include paid functionalities. And once the transaction starts, we want to make sure it is not a fraudulent one. Verifying the application binary, the installation from the trusted source, and the device integrity are common measures to do that.
Most of it requires the participation of the server side. The way it might work is by exchanging an encrypted message between an application server, installation source and the app itself. If the application was installed from an untrusted location or has been tampered with, then the check should not pass. This is the mechanism Google Play Integrity API uses and this is what you might want to leverage as well if your app were published on a third-party platform.
##### Integrity monitoring
Let’s assume the application successfully reaches the user’s device with its integrity verified, and the safety of the device confirmed. There’s nothing to say it will stay this way forever. The user might catch a trojan, obtain root privileges on the device, or intentionally try to break the application integrity. A user could even try to access the memory dump of the application to search for runtime secrets.
As a developer, you would want to know if any of these incidents had happened. It’s especially important to detect the attempts to compromise the application integrity and report them to the application server. Having such monitoring will allow blocking access to sensitive features, mark the user as a potential fraudster, or just save the information for future use.
### Don’t compromise your app’s integrity
As we’ve highlighted in this article, the implementation of proper integrity control is not an easy task. What’s more, integrity control doesn’t only mean securing app distribution and app/device attestation. The next major component of integrity control is the protection of application runtime memory and defending against malicious code injection.
The number of mobile security incidents around the world right now shows us that there are no completely reliable, secure solutions from mobile platform vendors themselves. In most cases, developers need to implement solutions from commercially-available protection products.
Mobile applications are valuable - often critical - assets for modern businesses. When considering publishing your app outside the big two official app stores, it’s worth considering the tools you’ll lose access to on the two big platforms.
If you do decide to publish on a third-party platform, it’s vital that you equip your application with protection mechanisms that maintain its integrity.
Whether you secure your app yourself or you look for a solution from a mobile app protection vendor, be sure to focus on integrity control. Check that the vendor places a high value on application integrity and that they offer the protection measures we’ve set out in the checklist in this article. Then you’ll be sure that any potential gaps have been covered.
30 Aug 2022
### Is it safe to combine CI/CD tools with external cloud mobile app protection solutions?
URL: https://licelus.com/insights/is-it-safe-to-combine-ci-cd-tools-with-external-cloud-mobile-app-protection-solutions
# Is it safe to combine CI/CD tools with external cloud mobile app protection solutions?
The modern mobile application market requires developers to move fast. It’s all about merging frequently, deploying on a weekly or bi-weekly cadence, incorporating feedback from users, and monitoring application behavior.
But this is impossible without constantly merging developers' changes and deploying new versions of the app all the time, too. There’s no shortage of tools - called Continuous Integration / Continuous Deployment platforms - out there to help. Solutions like Bitrise.io, MS App Center, Github Actions, Circle CI, and others allow you to build and deploy mobile applications using their cloud solutions.
In this article we’ll explore why so many developers are using cloud-based CI/CD platforms. And we’ll explain how you can combine them securely with app protection solutions.
### Why do mobile developers use CI/CD solutions based on cloud infrastructure?
Going from a bunch of source code files to a published app is quite the journey. After getting sources from code storage and compiling them, you need to run tests and other tools to assess the quality. Then you need to apply some protection measures, including signing. Only then can you send it for publication.
Imagine you started building a new mobile application from scratch with a couple of other developers: you have nothing to begin with aside from the idea of an app.
To build a CI/CD pipeline - something you can’t proceed without - requires quite a lot of work. You need a repository to store the code in, for example. You also need a computer that’s different from the one you write code on in order to build the application - unless you want to be a bottleneck for the whole team.
This computer will have to run some scenarios to build your app, like running Gradle or Xcode build. It will also need to get the source code from the repo, have signing certificates securely accessible, and make a connection to application stores to publish the app.
As well as this, you’ll likely also need this computer to be manufactured by Apple, since there’s no other hardware you can build an iOS app on. Lastly, if you want to have several builds in parallel, you need to orchestrate the build process. You could install Jenkins and its agents to several machines and run the whole story, of course, but this would require a lot of time and effort.
In the end, you’ll need to know via a mail notification either that the build has been completed successfully, or that it has failed. More efficient still would be a pipeline status on the code storage, which requires additional integration setup. Whichever way you look at it, it sounds like a lot of work.
This is where cloud CI/CD solutions come into play.
Many cloud services have some of the typical mobile development steps already integrated: installing react-native dependencies, signing the app, running tests, publishing to MS App Center, sending notifications, or having integrations with code storage platforms. The cost of those services is low - particularly when compared to a developer’s hourly rate. This makes them a great tool for developers to focus on app development without worrying about the delivery pipeline itself when there’s no existing infrastructure in place.
Before we move on to explore the best ways of protecting your app as part of the wider CI/CD process, a quick reminder about why security is so important might be useful.
Distributing your application without any protection is extremely risky. You need to safeguard the app from illegal redistribution, protect the data it writes on the device, secure its business logic and intellectual property (like assets or ML models) and make sure the app doesn’t have pre-existing vulnerabilities.
These are all tasks that can be completed using an app protection solution. It obfuscates the app’s logic, introduces integrity controls, and protects the file system APIs with the encryption-enabled versions.
### What is the basis of Cloud CI/CD service security?
CI/CD solutions should be reliable, high performing, secure, and cost-efficient: otherwise, there would be very few developers trusting them as the key part of the application delivery process. After all, reputation is a tough thing to build but can be ruined in a matter of hours. That’s why CI/CD vendors pay a lot of attention to making their infrastructure secure.
One of the important aspects of the CI/CD pipeline is building reproducibility. As a developer, you expect that if you build the same code twice in a row, then you’re going to get the same binary twice in a row. To grant reproducibility vendors use modern virtualization technologies like virtual machines and containers. This also helps with security: nothing can influence your build except the code of your repository.
A key step in the mobile application publication journey is signing. The private keys should be kept secure; this leads the CI/CD vendors to treat the application secrets carefully. Usually, this is achieved by encrypting those secrets and making the encryption keys accessible only by the building runtime.
The last thing worth mentioning is protection from external threats. The CI/CD infrastructure should be guarded on the network level by allowing only necessary network ports, filtering traffic, introducing application level firewalls, encrypting traffic, and so on.
Infrastructure should also be updated frequently as well to have any discovered vulnerabilities patched.
CI/CD vendors can properly secure their infrastructure as they own it and value their reputation.
But can they do the same with external vendors?
### Why using an external cloud security solution is risky
We talked earlier about reasons to repackage or protect your app. Third-party services claim to do the necessary work and protect your application from further attacks. But once you build the app on a single cloud service and then use another cloud-based one for the application protection, you increase the risks for the overall app delivery. Particularly when it comes to application integrity.
Any service outside the deployment environment is a risk from a security point of view. Not to mention in terms of availability and cost.
First of all, you have to support a secure channel between the cloud environments: this includes at least a VPN network and proper authorization and authentication on behalf of the cloud service. The package itself should also be protected as there’s data in transfer and, we know that while [encryption is easy, key management is hard.](https://vixentael.dev/talks/10-lines-of-encryption/) Aside from having the package encrypted, you should also ensure its integrity, preferably using not only a checksum but an encryption key.
The second consideration is that it should provide high availability. Let’s imagine you have a strict deadline for release due to either legislation or technical requirements. You rush the development process and finally submit your app for release. Your pipeline triggers the third-party protection tool and, instead of working for the bundle, it replies with a 502 error. You re-run the pipeline but the error is still there. You reach out to the support team at the cloud mobile app protection service, but they can’t provide you with any ETAs. This is a major risk from a supply chain point of view - not to mention for the reputation of your business.
The third consideration is exposing the unprotected application outside of the deployment pipeline. The threat model of almost any company has to include a malevolent employee; this is why we have a [principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege) in the first place. Let’s say there’s just one employee at the third-party company who has access to the app protection infrastructure. It would be easy for them to install a file system hook, which could dump all the unprotected APK files and upload them to a server outside the company - or even to a workstation where said employee could copy it to a flash drive.
Then there’s the possibility of a network sniffer being installed on the service infrastructure. Internal documents can be of lesser interest to hackers than the applications which go through the service.
These are just some examples of supply chain-related threats. We haven’t covered others like using the wrong dependencies on the build server, building from a different source code than intended, and so on. Each SaaS should carefully examine threats and provide proper protection. If there is a combination of those services, it becomes much harder.
The last consideration is about [the App Bundles format for Android applications.](https://licelus.com/insights/why-the-shift-to-making-android-app-bundles-mandatory-has-sparked-a-debate-about-trust) With the shift from APKs and the introduction of features like [Code Transparency](https://developer.android.com/guide/app-bundle/code-transparency), a new set of issues arises from the cloud mobile app protection services perspective.
First of all, if you leverage Code Transparency, which is an application signature for App Bundles, you need this third party service to manage your application signature, which is also risky. If you don’t do so, then you can’t leverage this tool as an integrity control. Again, not an ideal scenario by any means.
Another problem will arise once you start using Runtime SDKs, which are required to properly manage the permissions of the third party libraries. There is zero understanding of how to manage signatures for them when using cloud mobile app protection services.
### A safer alternative to cloud mobile app protection services
We can see that the application handover from a CI/CD pipeline breaks the internal (and well protected) perimeter and exposes an unprotected application to lots of risks.
That’s why our recommendation is to manage app protection in the same environment you build and deploy the application. If you build it on-premise, use locally installed app protection solutions. If you go with the cloud solutions, stick to the tools and integrations supplied by the same vendor.
For example, bitrise.io has a list of [verified steps](https://devcenter.bitrise.io/en/steps-and-workflows/developing-your-own-bitrise-step/verified-steps.html#:~:text=A%20Verified%20Step%20means%20that,performance%20for%20any%20Bitrise%20user.) that you can leverage in the CI/CD pipeline. You can also ship the app protection tools alongside the application itself and run the app protection from there without breaking the CI/CD perimeter. If you’re using Github Actions, you can create a [custom action](https://docs.github.com/en/actions/creating-actions/about-custom-actions) running an arbitrary binary or even running a docker container. That way you leave all the sensitive transformations of the application in the same environment.
Using an on-premise tool as part of the CI/CD pipeline mitigates a long list of risks connected to combining different execution environments. Many of which we’ve outlined in this article. Both of them combined should put significant effort into protecting the pipeline from internal and external threats, making sure they work with the actual source materials, providing mechanisms to detect tampering, and working with verified dependencies. The fact that on-premise tools completely alleviate those risks for the second platform makes them a much safer choice for application protection.
Having on-premise tools for application protection is our recommended solution for the reasons set out above. However, that isn’t to say that having all the tools in the same environment is a catch all.
The best strategy to work with a highly-valuable application is embracing a holistic approach to mobile security. That means secure development and building infrastructure, [secure SDLC](https://cloud.google.com/blog/products/application-development/google-introduces-slsa-framework), vulnerability management, and keeping all the valuable assets far away from potential attackers and third party services if they’re not robustly protected.
### The secret ingredient of end user security
URL: https://licelus.com/insights/the-secret-ingredient-of-end-user-security
# The secret ingredient of end user security
### Your end users can play a crucial role in the cybersecurity story. But only if you empower them to do so.
Cyber attacks are so commonplace these days that it helps to have your end users on your side. You can achieve this by treating them like human beings and clearly communicating the dangers to them.
### A manifesto for communicating clearly
A few days ago I received an email from my bank aimed at improving end user security.
The email used clear and simple language to explain that they’d soon be introducing a new device verification process to keep my account secure.
This, it turns out, was in response to a phishing attempt that had affected some users. Bad actors were using the bank’s name as a keyword in an ad campaign in the hope that people would click on the link in that ad. Those who did were then taken to a fraudulent page where their credentials were stolen.
At the end of the email were some tips to keep my account secure, including a personal favorite of ours here at Licel:
_Be constantly vigilant_.
While it wasn’t the first email like this that I’d come across - most banks are trying to educate their end users in some way - this one felt particularly effective.
The tone was just right. The bank didn’t hide the day-to-day dangers end users like me face. Instead they respected that I’d be able to absorb the information and take the appropriate action.
What I liked best, though, was that the bank didn’t communicate in a robotic way.
### Don’t forget your end user is a human being
Speaking to your end user like a human being rather than a robot might sound like an obvious piece of advice to give. But it’s amazing how often jargon-laden, robot-friendly language is employed.
It’s as if somewhere along the road toward developing an application - with all the little stresses that pop up - the end user can get forgotten. They can become something of an afterthought. A member of the supporting cast instead of the protagonist.
And this minor role is then reflected in the communications they receive.
The irony here is that it should be pretty easy for all of us to empathize with end users given that we’re all end users ourselves.
You might have had that feeling yourself in the pit of your stomach when, in a moment of distraction, you click on a link that you thought was genuine. Perhaps you’ve experienced the growing anxiety that comes from knowing deep down that the UI in your mobile banking app looked ever so slightly different today compared to how it normally looks.
These are important feelings to remember during the development process and beyond because they act as reminders that you’re not designing an app for a robot. You’re designing an app for an emotional human being. Someone who might use your app after a fight with her boyfriend, after a difficult conversation with her boss, or simply at the same time as she tries to complete today’s Wordle.
### The hero’s journey
In a lot of classic adventure books and movies - think Star Wars or Lord of the Rings - we follow the protagonist along a now familiar path.
At the start of the story they’re living a fairly ordinary life. Then, something or someone calls them to begin a journey. They often meet a mentor character who explains the true meaning of the quest and helps them to be better prepared for the challenges and temptations they’ll encounter along the way. Then, when everything seems to be going well, our protagonist suffers an enormous setback. This results in a transformation in their mindset and a renewed determination to see the mission through to the end, however traumatic it may be. Finally, they return home triumphant to the adulation of those who might earlier have doubted them.
This format is often referred to as [the hero’s journey](https://en.wikipedia.org/wiki/Hero%27s_journey).
It’s still a winning formula for adventure books and movies to this day. But it’s also taught in marketing and business classes as a way of seeing your customer (or end user).
When you’ve created something, be it a product, service, or application, the temptation is to see your company as the hero of the story. But actually the hero should be the person who benefits from what you’ve created.
The role you should play in this story isn’t Luke Skywalker or Frodo Baggins.
It’s Yoda or Gandalf.
### Embrace end user education
The role of the mentor character in these classic tales is to equip the protagonist with all the knowledge and skills they’ll need to fulfil their quest.
They don’t sugarcoat the journey the protagonist is about to set out on. They’re quite open and speak simply and clearly (well, not quite as clearly in Yoda’s case!) about the perils that await them.
This is the best strategy for you to employ when it comes to communicating with your end users to improve their security.
There’s sometimes a reluctance for businesses to even mention cyber attacks to their end users. Almost as if the act of doing so might reflect badly on them for admitting that an attack is even a possibility. But this way of thinking is flawed. The modern consumer appreciates honesty and openness from the businesses they choose to buy - or download apps - from.
At the start of this article I used the example of an email my bank sent to me in which they were totally honest about attacks designed to trick customers like me. They even admitted that attackers had managed to access some end users’ accounts to commit fraud and that they were currently in touch with those customers.
I doubt I’m alone in feeling more trusting of the bank after reading than I was before.
End user education is powerful because, done right, it can empower end users. It can make them feel like allies in the wider battle to stop cybercrime.
So, what kind of things should you teach your end users?
### Tips to enhance end user security
The email I received is a great example of the type of comms you can share with end users to make their experience with your app more secure.
It’s also a good idea to be clear with them about the ways in which you’ll get in touch. The last few years have seen a big spike in the number of successful phishing attacks. The covid pandemic was a particularly fruitful time for bad actors as [they were able to exploit wider anxieties](https://licelus.com/insights/why-our-emotions-make-us-more-vulnerable-to-cyber-attacks) people felt as well as a reliance people had on authoritative voices.
But phishing attacks haven’t gone away. If anything, [social engineering](https://licelus.com/insights/how-can-you-protect-yourself-from-social-engineering) is getting even more sophisticated.
You can help your end users to avoid falling victim simply by making them aware of the ways you would never contact them. In the milliseconds it takes for someone to open a bogus text message and click on a link, your helpful email might pop into their mind and make them think twice and question the validity of the message.
You can also educate your end users about how your app works and the type of personally-identifiable information it processes. Not to mention security best practices they should be aware of while using the app.
[OWASP has a helpful guide of the ways you should manage sensitive user data](https://mas.owasp.org/MASVS/0x07-V2-Data_Storage_and_Privacy_requirements/) which is definitely worth referencing. Because as we’ve said a few times on this site, educating your end user can appear quite hollow if you don’t also work hard to protect your application. One of OWASP’s MASVS requirements - MSTG-STORAGE-12 - states that mobile apps must be transparent about the user data they collect and share, without exceptions.
The key word here is transparent. Your end users value and increasingly expect transparency. They’re generally much more knowledgeable about privacy issues these days. And that means they’re more likely to want to know how their data is being used.
This reality helps to explain why [Google has invested so much time in educating developers](https://blog.google/products/google-play/data-safety/) to be clear about how they handle user data.
Yet from our experience, this is still an area developers are likely to overlook on the journey toward verifying their app for security issues.
### Acknowledge the strangeness of your end user’s world
Technology evolves so quickly these days that most of the time we barely even notice. But sometimes it can all feel a bit too much. The constant churn of information flying across screens and demanding our attention is the ideal environment for bad actors who set out to trick us.
After all, human beings haven’t changed all that much in millenia. Our brains are pretty much the same as those of our ancient ancestors. And yet ours are expected to process about a thousand times as much information on a daily basis. It’s little wonder, then, that we occasionally make the odd mistake and click on something we shouldn’t.
But this reality is rarely recognized or talked about.
[Having empathy for your end users](https://licelus.com/insights/how-encouraging-empathy-can-help-you-to-develop-safer-apps) is absolutely essential if you want to set your company apart from your competitors. By [acknowledging the strangeness of the world we live in](https://licelus.com/insights/5-tips-for-securing-your-mobile-device-in-the-post-pandemic-world), you can show your end users that you care. And by doing so you can build trust with them.
Remember, your end users already know that there are dangers lurking in the shadows. What they’re waiting for is somebody to shine a light to keep them safe.
28 Oct 2022
### How bad actors deliver mobile malware into your device
URL: https://licelus.com/insights/how-bad-actors-deliver-mobile-malware-into-your-device
# How bad actors deliver mobile malware into your device
### Mobile malware is getting smarter and is exploiting a host of new attack vectors. But there are things all of us can do to stop it from further extending its reach.
The COVID-19 pandemic and the many uncertainties that have followed it have cemented an already prominent trend:
Our reliance on mobile devices and mobile applications to help us manage our daily personal and professional activities is increasing rapidly.
As proof of this, look no further than the case of a fire at a data center recently causing an outage [that downed the popular South Korean “super app”, Kakao](https://www.nytimes.com/2022/10/19/world/asia/korea-kakao-ceo.html?hss_channel=lcp-5012731). Its absence for a few days felt genuinely debilitating for some.
And you better believe that bad actors aren’t going to stand idly by while this trend continues to gather pace around us. Not when they have such a massive opportunity to profit from it. This reality helps to explain why there’s been a surge in mobile malware attacks recently. As [ProofPoint reported, there was a 500% increase in attempted mobile malware attacks in Europe during early 2022](https://www.proofpoint.com/us/blog/email-and-cloud-threats/mobile-malware-surging-europe-look-biggest-threats).
This is a strong sign that mobile malware continues to pose threats and cause harm to its victims - from stealing and abusing personally identifiable information (PII), to performing automated attacks to extort money from a bank account (otherwise known as automatic transfer system (ATS) malware).
In this article we’ll share several ways bad actors deliver malware into your device and spread its reach still further. And crucially we’ll also explain how you can protect against malware attacks.
### Malware infection vectors
##### Fraudulent apps
Developing and distributing [fraudulent apps](https://licelus.com/resources/guide-to-mobile-application-protection/threats/mobile-app-fraud) is the easiest and most commonly-used vector by which bad actors spread malware. As we’ve already said, cybercriminals are well aware of our reliance on apps to perform daily tasks. And so it makes perfect sense for them to develop (and then inject malware into) the kind of lifestyle app that we already trust and use everyday. The type of app that has a consistent level of demand - like a cashback app, for example. Most people like to try out various cashback apps to get the best deals, while businesses offer cashback as a way to drive more sales and increase brand loyalty.
Another example is an app that promotes a service or facility for increasing Instagram followers quickly. The unsuspecting Instagram user would be unaware that the primary goal of this app is actually to credential harvest people just like them.
Bad actors leverage various distribution channels to make sure that their malware reaches its intended target. Examples include (but are not limited to):
- Uploading the app to public application stores such as the Google Play Store or Apple App Store
- Crafting a seemingly benign phishing message, notification, or alert that contains a link to download the fraudulent app. This is sent to target victims via widely-used communication channels such as SMS, email, and messaging apps
- Displaying a false advertisement (malvertising) via websites and social media apps
##### **Malicious, pre-installed apps**
Nowadays, it’s difficult to find and buy a device without at least some pre-installed applications - especially on Android devices. Because of its open nature, device manufacturers are free to perform any customizations on Android at will. And one of these is to pre-install some applications that users can disable but cannot remove.
Some device manufacturers even grant these pre-installed applications elevated privileges and special permissions. While this freedom gives manufacturers the ability to ship useful apps to provide a better experience for their users, it might also become a delicate attack vector for bad actors to deliver malware to your device. This is often the case with many [low-cost Android devices, as reported by Malwarebytes](https://www.malwarebytes.com/blog/news/2020/01/united-states-government-funded-phones-come-pre-installed-with-unremovable-malware).
There are several possible situations that might be influencing this trend. But first up is the fact that low-cost Android device manufacturers are under continuous pressure to drive significant revenue. Malware developers are aware of this and are set up to exploit it. For example, they might masquerade themselves as an advertising agency and create an app that displays ads to the device users. Then they could work with a device manufacturer in some ad revenue sharing model provided that their app is pre-installed in every manufactured device. So, the device manufacturer agrees to their terms and ships their app as part of the system firmware. That is, without knowing that it has been embedded with various malicious payloads ready to launch with a single command from a remote C&C (command & control) server.
Another possibility is that low-cost Android device manufacturers are also pressured to reduce expenses as much as possible. So, they outsource some (or all) of their device manufacturing processes to contractors. Malware developers could exploit this opportunity by pretending to be a device foundry that provides white-label Android devices, before offering it to those manufacturers. With a tight budget and limited resources to produce a quality device, this could prove a tough offer to pass up on. Once a partnership is formed, this bogus foundry can freely ship whatever it wants into the device. This includes pre-installing malware into the OS that users would then be unable to remove.
##### **Malicious software development kit (SDK) and libraries**
Another way your device can become infected with malware is through a supply chain attack carried out on apps that you use. A good example of this kind of attack was highlighted in [Snyk’s findings on the Mintegral SDK](https://snyk.io/blog/sourmint-malicious-code-ad-fraud-and-data-leak-in-ios/).
The fact that app developers use libraries and dependencies compromised by malware is perhaps not that surprising given the pressure they’re often under to deliver. They’re so focused on getting the job done efficiently that something of an overreliance on third-party dependencies and libraries is now pretty commonplace in the industry.
But clearly integrating a third-party library is a double-edged sword. While it can dramatically speed up the development process, it can also expose - or even attack - your app from the inside. For example, malware developers could intercept all device network communications and collect device data stealthily. Or they could download and then load malicious code from a remote C&C server (known as dropper malware).
##### **Outdated, deprecated, or vulnerable OS**
Google and Apple continuously implement security improvements for Android and iOS respectively. This includes introducing new security features as well as patches and fixes for known vulnerabilities. However, having device manufacturers incorporate or ship these improvements into their OS update package will ultimately not always be enough. That’s because at the end of the day it’s the device owners themselves who decide whether or not they want to update their OS.
Lots of device owners are ignorant about the need to update their OS for security and privacy reasons. And, once more, this opens some gaps that can be exploited by malware developers.
One of the most recent mobile malware attacks that exploited outdated or deprecated OS is [BlueFrag](https://insinuator.net/2020/04/cve-2020-0022-an-android-8-0-9-0-bluetooth-zero-click-rce-bluefrag/). By exploiting a bluetooth implementation vulnerability in Android 8 and 9, bad actors could remotely distribute malware and execute arbitrary code through a Bluetooth daemon privilege without the need for any end user interaction.
While mobile malware that exploits OS vulnerabilities is not quite as common these days, the damage it can cause makes it a scary proposition.
##### Tips for malware attack prevention
It used to be thought that mobile malware developers and authors primarily target device owners. While they are still a significant target, the story isn’t so simple anymore. The rise of devices shipped with pre-installed malware and supply chain attacks injecting malware into popular libraries shows that bad actors are taking aim at manufacturers and app developers, too.
These types of malware attacks are particularly anxiety inducing because often you’d be completely unaware an attack had even taken place until it’s too late. So, malware attack prevention is now a shared responsibility between device owners, manufacturers, and app developers.
We’ve shared some specific advice below for end users of applications. But if you’re reading this article as a business that has lots of people using your app(s), remember that you also have a responsibility to educate. As we wrote in a separate article recently, having empathy for your end users and speaking clearly to them about the threats that exist is something of a [secret ingredient for improved security](https://licelus.com/insights/the-secret-ingredient-of-end-user-security).
### 1. Application developers and vendors
##### **Implement a software composition analysis (SCA) practice**
The entry point of a supply chain attack is usually the application or software. And app developers should be the first line of defense to prevent this kind of threat from happening.
One of the best ways to mitigate this risk is to incorporate a software composition analysis practice into the development process and to leverage dependency scanners. OWASP has built a tool called [DependencyCheck](https://github.com/jeremylong/DependencyCheck) which can be used by development and security teams to scan for vulnerable dependencies. It’s vital to incorporate dependency checking throughout the entire development cycle to ensure that this kind of risk can be detected and mitigated as soon as possible. In other words, before it reaches your end users.
We recently launched a new feature into our own [DexProtector](https://licelus.com/products/dexprotector) to extract and scan mobile applications for known vulnerabilities and malicious dependencies. We’re thrilled that many of our clients have already benefited from this functionality and see it as being increasingly important in the coming months and years.
In addition, you can also host vetted copies (after a comprehensive analysis) of publicly available libraries or dependencies on your local repository. And you can configure it so your build system pulls only from that repository. This can help prevent malicious or vulnerable dependencies finding their way into your application.
##### **Perform device attestation**
Malware often tries to fool device users or exploit system vulnerabilities to disable critical device security features. Especially those that might get in the way of it achieving its goals. So, Google Play Protect (built-in anti-malware feature by Google/Android) for example, or SELinux enforcement, or bootloader/OEM lock.
It’s important that app developers carry out attestation to make sure the runtime environment is safe for the app to operate in. They can also alert users if there are any potential risks or anomalies (including malware) detected so they can take further action about it.
### 2. Device manufacturers
##### **Incorporate anti-malware features within the OS itself**
Not all end users will heed advice about installing anti-malware solutions on their devices. And third-party anti-malware tools might not have full privilege to protect those users anyway. That’s why incorporating a malware scanning feature within the OS itself - something only you as device manufacturers can do - would significantly help prevent malware from being installed and harming users.
### 3. End users of mobile devices
##### **Only download apps from trusted sources**
Always make sure that you download applications from trusted and secure sources such as recognized application stores such as the Google Play Store. That is, unless the app developer or owner officially directs you to a secure channel.
##### **Keep your OS up-to-date**
Keeping your OS up to date ensures you’ll benefit from the latest security improvements and features that help prevent malware from operating. For example, Google recently hardened its restriction to use Accessibility Service permissions on Android 13 for sideloaded apps. This move makes it much more difficult for malware authors. What’s more, device manufacturers often roll out their own security patches and fixes which you should also take advantage of.
##### **Use trusted anti-malware solutions**
Sometimes, however hard you try, it can be difficult to completely avoid the risk of malware from being installed on your device. Especially those that take the form of seemingly benign apps.
But you can rely on trusted anti-malware tools to scan for the presence of malware on your device and work on your behalf to remove it. They can also advise you on how to remove a particular malware in the event that they’re not able to do so on their own. This could be due to not being able to remove pre-installed apps due to limited privileges.
### Together we can stop mobile malware extending its reach
The mobile malware landscape is rapidly and continuously evolving. Bad actors work around the clock to deliver new and more sophisticated varieties. But together - those of us who work in security, alongside device manufacturers, developers and vendors, and end users of apps - can make malware a much less scary proposition.
Here at Licel we see step one of this journey as increasing awareness levels about mobile malware infection vectors and sharing tips for closing the gaps when it comes to malware attack prevention.
We hope that this article has gone some way to achieving these goals for you. But we’re not done just yet. We’ll follow up this piece with another one where we’ll take more of a technical look at how mobile malware exploits OS & application vulnerabilities. So watch this space.
29 Nov 2022
### Mobile app development frameworks - a security guide
URL: https://licelus.com/insights/mobile-app-development-frameworks-a-security-guide
# Mobile app development frameworks - a security guide
Thousands of new businesses are born every day. And more of them than ever before are offering a mobile application as their primary product.
When it comes to developing the app itself, a range of technologies can be used. From native Android and iOS development - using Kotlin and Swift respectively - through to cross-platform React-Native, Flutter and Web-based hybrid apps.
Here at Licel we look at everything through a cybersecurity lens, and it turns out that each mobile app development framework has its own pros and cons from a security standpoint.
So, in this article we’ll shed some light on these considerations and we’ll provide you with a comparison to help guide you when it comes to developing your own mobile application.
### A quick note about creating a threat model
Forward-thinking development houses and vendors acknowledge the importance of apps to overall business success. And so they also recognize that it’s vital to analyze the threats their app might be up against after publication. That way they can apply a necessary set of security solutions to keep it safe.
This process of surveying potential risks is called creating a threat model and is a must regardless of the mobile app development framework you end up choosing.
Let's imagine for a moment what a threat model could look like for a modern neobanking app. This is a deliberate choice given that banking apps hold an end user’s money and so are particularly attractive targets for bad actors.
First things first, the app should be protected from unauthorized use. Indeed, that’s why most mobile banking apps use biometric authentication and a pincode in order for the legitimate owner of the account to gain access.
Another threat comes in the shape of traffic sniffing and talking to a malicious server instead of the original one. This threat exists if apps do not leverage application level encryption, certificate verification and SSL Pinning.
The banking application might also be subject to reverse engineering attempts. This in turn could lead to repackaging with altered logic, traffic dumping, and other even more frightening changes.
The dependencies which make up a significant part of every modern app can be tampered with, too. This is known as a supply chain attack.
And our neobank app can also be run on a device [infected with malware](https://licelus.com/insights/how-bad-actors-deliver-mobile-malware-into-your-device). This malware can try to steal banking data, intercept text messages with OTP passwords, or show phishing screens.
You might be reading this and thinking “wait a second, the threats covered here aren’t necessarily specific to a mobile banking application.” Well, you’re completely right to think that way. After all, insecure networks pose a threat to any application which exchanges sensitive data over the network.
It just happens to be the case that [mobile banking apps are a particular target right now](https://licelus.com/proven-protection-for-financial-apps).
We highlighted the major threats facing mobile apps in our [State Of Mobile App Security Report](https://licelus.com/state-of-mobile-app-security) a few months ago. But in this article about threats for specific mobile development frameworks, we’re going to focus on just four of them:
Reverse engineering, tampering, man-in-the-middle attacks, and software supply chain attacks.
### Mobile app development frameworks
So, which frameworks will we cover?
We’ll explore native applications - whether that’s Kotlin for Android or Swift for iOS - where you largely rely on the libraries and frameworks shipped by Google and Apple respectively.
We’ll also look at building an application for two platforms and maximizing code reuse: so, React-Native, Xamarin and Flutter. Flutter is offered by Google, too, whereas React-Native is a Meta solution, and Xamarin is owned by Microsoft. The development of these apps happens with programming languages which are being run through a respected virtual machine or compiled to native code.
And then there’s always the option of creating an application using HTML/CSS and javascript and running the code in a WebView inside the app. Those apps are called hybrid apps, and we’ll cover them here as well.
If you’re ready, let’s jump right in.
### Native Applications
Every app in the App Store and Google Play is a native application at its core. Native applications are built with languages and tools officially supported by the OS vendor. And that’s a positive right off the bat because it means that Google and Apple pay close attention to the security aspects of the application and ship security controls and tools to review it. For example, Android Studio comes with a set of inspections of both general code quality rules alongside security checks.
That said, this doesn’t mean these platforms will solve every security concern for you. They do their part of the job, ensuring the OS has a minimum attack surface and providing you with timely updates. But there are other security issues that are the responsibility of the developer - that means you.
Here’s what you need to know:
Kotlin and Swift are compiled into binaries, but that doesn’t mean they can’t be reverse-engineered. Such an attack can expose the internal logic of the application and give up the keys and tokens accidentally left in the app. Decompiled files can be also modified; for example, Android’s smali file has a text format. The attacker can alter the logic of the application, unlocking features, adding remote logs, and compromising security in general. After such modification the app can be redistributed via social engineering and third-party app stores. App protection tools - beyond what Apple and Google provide - are needed to counter these risks.
Native development can also be prone to [supply chain attacks](https://security.googleblog.com/2021/06/introducing-slsa-end-to-end-framework.html). If somebody snicks in a patched version of a famous library in maven central or an alternative jar repository, the application will find itself at risk. Make sure to verify the checksums of the packages you use, scan those packages for known vulnerabilities, and consider limiting the number of dependencies you use in the development process.
When it comes to man-in-the-middle attacks, both Android and iOS have lists of trusted certificates. All the network connections to the https URLs will be checked against those and will be denied if the remote server certificate is not trusted. But it’s not enough to rely on this system alone. Attackers can trick the user into installing certificates on the device, and then the application might be subject to MitM attack. Please be sure to implement SSL Pinning to block this particular attack vector.
### React-Native
React-Native uses JavaScript (and TypeScript) as programming languages. All the source files get [transpiled](https://subscription.packtpub.com/book/web-development/9781789800104/1/ch01lvl1sec12/transpilation) (source code is transformed into another more compact form without types and using only vanilla js). The source code itself exists in the form of a single-file bundle which is interpreted when the app is running on the device. Yes, the source code is available in the application itself. What’s more, React-Native supports over-the-air bundle updates. That means the number one risk for a React-Native application is bundle modification and exposure to reverse engineering.
What about the risk of supply chain attacks? Well, the React-Native framework itself is shipped and maintained by Meta. React-Native is used for some Meta apps, but those are different versions really. You see there’s an internal one and a public one, and the latter gets updates from the former. At the end of the day it’s a question of how comfortable you are with another company - however well respected it is - being part of your application supply chain.
React-Native apps also use NPM packages as their dependencies. The problem with them is that compared to maven central, the publication of NPM packages is much easier. But even if they are genuine, there are no guarantees that the crucial packages are implemented correctly or provide reasonable config or default parameters.
Let’s go back to our neobanking app example again. Say we store our auth token in an Android Keystore via react-native-keychain, default configuration allows “null initialization vector” attack which could potentially result in a stolen banking account.
React-Native consists of the JS part, the React-Native bridge, and the native part for both Android and iOS. This architecture undoubtedly expands the attack surface. For example, if a vulnerability were found in the bridge itself or in the JS VM, then all the applications which use React-Native would be affected. Consider remote code injection: your app’s logic and data could be in danger. In the case of our neobanking application, your customer’s hard-earned money might end up on an account different from the target one.
The aforementioned JS part, known as JS Bundle, is the source code of the React-Native application, which is combined into a single file, compressed and slightly obfuscated. Still, the source code is in plain text which means one can read it as regular code with little effort as there will be a lot of anchors in the code like React Hooks, Components, Reducers and other parts. The logic of the application will be obvious to the reverse engineer.
Although React-Native uses JavaScript APIs for network connectivity, they still call platform APIs under the hood: in this sense React-Native is still a native application. That means the risks of a man-in-the-middle attack are the same as they are for a native app. And the countermeasures are the same as well.
### Flutter
React-Native is a cross-platform framework to make apps for iOS and Android (among others). Flutter does the same thing but in a different way. It uses the Dart programming language and its own VM. But Dart VM is only used in debug mode; for production applications, Dart is compiled into native libraries for the required CPU architectures. This approach significantly reduces the risk of reverse engineering by increasing the skill level required to perform it. But the risk is not eliminated entirely: [reverse engineering tools](https://github.com/Impact-I/reFlutter) do exist for Flutter. And these could allow an attacker to get a project structure and dart class names and infer the app logic quite conveniently. Some also allow [traffic interception](https://github.com/rscloura/Doldrums) for apps.
With a native Android app you could easily recompile the artefacts of reverse engineering into a new application; fortunately this is not the case with Flutter. As of now, we’re not aware of any tooling which can conveniently build up the application from decompiled Dart code. The update of the Dart part of the application is intentionally not supported either.
As with React-Native, Dart code which is responsible for the network connectivity still uses platform APIs. And so the framework doesn’t bring any additional protection against man-in-the-middle attacks by itself. Use HTTPS, apply encryption to the traffic at transit and verify the server origin by using SSL Pinning.
Another thing worth noting about Flutter is that the framework is relatively young. That means there aren’t many security-related materials, infrastructure and products. If you take a look at the [official security page](https://docs.flutter.dev/security) for Flutter, you won’t find much beyond short, general recommendations. We’re also not aware of any quality security scanners for the framework. But this can also be viewed from another, more positive perspective. Namely that the novelty of a technology allied with such a speedy pace of change these days makes for a challenging environment for reverse engineers. As the binary format of an executable changes fast, the tools to reverse them should change fast too, which can be expensive to keep up with.
Flutter pulls its dependencies from the [pub.dev](https://pub.dev/) resource: it’s a repository of Dart and Flutter packages. That means the supply chain concerns we mentioned for native and React-Native applications apply for Flutter as well. In order to publish to pub.dev you only need a Google account, which means that virtually anybody could upload a malicious package. Be aware of the packages you use, verify their origin, and make sure they don’t come with any known vulnerabilities.
### Xamarin
Xamarin is an open-source technology from Microsoft with applications developed using C# and .NET Framework. The code is compiled into a DLL and then shipped as a part of native application. At runtime the app bootstraps the Mono VM which in turn loads and executes said DLL.
The techniques to reverse engineer such an apk [are known](https://infosecwriteups.com/lets-know-how-i-have-explored-the-buried-secrets-in-xamarin-application-d6b8c5609c87?gi=ab4bf74cf430): it’s enough to decompile the APK or IPA file, find the DLL file within the assemblies folder, and then make an extraction and decompile as a regular .NET DLL. You’d need an additional extraction because a DLL is compressed for size optimization, but it can be done with a one-line script. And once you’ve obtained a DLL, the whole application is available for your inspection.
So, in other words the application logic is revealed as well as any hardcoded secrets and auth tokens. Surprisingly enough, some developers put the azure tokens straight into the application code because it’s convenient to use the same technology ecosystem for mobile, server side and infrastructure. But clearly this comes at the cost of basic security measures.
It’s also easy to replace the DLL file inside the app and repackage the whole application. This leaves it vulnerable to tampering which can eventually be used to trick your user into using the wrong version.
Xamarin proxies the network connectivity calls to the OS through System APIs. The framework doesn’t introduce any measures to control the internet connection out of the box, thus not adding protection against MitM attacks. So, as always, make sure to use SSL Pinning, and verify the origin and the date of the certificate of the remote server your app works with.
As with every other technology out there, nothing in the mobile application tends to be built completely from scratch. And Xamarin is no exception. Being part of .NET ecosystem, Xamarin uses [NuGet](https://www.nuget.org/) package manager to leverage dependencies. It’s relatively easy to submit a package there, and so we can’t call them secure. To avoid becoming a victim of a supply chain attack, check the packages, scan them for vulnerabilities, and be aware of any changes.
### Web-based Hybrid Apps
Hybrid apps are native applications with a single screen which holds the WebView component. The whole app is basically a web app loaded into a WebView engine that is developed using HTML, CSS and JavaScript. Using WebView in mobile applications brings a whole new set of technology risks.
The first of these is that WebView doesn’t limit the URLs you can navigate to. That means that failing to filter user input or just an error in the code can result in your user being taken not to a part of your application but somewhere else entirely. That’s why it’s a good idea to explicitly include an allow list.
Hybrid apps still need to communicate with the underlying operating system. There are different frameworks to do that like Cordova, which provides this via a native bridge. The problem is that you need to restrict the code that can access it. For example, iFrames shares this access to any code loaded there. That’s why it’s generally recommended not to use it.
Other problems are similar to those we’ve covered for the previous technologies. As with React-Native, Hybrid Apps’ bundle format brings the application logic in the form of JavaScript code, which is really easy to read, understand, and modify. This results in a high level of risk from reverse engineering and repackaging point of view. Especially if the application doesn't apply any obfuscation.
Hybrid apps are also subject to the same problems as React-Native apps when it comes to supply chain attacks as dependencies use the same NPM ecosystem.
And then there’s network interception. The fact that the app uses WebView does not help with certificate validation here. It means that the process should be done manually. However, with Cordova the process itself [is not that easy](https://cordova.apache.org/docs/en/11.x/guide/appdev/security/), so please consider that aspect carefully.
### Comparing mobile app development frameworks
As we said at the outset of this piece, a vital part of setting out to develop a mobile app is understanding the type of attacks it will have to defend against. We’ve covered some of them in this article, but the comparison table below gives you a colour-coded relative probability of each threat by framework.
For example, the probability of tampering for a React-Native application is high because the JS-bundle, while obfuscated, is still in plain text format and so doesn’t require a deep level of expertise. If you compare it to the risk of tampering with a native application, you’ll find the latter much harder, and thus the risk is shown as low.
But remember, low doesn’t mean impossible.
A mobile application - especially one dealing with sensitive data or money - should be properly and robustly protected against the security threats we’ve covered in this article.
Whichever framework you pick for your app, you’ll definitely face the threats of reverse engineering, your app being redistributed, shipping vulnerabilities within the app, or being a victim of supply chain attacks.
Mobile platforms do a good job of thinking about the security of the platform, shipping hardware and software solutions like encryption tools, secret stores, certificate checks, and so on. Whatever technology you use, you need to know what these tools are and how to use them properly.
But you also need to know the tools offered by external app security providers that you can use (for each particular framework) to block the threats covered above. These include mechanisms to detect dynamic instrumentation tools like Frida as well as RASP checks of your app’s immediate environment. Not to mention tools to security check your dependencies, code hardening (robust encryption and obfuscation), and [integrity control](https://licelus.com/insights/how-to-keep-integrity-control-when-publishing-apps-on-third-party-platforms) solutions that can detect whether a bad actor has tampered with your application since you published it.
Modern mobile app security relies on all of these interconnected layers working together to frustrate attackers. And that goes for any of the mobile app development frameworks we’ve covered in this article.
So, if you’re deciding which technology to go with for your build, we hope this piece will prove helpful when it comes to making a choice.
25 Feb 2023
### Ongoing Security: a step-by-step guide to a secure app development process
URL: https://licelus.com/insights/ongoing-security-a-step-by-step-guide-to-a-secure-app-development-process
# Ongoing Security: a step-by-step guide to a secure app development process
Mobile devices have become an integral part of our daily lives. We communicate with one another, entertain ourselves, bank, and shop with a few swipes and strokes of our fingertips. That’s why securing these devices and the apps we use is so important.
But this importance doesn’t always correlate to common secure practices during development.
Neglecting security in the development of mobile apps can have serious consequences. Hackers can exploit vulnerabilities in the app to access sensitive user data like login credentials and financial information. This can lead to identity theft, financial loss to the end user, and damage to the company's reputation. Insecure mobile apps can also be used to spread malware, which can compromise the security of other devices and networks.
It’s essential, then, that security be a top priority in the mobile development process. This is a commitment that requires a holistic approach involving all key stakeholders and incorporating various security measures at every stage of the development pipeline. The understanding of security as a never ending process is crucial in making digital products secure.
This leads us to the idea of building security in the product rather than adding it as a separate step. Only by building the solution securely - by design - can we get close enough to a truly secure product.
In this article, we’ll introduce the concept of ongoing security by introducing the security measures applied at each step of the product life cycle. We’ll demonstrate some [security-by-design](https://licelus.com/security-by-design) principles to follow, too.
### Why you need to think about security holistically
Lots of companies are tempted to bolt security on at the end of the development cycle. But this is a tactic that has proved itself time and again not to work.
You see, security vulnerabilities can be introduced at any stage in the development process. That means if you only think about security at the end, it might already be too late to fix issues that have crept in.
It’s vital to consider security throughout the entire mobile development process to ensure the development of secure and reliable apps. Or, in other words, to enjoy the benefits of a Secure App Development Lifecycle.
Security measures can dramatically impact the design and functionality of an app. For example, implementing encryption or authentication controls could require changes to the app's architecture and user experience. If these measures aren’t considered until the end of the development process, it may be difficult (or even impossible) to integrate them without a significant amount of rework.
Testing for security vulnerabilities is most effective when it’s performed early and often. If security testing is only done at the end of the process, it can be difficult to identify and fix all the vulnerabilities before the app is released. It can also actually lead to delays in the release of the app and increase the overall cost of development.
This is a theme we’ll return to again in this article - namely that waiting to think about security at the end doesn’t actually save you time at all. Investing some time to think about security from the outset will save you a lot more time in the long run.
This is one of the main reasons forward-thinking companies now accept that “shifting left” (incorporating security thinking throughout development) is a necessity.
### Security should begin before you start coding
Developers usually think that security work should begin once the first bunch of features are ready - when they need to think about authentication and protecting parts of the application. But again, this isn’t the right approach. You need to think about security before development even starts. At what we typically call the threat modeling stage.
Threat modeling is the process of identifying, analyzing, and prioritizing the potential threats and vulnerabilities that your app may face. It’s an important step in the mobile app development process because it helps to ensure that your app is designed and built with security in mind.
There are several approaches to threat modeling, but one common method is to start by identifying the assets that need to be protected (sensitive user data, system resources, and so on.) Then you identify the threats and vulnerabilities that could compromise these assets before evaluating the likelihood and potential impact of each threat. At which point you can figure out the appropriate countermeasures.
Threat modeling - like security in general - should be an ongoing process performed throughout the development cycle - not only before implementation. It’s one more way of empowering the development team to identify and address potential security issues early on, rather than trying to fix them later in the process.
Some examples of threats and vulnerabilities that may be identified through threat modeling include:
- Injection attacks, such as SQL injection and cross-site scripting (XSS)
- Unauthorized access to sensitive data
- Lack of encryption for sensitive data transmitted over the network
- Lack of proper authentication and authorization controls
- Insecure communication channels
It’s crucial to include all stakeholders in the threat modeling process. So, not only developers, but security experts, and business analysts, too. This helps to ensure that all aspects of the solution are considered and that the appropriate countermeasures are implemented.
[Designing for a zero trust world](https://licelus.com/security-by-design/zero-trust-world) is also a vital part of the threat modeling process. After all, during development you use lots of external tools, cloud services and other resources owned by third parties. Even the runtime environment - devices and mobile operational systems - are not controlled by you at any given point in time. So, we need to mitigate these potential risks. Take a read of [this article](https://licelus.com/insights/the-risks-of-letting-your-app-run-on-rooted-devices) we wrote about protecting your app in case of it being run on a rooted or a jailbroken device.
### Coding safely
You might say that the only code which is free of security problems is the code that hasn’t been written yet. That’s why we need to follow best practices when writing code in the first place, and then follow it up with security testing.
To minimize the probability of introducing an accidental vulnerability, developers should follow security code guidelines. These exist for every major platform and programming language out there, including [a guideline for Java](https://www.oracle.com/java/technologies/javase/seccodeguide.html), [the security guideline for Android](https://developer.android.com/topic/security/best-practices), and [a guide for iOS](https://developer.apple.com/documentation/security).
Before you commit your code to a repository or even run it locally, you can and should test it. Static testing means evaluating the quality and functionality of a solution without executing it. Mobile Development cannot be secure without it, as many problems are identified and fixed at this very early stage.
Static testing is represented by various techniques. The first one worth mentioning here is code review. This involves manually reviewing the source code of your application to identify issues such as bugs and security vulnerabilities.
You can also leverage something called linting. This is a tool that checks the code to make sure that it adheres to coding standards and best practices.
Lastly you can run a static code analysis tool. This examines the code for issues such as vulnerabilities, performance problems, and code complexity.
Static testing should be performed regularly throughout the development process to ensure the quality and reliability of your app. Static security testing should be run both on the developer’s machine during the development itself and on the CI/CD pipeline during builds. That way problems can be identified as you go and solutions to those problems found. The idea here is that you monitor the health of your app as it evolves.
For example, consider the following code snippet in an Android app:
```text
String input = request.getParameter(\"input\");
String query = \"SELECT * FROM users WHERE username = '\" + input + \"'\";
ResultSet results = statement.executeQuery(query);
```
This code is vulnerable to SQL injection attacks because the user input is not properly sanitized. An attacker could exploit this vulnerability by entering special characters or scripts into the \"input\" parameter, which could then be executed by the database.
Static analysis tools can detect this vulnerability and alert the development team. The issue can then be fixed by properly sanitizing the user input, as shown below:
```text
String input = request.getParameter(\"input\");
input = input.replaceAll(\"[^a-zA-Z0-9]\", \"\");
String query = \"SELECT * FROM users WHERE username = '\" + input + \"'\";
ResultSet results = statement.executeQuery(query);
```
This is a bit of an artificial example which you’d probably only encounter in real-life in a public kiosk-type application. But it provides a good example of what static analysis can do.
The example below is of an iOS app snippet:
```text
let token = \"aabb11ff11ee\";
let url = URL(string: kGraphURI + \"/v1.0/me/?token=\" + authToken)
var request = URLRequest(url: url!)
```
Here, the security testing tool can detect hard coded credentials and raise an error for the development team to investigate.
By performing a static analysis and fixing vulnerabilities early on, the development team can ensure the security of the app and protect against potential attacks.
### The build process
Developers work mostly with source code. But the fruits of their labor end up running on the device itself. This magical transformation that most people take for granted happens by compiling the code and bundling the end result - assets and other resources - into a working app. CI/CD pipelines are responsible for this process. And as with every other part of the development process, vulnerabilities can emerge here.
After all, a significant part of your application probably contains dependencies: frameworks and libraries which are responsible for common tasks like networking, dependency injection, image downloading, and so on. The CI/CD pipeline downloads these from public servers where bad actors might have injected modified versions of these dependencies that can compromise the app.
That’s why you have to regularly update the software and libraries used in the app or device to ensure that any known vulnerabilities are fixed. Failing to do so will subject the app to supply chain attacks further down the line, compromising not only your application but your end user’s device as well.
Another aspect of building a target application is a signing mechanism - a way to make sure that it’s actually you uploading that new version of your app to the AppStore. CI/CD pipelines must have access to the provisioning profiles, certificates and the keystore in order to sign the app. Those secrets should be stored and accessed securely, otherwise your app could be subject to cloning attempts.
To mitigate these risks CI/CD pipelines should incorporate strong authentication, RBAC models, and user control lists to limit the amount of people able to alter the pipeline. They should store secrets in industry-standard products and limit the read access only to the pipeline itself.
### When you have an app in place
Once you have several features combined, it’s time to think how they can influence each other from a security perspective. Penetration testing can help with that.
Mobile penetration testing is the process of evaluating the security of a mobile app or device by attempting to exploit vulnerabilities.
There are several types of mobile penetration testing, including:
- Black box testing. This involves testing the app or device without any prior knowledge of its internal workings. The tester is only given the external interface of the app or device and must try to identify vulnerabilities through testing.
- White box testing. This involves testing the app or device with complete knowledge of its internal workings. The tester is given access to the source code and other internal details of the app or device and can use this information to identify vulnerabilities.
- Gray box testing. This involves testing the app or device with partial knowledge of its internal workings. The tester is given some, but not all, of the internal details of the app or device and must use this information to identify vulnerabilities.
Let’s think about an example. Consider a mobile banking app that is being tested for vulnerabilities. During testing, the team may discover that the app is vulnerable to brute force: attackers trying to find a password matching a particular user’s account. This is an issue that could have been missed through other types of testing. Static analysis for example would never uncover such a problem. But by actively trying to exploit the app, this kind of issue can be found and a proper remedy provided. In this particular case the server side should limit the login attempts and leverage multi factor authentication. Again, design decisions like this cannot be introduced last minute.
Now let’s consider white box testing as an example of incorporating penetration testing into a development lifecycle. White box testing is particularly useful for identifying vulnerabilities that may be difficult to detect through other means, such as vulnerabilities in the underlying architecture or design of the app or device.
To perform white box testing, the tester will typically review the source code and other internal details of the app or device to identify potential vulnerabilities. They may also use tools such as static code analysis tools or debuggers to examine the code in more detail.
Once potential vulnerabilities have been identified - like insufficient encryption, brute force and others - the tester will attempt to exploit them to determine if they are serious. If a vulnerability is confirmed, the tester will work with the development team to determine the appropriate course of action, such as fixing the vulnerability or implementing a workaround. This again highlights that security is everyone’s responsibility, and not only the job of security folk.
### When your app is running on a device
Once you have your release build in the hands of your users, the real fun begins!
Remember, the way your app will be used in the wild is quite different to the controlled conditions before release. Imagine your application is a car - a lot of our ongoing security advice up to this point has related to safety measures you’d implement before the vehicle leaves the factory floor. But once it’s out on the road, there are all sorts of additional security concerns. Not least the way other cars - and drivers - behave.
The device running your app may be rooted or jailbroken. And your end user might have malicious intentions with your application - they could try to reverse engineer it.
The device running your app could even be infected with the malware.
This is a complex set of risks that only a holistic strategy can mitigate. One of the key points of tackling such problems is ensuring you place a high importance on application integrity. You can achieve and maintain integrity via cryptographic integrity algorithms, checking application signatures, leveraging SSL pinning to double check the server connection safety, applying the security tools provided by the platform, and many more.
But even before the application reaches the end user you need to make sure your application hasn’t been tampered with. Integrity checks at runtime can help with this, but so too can prioritizing ongoing security across the whole development lifecycle and making your app more difficult to tamper with in the first place.
There are several other measures that you can take to ensure the ongoing security of a mobile app or device, including:
- Monitoring for security threats. Check your app or the device running it for security threats and take appropriate action if a threat is detected. This may involve implementing additional security measures or working with security experts to resolve the issue. One example is a mobile banking app integrating an anti-malware engine to make sure it’s safe to run on every device.
- Conducting regular security testing. Static analysis, dynamic testing, and penetration testing can help you identify and fix vulnerabilities before they can be exploited.
- Educating end users and stakeholders. It’s vital you teach your end users and other stakeholders about security best practices and tips to protect their sensitive data. This may involve providing resources and training materials or implementing security awareness programs. Make sure that you communicate clearly and transparently with your end users so they know how to differentiate genuine comms and bogus phishing messages. And preach the importance of being suspicious in general.
- Using tested primitives. A big part of encryption problems come from incorrect usage of libraries such as failing to provide good random seeds or mixing up the parameters. Don’t [reinvent the wheel](https://licelus.com/security-by-design/dont-reinvent-the-wheel) and rely on good quality tools that exist to minimize errors (like [BoringCrypto](https://boringssl.googlesource.com/boringssl/+/master/crypto/fipsmodule/FIPS.md).)
By taking these ongoing security measures, the development team can ensure the security of your app over time and protect against potential threats.
### Ongoing security is about layers
At this point it’s important to say that you can’t limit your security to one single measure. All of the mechanisms we’ve mentioned in this article play their part.
The goal here is to add one measure on top of the other until you get what we call multiple layers of security. This is also often referred to as [\"defense in depth\"](https://licelus.com/security-by-design/depth-of-security) and is a key principle of cybersecurity.
Some examples of how different layers of security can help to keep a mobile app or device safe include:
- Network security. Network security controls, such as firewalls and intrusion detection systems can help to protect the app or device from network-based attacks.
- Device security. Device-level security controls such as encryption and biometric authentication can help to protect the app or device from unauthorized access.
- App security. App-level security controls like secure coding practices and input validation. These can help to protect your app from vulnerabilities.
- Data security. Controls like encryption and secure data storage. They protect sensitive data stored on the app or device from being accessed by unauthorized parties.
### What if an incident does occur?
Some security vendors market their products as if they’re offering 100% security. But in reality this is a bogus concept. There’s no such thing as 100% security because human nature doesn’t allow it. Mistakes can always happen. People can be tricked by sophisticated social engineering campaigns, for example.
In the event that a security incident does occur, it’s important for you and your development team to have a plan in place for responding to and resolving the issue. This may involve the following steps:
- Assess the severity of the incident. This is vital when determining the appropriate level of response. For example, a minor security breach will require a different level of response than a major data breach.
- Contain the incident: Prevent the incident from spreading or worsening. This may involve disconnecting affected systems from the network, shutting down certain services, or taking other appropriate measures.
- Investigate the incident: Conduct a thorough investigation of the incident to determine the root cause and identify any potential vulnerabilities that may have contributed to the incident.
- Communicate with relevant stakeholders: Transparency is key. Let your end users, customers, and regulatory authorities know about the incident and any actions that are being taken to resolve it.
- Implement corrective measures: Based on the results of the investigation, you should put corrective measures in place to fix any vulnerabilities and prevent similar incidents from occurring in the future.
By following these steps you can minimize the impact on the app itself and on your business reputation. A well-defined incident response plan can ensure that your team is prepared to handle any security incidents that may arise.
### Repeating the release cycle
Once one version of your app reaches your end user, the work on the next version is typically already in motion. So, you need to carry out threat modeling again, then run security testing, provide application integrity, protect your CI/CD pipeline process, and secure data at rest and in transit.
This is ongoing security.
We hope you’ve learned from this article that the security of your application is not a one-time step. It’s an ongoing, holistic process which involves subject matter experts, developers, quality assurance engineers, product managers, SREs, security experts and others.
At each step of your application development process, be it gathering requirements, writing code, or shipping to production, you need to pay close attention to be thinking about security. Which measures or techniques can you apply?
Truly secure applications can only be developed via an ongoing security process.
17 May 2023
### Why you should see mobile app security as a unique selling point
URL: https://licelus.com/insights/why-you-should-see-mobile-app-security-as-a-unique-selling-point
# Why you should see mobile app security as a unique selling point
You’re no doubt already aware of the need to protect your mobile application to secure your IP and your end user’s sensitive data (banking information, identification, health data, and login credentials).
But did you know that mobile app security can act as a unique selling point?
Equip your app with robust protection mechanisms and you gain trust and credibility. You also meet compliance and regulatory requirements, and you reduce risk (and costs) in the long term.
Above all, mobile app security can set you apart from the competition. You see, not all of your competitors see it as a USP. But those that continue to be blind to its benefits will almost certainly be left behind in the coming years.
### Asian super apps and QR code payments
Our focus in this article is on the Asian market because something very interesting is happening there. Asian super apps that offer a range of services, from banking to food delivery, are booming.
People are so reliant on these super apps that when a fire at a data center of the Korean version, Kakao, caused an outage, [everyday life for millions stuttered](https://www.nytimes.com/2022/10/19/world/asia/korea-kakao-ceo.html?hss_channel=lcp-5012731). That’s because Kakao is used for pretty much everything.
It’s just one of a growing list of super apps that includes Naver in Korea, WeChat and Alipay in China, LINE in Japan, GoJek in Indonesia, GCash in the Philippines, and Grab and Careem across South East Asia.
You can pay (typically by scanning QR codes) with these apps, you can chat with friends, book trips overseas, and even manage your healthcare services.
A big reason for the popularity of Asian super apps can be explained in one word: convenience. End users of these apps often have very little need for others.
And for the companies behind them, it’s all about the opportunity to build more loyalty among customers. Some analysts already [fear for the future of banks in Asia](https://bfsi.economictimes.indiatimes.com/news/banking/how-super-apps-are-set-to-revolutionise-banking/90933115) that only offer banking services given that users of super apps can do that and much more besides. That’s why a lot of banks are partnering with super apps - they want to be a part of this flourishing ecosystem.
A big aspect of this super app ecosystem is instant QR code payments. And much like the attraction to super apps in general, the rapid spread and normalization of QR code payments in Asia speaks to a desire for convenience. And of course we’re talking here about societies where there’s a large user base of smartphone users who are open to new ways of paying.
There’s been a lot of government support for QR code payments in China and Southeast Asia in particular. There’s a realization in the region that this is a payment method with barely any barriers to entry. Users don’t need NFC-enabled devices - they just need a camera. And it doesn’t need to be a top quality smartphone, so pretty much anybody on the planet with a smartphone can pay via QR codes. There’s also no need for expensive payment terminals (which also makes it a greener option) or processing fees, so QR code payments are much cheaper than alternative methods.
But it’s worth reminding ourselves that the phone wasn’t designed to be a payment terminal. As with [SoftPOS apps](https://licelus.com/insights/introducing-softpos-the-fast-tracked-financial-trend-ready-to-revolutionize-payments) that allow you to accept payments on your mobile device, QR code applications - or super apps of which QR code payments are just one of its functionalities - need to be equipped with robust protection mechanisms.
After all, while QR code scanning and payments have become commonplace in Asia, that isn’t to say that the practice is always safe, [as we’ve written before on this website](https://licelus.com/insights/are-qr-codes-safe).
Malicious QR codes can be used to spread malware. Bogus QR codes can direct people to a fake site where attackers can carry out phishing attacks. And bad actors can even intercept them, stealing sensitive credentials and payment information.
### What’s at stake?
In recent years, Asia has been targeted with a glut of attacks aimed at mobile applications (and mobile devices in general). [Malware](https://www.mcafee.com/blogs/other-blogs/mcafee-labs/goldoson-privacy-invasive-and-clicker-android-adware-found-in-popular-apps-in-south-korea/) and [phishing](https://www.straitstimes.com/singapore/over-100-android-users-fall-prey-to-phishing-scams-since-march) have been the most common methods.
Hackers clearly see an opportunity in a market where adoption and usage of mobile apps is some way ahead of the general understanding of the risks.
And super apps in particular are an attractive target given the diverse range of riches available to the attacker, from banking details and credentials through to health records and IDs. The modern super app is the equivalent of a Spanish galleon in the early seventeenth century, returning from the Americas overloaded with gold and with insufficient means of protecting itself from pirates.
It’s worth keeping in mind, too, that the nature of Asian super apps - utilizing functionalities, integrations, and components from third parties - is such that [there are inherent vulnerabilities](https://www.manilatimes.net/2023/04/16/business/sunday-business-it/security-a-must-for-super-app-developers/1887266).
It’s the perfect storm. And the bigger the waves get, the better it is for the hacker.
This current reality is exacerbated by the fact that regulations enforcing mobile application protection can be slow to arrive around the world. But really an app developer shouldn’t have to be told about the need to protect their end users’ valuable data. Not when most app users download an application assuming that it’s already equipped with the means to defend itself against sophisticated attacks.
As we know, this isn’t always the case. And so successful attacks can have a devastating impact on individual lives. Savings that have taken years of hard work to amass can disappear overnight. In a moment of digital distraction, your end users can be tricked into downloading a fake version of your super app or payment application - where their credentials can be siphoned off to extract funds from the genuine app.
In this specific example, however, there are things you can do to stop the attack. Firstly, you can harden your application against both [decompilation and modification](https://licelus.com/resources/guide-to-mobile-application-protection/threats/decompilation-and-modification) and against [dynamic analysis and tampering](https://licelus.com/resources/guide-to-mobile-application-protection/threats/dynamic-analysis-and-tampering) attempts. That will make the cloning process much more difficult for an attacker. You can also educate your end users about the dangers of phishing attacks and [what’s at stake for them](https://www.straitstimes.com/singapore/courts-crime/ocbc-bank-customer-lost-120k-in-fake-text-message-scam-another-had-250k-stolen). Preach suspicion as much as you can.
But your end users aren't the only ones who stand to suffer. Businesses like yours that develop applications would also take a huge hit if an attack found its target.
### Seeing mobile app security as a unique selling point
Everything that you stand to gain from seeing mobile app security as a unique selling point is the reverse of what you stand to lose should you neglect security.
Take end user trust, for example. By demonstrating a commitment to doing all that you can to protect your end users’ sensitive data, you’ll gain their long-term trust and loyalty. It’s important to understand that consumers are changing, as is the business-customer relationship. Your end users put a lot of stock in feeling secure and protected in the digital world. Your efforts to make them feel this way will be rewarded in the long run. And competitors who don’t make this commitment will quickly disappear from view as successful attacks cause trust to disintegrate, destroying their business reputation.
It’s a similar story with long-term risks and costs. Security is often misunderstood by app developers as something that adds time and costs to the development plan. But the truth is that much more time and funds tend to be funnelled into firefighting after a successful attack than what is spent coding securely and then engaging and partnering with a reputable app protection company that can help you prevent such attacks from happening in the first place.
This picture is also true of regulations and compliance. In the coming months and years, more and more standards are set to arrive - particularly in the finance industry. Being able to demonstrate that your application complies with them will not only act as reassurance for your end users. It will also mean you don’t have to worry about potential penalties and the reputational hit that would come with a fine.
Finally, there’s the competitive advantage that app security provides you. Imagine that your company and a competitor are both launching super apps to the Singapore market at the same time. Your competitor sees security as a burden to its resources. It wants to deploy on time and sees equipping its app with protection mechanisms as something that would prevent this from happening.
Your company, on the other hand, operates a security by design approach, making sure the app is not only designed and coded securely but is also tested regularly against the most modern types of attacks. You engage and partner with an app security company early on in the process and add layers of security to safeguard your IP and end user data.
Which app do you think your prospective end users would choose to download?
24 May 2023
### What is zero-trust application security?
URL: https://licelus.com/insights/what-is-zero-trust-application-security
# What is zero-trust application security?
**As cyber threats continue to evolve and become more sophisticated, traditional security models that rely on perimeter defenses are no longer effective. In response, a new security model called zero trust has emerged.**
Zero trust refers to a security model that assumes that nobody, whether they’re inside or outside your organization, should be trusted by default. This means that all access requests to systems, applications, and data must be verified, authenticated, and authorized before being granted. The zero-trust model operates on the principle of least privilege. This means that users and devices are only given the minimum access required to perform their tasks.
In today's complex world where the threat landscape shifts like desert sands, designing applications with zero-trust principles can help reduce the risk of cyber-attacks. By designing applications that require authentication and authorization at every step, you can make sure that only the authorized user is accessing sensitive data or application features. What’s more, zero-trust application security is designed to be better equipped to detect and respond to threats promptly. So, it minimizes the damage caused by cyber-attacks.
In this article, we’ll explore some key strategies for embracing zero-trust application security. These include being wary of third parties, the benefits of zero-knowledge cryptography, and how to mitigate insider threats.
So, let’s get started.
### Be wary of third-party services
Imagine that your application is a car.
The moment it leaves the factory, a myriad of security concerns appear from every angle. You have to consider the environment, the roads, pedestrians, cyclists, other cars, and the drivers of those cars. As a manufacturer you need to equip the car with safety measures for all the various threats such as speed controls, autobreaks, lane control systems, and many more besides. A peculiar example of such a check is the temperature and controllability test that modern cars perform - they’re able to tell you that the road may be slippery.
Well, the same principles can be applied to a mobile application. The application is launched into the wild in pretty much the same way.
Third-party services are an integral part of modern application development. But they are also a significant source of risk because they introduce additional attack surfaces and vulnerabilities that can be exploited by attackers. Third-party services often require access to sensitive data, and if these services were compromised then attackers would gain access to this data.
We wrote an article on this site where we considered [the usage of cloud-based app security solutions](https://licelus.com/insights/is-it-safe-to-combine-ci-cd-tools-with-external-cloud-mobile-app-protection-solutions) to be too risky. We arrived at that conclusion because it means you’re handing over your valuable asset to third-party services and at that point it’s then completely out of your control.
One strategy for reducing your reliance on third-party services is to develop in-house services that can perform the same functions. This approach provides more control over the service and reduces the risk of compromises. That said, we recognize that developing in-house can be time consuming and costly. Especially for smaller organizations with limited resources.
Another strategy is to use open-source software instead of third-party services, as open-source software can be audited and reviewed by the community for security vulnerabilities. Open-source software also provides transparency, allowing developers to see how the software works and what data it has access to. This can help identify any potential security risks and allow developers to address them before deployment.
You should be equally prudent about the third-party components within your application. Modern apps consist of useful libraries covering navigation, image loading, dependency injection, networking and other aspects of a mobile application. Despite being a great help in speeding up the dev process, these libraries also bring the risk of supply chain attacks. This is where the target application gets infected indirectly through one of its dependencies. A [worrying example](https://blog.checkpoint.com/2019/03/13/mobile-supply-chain-attacks-are-more-than-just-an-annoyance/) of such an attack led to the potential leakage of around a third of the Chinese population’s contact details.
### Zero-knowledge cryptography
A big part of zero-trust application security is zero-knowledge cryptography.
This is a technique that allows two parties to exchange information without revealing any sensitive data to one another. In zero-knowledge cryptography, one party can prove to the other that they know a particular piece of information without actually revealing that information to the other party.
It’s a particularly useful technique for situations where two parties need to exchange sensitive information but don’t trust each other. Zero-knowledge cryptography can be used to authenticate users or devices without exposing any sensitive data or credentials to unauthorized parties.
The main advantage of zero-knowledge cryptography is its ability to provide strong authentication and verification of user identity, without compromising user privacy or exposing sensitive data. This makes it an excellent solution for use cases where privacy and security are critical, such as in financial transactions, healthcare, and identity verification.
Zero-knowledge cryptography also enables secure remote access to sensitive data and systems, without requiring users to reveal their passwords or credentials to third parties. This is particularly important in situations where users need to access data or systems from public or untrusted networks, such as over the internet or via mobile devices.
There are several technologies and protocols that can be used to implement zero-knowledge cryptography, including:
- [Secure Comparator](https://docs.cossacklabs.com/themis/crypto-theory/cryptosystems/secure-comparator/) - allows two parties to compare a shared secret without revealing it to a potentially dishonest party (as well as to any third party that might be listening in).
- [Secure Remote Password](https://blog.1password.com/developers-how-we-use-srp-and-you-can-too/) (SRP) - a protocol for secure password authentication that uses zero-knowledge proofs to verify the identity of users without revealing their passwords to the server.
- [Password-less authentication](https://fidoalliance.org/fido2/) - a cryptographic-based method for conveniently authenticating users without storing password material on the server and sending knowledge over the network. It is now generally [available](https://blog.google/technology/safety-security/the-beginning-of-the-end-of-the-password/) on Android and iOS, supported by both Google and Apple.
- [Signal Protocol](https://github.com/signalapp/libsignal) - a secure messaging protocol that uses zero-knowledge proofs to enable end-to-end encryption, without revealing the contents of messages to third parties. You can use it to build your own clients, leverage the crypto primitives, implement zero-knowledge credentials, and more.
- Zero-knowledge proof systems (ZKPS) - a family of cryptographic protocols that enable two parties to prove the validity of a statement without revealing any sensitive data or information.
Despite its many advantages, zero-knowledge cryptography also has several challenges and limitations that you should consider. One of the main challenges is the complexity and overhead of implementing zero-knowledge protocols, which can make them difficult and costly to deploy. This can be overcome through the use of open-sourced, highly-trusted implementations of zero-knowledge primitives.
Another challenge is the need for strong randomness and entropy, which is required to generate the cryptographic keys and nonces used in zero-knowledge proofs. Without strong randomness, zero-knowledge protocols can be vulnerable to attacks and exploitation.
Finally, zero-knowledge cryptography is not a fix for all security and privacy issues. While it can provide strong authentication and verification, it doesn’t protect against other types of attacks like side-channel attacks, malware, or social engineering.
### Risks from end users and employees
Human error, carelessness, or malicious intent can also compromise the security of your application. For instance, a user might unwittingly download malware or fall victim to a phishing attack. And an employee could intentionally steal sensitive data or credentials.
Employee trustworthiness can be affected by a range of factors, such as the size and complexity of the organization, the type of data being accessed, and the level of privileged access granted to users or employees. A small organization with only a few employees might be able to trust its staff more than a large enterprise with thousands of employees spread across multiple locations and systems.
There have been numerous cases of employee breaches that have resulted in significant data breaches. For example, in 2020, Twitter suffered [a breach](https://en.wikipedia.org/wiki/2020_Twitter_account_hijacking) that resulted in the compromise of numerous high-profile accounts. The breach was caused by a social engineering attack that targeted Twitter employees and resulted in the theft of employee credentials. Another example is the [2014 Sony Pictures breach](https://en.wikipedia.org/wiki/Sony_Pictures_hack), which was caused by an insider threat that involved the theft and dissemination of confidential data by a disgruntled employee.
Digital banks tend to be particularly paranoid about[the principle of least privilege](https://www.techtarget.com/searchsecurity/definition/principle-of-least-privilege-POLP). And with good reason. Those that truly care about security have a range of tools and processes in place to make sure the personal data of their clients isn’t misused, or worse, leaked.
One strategy for reducing human risks from end users and employees is to implement strict access controls and authentication mechanisms. This includes using strong passwords, multi-factor authentication and, more importantly, role-based access controls to limit access to sensitive data and systems. Access controls are an effective way to manage user permissions and reduce the risk of unauthorized access. Role-based access controls (RBAC) assign permissions to users based on their role in the organization, limiting access to sensitive data and applications. You can see this in the App Store Developer console: you assign a person either content editor permission or billing permission, thus denying them the right to upload builds and reducing the amount of people able to perform a particular action.
Implementing multi-factor authentication (MFA) can also help protect against unauthorized access as it requires users to provide additional verification. This might be a code generated by a mobile app or a fingerprint scan. Many companies are leveraging one-time passwords (OTPs) either through applications like Google Authenticator, or by sending them through text messages.
Another strategy is to implement security training programs for employees to raise awareness of cyber security risks and best practices. Security training programs can help people to understand the importance of security and their role in protecting the organization's assets. They can also teach them how to recognize and [protect themselves from social engineering scams](https://licelus.com/insights/how-can-you-protect-yourself-from-social-engineering), identify malicious links, and [avoid downloading malware](https://licelus.com/insights/how-bad-actors-deliver-mobile-malware-into-your-device).
Security programs for employees shouldn’t only include training materials, but also the testing of phishing attacks. This not only helps you to identify the awareness levels of threats among employees but also helps you to improve your own internal security measures.
You should also consider homomorphic encryption. This is a method to enable access and transformations over encrypted data without the need to decrypt it in the first place. [Given such a possibility](https://www.openfhe.org/) exists, imagine a use case of an organization that wants to analyze customer data to identify trends and patterns but doesn't want to give their employees access to the raw data due to privacy concerns. With homomorphic encryption, the company can encrypt the customer data and then perform computations on the encrypted data without needing to decrypt it at all. This allows the organization to analyze the data without exposing the raw data to their employees, thereby reducing the risk of data breaches or misuse.
Another example would be searching over the encrypted data without exposing encryption keys to the client and the server side logic. You can read more about homomorphic encryption, [here](https://www.cossacklabs.com/blog/secure-search-over-encrypted-data-acra-se/). The [open-source implementation from Microsoft](https://www.microsoft.com/en-us/research/project/microsoft-seal/) is also worth considering.
As far as your end users are concerned, keep in mind that they can be a huge asset in the fight against cybercrime. [But only if you empower them to be](https://licelus.com/insights/the-secret-ingredient-of-end-user-security).
And remember to develop your app with empathy for the end user. They’re now living in a world with thousands of data points pinging on their phone each day. It’s very easy for them to be tricked in a moment of distraction.
So, educate them to be suspicious first and foremost. And teach them how to recognize a bogus message from a genuine one from your company.
### Embrace zero trust to future-proof your security posture
Organizations continue to operate in a world full of dangerous cyber threats, so it’s vital for developers and architects to design applications with security and privacy in mind. By not trusting third parties, relying on zero-knowledge cryptography, and adopting a least-privilege approach, you can reduce the risk of data breaches and cyber attacks.
That said, zero-trust architecture is not a one-size-fits-all solution. It requires careful consideration and planning to implement effectively. But by adopting these best practices, you can significantly enhance your security posture and future-proof your application’s security in an increasingly interconnected world.
Forward-thinking companies are already sold on zero trust - and it’s slowly becoming the industry-standard approach. Libraries and frameworks for zero-knowledge are publicly available, passwordless standards adopted by the biggest players like Google and Apple are becoming [mainstream](https://blog.google/technology/safety-security/the-beginning-of-the-end-of-the-password/), and homomorphic encryption is being used more widely.
Designing applications with zero trust in mind requires a holistic approach that considers security and privacy at every stage of the development lifecycle. By following the best practices outlined in this article, you can make sure your applications are secure, reliable, and trusted in a world where trust is no longer a sure thing.
## Zero Day Attack Prevention
[All insights](https://licelus.com/insights)
### Follow us
15 Jun 2023
### Zero day attack prevention via enhanced mobile app security
URL: https://licelus.com/insights/zero-day-attack-prevention-via-enhanced-mobile-app-security
# Zero day attack prevention via enhanced mobile app security
The increasing popularity of mobile apps has attracted the attention of cybercriminals. And the inevitable result is a rise in the number of sophisticated attacks.
One particularly insidious type of attack is the zero day exploit which takes advantage of previously unknown vulnerabilities in apps or operating systems.
In this article, we’ll explore some enhanced mobile app security strategies that can aid in zero day attack prevention. Armed with the insights below, you can protect your app and safeguard your end users' valuable data and privacy.
### OS updates
When it comes to mobile security, keeping the operating system (OS) up to date is key. Both iOS and Android platforms release regular updates to patch security vulnerabilities and enhance overall system stability.
For example, one of the latest system iOS updates [patched](https://www.securityweek.com/apple-ships-urgent-ios-patch-for-newly-exploited-zero-days/) the critical vulnerabilities in IOSurfaceAccelerator and WebKit. This allows for the remote code execution (RCE) of kernel privileges by manufacturing a specific web page. With the latest security patches in place, you can encourage your end users to update their OS version promptly, which significantly reduces the risk of zero day attacks.
Sticking with the iOS platform, Apple also provides a robust system called [Lockdown mode](https://support.apple.com/en-us/HT212650). This enables a higher level of security by restricting access to sensitive information and features. If you’ve developed an app, then you should definitely educate your users about the benefits of enabling this mode and following the recommended security practices. Lockdown mode was created specifically with a view to protecting individuals more likely to be targeted - or even persecuted - by bad actors. Human rights activists, for example. But it’s a feature that anybody can use if it makes them feel safer on their device.
Android developers have the advantage of utilizing [a sandbox model](https://licelus.com/insights/the-risks-of-letting-your-app-run-on-rooted-devices) which isolates an app's processes and data from other apps and the underlying OS. To maximize the security benefits of the sandbox model, you should set the targeted SDK value as high as possible during app development. This makes sure that the app is built using the latest version of the SDK, incorporating the most advanced security features and mitigations available.
But OS updates alone aren’t enough to ensure zero day attack prevention.
If you’re a developer, then there are plenty of other enhanced mobile app security measures you should adopt.
### Device Authentication
Verifying the authenticity of the operating system and the device itself is another critical aspect of mobile app security. Android offers a powerful framework called [Play Integrity API](https://developer.android.com/google/play/integrity/overview) which enables developers to verify the integrity of the OS and device.
Play Integrity API, the successor to SafetyNet, allows you to perform device attestation. This is the act of making sure that the app is running on a genuine and trusted device. In comparison to SafetyNet, Integrity API can also verify that an application is the very same binary that was purchased or downloaded from Google Play.
Another powerful feature of device integrity checks is security keys attestation. Using the API and data [provided](https://developer.android.com/training/articles/security-key-attestation) by Android, you can make sure that your encryption keys are stored securely in hardware and the underlying OS is shipped by Google with the given guarantees. It enhances trust assurance, protects against key extraction, and provides resistance to tampering attempts.
In much the same way, iOS provides the Attestation Framework, which allows developers to authenticate the device and OS.
By utilizing these frameworks, you add an extra layer of protection against unauthorized usage, tampering, and attacks targeting compromised devices.
Implementing device authentication doesn’t only help with zero day attack prevention. It also stops unauthorized usage on rooted or jailbroken devices. It’s essential that you integrate these authentication mechanisms into your app to ensure the highest level of security (and therefore long-term trust from end users). We covered the importance of device attestation frameworks and integrity control in a bit more detail in a separate article about [publishing apps on third party platforms](https://licelus.com/insights/how-to-keep-integrity-control-when-publishing-apps-on-third-party-platforms).
So, by leveraging the sandbox model and implementing device authentication mechanisms, you can significantly bolster your app's resilience against zero day attacks. These measures, when combined with other enhanced protection techniques, create a robust defensive system.
With this holistic defensive system in mind, let’s move onto the next step in zero day attack prevention - data encryption and device binding.
### Data Encryption and Device Binding
Data encryption and device binding techniques provide additional layers of protection for sensitive data and strengthen your app's resilience against reverse engineering attempts.
##### **Data encryption**
Data encryption plays a crucial role in safeguarding sensitive information stored locally within your mobile app. By encrypting data, you can make sure that even if an attacker gained unauthorized access to the device or the app's data, [then the information would remain incomprehensible and unusable](https://licelus.com/resources/guide-to-mobile-application-protection/threats/decompilation-and-modification).
There are various encryption algorithms and techniques available that you can implement. But remember, it’s vital to choose strong encryption algorithms and employ best practices for key management to maintain the integrity and confidentiality of the encrypted data. You should also consider encrypting data during transmission to protect it from potential interception and tampering.
It’s also worth exploring the option of minimizing data storage on the device. By adopting a \"data-not-stored\" approach - where sensitive information is retrieved from secure servers when needed and promptly discarded afterwards - you can significantly reduce the attack surface. And as such the potential impact of zero-day exploits targeting locally stored data is also diminished. This approach is frequently adopted by online banks. Their mobile apps often store nothing except for the username of the user.
Both Android and iOS provide developers with tools and libraries to encrypt data at rest, ensuring the confidentiality and integrity of sensitive information stored on mobile devices. And while the overarching goal of data encryption is similar on both platforms, there are some differences in the specific tools and approaches available.
Android offers the KeyStore system, which provides a secure container for storing cryptographic keys and performing cryptographic operations. Developers can generate and securely store encryption keys within the KeyStore, leveraging hardware-backed security if available. The KeyStore API allows for seamless integration with various encryption algorithms and modes, ensuring data confidentiality.
The corresponding capability for iOS is the Keychain Services API. It allows developers to securely store sensitive data, including encryption keys, passwords, and certificates. The Keychain Services API handles key management and provides strong protection for stored data, leveraging hardware-backed security.
Android also provides the EncryptedSharedPreferences class as part of the AndroidX [Security](https://developer.android.com/topic/security/data) library. With this tool you can encrypt shared preferences, providing a convenient way to store small amounts of encrypted data over time.
A set of cryptographic functions and APIs for iOS bears the name of CommonCrypto Framework. You can use this framework to perform data encryption using symmetric or asymmetric encryption algorithms. These include AES (Advanced Encryption Standard) or RSA (Rivest-Shamir-Adleman).
iOS adds data protection by default to all application data after the user enables the passcode on the device. This capability is called Data Protection API - it enables automatic encryption of files and data at rest. By applying appropriate data protection classes to files or directories, you can be sure that the data remains encrypted when the device is locked or in a powered-off state.
It’s important to note that while both Android and iOS provide native tools and libraries for data encryption, there are also additional security measures worth considering. These include secure key management, strong encryption algorithms, and adherence to best practices for secure coding and data handling.
##### **Device binding**
Device binding is a technique that helps prevent reverse engineering and unauthorized usage of the app by tying it to the specific characteristics of the device. By establishing a strong binding between the app and the device, you create an additional barrier for attackers attempting to analyze and modify your app's behavior.
Device binding can be implemented using various methods, such as generating unique device identifiers, utilizing hardware-based attestation, or leveraging device-specific characteristics like device fingerprints. These techniques enable the app to verify the integrity of the device it’s running on and to detect potential tampering attempts.
You should refer to resources such as the [OWASP Mobile Security Testing Guide](https://mas.owasp.org/MASTG/) for comprehensive guidelines on implementing device binding in your apps. We also covered it in [our guide to mobile application protection](https://licelus.com/resources/guide-to-mobile-application-protection/threats/mobile-app-fraud) as part of our advice for stopping mobile app fraud.
By incorporating robust data encryption techniques and implementing device binding, you can significantly enhance the security of your mobile apps. And this can go a long way in helping to achieve zero day attack prevention.
That said, it’s important to note that these strategies should be complemented by other protection techniques to establish a comprehensive security framework. And as technologies evolve, there are new and exciting ways to fortify mobile app security against zero day exploits.
### Leveraging Anomaly Detection with AI
As the sophistication of zero day attacks continues to evolve, traditional rule-based security mechanisms may fall short in detecting and preventing these exploits. To augment the security posture of mobile apps and achieve zero day attack prevention, you can leverage the power of anomaly detection techniques based on artificial intelligence (AI).
Let's explore how AI can be utilized for anomaly detection in mobile app security.
##### **Identifying Suspicious Patterns**
AI-based anomaly detection algorithms can analyze various aspects of app behavior, such as the number of requests, payload sizes, and error patterns. By establishing baseline patterns of normal behavior, AI models can detect deviations from said patterns, which might indicate potential zero day attacks or abnormal activities.
For example, say an app suddenly experiences an unusually high number of requests or encounters unexpected payload sizes. This may suggest a malicious attempt to exploit a vulnerability. AI algorithms can detect these anomalies and trigger appropriate security measures, from simply logging the event, to alerting administrators, or even automatically blocking suspicious activities.
##### **Training AI Models**
To implement effective anomaly detection, developers need to train AI models using representative and diverse datasets. This training data should include both normal app behavior and various attack scenarios. By exposing the AI models to a wide range of app activities, they can learn to distinguish between legitimate behaviors and anomalous patterns that might hint at a zero day attack.
It’s vitally important to continually update and refine the AI models as new attack patterns emerge. Make sure to keep a keen eye on emerging threats, security research, and the latest industry practices to ensure the AI models remain effective against evolving zero-day attack techniques.
##### **Collaborative threat intelligence**
Collaboration within the developer community and information sharing about zero day attacks can be invaluable in combating them in the long run. By sharing anonymized threat intelligence data, you can collectively build more robust AI models for anomaly detection.
Industry groups, security communities, and threat intelligence platforms each provide channels for sharing insights and indicators of compromises related to zero day attacks. If you’re a developer and you’re interested in security, then you should actively participate in these initiatives to stay informed about emerging threats. You’ll then be able to leverage this shared knowledge to enhance your own app security.
So, by harnessing the power of AI for anomaly detection, you can augment your app's security defenses against zero day attacks. But it’s important to remember that AI-based approaches should be used in conjunction with other protection techniques mentioned earlier in this article, such as data encryption, device binding, and OS updates. Each of them help to create a comprehensive security framework.
### Zero day attack prevention strategies
The mobile app security landscape is ever changing. And so zero-day attack prevention requires a multi-layered approach. In this article we’ve explored several key strategies that you can employ to fight against zero day exploits.
One key idea to highlight before the end of this piece is that any attack, regardless of its sophistication, leaves behind traces. This notion challenges the widely-held misconception that zero-day attacks are somehow undetectable and untraceable. By implementing security measures such as data encryption and device binding, you create barriers that make it significantly harder for attackers to exploit vulnerabilities and cover their tracks completely.
What’s more, the adoption of device attestation and anomaly detection with the help of AI introduces proactive defense mechanisms. Device attestation ensures the integrity of cryptographic keys and verifies the authenticity of the device, while anomaly detection employs AI algorithms to identify suspicious patterns and behaviors. These techniques allow for the online detection of zero-day attacks during their active phase, providing the opportunity to identify their traces and prevent further exploitation.
But remember that all of the strategies we’ve set out in this article should be implemented in conjunction with one another. That way individual protection techniques can become something much bigger - a comprehensive security framework. Additional measures like [code protection](https://licelus.com/resources/guide-to-mobile-application-protection/threats/decompilation-and-modification), [protection against MITM attacks](https://licelus.com/resources/guide-to-mobile-application-protection/threats/network-communications-interception), and application integrity should be considered to further strengthen app security, too.
As a mobile developer you must prioritize ongoing education and awareness regarding emerging threats and best practices in mobile app security. Collaborating with industry groups and sharing threat intelligence can make zero day attack prevention more achievable for all of us.
So, safeguarding mobile apps against zero-day exploits requires a proactive and multi-faceted approach. By making OS updates a priority, leveraging the sandbox model and device authentication, implementing data encryption and device binding, and utilizing AI-based anomaly detection, you can significantly enhance the security posture of your app.
All of us have to continually adapt and evolve our security strategies to keep pace with the evolving threat landscape.
But achieve this goal and the result is well worth it - you ensure the protection of your users’ data and their privacy. And by doing so you gain their long-term trust.
## App Sideloading Impacts
[All insights](https://licelus.com/insights)
18 Jul 2023
### The push to open up Apple's walled garden
URL: https://licelus.com/insights/the-push-to-open-up-apple-s-walled-garden
# The push to open up Apple's walled garden
**Apple’s walled garden** is well known as a tightly-controlled and secure place.
But not everyone is happy with what goes on behind the garden walls. For a while now, some have glared at them with suspicious, sceptical eyes. They see a place that’s closed to competition where Apple sets the rules and profits too handsomely as a result.
Such is this strength of feeling, especially in the EU, that **there’s now legislation in place that will push Apple to open up its walled garden and allow app sideloading** (downloading apps from third-party sources).
But what might the security implications be of this shift?
And what does the move tell us about the wider tension in tech between a desire for greater freedom and competition and the need for robust security mechanisms?
### Inside the garden walls
**Apple’s ecosystem is known as the walled garden because of its comprehensive security measures** and the restrictions placed upon end users of its devices and operating systems.
These restrictions are often cited when people compare iOS with its rival platform, Android. Those who value technological freedom above all else might choose the latter because by nature it’s a lot more open. But for the same reason there tend to be more risks and vulnerabilities in the Android ecosystem.
To begin with, think for a second about all of the manufacturers of devices that run the Android OS. There are **a lot** of them, from Samsung to OPPO and Huawei. With Apple, on the other hand, there’s just one: Apple. And that means the company has complete control over development, distribution, and security.
A good example of this is OS updates. The fragmentation of Android means that update rollouts aren’t always quick or consistent. Indeed, some older devices are often left out of this update process altogether. Apple updates, on the other hand, tend to be rolled out quickly and seamlessly. This helps to make sure that devices are equipped with the latest security mechanisms that protect against known vulnerabilities.
iOS apps also go through a rigorous review process before they arrive on the App Store and can be downloaded by end users. This is done to make sure that new apps meet Apple’s quality, privacy, and security standards. As we’ll explore in more detail later, this is a key reason why Apple has been reluctant to allow app sideloading.
Again, Android provides an interesting point of difference here. Google too has sophisticated security features integrated to the Android Play Store, but it also allows end users to install apps from several sources. Including from third-party websites and app stores. So, Android users have more freedom, but they’re also exposed to more vulnerabilities (including potentially malicious or compromised apps) if they choose to download them outside of the Google ecosystem. A pointer, perhaps, to what might be in store for iOS users should they choose to search for apps outside the App Store.
It’s useful to mention at this point that iOS security can be a little overstated. [It certainly isn’t quite as infallible as some people think](https://securelist.com/operation-triangulation/109842/). Indeed, we sometimes have to explain to prospective customers of our own mobile app protection product, DexProtector, why they really should be applying the same protection mechanisms to both their Android and iOS apps. Especially if they want to protect their logic and sensitive data from reverse engineering, tampering, and theft.
That said, it’s true that **the walled garden approach invites fewer outside unknowns that can become threats further down the line**. Apple has invested heavily in achieving and maintaining a reputation as the safer of the two big mobile OS ecosystems. And on the whole this effort has paid off. End users do tend to associate iOS with a higher level of security than Android. And so security has become an important selling point for Apple in recent years.
But while some users associate iOS with security and privacy, other individuals and groups have been more judgmental. [Elon Musk has openly lamented what he sees as Apple’s payment monopoly](https://fortune.com/crypto/2023/06/15/musk-takes-a-shot-at-apples-payment-monopoly/?queryly=related_article). And he’s not the only one. Epic Games, the creator of the popular Fortnite game, took Apple to court in 2020 citing the App Store’s unfair in-app-purchases practices. Most saw the result of that case as a victory and vindication for Apple - [more recently the company also won their appeal case](https://techcrunch.com/2023/04/24/apple-wins-antitrust-court-battle-with-epic-games-appeals-court-rules/?guccounter=1&guce_referrer=aHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS8&guce_referrer_sig=AQAAALnVtzF7RCtGfjFzIWFwrWMIaX-sr1-h3ojZj4ZN0UkB7_SF8TqUhmeeYy0aHdYYgefTHrZMXvGVWSoDWuXA_SriSVizY0sSPuUUYyn46rSIcGwaccZFlPmVzHltv2nPHAOdWb8zpw7N7bwUDmWieSHxyI54Gf1F9rlAzJdt59ZV) - but there’s no denying it helped to more widely publicize what many see as anti-competitive behavior. The 30% cut that Apple takes from app purchases and in-app transactions in particular has seen plenty of raised eyebrows.
Among those to take note was the European Union. Rather than Elon Musk or Epic Games, it’s **the EU Government that appears to have compelled Apple to open up its walled garden in this way and allow app sideloading** - at least in Europe. Their Digital Markets Act (DMA) is designed to encourage competition in the app market. In Apple’s case that means making some big changes to how they operate - at least in Europe. They have until 2024 to comply with the DMA; if they don’t then they’ll be liable to pay a hefty fine (up to 20% of annual global revenue).
While this isn’t the first time that Apple has relaxed its policies - the company has made gradual changes in recent years, including [loosening its restrictions for publishing to the App Store](https://techcrunch.com/2022/06/07/apple-loosens-some-of-its-app-store-review-guidelines-with-latest-update/?guce_referrer=aHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS8&guce_referrer_sig=AQAAAKafzJCiwcSpzewYq7dNyqXp_d-c2uHkmfhMedp8_mx_zvs4sdT31P3CI-aL_74PdMvyO3jBgeiOsvqkFFxdoZeQ2EF9c-f-KdUJ2avL0XalgDmNSMO57bvIh06bfpIWQnbsI37kZcD2-KakTfrECe7xsV7V4NCJ6-dsH1AgF7fv&_guc_consent_skip=1688053628) - app sideloading feels like the most significant shift yet.
So, what does it mean for security?
### The security implications of app sideloading
This isn’t the first time we’ve highlighted [the difficult balance between a desire for greater level of competition and the need for strong protection mechanisms](https://licelus.com/insights/how-to-keep-integrity-control-when-publishing-apps-on-third-party-platforms). It’s something of a recurring theme in the tech space, after all. But this latest example of a growing tension between the two begs the question:
Could the DMA’s goal of increasing competition in the mobile app market come at the cost of more cyber risks facing end users?
Apple has certainly claimed as much, stating that app sideloading would lead to end users being up against some serious security threats.
**App sideloading certainly has the potential to expose iOS applications, devices and users to more risks**. Apps that are available to download and install on third-party stores might not be subject to the same strict review process carried out at the App Store. That means end users might mistakenly install apps that contain [malware](https://licelus.com/resources/guide-to-mobile-application-protection/threats/malware) or other forms of malicious code.
Similarly, Apple and others arguing against this shift are fearful that fake versions of genuine apps might appear on third-party platforms for unsuspecting end users to download. **These apps too could come with malicious code or malware capable of stealing information via overlays or keyloggers**.
In recent years Apple has also gained a lot of credit among end users and tech analysts alike for [its privacy policies](https://www.apple.com/uk/privacy/control/). Features like App Tracking Transparency exist to give end users more control over how their data is used. And so it’s unsurprising that privacy has also emerged as one of the key arguments against app sideloading. The fear for some is that third-party stores wouldn’t apply the same level of scrutiny that Apple does and so personal data might be misused or collected without authorization.
Again, Apple currently has complete control over the applications uploaded to its App Store so it can monitor any bogus apps that slip through the net. But this would no longer be the case if app sideloading was allowed. The company would also have much less sway when it comes to enforcing security guidelines for developers to follow, with the potential end result being a greater number of less secure apps available for end users to download.
**Opening up Apple’s walled garden could therefore damage iOS’ hard-fought reputation** as the more secure of the two big mobile platforms. And it could expose end users of iOS apps to the kind of threats that they’ve perhaps steered clear of up to now.
But there are also implications for developers of applications. As we’ve already mentioned, there’s sometimes some complacency when it comes to protecting iOS apps. Apple’s reputation for security is such that some developers assume it isn’t necessary to apply the same kind of enhanced protection mechanisms used to protect Android apps. This isn’t true now - and it certainly won’t be true in the event of app sideloading and the increased vulnerabilities that this shift will bring about.
### Securing iOS apps outside of the walled garden
So, what should you as an iOS app developer be mindful of now and in the near future (once the iOS ecosystem opens up)?
The threat landscape is ever changing (as the push to open up Apple’s walled garden neatly illustrates) and so you need to cover as many bases as possible to make your app significantly tougher to crack.
Perhaps the easiest way to think about this is that your iOS app needs [four interconnected layers of security](https://licelus.com/resources/guide-to-mobile-application-protection/principles/the-four-layers-of-mobile-application-protection).
First up is **code and resource hardening**. The idea here is that you use sophisticated encryption and obfuscation to make the decompiled code within your iOS app extremely difficult - if not impossible - to decipher. This is vital because decompilation is more often than not the first step an attacker would take before carrying out any of the attacks mentioned in the previous section.
These days, though, the vast majority of attacks happen while your app is running, which is why you need to ensure a **secure runtime environment**, too. A runtime application self protection (RASP) solution enables your app to protect itself at runtime by detecting the presence of rooted devices and dynamic instrumentation tools like Frida, among other threats. If they’re detected, you can then prevent the app from running, which stops bad actors from taking full control over your app’s execution.
Of course it isn’t only your iOS app that needs protecting but the communications channel between it and its remote endpoints, which brings us to our next layer of protection: **secure network communications**. iOS performs public key certificate validation checks to prevent network attacks, but it’s possible to override this system check and install fraudulent root certificates. So, it’s crucial - especially in a world where app sideloading is permitted - that you perform such checks from the mobile app itself.
Finally, there’s arguably the most important layer of all - **application integrity**. Last summer we wrote [another article](https://licelus.com/insights/how-to-keep-integrity-control-when-publishing-apps-on-third-party-platforms) about protecting your app if it’s published on a third-party platform, and maintaining integrity control was our number one focus. Why? Well, application integrity is all about stopping an attacker from tampering with your app’s binaries. Because if they’re able to do so, they can disable other protection mechanisms we’ve set out in the previous layers. Being able to check that nothing has changed in your app is therefore absolutely essential, especially if it’s out of your direct control on a third-party platform.
As one of the main dangers of sideloading apps is the existence of applications with malicious code or malware, it’s also important you equip your app with malware mitigation measures. This includes blocking screen capture, preventing the use of custom keyboards, and disallowing the presence of overlays on sensitive UI pages.
Educating your end users will also be incredibly important in the event that Apple is forced to accept app sideloading. After all, as iOS users they’ll almost certainly be less aware of the threats that exist out there compared to those using Android devices. The most obvious piece of advice would be to make sure that end users trust the company behind an app or its developer before downloading from somewhere other than the App Store.
It’s also vital that end users keep an eye on the permissions that apps are asking for. This is something they should ideally be doing anyway, but away from the App Store and Apple’s lauded privacy measures, this becomes even more important.
### Be prepared for an ever-changing threat landscape
It should be said that the intentions of the DMA are noble - there’s a very solid argument in favor of greater competition in the tech space. Opening up the application ecosystem can be a positive thing for creativity and innovation, too. It would potentially give developers more freedom as well as a greater share of the overall revenues their app generates.
The problem is that unfortunately we’re living in a world where bad actors are skilled at exploiting any opportunity. And app sideloading can be such an opportunity if you don’t equip your iOS application with the means to protect itself in the wild world of third-party app platforms.
When you think about it, the modern technological world we inhabit is one big balancing act between risk and reward. Deep down we’re all aware that when we use our favorite social platforms, we’re constantly sharing data about ourselves that can later be used for advertizing purposes. But we do so because we decide this is a price worth paying for the enjoyment we take from that app.
But as the digital landscape evolves, our risk-reward calculations might have to change, too. Ultimately it’s on end users to decide whether, for example, they’re willing to download a mobile game from a third-party store that doesn’t have the in-built safety features that the App Store has.
Our objective here at Licel is [to encourage the use of enhanced mobile app security](https://licelus.com/resources/guide-to-mobile-application-protection) so that a lot of the threats that can emerge as a result of app sideloading are less of an issue. But there will still always be threats and the potential for human error like [falling for a social engineering scam](https://licelus.com/insights/how-can-you-protect-yourself-from-social-engineering) - something that any of us are capable of in a distracted moment.
Apple is due to announce its strategy for dealing with app sideloading in the coming weeks. The most likely scenario is that they do open up their walled garden but with some conditions, such as ensuring that developers of apps abide by their strict security and privacy policies.
But there will be those who seek to prod, probe and profit from any weaknesses as everybody recalibrates to this new reality.
The best thing you can do is make sure that your app is protected as well as it can be. That way it won’t be exposed to these new threats that will almost certainly emerge.
Read our report into [the state of mobile app security](https://licelus.com/state-of-mobile-app-security) to understand how our digital world is evolving and why enhanced application security is so important.
## Custom Security Solutions Caution
[All insights](https://licelus.com/insights)
### Follow us
22 Jul 2023
### Why you should think twice about creating custom security solutions
URL: https://licelus.com/insights/why-you-should-think-twice-about-creating-custom-security-solutions
# Why you should think twice about creating custom security solutions
Modern mobile apps are being forced to battle an overwhelming number of threats. These include untrusted environments, rooted and jailbroken devices, and the schemes of malicious actors.
Among the weapons you can wield to stop these threats are solid user authentication, encrypting the data being transmitted between the app and the server, ensuring the authenticity of said server, and monitoring the app for behavior anomalies.
But as the sheer range of cybersecurity threats widens, it can be tempting to want to create custom security solutions to deal with them.
This could include creating custom cryptographic systems, designing unique authentication mechanisms, inventing your own pin-code screens, or even building your own network protocols.
Sadly, though, this can lead to you simply reinventing the wheel. And the end result can actually be a less secure application.
In this article we’ll explore the core components of modern cybersecurity - cryptography, authentication (including biometrics and pin-code screens), and network layer security. We'll delve into the intricacies of each and explain the challenges that can come from designing custom security solutions in these areas. And we'll explain why existing, established solutions often provide a safer, more reliable approach to securing your mobile applications.
### Understanding cryptography
Imagine you need to send an important message to your colleague.
You’ll want to make sure that two things happen. Firstly, that nobody except your colleague is able to read your message. And secondly, that she receives exactly what you sent to her and not a modified version.
One of the best ways to make sure this happens is by using cryptography. The backbone of modern digital security, cryptography is what keeps our online interactions confidential. It ensures the integrity of our data, and verifies the identity of communicating parties.
Cryptographic systems revolve around two core elements: encryption algorithms and cryptographic keys. Encryption algorithms convert plaintext information into unintelligible text (ciphertext), while cryptographic keys are secret values used in these algorithms to ensure security. The way these keys are used gives rise to various types of cryptography: symmetric-key, asymmetric-key, and hash functions, for example. And each has its unique advantages and use-cases.
Developing a secure cryptographic system, however, is not as simple as choosing an encryption algorithm and creating a key. The complexity of cryptography lies not only in designing the algorithms but also in making sure they’re implemented and managed securely.
Missteps in any of these areas can lead to vulnerabilities that can be exploited by bad actors. For example, creating a short key could allow them to brute force it. Failing to store the encryption key securely can result in the encryption efforts becoming pointless. And not providing random initialization data to the crypto algorithms opens up a whole new variety of attacks.
Attempting to design custom cryptographic systems yourself to solve these challenges can also further exacerbate risks. The field of cryptography has a long history, with many algorithms that seemed secure at first later being found to contain critical vulnerabilities. These flaws are often only discovered after years of rigorous testing and analysis by the global cryptographic community.
Remember, even a seemingly minor oversight or error in a custom cryptographic system can render it completely insecure.
Established cryptographic systems, on the other hand, have withstood the test of time (and scrutiny). They’re designed by experts in the field, extensively peer-reviewed, and are continually updated in response to new threats that emerge. So, they offer a level of security and reliability that custom security solutions typically can't match.
As we continue to delve into other components of cybersecurity - biometric authentication, pin-code screens, and network layer protocols - you’ll see the same principle repeating:
It's generally much more secure and efficient to rely on established solutions than to attempt to reinvent the wheel.
### The importance of secure authentication
User authentication exists and is so important because it serves as a gatekeeper. It stops unauthorized access and protects sensitive data from malicious threats.
There are various forms of authentication in use today, ranging from simple password systems to more advanced biometrics and multi-factor authentication (MFA) systems. There are even combinations of each. These methods have been developed and refined over the years to provide a balance between security and user-friendliness, which is not an easy task.
Biometric authentication is a popular method that involves verifying an individual's identity based on their unique physical or behavioral characteristics. These include fingerprints, facial patterns, or voice recognition. While these methods offer a high level of security, they also require sophisticated technology and careful implementation to avoid potential vulnerabilities. For instance, a poorly-implemented facial recognition system might be tricked by a photo. And a voice recognition system could be fooled by a recording of somebody’s voice.
Similarly, pin-code screens are widely used due to their simplicity and convenience. But by creating custom pin-code systems you can open the door to security risks. After all, implementing a secure pin-code system is about more than just accepting and verifying a numerical input. It also needs to account for factors like secure data storage, resistance to brute force attacks, and protection against data leaks during input.
[Banking trojans](https://licelus.com/insights/how-bad-actors-deliver-mobile-malware-into-your-device) are another important consideration. They exploit the OS to capture what’s on the screen, log your end user’s input, and show overlays that resemble legitimate banking app screens. They’ve been around for more than a decade, [they’re multiplying fast](https://www.kaspersky.com/about/press-releases/2023_200000-new-mobile-banking-trojan-installers-discovered-double-the-2021), and are a significant threat to protect from.
In both these cases, using established authentication solutions that have been extensively tested and refined is a more secure approach. These solutions are designed with security best practices in mind and have been scrutinized by the wider cybersecurity community to identify and rectify potential vulnerabilities.
### Custom pin-code screens: a cautionary tale
Both mobile iOS and Android platforms include the phone-locking functionality. You get to choose 4 to 6 digits to prevent anybody from accessing your phone. Mobile devices are valuable possessions, so there’s no shortage of people developing solutions to brute force, crack and breach the pin-code.
This context helps to explain why platform developers are constantly working on improving the security of pin-code screens. But again, there are examples out there of custom implementations of pin-code screens that have invited even more risks.
There’s more to a secure pin-code system than you might think. It doesn't just verify that the entered pin matches the stored pin. It also needs to account for data protection during input, storage, and transmission. And user inputs need to be concealed to prevent over-the-shoulder peeping or screen recording attacks. What’s more, secure storage practices like hashing and salting need to be used to protect the pin in case the data storage gets compromised.
The system should incorporate security measures to prevent brute-force attacks (repetitive attempts to guess the pin). This could involve limiting the number of incorrect pin attempts, introducing time delays after failed attempts, or temporary account lockouts.
In many reported breaches of pin-code screens, the root cause was often some kind of overlooked security practice. So, using insecure data storage methods or [failing to adequately protect against brute force attacks](https://www.kitploit.com/2021/04/android-pin-bruteforce-unlock-android.html), for example. There are plenty of harsh reminders out there that prove that implementing a secure pin-code screen is not as easy as it might seem at first.
There are a wide range of established solutions for pin-code authentication available today, each designed with a deep understanding of these threats and how to mitigate them. These tested, proven tools are updated as new threats emerge and are a much better bet than custom solutions.
### The challenge of network security
One of the fundamental components of network security is the use of protocols, which are rules or standards that dictate how devices on a network exchange information. Protocols define processes for tasks such as error checking, data compression, and data transmission. They’re critical when it comes to making sure that network communications are performed efficiently and securely.
Typically, there are committees which suggest changes to these protocols and discuss them thoroughly. Given their complexity and the security implications of getting them wrong, network protocols are extensively tested and analyzed before widespread adoption.
Well-known protocols like the Transmission Control Protocol/Internet Protocol (TCP/IP), Secure Sockets Layer/Transport Layer Security (SSL/TLS), and HyperText Transfer Protocol Secure (HTTPS) have become industry standards. The reason they’re used so extensively is because they’ve proven over time to be secure and reliable.
But even having committees, reviews and other measures in place can’t guarantee problem proof protocols. As it was shown several years ago, [even protocols with a well-established history are susceptible to security and privacy problems](https://thehackernews.com/2020/11/facebook-messenger-bug-lets-hackers.html), such as sending audio in a phone before the callee actually picked up.
This might provide some context for why organizations and developers can sometimes be tempted to develop their own custom network protocols. Such a decision might arise from specific business requirements, the desire for optimization, or a misguided belief in \"security by obscurity\". In other words, keeping the design of the protocol secret to prevent attackers from discovering vulnerabilities in it.
However, creating your own custom network protocol can introduce significant security risks. Not least because it wouldn’t be put through the extensive testing and scrutiny that standard protocols undergo. And so the likelihood of undiscovered vulnerabilities increases. Security by obscurity has also been widely discredited in the cybersecurity community for promoting a reliance on secrecy rather than on robust, proven security measures.
Custom protocols can introduce compatibility issues, too. They increase the complexity of network management which leads to a higher likelihood of configuration errors and potential security gaps.
For these reasons, it's generally best to stick with established network protocols. They’ve been verified through years of use and have a broad base of experienced developers who understand their ins and outs.
### Don’t risk doing it yourself
As you might have noticed throughout this piece, the desire to design and implement custom security solutions often comes with the best intentions.
But whether it's to optimize performance, satisfy unique requirements, or simply a drive to innovate, these ambitions can lead to unforeseen cybersecurity risks.
Take the example of Telegram, a popular messaging app. In the early years of its existence, its developers created their own protocol to exchange information. But before long, [security experts found flaws in it](https://enos.itcollege.ee/~edmund/materials/Telegram/A-practical-cryptanalysis-of-the-Telegram-messaging-protocol_master-thesis.pdf). The research found several attack vectors which wouldn’t have existed if Telegram had used battle-tested primitives and approaches.
Signal is a rival messaging app. It too uses its own protocol, but it proved to be a more reliable and hack-proof messenger. For example, when a small portion of users were affected by a hack, [no data was actually leaked to the malicious users](https://www.kaspersky.co.uk/blog/signal-hacked-but-still-secure/24864/). And it emerged that the hack didn’t come about via Signal itself but rather a less secure company in the supply chain that was sending auth codes. Still, this example represents something of an outlier.
As we've seen in the previous chapters of this article, each component of cybersecurity - cryptography, authentication, and network security - is a complex field in and of itself. Each comes with decades of research, development, and real-world testing behind it that has resulted in the existing solutions that are tried and tested.
Attempting to create custom security solutions in these areas doesn’t only require substantial expertise. It also requires a deep understanding of potential vulnerabilities and the knowledge of how to mitigate them.
But even with considerable experience, it's easy to overlook a small detail or underestimate a potential threat. And this can lead to significant security vulnerabilities.
A custom cryptographic algorithm might seem secure on the surface but could be susceptible to specific types of attacks (see the Telegram example above). A self-designed authentication mechanism might not account for all potential intrusion methods. And a custom network protocol might contain loopholes that could be exploited for data breaches.
What’s more, DIY solutions don't benefit from the continuous updating and refining that established solutions receive. In the world of cybersecurity, threats are constantly evolving, and security measures that are effective today might not be quite as foolproof tomorrow. Established solutions are maintained by dedicated teams of experts who stay abreast of the latest trends and update the solutions accordingly.
There's also the question of resource allocation. Developing, testing, and maintaining custom security solutions can consume significant time and resources that might be better directed elsewhere. So, improving the overall user experience or adding new features, for example.
Remember, cybersecurity is a marathon, not a sprint. The key to winning is not outpacing everyone in a burst of speed, but maintaining a steady, unyielding defense that can stand the test of time.
For mobile application protection best practices, check out [our definitive guide](https://licelus.com/resources/guide-to-mobile-application-protection). It explains how attackers target apps and how you can combat them effectively.
29 Jul 2023
### The psychology of social engineering
URL: https://licelus.com/insights/the-psychology-of-social-engineering
# The psychology of social engineering
### Troy
In the myth of Troy, the leaders of the famous city in modern-day Turkey thought they’d outsmarted the Greeks who had tried and failed to take the city by force. But the Greeks knew of the Trojans’ belief in superstition. And so they devised a cunning plot that played on it.
The Greeks constructed a giant wooden horse and placed their best warriors inside. Then they feigned defeat and retreated from the battlefield, leaving only the gigantic horse - seemingly a trophy for the victors - behind.
So, the Trojans wheeled the gift inside the city walls and the Greeks within waited for nightfall.
The famous myth of Troy, retold for thousands of years, is familiar to those of us working in cybersecurity. Because like the Ancient Greeks, modern-day social engineers are also highly-skilled at exploiting human emotions.
A 21st century equivalent of a large wooden horse is a bogus SMS message purportedly from a trusted friend or colleague. And inside that message lies a malicious link that can cause almost as much malaise as a crack group of Athenian warriors.
It’s often forgotten that many of the tactics employed by bad actors today are actually nothing new. The psychology of social engineering has been perfected by human beings for thousands of years.
### Mimicry
We’ve sometimes described cybersecurity as being a bit like [a form of martial arts](https://www.linkedin.com/pulse/licel-mobile-security-trends-2023-ivan-kinash/). The defender is constantly having to enhance his craft to block attacks that are coming at him from all sides and are growing in complexity all the time.
The defender might sometimes think he’s on the verge of victory. But the attacker knows that he has a trick up his sleeve: [deception targeted to appeal to base human emotions](https://licelus.com/insights/why-our-emotions-make-us-more-vulnerable-to-cyber-attacks).
There’s a reason why social engineering often feels like such a pervasive threat, persisting despite the sophistication of cyber security tools. It’s because the psychology of social engineering is designed to appeal to human emotions. However smart we think we are, we’re all - even those of us who work in cybersecurity - susceptible to welcoming these emotions in a moment of distraction or vulnerability. And then we can be tricked.
Mimicry and deception exist in flora and fauna, too. There are plants and animals that pretend they’re something they’re not either to attract prey or to convince predators that they’re not worth attacking.
But the skills we now recognize as social engineering are most commonly associated with the human race. After all, we haven’t risen to the top of the food chain because of our immense strength and ferocity. Instead, our power lies in our intelligence, cooperation skills, and the trust that we place in one another. As Yuval Harari explains in his popular book, Sapiens, there’s no way the human race would have risen so far without our ability to tell stories.
It’s just that not all of these stories are true.
### Sicily
In 1943, the Allied forces needed to open up another front in Europe to alleviate the pressure on the Soviet Union. Sicily was the most logical choice - the only problem was that the Germans knew this, too. So, the allies needed to think of a way to distract them and convince them that Sardinia was the real target.
The solution they happened upon was more than a little leftfield. It involved an already-deceased man, a briefcase, and an array of manufactured documents.
British Intelligence procured the body of a homeless man in London and dressed him as a Royal Marines officer named Major William Martin. And in his briefcase, chained to his wrist, they stuffed a host of classified documents - all of which pointed to an imminent invasion of Greece and Sardinia.
The body was dropped into the sea off the coast of Spain to be discovered by Spanish fishermen. The British were confident that the Franco regime in Spain would hand over the plans they’d discovered to the Germans.
They were right. And the Germans were suitably convinced by the deceit to move sizable military resources away from Sicily.
### Trust
Interpol defines social engineering in the following way:
Social engineering fraud is an extensive term that encompasses the tricks employed by criminals to exploit an individual’s trust, aiming to either directly obtain money or extract confidential information for future illegal activity. While social media is the favourite conduit, it’s not uncommon for these interactions to occur over the phone or face-to-face.
**“To exploit an individual’s trust.”**
This is the sad truth behind the psychology of social engineering attacks - they tend to prey on positive emotions. Though it might not always seem that way, we’re inclined to see the good in people most of the time and to act in a kind way towards others. That’s why you might have once held the door open for someone at your office building and only later wondered whether they actually worked there. Our instinctive reaction is to hold the door open before we begin to suspect the person walking behind us. This is something tailgaters are well aware of and their online equivalents are constantly looking to exploit it.
However it might happen, being tricked in the digital world is a massive problem on both a micro and macro level. For individuals it can cause savings that have taken years to accrue to disappear in seconds. And for the economy as a whole, the impact is shocking. Social engineering attacks have led to considerable monetary losses in the United States alone. In 2021, vishing attacks [resulted in approximately 30 billion USD in losses](https://earthweb.com/vishing-statistics/), and in 2023, business email compromises [had caused an astounding loss of 50 billion USD](https://www.ic3.gov/Media/Y2023/PSA230609). Various research studies and [reports](https://www.proofpoint.com/sites/default/files/threat-reports/Proofpoint_Threat_Research_Social_Engineering_Report_2022.pdf) categorise social engineering as an integral aspect of the majority of cyber attacks.
Much like the Greeks at Troy, modern social engineers often conceal their true intentions under the guise of presenting a gift. They use impersonation to exploit trust and other human emotions. They impersonate entities trusted by the victims - this could be their friend or bank - to dupe them into divulging confidential information, clicking on harmful links, or unwittingly installing malicious software. Much of the losses recorded in the US above are from victims’ bank accounts that they unwittingly allowed access to.
### Dmitry
At the beginning of the 17th century, False Dmitry I ruled Russia for nearly a year after successfully masquerading as the rightful heir to the throne. He’s the only Tsar to have risen to power after a military campaign or popular uprising.
False Dimitry’s reign occurred during a tumultuous era in Russia known as The Time of Troubles. He claimed to be Tsarevich Dmitry Ivanovich, the youngest son of Ivan the Terrible - a boy who had supposedly died in childhood under mysterious circumstances.
A man of uncertain origins, False Dmitry surfaced in the Polish-Lithuanian Commonwealth around 1603. He asserted that the child who had passed away was not the Tsarevich, but a stand-in. He claimed to be the true Tsarevich who had been spared and had been living under the radar for years and began his bid for the Russian throne, arguing he had been unjustly stripped of his birthright.
Endowed with powers of persuasion and a slight resemblance to the late prince, False Dmitry I managed to convince numerous influential Polish nobles and the Catholic Church of his legitimacy. His declared intention to convert to Catholicism, which would bolster Poland's sway over Orthodox Russia, also won him allies.
Equipped with Polish support and several thousand troops, he spearheaded a march on Russia. His assertion of being the legitimate Tsar resonated with many, allowing him to grow his forces still further. His charisma and reformist promises endeared him to the common folk and even some boyars (Russian nobles).
Upon reaching Moscow, he managed to capture the Kremlin and was inaugurated as Tsar Dmitry Ivanovich. As a skilled social engineer, False Dmitry manipulated his surroundings through the guise of a royal persona, exploited the political environment, and utilized charismatic persuasion to secure the throne.
### Engineering
The key to False Dimitry’s success - however short (his name hints at his legacy!) - is the period of chaos he lived through. Pseudo-Philip was able to secure the throne in Macedon in a similarly turbulent period nearly two millennia earlier.
This story, too, is reflected in the modern-day psychology of social engineering. Because attackers using these techniques tend to thrive in times of upheaval and uncertainty. Times when emotions run high and rational thinking is often forgotten in favour of impulsive reactions based on emotion.
This helps to explain why there was such a surge in social engineering attacks during the covid pandemic. Bad actors knew that people were more vulnerable and more open to advice from authorities than they’d been for a long time. The conditions, in other words, were just right for people to fall for bogus bank messages and texts telling them their parcel would be released **“if only they clicked on this link”**.
The most accomplished social engineers can do more than merely exploiting such conditions. They can orchestrate situations where rational thinking is undermined, goading individuals into relying on emotions rather than lucid, rational thought. They engineer circumstances where human intellect is superseded by emotions.
And if anything, this task is infinitely easier for the modern-day social engineer [because of the smartphone](https://licelus.com/insights/how-can-you-protect-yourself-from-social-engineering). It’s much easier to be tricked in a millisecond when you’re so used to reacting rapidly to notifications that ping almost ceaselessly on your device.
But don’t be fooled - the techniques attackers use are nothing new. The truth is they’ve been finely honed over thousands of years of history.
Check out our report into [the state of mobile app security](https://licelus.com/state-of-mobile-app-security) to understand how attackers exploit emotions in the digital world.
## iOS Security Vulnerabilities
[All insights](https://licelus.com/insights)
### Follow us
08 Aug 2023
### Investigating iOS security vulnerabilities
URL: https://licelus.com/insights/investigating-ios-security-vulnerabilities
# Investigating iOS security vulnerabilities
iOS is renowned for its robustness and its rigorous security measures. It's a closed ecosystem, with Apple strictly controlling both hardware and software. The upshot of this is a unique and comprehensive approach to security. And it means that iOS has traditionally provided a safer environment than other platforms due to its strict review process for apps and limitations on customizations.
But security isn't a state. It's a process. And there are no platforms - iOS included - that are invincible to sophisticated threats. There are iOS security vulnerabilities that need to be investigated.
And there might be more in the future, considering how quickly the threat landscape changes in the tech world. Take the recent news surrounding [Apple’s potential introduction of sideloading](https://licelus.com/insights/the-push-to-open-up-apple-s-walled-garden) - the ability to download and install applications outside of the App Store. This has also sparked a debate about the future sturdiness of iOS’ security.
Sideloading aside, insecure networks, OS vulnerabilities, reverse engineering, supply chain attacks, jailbreaks, and social engineering all have the potential to threaten the security of iOS apps.
There’s a tendency, though, for mobile app developers to spend less time and effort thinking about security for iOS apps than they do for Android equivalents. If anything, iOS’ reputation for security in recent years has caused some complacency.
The good news is that understanding these risks and applying best practices for mitigation can go a long way in safeguarding your applications and your data. After all, it's not just about having a secure platform. It’s also about how you, as an app developer or user, navigate within that platform.
In this article we’ll explore the major risks facing iOS apps and we’ll offer some practical strategies for how to keep them secure (and how to maintain the safety of your end users). So, whether you're a seasoned developer or an iOS user, read on.
### Exploring some iOS security vulnerabilities
**Insecure networks**
Even the most secure devices can be exposed to risks when connected to insecure networks.
**Public Wi-Fi networks, for example, are breeding grounds for malicious activities**. Cyber attackers often exploit these networks to intercept data transmission, gain unauthorized access to devices, or spread malware. The obvious risk here is the exposure of sensitive personal and business information.
[Mitigation strategies for network communications interception](https://licelus.com/resources/guide-to-mobile-application-protection/threats/network-communications-interception) include using VPNs to encrypt data transmission, and avoiding public Wi-Fi for sensitive operations and transactions. It’s also a good idea to leverage SSL Pinning and to regularly update iOS software to benefit from the latest security patches and updates from Apple.
**OS vulnerabilities**
No operating system, iOS included, is devoid of vulnerabilities. And weak spots in the software can be exploited by attackers to gain unauthorized access, disrupt operations, or even steal sensitive data.
For instance, in 2020, a vulnerability dubbed \" [MailDemon](https://wccftech.com/900-million-iphones-left-vulnerable-to-the-maildemon-security-flaw/?dark=1)\" was discovered in the default Mail app of iPhones that could allow remote code execution (RCE) upon the opening of malicious emails. Another vulnerability in the iOS platform allowed RCE in [IOSurfaceAccelerator and WebKit](https://www.securityweek.com/apple-ships-urgent-ios-patch-for-newly-exploited-zero-days/) and was exploited before Apple could release a patch for it.
OS vulnerabilities also do a good job of stripping iOS devices of the restrictions Apple imposes on them. Jailbreaking software intended to allow application side loading and unlocking other functionalities can only work via vulnerabilities discovered in the iOS. We’ll touch on jailbreaking a bit more later in this article.
If you’re an iOS app developer, you can minimize the impact of vulnerabilities like these from being exploited by [embracing zero-trust strategies](https://licelus.com/insights/what-is-zero-trust-application-security) for information security.
### Diving deeper into specific threats
##### **Reverse engineering**
Reverse engineering involves deconstructing a software program to understand its architecture, functionality, and potential vulnerabilities. When applied to iOS apps, this process can reveal proprietary algorithms, hidden features, and even potential weaknesses that can be exploited.
The traditional view is that iOS apps are much harder to reverse engineer than Android apps due to the usage of machine code instead of JVM bytecode - as well as other protection practices.
Let’s investigate this.
When a developer writes an iOS app, they write it in a high-level language like Swift or Objective-C. This code is then compiled into machine code that the device's processor can understand and is stored in the application binary. The binary itself is then encrypted using a symmetric encryption algorithm (AES) - a process that happens when the app is submitted to the App Store. This encrypted application binary is then hosted on Apple's App Store, and when a user downloads the app they download this encrypted version. The user installs and opens the app on their iOS device, and the system's kernel decrypts the application binary in memory. This decryption process uses a unique key that is generated and managed by the device's Secure Enclave - a hardware-based key manager which is isolated from the main processor to provide an extra layer of security. The decrypted code is stored in the device's memory, but it isn’t accessible for other processes or apps due to iOS' memory protection mechanisms. Each app runs in its own isolated space (known as a sandbox) and doesn't have access to other apps' data or code.
This fairly robust system helps to explain why iOS apps are seen as being more difficult to reverse engineer than their Android counterparts. But it isn’t enough to put off a skilled attacker.
With an understanding of the protection measures in place, a bad actor will look to employ counter strategies. The first step in cracking the code encryption of an iOS app often involves an attempt to jailbreak the device. **Jailbreaking removes the security restrictions imposed by iOS**, allowing the attacker to gain full control over the device's file system and execute any code that they like. **Once the device is jailbroken, attackers can use various [dynamic binary instrumentation tools](https://licelus.com/resources/guide-to-mobile-application-protection/threats/dynamic-analysis-and-tampering) to dump or extract the decrypted binary code of the app**. This is possible because, as we touched on earlier, the application binary gets decrypted in the memory when the app is running. Tools like \" [frida-ios-dump](https://github.com/AloneMonkey/frida-ios-dump)\" or \"Clutch\" can be used to dump the decrypted binary from memory. With the decrypted binary code in their hands, attackers can then proceed to reverse engineer the code. Tools like Hopper or IDA Pro can disassemble or decompile the binary into a human-readable form. And once the code is disassembled, [attackers can analyze it](https://www.corellium.com/blog/ios-mobile-reverse-engineering) to understand its operation, identify vulnerabilities, extract sensitive information (such as keys or passwords), or modify the code to alter the app's behavior.
If you’re a developer, you can safeguard your iOS apps from reverse engineering in a number of ways. **Integrating [code obfuscation](https://licelus.com/products/stringer-java-obfuscator) techniques is a good starting point as it makes your code harder to understand** and harder to reverse-engineer. And application shielding mechanisms can protect your app from tampering, cloning, and similar threats. You can find out more about the steps you can take to block these types of attacks with our [mobile app protection checklist](https://licelus.com/resources/guide-to-mobile-application-protection/practice/mobile-app-protection-checklist).
##### **Supply chain attacks**
Supply chain attacks happen when an attacker infiltrates your system via a third-party partner or provider who has access to your systems and data. The notorious SolarWinds attack in 2020 is a prime example of how damaging these attacks can be. While this type of attack isn’t as common for apps in the Apple ecosystem as it is for Android apps, that isn’t to say that supply chain attacks are impossible with iOS.
Let’s look at an example. Bad actors exploited the 'Run Script' feature in Apple's Xcode Integrated Development Environment (IDE). This clever manipulation targeted Apple Developers by sharing Xcode Projects. The malicious Xcode project, known as [XcodeSpy](https://www.sentinelone.com/labs/new-macos-malware-xcodespy-targets-xcode-developers-with-eggshell-backdoor/), works by subtly installing a custom variant of the EggShell backdoor on the developers' macOS computer, which is then entrenched through a persistence mechanism.
This backdoor isn't simply a passive observer. It actively records input from the victim's microphone, camera, and keyboard. And it has the capability to upload and download files. The unsettling truth is that the infection vector XcodeSpy uses could potentially be adopted by other malicious actors. As such, **we strongly recommend that iOS developers who frequently use Xcode remain vigilant when using shared Xcode projects**.
In an ideal world, you’d want to [apply robust security measures across your software supply chain](https://licelus.com/insights/how-to-stop-software-supply-chain-attacks). This includes thoroughly vetting third-party vendors, regularly reviewing and updating security protocols, and employing a robust system for managing and securing access controls. If you’re interested in learning more about this topic, we considered the security guidelines for various mobile technologies, including iOS native development, [in an earlier article](https://licelus.com/insights/mobile-app-development-frameworks-a-security-guide). It also covers supply chain threats and mitigation measures.
##### **Jailbreaking**
As we’ve said, jailbreaking an iOS device means freeing it from the restrictions imposed by Apple. **Jailbreaking enables users to install applications, extensions, and themes that aren't available through the official App Store**. The process takes advantage of certain iOS security vulnerabilities - be that software or hardware.
A popular example of a modern jailbreak framework is \"unc0ver.\" This semi-untethered jailbreak tool uses a variety of exploits in iOS to gain elevated privileges, and it supports a wide range of iPhone models and iOS versions.
From an end user's perspective, jailbreaking can appear attractive because it provides them with more freedom and customizability. Jailbreaking tools like unc0ver are designed to be user-friendly, often requiring little more than the tap of a button to perform the jailbreak.
But **jailbreaking an iOS device can carry significant risks**. As we mentioned earlier in this piece, iOS employs a security feature known as \"sandboxing\" by default. This isolates apps from each other and from the system itself. So, even if an app is compromised, the damage it can do is limited to that app alone. Jailbreaking removes this sandboxing, leaving the system vulnerable to malicious apps that can access data from other apps or even from the system.
Jailbreaking can’t work without using known iOS security vulnerabilities. When you jailbreak your device, you intentionally leave these vulnerabilities unpatched which could then be exploited by bad actors to install harmful software.
While the creators of jailbreaking tools generally aim to provide a safe and secure environment for their users, there's no guarantee that all jailbreaking software is benign. Some tools might come with [hidden malicious payloads](https://licelus.com/insights/how-bad-actors-deliver-mobile-malware-into-your-device) such as spyware or ransomware that could compromise your data or your device.
There are even examples of software that pretends to be a jailbreak tool but instead exploits the user. One of those is called [CheckRain](https://blog.talosintelligence.com/checkrain-click-fraud/): a website claiming to be a jailbreak tool but instead providing a malicious provisioning profile to perform click-fraud.
**Jailbreaking is strongly discouraged by Apple. It voids the device's warranty** and you lose access to Apple's support channels. Also, Apple's updates to its iOS can often render jailbroken devices inoperable, forcing users to choose between updating their software and maintaining their jailbreak.
As we’ve said many times before on this website and will continue to say, there’s often a conflict in the tech world between convenience and security. As a user, jailbreaking can bring you more freedom to use your device exactly as you’d like to. But at what cost?
##### **Social engineering**
Social engineering involves tricking users into divulging sensitive information or performing actions that compromise security. It's less about technological vulnerabilities and more about [exploiting human psychology](https://licelus.com/insights/the-psychology-of-social-engineering).
[Protecting against social engineering attacks](https://licelus.com/insights/how-can-you-protect-yourself-from-social-engineering) is a job for all of us. Developers can educate end users about threats within the app and via other trusted communication channels. And users can help stop social engineering from succeeding by being naturally suspicious. That means taking a moment to question unsolicited communications, and only sharing sensitive information when absolutely necessary (and through trusted channels.)
### The security journey
Keep in mind that while this overview of iOS security vulnerabilities and protection strategies is comprehensive, it's by no means exhaustive. The cybersecurity landscape is evolving at a rapid pace, so staying informed is the key to staying secure.
There's no room for complacency. Even for a robust and closed ecosystem like iOS, vulnerabilities exist and risks abound. But with the right understanding and vigilance, these can be effectively mitigated.
Remember, the role developers can play in maintaining application security cannot be overstated. As a developer, [your commitment to best practices and ongoing education](https://licelus.com/insights/ongoing-security-a-step-by-step-guide-to-a-secure-app-development-process) is the first and most important line of defense. But security is not a one-man job, as we know. It's a collective responsibility that involves users, developers, and the platform provider.
We're in this together, navigating a constantly evolving cybersecurity landscape. The risks will continue to change, and new threats will emerge. But with clarity, transparency, and a little bit of positivity, we can continue to foster a safer and more secure digital environment.
Whether you're looking to secure an iOS app or Android app, we've got you covered. Our handy [mobile app protection checklist](https://licelus.com/resources/guide-to-mobile-application-protection/practice/mobile-app-protection-checklist) is there to help you sense check that your application is as resilient as possible against a variety of attacks.
## Authenticator Apps Security
[All insights](https://licelus.com/insights)
12 Sep 2023
### Investigating the safety of MFA methods: are authenticator apps secure?
URL: https://licelus.com/insights/investigating-the-safety-of-mfa-methods-are-authenticator-apps-secure
# Investigating the safety of MFA methods: are authenticator apps secure?
Imagine you’re an employee of a software development company.
You log into an authentication provider like Okta and, after entering the login and password details, you get a push to your app to confirm the login. Then you open github and enter the one-time authentication code to access the repository you’re working with.
At the same time you decide to check your current bank balance. And so you open your mobile banking app which also requires a one-time password (OTP) to login.
As we continue to integrate technology into virtually every aspect of our daily lives, **the security of our digital data has become a critical concern**. From private email exchanges and social media accounts to sensitive banking and healthcare information, vast quantities of data are now stored online and so can be vulnerable to cyber threats.
One of the most prevalent threats we face today is phishing attacks. Every day, cybercriminals trick individuals into revealing sensitive information such as usernames and passwords - typically through bogus emails or text messages.
**Traditional security measures such as password protection are increasingly inadequate against these sophisticated attacks**. It's a well-known fact that many individuals use weak passwords or reuse them across multiple platforms. And this makes it much easier for attackers to compromise our defenses. In 2022, a study revealed that [82% of breaches involved a human element](https://www.cygenta.co.uk/post/the-human-element#:~:text=One%20headline%2Dgrabbing%20statistic%20this,when%20it%20was%20a%2085%25.&text=I%20presented%20at%20two%20conferences,of%20technology%20and%20business%20leaders.), such as falling for phishing scams or using weak passwords.
This alarming statistic helps to explain the move towards Multi-Factor Authentication (MFA), which adds an additional layer of security. **The idea behind MFA is a simple one: provide more than one form of verification to confirm the identity of the user**. This typically includes something the user knows (a password), something the user has (a mobile device or a hardware token), and something the user is (biometrics like fingerprints or facial recognition).
In this article we’ll take a look at the different types of MFA available and we’ll compare them from a security perspective. We’ll pose an important question: are authenticator apps secure? And we’ll explore how to keep authenticator apps safe to use as they evolve in the coming years.
### The current MFA state of play
Perhaps **the most common and widely-known method of MFA is SMS-based verification**. This is when a code is sent to the user's mobile device which they must then input to access their account. But this method, though popular, can be vulnerable to SIM swapping, and the 2FA codes can even be intercepted.
**Hardware tokens are another MFA method** where codes are generated that users can input to gain access. These tokens are separate physical devices and, while they're quite secure, they can be inconvenient due to the need to carry around an additional device.
**A more secure and convenient method is [authenticator apps](https://licelus.com/insights/investigating-the-safety-of-mfa-methods-are-authenticator-apps-secure)**. These are applications installed on a user's device that generate a code - often time-based - for the second factor authentication. Notable examples include Google Authenticator, Microsoft Authenticator, and Authy. The codes are generated within the app on the device itself and are not transmitted over the network, making them a safer choice for 2FA.
There is an important caveat and wider problem with MFA here, though:
**The original idea and assumption behind two-factor authentication was that users would never be logging in and receiving second factor codes on the same device**. So, if you were logging in via a web-interface, you’d receive a one-time code to your mobile device. For obvious reasons this makes the whole process much more secure (and helps to explain why hardware tokens on a separate physical device were seen as the safest option for a long time.)
But plenty of companies - including authentication software, banks, and even internet giants like Apple - break this rule.
Let’s go back to the example we asked you to imagine at the beginning of this piece. If you’re logging in to Okta from your mobile browser, you’ll most likely receive the OTP on your mobile device. Or, if you’re entering iCloud from a browser on your MacBook, it will send the OTP to the very same MacBook.
When you think about it, this makes 2FA useless if we judge it strictly based on its original purpose and intentions. If you’ll allow us to circle back to a rather common topic here at Licel (and one you’ll recognise if you’re a regular reader of our blogs) it’s almost as if convenience and security aren’t always the best bedfellows.
At the very least it’s something you should keep in mind while using 2FA apps.
### Security challenges facing SMS and hardware tokens
While two-factor authentication (2FA) offers a robust shield against security breaches, not all 2FA methods are created equal. Among the three most popular methods - SMS, hardware tokens, and authenticator apps - the first two face unique challenges that can potentially compromise the safety of user data.
Let’s start with SMS.
**SMS-based 2FA**
For lots of people, their only interaction with (and understanding of) MFA is SMS based. This makes sense given the simplicity of SMS and the global familiarity with it for the past two decades. Indeed, it’s this familiarity that presents the biggest challenge to alternative forms of MFA like authenticator apps.
After all, it’s quite an ask for people to switch from receiving a text message on a familiar and convenient channel. Especially when that channel might not even require any actions from the user given that many applications can extract the OTP from the SMS automatically.
SMS-based 2FA is certainly a more secure option than single-factor authentication. But it has several limitations.
Let’s start with the fact that a unique authentication code transmitted over a mobile network is susceptible to attacks:
**When codes are sent over the air, technically savvy hackers can employ techniques to intercept the messages and gain access to the authentication codes**. This can happen for example when a trojan is deployed to a mobile device and is programmed to intercept the code. This particular attack was highly popular in the earlier days of Android when the OS didn’t have the sophisticated permissions system it has today.
Nowadays, code interception still happens - but with different mechanisms. Instead of directly listening to SMS events, mobile malware [implements Accessibility APIs](https://hackmag.com/mobile/android-api-2/) and tricks users into allowing it. Once access is granted, the malware can scan input codes and intercept notifications which inevitably leads to stolen OTPs.
**Hackers can also manipulate the mobile service provider into transferring a user's phone number to a new SIM card owned by the attacker**. [Bad actors](https://licelus.com/insights/how-bad-actors-deliver-mobile-malware-into-your-device) might obtain a copy of the target user ID and claim the original sim was lost or malfunctioning. If successful, the attacker will receive all SMS messages intended for the victim, including 2FA codes.
Cybercriminals can also dupe users into revealing their 2FA codes via phishing attacks where [the attacker impersonates a trusted authority](https://licelus.com/insights/the-psychology-of-social-engineering) and persuades the victim to share their sensitive information. This kind of attack can happen to any of us at any time, so [we need to remain vigilant and suspicious at all times](https://licelus.com/insights/how-can-you-protect-yourself-from-social-engineering).
**Hardware tokens**
Hardware tokens are physical devices that generate 2FA codes. These tokens, while extremely secure, present unique challenges of their own.
Because they are physical objects, hardware tokens can be lost, stolen, or damaged. If a token falls into the wrong hands, then the owner’s accounts could potentially be at risk. Hardware tokens look like flash-drives after all; and we all know somebody who has lost one of those.
Then there’s the fact that having to carry an additional piece of hardware can be pretty inconvenient. Especially in an age when we’re so used to storing everything on our phones.
As we’ve hinted at already in this article, users will typically be attracted to the most convenient form of MFA. And so the inconvenience of hardware tokens can actually discourage users from setting up 2FA at all, creating associated security risks.
What’s more, hardware tokens can be expensive to produce and distribute, making them a less attainable option for many individual users and smaller organizations.
Imagine you’re the head of security at your company. It’s likely the idea of purchasing, configuring, and distributing thousands of tokens among employees and the associated costs and energy this entails might make you think twice about signing off on hardware tokens. And that’s before you get round to coming up with procedures for replacements.
Again, it's vital to find a 2FA method that offers a good balance between security and convenience.
And that's where authenticator apps come into play.
### Authenticator applications - the most modern MFA method
Authenticator apps appear to occupy the sweet spot [between security and user friendliness](https://licelus.com/insights/balancing-security-and-usability). And this helps to explain why they’ve emerged as the preferred option for many individuals and businesses.
**Functionality and usage of authenticator apps**
Authenticator apps work by generating time-sensitive, one-time-use codes on the user's device. After linking the app to your online accounts - typically done by scanning a QR code during the setup process - the app will produce a unique code every 30 seconds (or some other predetermined time interval) for each account.
To use the code, you simply open the app, find the code associated with the account you're trying to access, and enter it on the login page after inputting your password. Because these codes are generated on your device and expire after a short time, they offer a secure means of 2FA that is less susceptible to some of the common MFA attacks we’ve covered in this article (including interception and phishing.)
**The differences between authenticator apps and SMS based 2FA**
The primary difference between authenticator apps and SMS-based 2FA is in the delivery method of the codes. With authenticator apps, the codes are generated on the user's device, making them less vulnerable to interception or phishing attacks. In contrast, SMS-based 2FA codes are sent over the network, making them more susceptible to such threats.
Authenticator apps don't require a network connection to generate codes either, which makes them a more reliable choice in situations where network coverage is spotty or non-existent.
**The encryption behind 2FA codes**
Encryption plays a vital role in securing our digital lives. And it's at the core of how authenticator apps work, too.
Authenticator apps [generate 2FA codes](https://zserge.com/posts/one-time-passwords/) using specific algorithms, typically either the Time-Based One-Time Password (TOTP) algorithm or the HMAC-Based One-Time Password (HOTP) algorithm.
As the name suggests, TOTP generates a one-time password that is valid only for a short period of time - typically 30 seconds. It does this by combining a secret key with the current timestamp using a cryptographic hash function. The result is then typically truncated to a six-digit number.
The HMAC-Based One-Time Password algorithm also uses a secret key but combines it with a counter that increments with each new password. Like TOTP, the result is then truncated (usually to a six-digit number). The password remains valid until it's used, at which point the counter advances and a new password is required.
**An authenticator app’s encrypted communication with the server**
Consider the process of logging into an account protected by 2FA using an authenticator app.
You enter your username and password as usual and the server then asks for your 2FA code.
You open your authenticator app which uses the shared secret key and either the current timestamp (TOTP) or a counter (HOTP) to generate a code. Then you enter this code on the server.
And the server itself, having the same secret key and knowing the algorithm used, generates a code and compares it with the one you’ve inputted. If they match, the server grants you access.
### Are authenticator apps secure? Investigating some security challenges
Even with the added security of authenticator apps, it's crucial to understand that no system is entirely immune to threats. One challenge for some authenticator apps is the lack of encryption for stored secrets. If an attacker were able to access the device and the app's storage isn't encrypted, they could potentially extract the secret keys.
More secure authenticator apps address this by encrypting the stored secrets and making use of hardware enclaves where available. Hardware enclaves are secure areas of the processor where data can be stored and used but not extracted, offering an additional layer of security.
An authenticator app's primary function is to securely generate 2FA codes using a secret key. If an attacker were to steal the secret key, then they’d be able to generate their own valid codes, [which was demonstrated here](https://faui1-files.informatik.uni-erlangen.de/public/publications/Spreitzenbarth-Polleit-IMF-2018-Defeating_OTP.pdf).
So, secure storage of the secret keys and using encryption and hardware enclaves wherever possible is crucial for protecting against sophisticated threats.
Whether to trust a user's device to act as an authenticator or to use a separate hardware token like a FIDO or Google Titan key is another question. Smartphones are already a target due to the amount of personal data they hold - adding authenticator functionality only makes them more attractive to attackers.
Finally, if a device with an authenticator app is lost, stolen, or broken, users need a way to restore their secrets to a new device. Some authenticator apps offer a backup functionality, either by allowing the user to create a backup code during setup that can be used to restore the secrets, or by storing an encrypted backup in the cloud. But the backup process itself must be secured. If an attacker gained access to the backup, they could potentially restore the secrets to their own device instead.
### How users can help to make authenticator apps more secure
Keeping in mind the threats listed above, what can we do to ensure the security of authenticator apps?
Let’s take a look at a few approaches.
**Use strong, unique passwords for associated accounts**
Remember, an authenticator app is a second layer of security. The first layer, your password, should be as strong as possible. Use a unique password for each of your accounts and make sure it's long, complex, and includes a mix of letters, numbers, and symbols. Using a reputable password manager can make this process more manageable.
**Protecting the smartphone itself**
The device hosting your authenticator app should be protected with a strong lock mechanism. This could be a complex passcode, a pattern, or biometric security like a fingerprint or facial recognition. This step ensures that even if your device fell into the wrong hands, the perpetrator wouldn’t be able to access your authenticator app.
Also, your device should never be jailbroken or rooted. [This modification significantly increases the risk of data loss](https://licelus.com/insights/the-risks-of-letting-your-app-run-on-rooted-devices) and therefore rendering the 2FA protection obsolete.
**Don’t ignore software updates and patches**
Regularly updating your device's software is crucial for its security. Updates often include patches for known vulnerabilities that could be exploited by attackers. So, keeping your device up to date helps protect not only your authenticator app but all of the data on your device.
**Avoid downloading apps from untrusted sources**
Only download apps - including authenticator apps - from reputable sources like the Apple App Store or Google Play Store. Apps from other sources may not have undergone rigorous security checks and [could potentially contain malware](https://licelus.com/insights/how-bad-actors-deliver-mobile-malware-into-your-device) or other security threats.
**Encrypt sensitive data**
Encrypting sensitive data on your device provides an additional layer of security. If an attacker did gain access to your device, encryption would help to ensure they can't read your data. Some devices offer full-disk encryption, while others allow you to encrypt specific sets of data.
In the case of authenticator apps, choose an app that encrypts your secret keys, as discussed in the previous section of this article. This feature provides an extra layer of security and protects your 2FA codes even if your device is compromised.
By following these best practices, you can ensure your authenticator app serves its purpose - to add an extra, secure layer of protection to your online accounts.
### Advanced security measures for authenticator apps
Beyond the essential end user advice outlined above, there are more advanced measures you can take to increase the security of your authenticator app. These steps may require more technical expertise or additional resources, but they offer substantial benefits in terms of security.
**In addition to protecting your device with biometric security, you can also use biometric authentication to access your authenticator app**. This functionality provides an additional layer of security, ensuring that even if someone can unlock your device, they can't access your 2FA codes without your unique biometric data. Unfortunately, at the time of writing, the most popular 2FA apps like Google Authenticator do not leverage this practice.
**Secure backup of the secret keys used by your authenticator app is important**, too. This process involves creating encrypted backups of your secret keys, either locally or on cloud storage, using a process known as key vaulting. This is a common practice in cryptographic security, which allows for the encrypted storage of digital keys in a secure device known as a key vault. This approach can prevent attackers from obtaining your keys, even if they gain access to your backup files.
Taking advantage of [exploit mitigation techniques](https://developer.android.com/training/articles/security-tips) like Address Space Layout Randomization (ASLR) and Data Execution Prevention (DEP) can prevent common types of attacks that might compromise your device. The most advanced attacks exploit errors in the OS components in a way that would allow the malware to put some code into an executable area, which normally is not accessible to the program. ASLR and DEP features make it so the malicious code cannot be executed, preventing the exploit from working.
### Recovering from 2FA breaches
Even with advanced protection measures in place, it's a good idea to be prepared for the unfortunate eventuality that your authenticator app might be compromised. Recovery from such breaches requires swift action and an understanding of the technical nuances involved.
**Steps to take when an authenticator app is compromised**
As soon as you suspect your authenticator app might be compromised, your first step should be to change the passwords for all of your associated accounts. Then, access the security settings of your accounts and revoke the current 2FA method. This action will invalidate the secret keys in the compromised authenticator app.
After that, you should try to determine the nature of the breach. Did malware compromise your device? Was your physical device stolen? Depending on the situation, consider wiping your device and restoring from a secure backup or even opting for a complete factory reset.
Once you’ve made sure your device is secure, re-enable 2FA for your accounts. This time, consider using a different method or a more secure authenticator app if the breach resulted from app vulnerabilities.
Monitor your accounts for any unauthorized activities. Check logs and notifications for any sign of illicit access. This can include password changes, email modifications, or unauthorized transactions.
Where possible, enable email or SMS alerts for suspicious account activities. This measure ensures that you're notified quickly in the event of any future breaches.
**Dealing with account lockouts**
If you find yourself locked out of an account due to 2FA issues, take the following steps.
Reach out to the platform's support team immediately. Most services have a procedure to handle 2FA lockouts, and they'll guide you through the recovery process. Be ready to provide them with additional identity verification. This may include answering security questions, providing ID documentation, or confirming other personal details linked to your account. For platforms that support it, consider having a backup authentication method, such as an alternative email or phone number.
**The importance of recovery codes**
When you enable 2FA on Github, the platform will ask you to save the so-called recovery codes. They are typically a set of unique codes provided by the platform when you set up 2FA. Each code can be used once and provides a way to access your account if you lose access to your 2FA method. Store your recovery codes in a secure place. This might be a secure password manager, a bank safe deposit box, or another secure offline location.
If you lose access to your authenticator app or device, use one of the recovery codes to regain access to your account. Remember, each code is usable only once.
Understanding the steps required for recovery is just as vital as the initial setup of 2FA. Being prepared and knowing what to do can help reduce the impact of a breach and ensure the continuity of your digital security.
### The future of authenticator app security
As the cyber landscape continually evolves, so too must the technology underpinning our security tools. Authenticator apps, despite their present efficacy, will undeniably benefit from upcoming advancements in tech, especially from fields like machine learning.
First of all, future authenticator apps might leverage AI-driven behavioral analytics to offer more dynamic and adaptive security measures. By constantly learning from a user's typical behavior patterns, these apps could detect anomalies in real-time. For instance, if a 2FA request originated from a location or device the user has never accessed before, the system might trigger additional security challenges or temporarily block the request. [These tactics also apply in battling zero-day attacks.](https://licelus.com/insights/zero-day-attack-prevention-via-enhanced-mobile-app-security)
Machine learning algorithms could also be trained to detect emerging threats or vulnerabilities by analyzing vast datasets from across the web. For authenticator apps, this could mean pre-emptive measures taken before a known vulnerability is exploited.
One common critique of security tools is that they can sometimes impede user experience. AI can play a role in streamlining the 2FA process. For instance, an AI-based system might recognize that a user is trying to log in from their home on a previously authenticated device and might simplify or skip the 2FA step, whereas a login from an unknown device or location would still trigger the 2FA process.
At the same time, phishing remains one of the most significant threats to online security. Advanced ML algorithms can help in identifying and blocking phishing attempts in real-time. They can analyze patterns, domain names, and the content of web pages to determine if a user is being redirected to a fraudulent 2FA prompt.
In our increasingly digital world, the importance of robust online security cannot be overstated. Authenticator apps, as a cornerstone of multi-factor authentication, play a pivotal role in safeguarding our online activities. However, as cyber threats become more sophisticated, the tools we use must evolve in tandem.
The integration of AI and machine learning promises to propel authenticator apps to new heights. They offer the potential for these apps to not only react to threats but to proactively predict and counter them. Yet, it's crucial to remember that as we harness these advanced technologies, we must also ensure they remain secure and are used ethically.
In essence, the future of authenticator apps is not just about technological advancement but about balancing innovation with responsibility. It's a commitment to a safer online landscape, where users can enjoy both convenience and security.
Refer to our [guide to mobile application protection](https://licelus.com/resources/guide-to-mobile-application-protection) for all you need to know about how and why attackers target apps and what you can do to stop them succeeding.
## Social Engineering Principles
[All insights](https://licelus.com/insights)
### Follow us
12 Sep 2023
### The seven principles of social engineering
URL: https://licelus.com/insights/the-seven-principles-of-social-engineering
# The seven principles of social engineering
A principle is a fundamental truth, doctrine or law. It serves as the foundation for a system of belief or behaviour.
More than two thousand years ago, [the core principle of justice](https://www.scu.edu/ethics/ethics-resources/ethical-decision-making/justice-and-fairness/) was defined by Aristotle who asserted that “equals should be treated equally and unequals should be treated unequally.\"
A modern translation of this principle might read something like this:
You should treat individuals the same way unless they differ in ways that are relevant to their situation.
Like justice, social engineering, too, has its principles which have been followed since long before the days of Aristotle. For millennia people have used tricks to exploit others, influencing them to willingly give away something they possess.
As time passes and technology evolves, these tricks change shape and color somewhat. But the fundamental principles behind them stay the same as they ever were.
### Introducing the seven principles of social engineering
There are seven core principles of social engineering:
- Fear and anxiety will be abused
- Lust will be abused
- Shame or embarrassment will be abused
- Greed will be abused
- Curiosity will be abused
- Trust will be abused
- There is no absolute protection
As we covered in the previous article in this series, [the psychology of social engineering](https://licelus.com/insights/the-psychology-of-social-engineering) leans heavily on human emotions.
That has a lot to do with the fact that our emotions can provide us with an immediate response to stimuli. In that sense, emotions are the polar opposite to logical thinking which requires deliberate analysis and reasoning.
It’s this immediacy that can make emotional responses more influential in guiding our behaviour - especially in situations that require quick decisions. This is well-studied by Kahneman, Tversky and others in [dual process theory](https://en.wikipedia.org/wiki/Dual_process_theory).
Emotions are closely tied to our needs, desires, and values. They can serve as powerful motivators, pushing us towards - or pulling us away from - certain actions. The brain's emotional centres, like the amygdala, are deeply interconnected with other regions of the brain that govern survival instincts and basic functions. This connection may give emotions a more primal influence over our behaviour. For example, the fear of failure might drive someone to work harder, even though this fear might be completely irrational sometimes.
This power that emotions hold over us is a honey trap for modern-day social engineers. And if anything, the modern world has encouraged us to act even more emotionally and impulsively. In the space of a decade or two, our brains have evolved to the smartphone and social media, releasing dopamine when notifications tell us that others have liked our photos, have followed us, or have found us attractive. When one of these little boosts ping on our mobile devices, we often can’t resist the urge to reach for them at that very moment.
### 1. Fear and anxiety will be abused
Almost any form of fear or anxiety can be exploited. Consider the scam emails or text messages that warn you about a compromised password, urging you to click on a specific link. Think about those that falsely notify you that your bank card has been blocked.
A common fear in our age of economic instability is being made redundant. And this has led people to think more about their long-term security and pension payments. In the UK, pension scams [surged by 45%](https://maps.org.uk/2023/08/10/pension-scams-in-the-uk-evidence-review) in 2021 alone. Scammers will often entice individuals to transfer their pensions with the promise of implausibly high returns on foreign or alternative investments. They might also recommend a transfer to a scheme that isn’t in the client's best interest simply so that they can collect a fee. Bad actors sometimes even target victims of previous pension scams, offering to recover their lost funds (for a fee, of course.)
Social engineers sometimes pretend to be an employee’s boss, deceiving them into buying gift cards or transferring money from the company account. The greater the employee's anxiety, the more likely they are to comply with even the most absurd requests from their bogus boss.
A related form of exploitation is the fake job offer scam. When people are fearful of losing their job, they may start exploring other opportunities as a safety net. Scammers capitalise on this by posting seemingly legitimate job listings that are actually fake. Then they reveal that you can only apply for the role if you pay a fee.
Fear and anxiety can cloud rational judgement. These emotions can cause individuals to comply with the scammer’s demands without stepping back for a second and questioning their legitimacy.
### 2. Lust will be abused
Lust is a potent human emotion that social engineers and scammers know they can exploit easily.
It’s another example of an age-old exploitation principle that has gotten easier with the advent of technology like the smartphone.
The methods of exploitation are varied. Fake dating apps that offer in-app purchases to boost your chances of finding a match are one example. Then there are more explicit phishing emails promising to share photos of a [friend's girlfriend](https://www.bleepingcomputer.com/news/security/malware-spread-as-nude-extortion-pics-of-friends-girlfriend/) or a celebrity.
While most internet users might like to think of themselves as being far too savvy to fall for scams like these, this actually misses the point. Attackers only need a few of us to take the bait to make their social engineering campaign worthwhile.
### 3. Shame or embarrassment will be abused
Everyone has something to hide.
Shame is a very powerful emotion - one that attackers are constantly looking to exploit. [Sextortion scams](https://www.ncsc.gov.uk/guidance/sextortion-scams-how-to-protect-yourself) are a prime example of this. In these phishing attacks, individuals are typically coerced into paying a Bitcoin ransom under the threat of having sensitive, compromised videos of them exposed for the world to see.
The scam may be sophisticated, involving actual stolen photos or somebody’s browser history. But it’s just as likely to be a mass mailing effort where the hope is that some vulnerable people might fall for it. Once the emotion of shame is activated, rational thinking often takes a backseat.
### 4. Greed will be abused
At least a hundred years before the internet arrived and the infamous [Nigerian 419 email](https://en.wikipedia.org/wiki/Advance-fee_scam) scam emerged, there was a very similar con called “ [Spanish Prisoner](http://theappendix.net/issues/2013/10/proto-spam-spanish-prisoners-and-confidence-games)”. It exploited greed in just the same way the Nigerian email scam does. This acts as a useful reminder to us that while a lot of modern attacks feel very new, when you dig beneath the surface a little you begin to realize that it’s often only the delivery method that has changed over time.
Greed is a potent emotion characterised by an intense desire to acquire something - be it money or power. While the methods have evolved in the digital age (as highlighted above), the underlying principle remains the same. Scammers craft \"once-in-a-lifetime” opportunities, creating a sense of urgency and a fear of missing out in the recipients which compels them to take action.
Fraudsters promise a large sum of money in exchange for bank details, only to empty the victim's account. The scam often involves convincing the target that they’re entitled to money or winnings. The emotion of greed is thus triggered and a fee or personal details are requested to release the funds. As is often the case, emotion clouds rational judgement, making the social engineering attack successful.
### 5. Curiosity will be abused
Curiosity is another emotion that's easily exploited, with [clickbait](https://www.semrush.com/blog/what-is-clickbait/) being its most benign form. Companies use sensational headlines to drive traffic to their blogs or websites, costing the user nothing more than their time.
But more elaborate schemes can have serious consequences, as demonstrated by the [RSA hack](https://www.wired.com/story/the-full-story-of-the-stunning-rsa-hack-can-finally-be-told/). A meticulously crafted email titled \"2011 Recruitment Plan\" piqued an RSA employee's curiosity enough to retrieve it from the junk folder and open it. This action unleashed a virus that paved the way for a complex attack on the company's information systems. In just a few seconds, the power of emotion effectively sidelined rational thinking and led to one of the most infamous hacks of recent times.
### 6. Trust will be abused
As social creatures, humans have evolved to place significant emphasis on emotions in shaping social interactions and relationships. Emotional bonds, such as empathy, love, and trust, often wield more influence over our behaviour than logical reasoning.
Over the course of human evolution, the concept of a [social contract](https://ethicsunwrapped.utexas.edu/glossary/social-contract-theory) has also emerged. Initially, specialised roles like military service were established, followed by healthcare, law enforcement, and banking. Nowadays, even our private communications, personal photos, and digital assets are managed by external organisations rather than by ourselves.
This social contract is rooted in trust. We trust the police to maintain public order, we trust healthcare professionals to provide competent and ethical treatment, and we trust banks to safeguard our finances.
Abusing this trust is a go-to principle of social engineering. And it’s made much easier for the attacker because so many of these social contracts are realized on our mobile devices.
Here are some examples of scammers pretending to be in positions of authority and so benefitting from the trust people tend to have in them:
**Tax scams**:
Scammers have been known to impersonate tax authorities like HM Revenue & Customs (HMRC) in the UK. They contact victims through phone calls, SMS, or emails, demanding immediate payment for alleged unpaid taxes and threatening legal action.
**Tech support scams**
Here, scammers pretend to be from reputable tech companies and claim the victim's computer has a virus or some other kind of security issue. They may request remote access to the computer, which can lead to the theft of personal information or financial loss.
**Law enforcement impersonation**
Some scammers pretend to be police officers or other law enforcement officials. They then use this fake position of authority to extort money, claiming that the victim is under investigation or has outstanding fines to pay.
**Banking Scams**
Impersonation of banking officials is also common. Scammers may claim to be from a bank's fraud department and ask for sensitive information to gain access to bank accounts.
**COVID-19 Related Scams**
During the COVID-19 pandemic, there were reports of scams involving impersonation of health authorities or government officials. They offered false information like bogus, malicious links to book a vaccine, or solicited payments for vaccines and tests.
Trust is often more emotional than rational. We don't fully understand the intricacies of medical treatments or the complex systems banks use to secure our finances. We essentially take a leap of faith, because every time trust is embraced, there’s also an underlying fear of betrayal.
### 7. There is no absolute protection
We interact with authorities and companies via a myriad of channels, including mobile apps, text messages, websites, emails, calls, notifications, physical mail, and even video calls. This multitude of mediums creates a complex landscape, and one that can be easily exploited by attackers.
In the modern world there’s an unwritten rule to many of the social contracts that we sign; we often trade freedoms for convenience. We use social networks to keep in touch with friends but acknowledge that in return our digital habits are used for advertising purposes. We book restaurants and travel arrangements online, store our photos in the cloud, and rely on GPS-enabled navigation systems to get around. And we know that by doing so we’re placing our trust in service providers to respect and protect our privacy.
The truth is that most people aren’t aware of how the technology behind communication mediums and services actually works. The tech is continually evolving, and it's often difficult for the masses to keep up. As Arthur C. Clarke famously said, “any sufficiently advanced technology is indistinguishable from magic.”
It's impossible to control or understand every aspect of our technological world. And the mystery is often by design - no bank or social network would allow you insight into how things work inside their systems. But it’s also unrealistic for most of us to abandon our digital lifestyle and live off-grid.
So, what’s the answer?
It’s up to all of us to be aware of these seven principles of social engineering and make sure we have empathy for other people living under their rule. That means if you’re a user of mobile apps, email, and SMS, make sure to take a second to step back and analyze the message you’ve just received - however contrary to the modern world that might feel.
If you’re a software engineer, make sure you have empathy for those who will be using your application while you develop it. And make sure you do your bit when communicating with your users to make things clearer for them. That way they can distinguish your messages from the fake ones.
In the last decade or so the mobile phone has transformed from a communication device into a device for everything. And this has had a massive impact on the ease with which bad actors can scam and trick us. Find out more about how the modern world has made social engineering more menacing in our [state of mobile app security report](https://licelus.com/state-of-mobile-app-security).
31 Oct 2023
### Creating a company culture for security
URL: https://licelus.com/insights/creating-a-company-culture-for-security
# Creating a company culture for security
A company’s culture goes far beyond what's outlined in a job description. It encapsulates the foundational principles and practices upon which a business operates.
The cultural characteristics of an organization can even shape its cybersecurity resilience.
After all, in the digital age security isn’t determined by technological fortifications alone. Social engineering attacks that prey on human emotions remain a top cause of security breaches.
And so beyond firewalls and encryption, the very culture of an organization can play a key role in reducing vulnerabilities. From the way employees communicate with one another to the rigidity of company security policies, the internal dynamics of a business can either fortify its defences or expose it to breaches.
In the following paragraphs we’ll delve into the importance of **creating a company culture for security**. We’ll do this by exploring how various negative cultural norms can undermine an organization's ability to stop sophisticated cyber threats.
### Team silos
Humans have an inherent tendency to categorise, which can lead to phenomena like [ingroup favouritism and outgroup prejudice](https://opentextbc.ca/socialpsychology/chapter/ingroup-favoritism-and-prejudice/).
In companies where departments are separated based on specializations, this natural inclination is encouraged and amplified.
The result? Reduced inter-departmental communication.
Employees become less inclined to engage with (or seek assistance from) those outside their immediate department.
This lack of communication often means employees remain unfamiliar with their colleagues in other departments. And this detachment fosters information silos where knowledge about one department's operations and expertise remains confined within its boundaries. This workplace environment is ripe for exploitation by social engineers. In fact, if you asked one how they’d want their target company to be set up, they’d describe silos just like these.
Let’s look at an example scenario:
An attacker decides to impersonate a member of a bank’s legal team and requests IT access. In this scenario within a company operating in departmental silos, the target IT personnel could be unfamiliar with anyone from the legal team due to the absence of relational communication. As such they’d probably lack understanding of the legal team's functions, boundaries, and responsibilities. What type of questions might they realistically ask them? The IT team might even be hesitant to verify the legitimacy of the request with someone within the legal team, influenced as they are by outgroup prejudice.
**“Who’d want to talk to those slackers in suits, anyway?”**
A more generalised team structure, where knowledge is diverse (and shared) can significantly reduce the risk of such breaches. Remember, [security is everybody's responsibility](https://licelus.com/security-by-design/responsibility) and the best way to make people feel empowered is to encourage clear communications among employees.
This is true within a single team as well as across departments. Engineers who operate in silos, focusing only on their small facet of the application they’re developing, might miss some crucial contextual information needed to adequately secure the app they're working on.
We’re living in a world where it’s normal to split employees up based on areas of expertize [without fully considering the potential drawbacks of doing so](https://www.amazon.com/Range-Generalists-Triumph-Specialized-World-ebook/dp/B07M6QPRRG/). Clearly, it makes sense to do this to some extent, but there is a certain irony in attempting to counteract the resulting fragmentation with superficial solutions like corporate parties rather than addressing the root cause of the issue.
So, our first tip for creating a company culture for security is to be wary of silos and to encourage empathy and understanding both within and across departments.
### Command and control
Many corporate environments operate under the \" [disagree but commit anyway](https://medium.com/blablacar/the-superpower-of-the-disagree-and-commit-culture-c7085956bde0)\" ethos, which is itself a derivative of the military's \"command and control\" principle. While this approach may streamline decision-making (and be perfectly viable in a military environment), it’s less well suited to modern organizations.
Not least because this approach often stifles open dialogue and questioning. Employees learn they simply have to execute orders without asking questions if they want to progress. Even if they have concerns or reservations.
Again, this culture can be fertile ground for social engineers to succeed.
By impersonating your boss, they know they can potentially manipulate your entire department. Employees conditioned to complying without asking questions then become vulnerable targets.
We wrote recently about [how social engineers can manipulate feelings of fear or anxiety](https://licelus.com/insights/the-seven-principles-of-social-engineering). And one very prevalent example of this is the concern over losing one's job - something which has provoked a sense of insecurity among many workers. By the end of September 2023, [more than 170,000 US-based tech employees had lost their jobs this year alone](https://news.crunchbase.com/startups/tech-layoffs/).
Research indicates that the impact of these layoffs is not limited to those who lose their jobs. Both those laid off and the survivors often experience diminished motivation and trust towards their employers. Many report feelings of anxiety or depression. [And 65% of those who remain report feeling overburdened](https://www.bizreport.com/layoff-aftermath-survey-2022/) [.](https://www.bizreport.com/layoff-aftermath-survey-2022/)
It turns out this cocktail of reduced motivation, increased workload, and the looming threat of job loss has significant implications for cybersecurity threats. Employees, feeling like expendable parts in a corporate machine, might either become susceptible to boss impersonation attacks due to their fear of the repercussions of inaction, or they become apathetic towards the organisation's security altogether.
In other words, when employees perceive themselves as easily-replaceable cogs in a machine, they can be much more susceptible to social engineering tactics. So, fostering a culture where employees feel empowered to share ideas and not just do as they’re told can aid your company’s security posture.
### Blame culture
A pervasive cultural trait that exacerbates the fear of job loss is the blame culture.
In many organizations, when things go wrong the immediate response is to find someone to hold accountable. But humans make mistakes and, while the risk of errors can be minimised, it cannot be removed entirely. The focus ideally should be on mitigating the impact of these mistakes rather than pointing fingers afterwards.
Historical events underscore the dangers of adhering to a blame culture. The Chernobyl meltdown in 1986 serves as a stark reminder. The catastrophe's aftermath was made worse [by the reluctance of officials to admit the severity of the situation](https://www.history.com/news/chernobyl-disaster-coverup). Their fear of being held responsible and potentially losing their jobs was placed above other considerations. This flawed mentality led to delays in addressing the crisis, increasing the disaster's human toll.
A more contemporary, cybersecurity-focused example is the 2016 Uber data breach. The company's then-security chief, Joseph Sullivan, [opted to conceal the breach and pay hackers the ransom they demanded](https://www.bbc.com/news/technology-65497186#). This decision, likely driven by the fear of being blamed for the security lapse, resulted in legal repercussions for Sullivan and a hefty $148M settlement for Uber.
In a company where a culture of blame prevails, an employee might hesitate to confess that they accessed a harmful file leading to a computer infection. This is a big problem, because detecting the attack promptly can help in reducing its overall impact.
For social engineers, a company beset by blame culture is akin to a goldmine. By crafting threats or manipulative requests that prey on an employee's fear of being blamed, they can coerce compliance. A seasoned social engineer might even gather intelligence on an employee's past errors, leveraging this information to craft a very persuasive attack.
For the reasons above, you should do everything you can to encourage a more open and transparent culture in your own organization.
### Micromanagement
Micromanagement, while distinct, shares similarities with the \"command and control\" approach.
Many companies elevate individuals to managerial roles who may not be equipped to handle the complexities of leadership. These managers, often overwhelmed by the intricacies of their roles, sometimes resort to exerting excessive control over their teams, focusing on the minutiae of daily operations. This approach to management is called micromanagement.
Esteemed thinkers and authors, ranging from Drucker and Ackoff to McGregor and Deming, [have labelled micromanagement as a detrimental force in the workplace](https://journals.sagepub.com/doi/abs/10.1177/009102601003900105). Their consensus is clear: micromanagement stifles employee motivation and initiative. When constantly monitored and dictated to, employees become conditioned to act only upon explicit instructions. They refrain from independent decision-making, even in situations that demand it.
In the realm of security, this conditioned passivity can be very dangerous. If employees encounter anomalies or potential threats that aren't covered by company security policies, they might choose inaction over initiative. Given that timely responses are crucial in mitigating many security threats, such hesitancy can make vulnerabilities more severe. In a micromanaged environment, employees might delay action, waiting for directives, thereby leaving the organisation exposed.
So, while micromanagement offers managers an illusion of control, it can actually weaken an organization's security posture by suppressing employee initiative.
### Excessive competition
A widespread feature of many corporate cultures is the promotion of individual or team competition, often manifested through performance reviews. [Despite some within management science highlighting the adverse effects of such practices](https://deming.org/dr-deming-called-for-the-elimination-of-the-annual-performance-appraisal/), they remain widespread.
In environments that foster competitiveness, employees or entire teams often feel isolated. They operate under the perception that their success comes at the expense of their peers. This mindset can be detrimental, especially in areas like IT security where collaboration is crucial.
[Research indicates that competition can stifle collaboration](https://journals.sagepub.com/doi/10.1177/105960118801300303). In the realm of cybersecurity, open communication is vital. Employees should be encouraged to share observations of potential threats, seek clarity on ambiguous communications, and admit mistakes without fear of judgement. However, in a competitive setting, the fear of appearing less sure than your peers can deter such transparency.
Furthermore, an overly-competitive culture can foster the same departmental silos we covered at the beginning of this article. Teams, driven by the desire to outperform others, may subconsciously (or consciously!) withhold information or fail to communicate in an effective or timely manner. Such fragmentation presents opportunities for malicious actors, who can exploit this lack of cohesion and unity within the target organization.
### A lack of training
A prevailing misconception in many corporate circles is that security, much like quality, is a matter of control rather than assurance. But drawing parallels with quality assurance, which proactively ensures products meet set standards, security assurance should similarly adopt a proactive stance. Merely reacting to breaches as they occur can be costly.
Social engineering [relies on exploiting human psychology](https://licelus.com/insights/the-psychology-of-social-engineering). Given its evolving nature, staying ahead requires consistent updates about risks and a certain adaptability. [Research underscores the importance of regular, up-to-date training](https://www.researchgate.net/publication/343451031_How_effective_are_social_engineering_interventions_A_meta-analysis) as a primary defence against such attacks. It's not enough to only incorporate training during onboarding; periodic security interventions are crucial to reinforce the message and enable employees to practice their acquired skills.
Beyond formal training sessions, cultivating a pervasive company culture for security is essential. This entails transcending the notion that security is the purview of the IT department alone. Instead, it should be woven into the very fabric of company culture. When employees across hierarchies know the significance of security and are armed with the knowledge they need, the business’s collective resilience is improved.
This links nicely to another cultural facet that can compromise your company’s security if you’re not careful: employee overload. The effectiveness of training diminishes if your employees are too time-constrained or exhausted to see threats emerging on the horizon.
### Employee overload
When people are burned out, their attention to detail, productivity, and overall quality of work is negatively impacted. The stresses stemming from work overload can also [cause them significant health issues](https://www.sciencedaily.com/releases/2016/01/160121121818.htm).
There are a variety of cybersecurity implications, too. Overburdened employees, in their haste, might inadvertently bypass crucial security steps, neglect the smaller details, or unknowingly overlook things. This can manifest itself in a number of ways, from failing to recognize the signs of a security breach to inadvertently introducing vulnerabilities - say by clicking on a bogus link that at a first tired glance appeared to be a genuine, urgent request.
Overloaded employees might not prioritise security protocols such as timely password updates. Even if they participate in security training, their engagement might be limited, leading to gaps in their understanding. The quest for efficiency might drive them to adopt shortcuts, potentially compromising security. Examples include resorting to unsecured personal devices for work-related tasks or employing unauthorised software tools.
Employees aren’t always vigilant or alert to unusual activities when burned out. And this makes it easier for malicious actors to operate undetected. Tired employees might also be less invested in the company's security wellbeing as much as usual, leading to a more lax attitude towards security.
### A lack of transparency
Humans possess an intrinsic need to bridge gaps in their understanding - a phenomenon formulated in the \" [information gap theory](https://www.cmu.edu/dietrich/sds/docs/golman/Information-Gap%20Theory%202016.pdf)\". This theory posits that when individuals see a void in their knowledge, they develop a sense of deprivation which forces them to seek out that information. Essentially, a deficit of information gives birth to curiosity.
Decent security training can certainly help employees realise that downloading and executing “Britney-Spears-naked-photoes.exe” from a random email might start an attack.
Such training acts as a safeguard, reducing the potential for external attacks that prey on human curiosity towards the outer world.
But no training can prevent people from being curious about what the [recruitment plan will be for the next year](https://www.wired.com/story/the-full-story-of-the-stunning-rsa-hack-can-finally-be-told/) or what promotions are possible. This information is directly related to work itself, encompassing activities like problem solving, research, innovation, and creative thinking. All of which inherently rely on curiosity as a driving mechanism. Suppressing this curiosity is counterproductive as it potentially stifles the very essence of intellectual work.
A better strategy to mitigate curiosity-driven vulnerabilities is to enhance information transparency to the highest possible degree. Some companies have even ventured into making almost all internal details, [including salaries](https://www.gamesindustry.biz/what-is-an-open-salary-policy-and-should-you-consider-having-one), accessible to everybody.
While complete transparency like this might remain an aspirational ideal or perhaps even not advisable for your organization - [as studies from sources like HBR suggest might be the case](https://hbr.org/2023/02/research-the-complicated-effects-of-pay-transparency) - it's important to embrace some form of transparency. It’s about striking the right balance.
By demystifying certain aspects of the organisation and making information as accessible as practically possible, you can potentially reduce curiosity-driven vulnerabilities.
### Conservatism
Conservatism signifies a resistance to change. A desire to maintain the status quo irrespective of external changes. The inability to adapt and evolve in response to market dynamics has been the downfall of many companies, with [Kodak's story](https://startuptalky.com/kodak-bankruptcy-case-study/) serving as a particularly effective example.
Conservative culture can manifest in various ways, from an inability to pivot in response to market changes to an overemphasis on setting rigid rules and routines in the pursuit of perpetual efficiency.
Consider a company that wholeheartedly adopts Scrum, mandating all its teams to adhere to the framework. Scrum masters, following the Scrum guide, ensure the preservation of the process. This rigid adherence can be the first step towards conservatism, where established processes become sacred and immune to criticism.
Questions like, \"Does security testing fit in this sprint?\" might arise, but the ritualistic following of the process will prevent much discussion or change.
So, how can this have an impact on security?
A company can become predictable. The repetitive nature of its practices can make life easier for would-be attackers.
There can also be a lack of critical thinking. Employees might cease to question or critically assess ritualistic processes, adhering to them without understanding or questioning the underlying rationale for adopting them in the first place. This lack of understanding can make them more vulnerable to outside manipulation.
Then there’s an overall resistance to change. Even when security vulnerabilities are identified, conservative companies might resist modifying their age-old processes - something that perpetuates security weaknesses.
Finally, there’s complacency. A false sense of security can sometimes emerge, where employees believe that merely following the established \"ritual\" ensures safety. And so they overlook emerging threats.
Conservatism can also often lead to a lack of training. After all, if everyone believes that the established routines are sufficient and effective, why change them?
### Build a company culture that's resistant to emotional manipulation
As we navigate the landscape of cybersecurity, it becomes evident that humans remain the primary victim for social engineering attacks. As highlighted in our previous article, \" [the seven principles of social engineering](https://licelus.com/insights/the-seven-principles-of-social-engineering)\", many human emotions are susceptible to exploitation. These emotions, while integral to our human experience, can inadvertently become gaps in our collective armour.
While emotions serve as vital catalysts driving our motivation and responses to various stimuli, they cannot - and should not - be suppressed. Instead, it’s vital to design our structures and work processes in such a way that they reduce the likelihood of attackers exploiting emotions such as fear.
The realm of organizational psychology offers invaluable insights into the genesis and influence of these emotions. By delving into the disciplines of management and psychology, we can better understand and design our systems to be more resilient against potential threats.
But it's vital to understand that the task of system design is not a one-off endeavour.
In a world characterized by rapid and relentless change, attackers often adapt faster than their targets do. The recent shift to remote working, propelled by the covid pandemic, has expanded the potential attack surface with malicious entities exploiting digital communication channels.
To safeguard against such evolving threats, it's crucial to constantly reassess and recalibrate our organizational practices.
That way we can make sure they align with the ever-changing dynamics of the digital age.
[Find out more about the history and psychology of social engineering.](https://licelus.com/insights/the-psychology-of-social-engineering)
## Boost Social Engineering Awareness
[All insights](https://licelus.com/insights)
### Follow us
21 Nov 2023
### How to boost your social engineering awareness
URL: https://licelus.com/insights/how-to-boost-your-social-engineering-awareness
# How to boost your social engineering awareness
### Isolation isn’t the answer
Humans are social beings. We can't hide from society and so we can't hide from **social engineering**.
Some analysts, commentators, and futurists have wondered whether the often-frightening direction of travel - increasingly-sophisticated cyber crime, deep fakes, and so on - might compel some of us to seek a life off grid.
But the inherent social nature of human beings makes complete isolation an impractical protective measure. After all, even living off grid requires some degree of digital interaction if you’re to live legally as a recognized citizen of a nation state.
Then there’s the negative impact of living alone away from the vast digital network that defines the modern world.
Social isolation isn’t just hard work; it's also a risk factor for early mortality. Social isolation and a lack of societal relationships have been linked with a 26% increased risk of premature death, [according to empirical evidence](https://journals.sagepub.com/doi/abs/10.1177/1745691614568352).
Surely it’s better, then, given our need for social connectedness, to navigate the complexities of the modern world - including the [risks associated with social engineering](https://licelus.com/insights/the-psychology-of-social-engineering) - rather than charting a course to some dark corner where we don’t need to engage with it.
### Information overload
Still, we can do this at the same time as recognizing that societal complexity is growing at an exponential rate. Professions appear and disappear with alarming frequency. Technologies emerge and then become outdated within years. New services quickly become commoditized. And even movies, jokes, and memes can become obsolete in just a few weeks.
We’re living in a world where a lack of awareness about current affairs can isolate us from everyday social interactions. The fear of being left behind - and therefore being left alone - drives our need to stay abreast of progress.
Thanks to technological advancements, we can now satisfy our craving for information with a few swipes of our fingertips. We follow the news, engage on social networks, watch and listen to various media, and even share our emotional reactions such as rage and pity.
All of it in the moment, as it happens.
But it’s perhaps unsurprising that behaving this way can result in a constant state of information overload and even stress.
This is important when viewed through the prism of cybersecurity too, because information overload and short dopamine cycles impair our critical thinking and [decision-making](https://pubmed.ncbi.nlm.nih.gov/34744601/). And as a result we can become [more susceptible to misinformation](https://www.scientificamerican.com/article/information-overload-helps-fake-news-spread-and-social-media-knows-it/) and social engineering attacks.
So, while social networks offer us an easy way to connect, talk, and share with one another, they also pose [an additional risk for scams to succeed](https://www.researchgate.net/publication/319259856_An_empirical_study_on_the_susceptibility_to_social_engineering_in_social_networking_sites_the_case_of_Facebook).
### Remember to breathe
Information hygiene can be maintained by carefully choosing the sources you read and by limiting the information flow. Make sure you rest properly to enhance your cognitive functions and critical thinking skills. If possible, limit the number of devices and information channels you use to minimise your potential exposure to social engineering attacks.
The first step in maintaining information hygiene is to reduce information overload. And one way of achieving this is by limiting constant news consumption on your smartphone and reducing social network usage.
OK, we know what you’re thinking. The idea of reducing social network usage might sound almost as extreme as embracing a life off grid. But the negative impact of high levels of social media usage on information hygiene is undeniable.
As with almost everything in the digital world, it’s about finding the right balance.
After all, changing habits can be challenging because it often necessitates significant alterations to your lifestyle and, by extension, your personality.
Imagine you decided to train for a marathon. You’d need to modify your diet, exercise, and sleeping habits. You’d essentially be aligning all of your activities with a singular goal. Achieving such a transformation isn’t easy.
But there is help available. Popular phone operating systems offer built-in features to monitor screen time. You could use this data to review your social network usage on a weekly basis. From there, you might decide to set a maximum screen time limit that is realistic and works for you.
Some people are even committing to specific 'digital detox' rituals with a partner, friend, or loved one. They might meet for phone-free lunches or even take a week-long vacation without TV, phones, and laptops.
This advice is scientifically grounded, and following it should enhance your vigilance, thereby increasing your social engineering awareness skills.
There is a caveat, though. Even those who are well versed when it comes to the [nature of social engineering](https://licelus.com/insights/ai-and-social-engineering) attacks aren’t immune to falling for scams. In some cases, confidence can actually result in a false sense of security, making people more vulnerable to attacks.
The underlying reason, once again, is straightforward: we are emotional beings. [Emotions are a common vector for exploitation in social engineering attacks](https://licelus.com/insights/the-seven-principles-of-social-engineering). And it’s unrealistic to think we can guard against emotional exploitation completely as this would mean severing our emotional responses altogether.
Still, gaining awareness of impulsive feelings and reactions and learning how to control impulses can provide us with a degree of protection. Some people swear by the benefits of regular mindfulness practice to help them be more present and aware of what is happening around them.
### Put an action plan in place
The following advice might seem a little extreme, but it’s important to keep in mind that some of us are more anxious than others about the dangers of the digital world. And so for some people an action plan that they can refer to when faced with potential scams is required.
It’s a fact that day-to-day training exercises, akin to fire drills, can prepare us for emergencies. Despite our self-perception as rational beings, we often act impulsively or behave irrationally in critical situations - a notion for which Daniel Kahneman won a Nobel Prize in his [System 1/System 2 theory](https://www.scientificamerican.com/article/kahneman-excerpt-thinking-fast-and-slow/).
A prepared, preemptive action plan can therefore be invaluable in emotionally-charged or high-stress situations, making it easier for you to stick to a rational course of action.
So, how might this work in practice?
Imagine you receive a seemingly urgent phone call, text message, or email, and your reaction, subconsciously encouraged by a decade or more of instant online behavior, is to respond immediately. It might be helpful to leave a little note somewhere that is easy to find (on your fridge, perhaps) reminding you to take a breath in such a scenario.
The note might remind you that if an urgent phone call makes you suspicious, you can always hang up and call the organization yourself to verify the legitimacy of the request.
The same is true of the urgent text or email. You can call the company or visit their website and try to get an answer there. Often scammers will include a malicious link in a text or email, hoping that you might click on it without thinking. So, be very careful and see if you can access the link yourself from the company’s website.
A basic checklist can help [protect](https://licelus.com/insights/how-can-you-protect-yourself-from-social-engineering) you from attacks that seek to exploit a sense of urgency, fear, or anxiety.
**Stop for a second and think**: who will benefit from this request, and how? What actions do I need to take? Why do I need to take them at all?
**Consult with others:** validate your thoughts with a friend or loved one. Two minds are often better than one, and [teams actually make you smarter](https://pubsonline.informs.org/doi/abs/10.1287/mnsc.1120.1668?casa_token=-UfEpKBtxmMAAAAA:bWAXEWpA1Ju2niKyiwT0oiVI0q0yALYpdujj1TUzTJjyY2pApn1ih6Xh4hJBV_yLxUb0_qtzOA).
**Verify the information:** do a Google search, call the company, email them, or even visit their physical store in person and talk with somebody there. It’s far more difficult for a social engineer to impersonate an employee in person.
### Spreading social engineering awareness
It’s important to note here that you can just as easily be targeted by social engineering scams at the office as you can be at home.
We recently wrote an article about some [common workplace cultural norms that can make it more likely that social engineering attacks succeed](https://licelus.com/insights/creating-a-company-culture-for-security). Please take a read so you’re aware of some common pitfalls to avoid.
And remember that though it might not feel like it sometimes, in reality there are only a few types of jobs that truly require immediate action. They include those in the medical profession, the army, the police, and firefighting. Each of these have secure protocols for immediate action which are well regulated. Chances are that you don’t work in one of these professions and the requests you receive aren’t quite as urgent as they might appear to be in the moment. So, try to act rationally rather than impulsively.
By spreading **social engineering awareness** you can also help others to stay protected. As with physical crimes, a well-informed and vigilant community can be a crucial deterrent - particularly in stopping mass attacks.
You could set up training sessions for friends and relatives who might be less knowledgeable about the threats that lurk in the digital world. Even if you are tech-savvy and well-versed in social engineering tactics, many around you may not be.
If you feel able to do so, you might engage with elderly people in your community, helping them to recognize the risks more readily and providing them with basic training.
[The principles of protection against social engineering](https://licelus.com/insights/the-seven-principles-of-social-engineering) attacks are simple. Follow them and you can help to make the digital world a little bit safer:
- Know you will be attacked
- Reduce your information overload
- Think before acting
- Create an action plan
- Spread the word
Find out the seven principles of social engineering.
[Read the article](https://licelus.com/insights/the-seven-principles-of-social-engineering)
## Threat Intelligence Synergy
[All insights](https://licelus.com/insights)
### Follow us
21 Nov 2023
### The interplay between threat intelligence and fraud scoring systems
URL: https://licelus.com/insights/the-interplay-between-threat-intelligence-and-fraud-scoring-systems
# The interplay between threat intelligence and fraud scoring systems
Imagine you’re ordering a taxi in a ride-hailing app like Uber or Bolt.
You choose the pick-up location, your destination, the ride category, and you confirm your payment method. All being well, you get assigned a driver in seconds.
What is hidden from view are all the security checks, [threat intelligence](https://licelus.com/products/alice-threat-intelligence) and **fraud scoring systems** that whirr into action in the background.
The app itself checks its integrity. At the same time, the fraud system validates the payment method via authorization as well as your ride history and contextual information such as location, price and other parameters. This is necessary because for the ride-hailing company all sorts of threats are present at the moment of ordering a ride. And they have a big responsibility to prevent fraud, stay secure as a company, and make the ride itself as safe as possible for both the driver and the rider.
In today's rapidly-evolving mobile ecosystem, security isn’t just a nice to have. It's a critical component that can significantly impact consumer trust and business growth. As mobile developers navigate through this complex landscape, two key concepts often surface as rods for [robust security](https://licelus.com/insights/balancing-security-and-usability): Threat Intelligence and Fraud Scoring Systems. While each is powerful in its own right, their true potential is unlocked when there is synergy between the two.
This article exists to explain what each of them does and to explore how this interplay can be achieved. In other words, we’ll examine the ways in which threat intelligence can significantly enhance the capabilities of fraud scoring systems.
Endpoint Detection and Response (EDR) and Extended Detection and Response (XDR) are two relevant concepts in this context, but our focus will not be on these solutions in isolation. Instead, we’ll explore the broader picture, emphasizing how real-time and predictive threat intelligence can be effectively incorporated into fraud scoring algorithms to create a more secure and resilient mobile environment.
Our hope is that this article will give you a comprehensive understanding of how these technologies can be harmonized to fortify your [mobile applications](https://licelus.com/resources/guide-to-mobile-application-protection/threats/mobile-app-fraud) against an array of security threats. Whether you're a mobile developer keen on implementing advanced security features, or a CTO strategizing the overall security posture of your organization, read on.
### What threat intelligence platforms and fraud scoring systems do
To fully grasp the intricate relationship between threat intelligence platforms and fraud scoring systems, it's important to first understand what each does and why they are pivotal in the realm of mobile security.
##### Threat Intelligence Platforms
Threat Intelligence refers to the collection, analysis, and dissemination of information related to cybersecurity threats. In the context of mobile security, threat intelligence can provide real-time insights into emerging vulnerabilities, malware, and attack vectors that specifically target mobile platforms (and apps) like Android and iOS.
Key components of Threat Intelligence include Indicators of Compromise (IoCs), as well as Tactics, Techniques and Procedures(TTPs).
Indicators of Compromise (IoCs) are specific data points that are used to detect unauthorized or malicious activities within a system. These indicators serve as red flags that can trigger alerts or can initiate automated responses. In the context of mobile security, IoCs are crucial for identifying potentially harmful behavior or vulnerabilities that could compromise an application or the device itself.
Let’s look at an example. A threat intelligence platform might be aware of an IP address (or a selection of addresses) which is known to belong to compromised systems. Similarly, malicious URLs often host phishing sites or [malware](https://licelus.com/resources/guide-to-mobile-application-protection/threats/malware). Monitoring the URLs that a mobile app interacts with can help in identifying potential threats.
Another indicator can be a file hash. Every file has a unique hash value that can be used to identify it. If a mobile application downloads a file with a hash that matches a known piece of malware, it's an indicator of compromise.
Tactics, Techniques, and Procedures (TTPs) refer to the behavioral patterns and methods employed by attackers during a cyber-attack. Unlike Indicators of Compromise (IoCs), which tend to link to data points, TTPs provide a more holistic view of how an attacker operates.
Tactics are the high-level objectives behind an attack, such as gaining unauthorized access or exfiltrating data. For example, an attacker might use [social engineering tactics](https://licelus.com/insights/the-seven-principles-of-social-engineering) to trick a user into revealing their authentication credentials.
The methods used to execute these tactics are called techniques. In a mobile context, techniques could include exploiting a vulnerability in the operating system or using malicious code injection.
Procedures are the specific steps or sequences of actions taken by an attacker to execute a technique. For instance, the procedure for a SQL injection attack would include crafting malicious SQL queries and identifying the point of injection in the application.
##### Fraud Scoring Systems
Fraud Scoring Systems are algorithms designed to evaluate the risk associated with a particular action or transaction within a digital environment, such as a mobile application.
These systems assign a risk score based on various metrics and indicators, facilitating real-time decision-making processes. For example, a high-risk score could trigger additional authentication steps before a mobile payment is approved, thereby adding an extra layer of security.
Fraud Scoring Systems operate at least two metrics. Risk Score is a numerical representation of the likelihood that a given transaction or action is fraudulent. The score is usually calculated based on a set of weighted variables such as user behavior patterns, geolocation, and transaction history. Or it might be calculated based on the ML models.
Another metric, called Confidence Level, indicates the reliability of the risk score and is often expressed as a percentage. A high confidence level suggests that the risk score is likely to be accurate, while a low confidence level may necessitate further investigation.
Fraud scoring leverages different approaches to evaluating the metrics of a particular action. One of the methods is a decision tree.
Imagine we have a set of attributes for the same user who was booking a ride in the intro of this article - their location, payment method, mobile OS version, timezone, and so on. We can make the following conclusions: if the user had 15 rides, allow a new ride. If not, check if the timezone matches their location. If it does not, then request additional verification.
Another method that emerges from decision trees is called Random Forest. It is an ensemble learning method that combines multiple decision trees for a more robust and accurate model.
Neural Networks are more complex algorithms capable of capturing intricate patterns. But these may require more computational resources, accurate learning, and careful experimentation.
A well-tuned fraud scoring system can [enhance user experience](https://licelus.com/insights/balancing-security-and-usability) by reducing friction in legitimate transactions while adding additional checks only for risky activities. After all, how long would you continue using a ride-hailing app if it asked you to take a selfie for verification every time you were booking a ride home?
Fraud Detection Systems bring a lot of value. But they also come with their own challenges and considerations. One of these is minimizing false alarms without compromising on security. This requires regular tuning of the methods and algorithms. Anti-Fraud should battle malicious users; but anti-fraud measures can drive trustful users away. We’ll explore this later in the article, but one of the benefits of a good threat intelligence system is that it can improve attack data, and so reduce false alarms over time.
Another challenge of Fraud Systems is that they require as much data about a user, as possible. Ensuring that the collection and processing of data complies with regulations like GDPR and CCPA is crucial. Failing to implement these measures will result in financial losses due to fines, not to mention losing the trust of your customers.
Also worth noting is that as the user base grows, the fraud scoring system must be able to handle a larger volume of transactions without performance degradation.
##### An overview of EDR and XDR
While Endpoint Detection and Response (EDR) and Extended Detection and Response (XDR) are not the central focus of this article, their relevance in the broader context of threat intelligence and fraud scoring systems cannot be overlooked.
EDR is a cybersecurity technology that focuses on monitoring, detecting, and responding to threats at the endpoint level. This includes mobile devices, laptops, and desktop computers. EDR solutions offer real-time monitoring, threat hunting, and automated responses to identified threats. EDR can provide real-time threat intelligence that can be integrated into fraud scoring systems, thereby enhancing their effectiveness.
For example, if an EDR system detected malware on a mobile device, this information could then be used to adjust the risk score for transactions originating from that device.
If you were to start collecting and correlating data from multiple security layers, say from endpoints, networks, and cloud services, this would be XDR.
Beyond real-time monitoring, XDR offers enhanced analytics and broader contextualization of security incidents by incorporating data from multiple sources.
XDR's comprehensive view of the threat landscape can be invaluable for fine-tuning fraud scoring algorithms. Say your XDR system identified a network-level attack targeting a mobile application's backend. This could influence the risk assessment of transactions processed through that application.
Let's consider another example:
A financial application on the iOS platform allows users to manage their bank accounts, make payments, and invest in stocks. Given the sensitive nature of the data and transactions involved, security is a top priority. The application is already using a basic fraud scoring system to evaluate the risks associated with each transaction. But to enhance its security posture, the development team decides to integrate an Endpoint Detection and Response (EDR) solution.
First of all, the team chooses an EDR solution that offers a Software Development Kit (SDK) specifically designed for mobile applications. This EDR SDK should be integrated into the iOS application using Swift or Objective-C. This allows the EDR solution to monitor system-level activities on the device where the application is installed.
The EDR solution would also require configuration to monitor specific Indicators of Compromise (IoCs) relevant to mobile security, such as suspicious API calls, unauthorized data access, or abnormal resource utilization.
Once integrated and configured, the EDR solution can begin monitoring in real-time. It checks for signs of malware, data exfiltration, or any other suspicious activities. The EDR solution can also be configured to receive threat intelligence feeds, which helps in identifying new and emerging threats targeting the iOS platform.
If the EDR detects any suspicious activity, it can take predefined actions like sending an alert to the user, forcing a logout, or even isolating the application to prevent further potential damage.
Then the real-time threat intelligence data gathered by the EDR is fed into the existing fraud scoring system. And if the EDR detected a keylogging malware attack, the risk score for transactions initiated from that device would be elevated.
### Creating synergy between threat intelligence platforms and fraud scoring systems
The integration of threat intelligence into fraud scoring systems is a transformative approach that significantly elevates mobile security.
One of the key elements in this integration is the use of threat intelligence feeds. These feeds can come from a variety of sources, including commercial providers and open-source platforms such as MISP (Malware Information Sharing Platform). These feeds deliver real-time data on Indicators of Compromise (IoCs) and Tactics, Techniques, and Procedures (TTPs), which we covered earlier.
To translate this valuable data into fraud scoring systems, RESTful APIs are commonly employed. These APIs facilitate the seamless transfer of threat intelligence, usually in JSON format. In some scenarios, threat intelligence data might be stored in databases like PostgreSQL or MongoDB and then synchronized with the fraud scoring system at regular intervals.
Once threat intelligence data is integrated, the fraud scoring algorithms can adapt in real-time. For instance, if a new type of mobile malware is identified, the risk scores for transactions originating from devices exhibiting similar behavior can be automatically elevated. This dynamic risk scoring is further enhanced by the application of conditional logic based on the incoming threat intelligence. For example, transactions originating from an IP address that has been flagged as suspicious could trigger additional authentication steps.
The integration also opens the door for automated responses, especially when coupled with Endpoint Detection and Response (EDR) or Extended Detection and Response (XDR) systems. Actions such as isolating a compromised device or flagging a transaction for manual review can be automated, thereby increasing the system's responsiveness to emerging threats.
On the predictive front, machine learning models like Gradient Boosting or Neural Networks can be trained on historical data that has been enriched with threat intelligence. This enables the fraud scoring system to predict future fraud attempts with higher accuracy.
Feature engineering plays a crucial role here, as attributes derived from threat intelligence such as the frequency of malicious IP addresses or known phishing URLs can be used to improve the model's predictive capabilities. Statistical methods like Z-score or clustering algorithms like K-means can also be applied for anomaly detection, adding another layer of predictive insight.
As we mentioned earlier, while the synergy between threat intelligence and fraud scoring systems brings huge amounts of value, you should be aware that there are some compliance risks.
The General Data Protection Regulation (GDPR) and the California Consumer Privacy Act (CCPA) dictate how data, including personal identifiers often found in threat intelligence, should be collected, stored, and processed. Non-compliance can result in significant fines and reputational damage.
For mobile apps handling financial transactions, adherence to the Payment Card Industry Data Security Standard (PCI DSS) is essential, too. This standard outlines requirements for secure data transmission and storage, which directly impacts how threat intelligence is integrated into fraud scoring algorithms.
Industry-specific regulations, such as the Health Insurance Portability and Accountability Act (HIPAA) for healthcare apps, may also impose additional constraints. These often require the use of specific encryption algorithms or security protocols like Transport Layer Security (TLS).
We don't include this to make you think twice about the benefits of the synergy we’ve outlined in this article but rather to act as a warning to do so in a data compliant manner.
The integration we’ve explored in this article offers a multi-faceted approach to security that is dynamic, adaptive, and predictive. Whether you’re looking to fortify mobile payment transactions or enhance multi-factor authentication protocols, the synergy between these two domains provides a robust framework for mitigating risks and blocking fraudulent activities.
And it’s an approach that aligns well with the compliance and regulatory requirements that govern mobile applications today. From real-time adaptation to predictive analytics, the practical applications are vast and compelling, offering mobile developers, CTOs, security managers, and others involved in mobile app development a nuanced understanding of the evolving threat landscape.
The upshot of the interplay between **threat intelligence and fraud scoring systems** is the ability to equip mobile apps with the resilience and agility they need to navigate the intricate web of modern cybersecurity challenges.
If your organization is looking to safeguard user trust and ensure business growth, then it’s certainly an approach you should strongly consider.
We recently reported on some aggregated data from our own threat intelligence platform, [Alice](https://licelus.com/products/alice-threat-intelligence).
[Read the short report.](https://licelus.com/company/news/alice-threat-intelligence-data-insights-september-2023)
## AI and Social Engineering
[All insights](https://licelus.com/insights)
### Follow us
21 Dec 2023
### AI and social engineering
URL: https://licelus.com/insights/ai-and-social-engineering
# AI and social engineering
### And the “truth”?
Before the emergence of sophisticated AI technologies like Large Language Models (LLMs), we were already grappling with a post-truth era.
This landscape was shaped by various factors: the impact of social networks on political opinions (including the social media bubble effect), the media's role in guiding public conversation, and the influence of censorship in muting certain topics.
These elements combined to obscure objective truth to the extent that the very concepts of 'truth' and 'facts' began to lose their meaning somewhat.
The introduction of AI into this mix only intensifies these challenges, further blurring the lines between fact and fiction. AI's capabilities go beyond merely tailoring messages for enhanced persuasion; it enables the creation of content at scale and with a precision that was impossible before.
This advancement poses a significant risk to the integrity of a shared, objective reality. Particularly as AI-generated material becomes virtually indistinguishable from content created by humans.
However, the concerns around AI extend beyond the production of false information. AI algorithms, especially those that govern content curation on social media platforms, tend to reinforce existing biases. They often create [echo chambers](https://www.counterterrorismgroup.com/post/artificial-intelligence-and-echo-chambers), [amplifying pre-existing views](https://sciencegenderequity.org.au/news/ai-poses-serious-risk-of-reinforcing-biases-in-learning/) rather than presenting challenging or divergent perspectives. This phenomenon can exacerbate divisions in an already-polarised society.
What’s more, AI's capacity to produce credible fake news, deep fakes, and synthetic media casts doubt on the reliability of legitimate news sources.
This escalation presents a serious challenge in the digital age when verifying authenticity is increasingly complex. And, as we’ll explore later, **AI also has serious consequences for social engineering**.
### Deep fakes
The advancements in AI technology has heightened the risks associated with deep fake technology. Today, not just the written word but also human faces, body language, and voices can be synthesised with great accuracy, marking a [new era in digital impersonation threats](https://www.brusselstimes.com/106320/xr-belgium-posts-deepfake-of-belgian-premier-linking-covid-19-with-climate-crisis).
While some older scams were easy to identify due to the attackers' limited English proficiency, ChatGPT has changed all of that. Crafting convincingly-authentic scam messages has become a trivial task.
You can train your virtual assistant over time to communicate in a particular tone of voice, after all. Attackers targeting customers of a bank might ask generative AI to craft a message in a particular style. They could also ask AI to write in the style of an experienced PR professional.
Such has been the rapid development in AI capabilities in recent years that there are now AI [Instagram models](https://www.businessinsider.com/ai-influencer-aitana-clueless-agency-tech-spain-2023-11), and [musicians](https://edition.cnn.com/style/kpop-virtual-bands-ai-intl-hnk/index.html). So, it’s not only the authenticity of an individual's communication that can be difficult to ascertain these days but their very being.
### AI and social engineering
AI is already playing a big role in the increasing sophistication of social engineering attacks.
An impersonator, armed with AI, can now initiate a phone call to a target individual, [seemingly from a trusted source](https://www.fcc.gov/spoofing) such as a family member. Scams could, in the coming years, exploit [synthesised voices indistinguishable from the real person](https://www.youtube.com/watch?v=ddqosIpR2Mk). It’s a lot harder to ignore a scam call when it sounds like a loved one is at the other end of the line.
The bad actor impersonating said loved one could convey a sense of urgency and authenticity. They might instruct the victim to transfer money urgently, generating additional sounds such as sirens or screams, effectively intensifying the scenario's realism.
The use of AI has also [significantly streamlined Open Source Intelligence](https://blog.sociallinks.io/using-the-power-of-chatgpt-for-osint/) (OSINT). Gathering and analyzing information about potential victims, once a time-consuming and manual endeavour, can now be efficiently conducted with simple prompts to AI tools like ChatGPT with internet browsing capabilities.
The ease with which impersonators can now acquire personal details to convince victims of their identity has never been greater.
Clearly it’s going to become harder in the future for us to identify genuine communications from those that look to trick us. But a lot of the suggestions we outlined in a previous article about [boosting your social engineering awareness](https://licelus.com/insights/how-to-boost-your-social-engineering-awareness) will remain valid.
These include something as simple as disconnecting and calling back the number you know to be the genuine one to verify the request's legitimacy.
Remember that the attacker is relying on you making an impulsive decision - preferably while anxious and flustered. And so sometimes simply taking a breath and deciding to call back can be an incredibly effective approach in [guarding against these advanced impersonation tactics.](https://licelus.com/insights/how-can-you-protect-yourself-from-social-engineering)
### Fabricating corporate entities
Consider a scenario where someone who has been away on business for a few days returns home and encounters a sudden infestation of ants in their apartment.
After deciding that over-the-counter solutions to remove the ants are toxic, they opt to search for professional help, googling 'city_name pest control service'. The top search results show several options, each boasting excellent reviews. So, the individual calls them, chooses one based on pricing, and schedules a visit.
Upon returning home after the pest control specialist’s visit, they are met with a shocking discovery: their safe has been broken into, and valuable family belongings are missing.
The victim calls the police, only to uncover a more complex web of deceit. Investigations reveal that the pest control service was an elaborate facade; the infestation was artificially created by the attacker, who also engineered a few counterfeit websites replete with fabricated reviews.
The websites had been [strategically SEO optimised to hijack traffic](https://www.godofprompt.ai/blog/steal-your-competitors-website-traffic-with-chatgpt-6-easy-steps-semrush-tips), ensuring that the top four search results for pest control services were fraudulent. Additionally, AI was employed to handle the phone interactions, leaving no traceable human evidence behind.
This story might sound a little bit like an episode of Black Mirror. But is it really that unbelievable?
After all, thanks to AI, producing a convincing fake company website [now requires minimal budget and no development team](https://lablab.ai/t/chatgpt-tutorial-how-to-create-a-website-with-chatgpt). These websites can also be easily populated with reviews from AI bots pretending to be real people. Each with their own social media profiles, interests, and posts. And all of it AI generated.
Such is the potential for AI and social engineering to form a toxic mix, that we might arrive at a point several years from now where people only feel confident about the authenticity of the person they’re talking to if they are physically standing in front of them.
### Wider societal manipulation
Beyond targeting individuals, AI's potential for misuse might also be exploited for corporate sabotage or unethical competitive strategies.
This could manifest in various forms, from diverting traffic from rival companies to tarnishing their image with artificial, negative reviews on platforms like Glassdoor. In 2023, there’s no need to manually enter [fake reviews on Glassdoor](https://medium.com/@narekgevorgyan/glassdoor-tolerates-fake-reviews-the-consequences-are-disruptive-de0252ed9cbe). AI has seen to that.
We also read recently about [a conference that attempted to enhance its appeal by creating a fictitious female speaker persona](https://fortune.com/2023/11/27/devternity-tech-conference-fake-women-speakers-profiles-engineering/). This effort was aimed at presenting an image of diversity and inclusivity in its speaker lineup. Might this become a trend given how easily fake online profiles can be created?
What is clear is that AI's role in shaping our social interactions and behaviors is expanding at pace. And whether it’s recommendation systems guiding our choices or AI-driven search engines and dialogue agents, it’s worth noting that these tools can exhibit subtle biases.
The capacity of AI to subtly manipulate content represents a significant concern in the digital age. This technology, particularly when integrated into spam bots, has the potential to shape beliefs and exacerbate societal polarization.
AI's ability to generate vast amounts of information far exceeds what was previously possible with real commenters or journalists. Consequently, bot farms, powered by sophisticated AI, can wield serious influence. And this too can have an impact on cybersecurity readiness.
In an online environment where a single opinion dominates a discussion thread, a discerning individual might typically grow suspicious. But LLM-powered spam bots can simulate nuanced and intelligent debates, employing varied tones, styles, and emotional nuances while subtly steering the conversation towards a desired narrative. This sophisticated mimicry can sway even the most sceptical minds towards the beliefs promoted by the bot farm operators. Again, this approach might be employed to trick someone into clicking on a link that they shouldn’t or handing over sensitive information.
It’s also worth a reminder that the human capacity to process vast amounts of information is [inherently limited](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC10322198/). And in an era when AI can generate overwhelming quantities of content, this limitation becomes increasingly problematic. Not least as it challenges our ability to discern truth and authenticity in a sea of AI-generated information.
[As we’ve said in previous articles](https://licelus.com/insights/the-seven-principles-of-social-engineering), the more inundated we are with information, the more likely we are to be distracted and click on a bogus link.
### Are we going full circle?
We suggested earlier that AI’s impact on social engineering might lead to so much paranoia about digital interactions that we’ll begin to prefer face-to-face meetings.
This shift - if it happened - could redefine communication norms, making in-person communication a luxury while the average person relies on AI-mediated interactions.
It feels important at this stage to acknowledge that AI has incredible potential for positive impact. Like any technology, AI's utility is subject to the intentions of its users, with the possibility of misuse by bad actors always present. And as a cybersecurity company, we’d be remiss not to explore this darker side of artificial intelligence.
Historical precedents like the Printing Press, the Industrial Revolution, and their profound social impacts, remind us that technological progress often reshapes societies and challenges the status quo. These changes have led to significant societal shifts, such as urbanization, class restructuring, and even revolutions.
The advent of AI might lead to similarly transformative changes. While the specific nature of these changes remains uncertain, one thing is clear: the world as we know it will evolve. And in this changing landscape, agility, lifelong learning, and a keen awareness of ongoing developments are all going to be crucial. As social beings, our ability to adapt and support one another will be key to navigating these novel cybersecurity challenges successfully.
For developers, this means not only being tech-savvy but also understanding and educating others about the potential risks and benefits of AI. As creators of software used by many, developers have a responsibility to help users reap the benefits of progress while safeguarding them against its pitfalls.
**AI and social engineering** can be a dangerous combination. But together we can guard against it.
Mobile application security involves more than just running tests and applying protections at the end of each development cycle. [Security should be a continuous undertaking.](https://licelus.com/resources/guide-to-mobile-application-protection/practice/continuous-security) Something that evolves alongside your app to stop the sophisticated threats that surround it.
## Understanding Mental Traps
[All insights](https://licelus.com/insights)
### Follow us
24 Jan 2024
### Beware of mental traps
URL: https://licelus.com/insights/beware-of-mental-traps
# Beware of mental traps
As human beings, [our decision-making is severely influenced by emotions](https://licelus.com/insights/the-psychology-of-social-engineering). And most of these emotions [can be exploited by people with malicious intent](https://licelus.com/insights/the-seven-principles-of-social-engineering).
Even when our thinking isn’t clouded by emotions, we aren’t as rational as we’d like to believe we are. Kahneman's work, particularly his Nobel-winning research, challenges the notion of humans as perfectly-rational beings.
### What are mental traps?
Psychologists have been studying the patterns of irrationality in our cognition for quite a while now. There’s a significant amount of knowledge and understanding around so-called mental traps (known as cognitive biases in the academic world).
**A mental trap (or cognitive bias) is a systematic error in thinking that occurs when people are processing and interpreting information in the world around them and affects the decisions and judgments that they make.**
It’s widely believed that **mental traps** have their roots in the evolutionary history of humans. These biases are thought to be the byproducts of mental shortcuts, known as heuristics, that evolved to help our ancestors make quick, efficient decisions. Often in an environment where rapid response meant the difference between life and death.
Many cognitive biases may have developed in response to the challenges faced by our ancestors in the \"environment of evolutionary adaptedness\" (EEA). This term refers to the environment to which a particular species is adapted.
For early humans, this environment was characterized by resource scarcity, physical dangers, and the need for social cooperation.
Cognitive biases likely conferred certain survival and reproductive advantages. For instance, the [availability heuristic](https://thedecisionlab.com/biases/availability-heuristic), where individuals judge the frequency or probability of an event by how easily they can recall similar instances, would have been useful in quickly assessing threats (and staying alive). Remembering and overestimating the frequency of dangerous encounters would have promoted cautious behavior, enhancing the probability of survival.
Humans are inherently social beings, and many cognitive biases reflect this social nature. Biases like [in-group favoritism](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4327620/) (referenced in [our article about creating a company culture for security](https://licelus.com/insights/creating-a-company-culture-for-security)) and [conformity bias](https://thedecisionlab.com/biases/bandwagon-effect) likely evolved because they facilitated group cohesion and cooperation. These were vital for survival in hunter-gatherer societies.
The development of cognitive biases can also be seen as a trade-off. The human brain, despite its complexity, has limitations in processing power. Heuristics and biases allow for quicker decision-making by simplifying complex information, even though this can sometimes lead to errors in judgment.
While these biases were helpful in prehistoric environments, they’re not quite as suitable for modern society. The same shortcuts that helped our ancestors survive can lead to errors in our complex, information-rich world.
Mental traps can make us behave irrationally. And the problem with irrational behavior is that it’s easily abused. Social engineers can use them to exploit us and our systems. And in the 2020s our go-to system is the one that’s always in the corner of our eye, easily within reach. Constantly pinging with tempting-looking notifications.
Let’s take a look at a few mental traps within the context of cybersecurity.
### Anchoring bias
Imagine an attacker wants to infect a company’s office network with a virus. The virus is on a flash drive and if anyone inserts that drive into their machine, it will install itself and infect the entire network.
The goal of the attacker is to make anyone insert the flash drive into any computer. But for argument’s sake, let’s say that this particular office is pretty well protected and there’s no easy way to access it physically.
What can the attacker do?
He approaches the security officer and sees a computer over the officer’s shoulder. The attacker pretends to be an employee who needs to access the office because he forgot to send a very important email from his computer.
The security officer demands some ID and office pass, and the attacker acts as if he’s forgotten his, feigning sadness and frustration. He says he’s going to be fired for sure if the report isn’t sent on time, and begs for access “just this once”. But again the security officer says no.
Time for another approach. What if, the attacker asks, the security officer could do him a massive favor and send the report from his computer. The attacker copies the data from his laptop to the usb flash drive, showing exactly what he’s doing to the security officer and appealing to the goodness of his heart to send the report via email.
The security officer looks pensive. But why?
Why would he be more receptive to this second tactic?
Well, this request appears relatively minor compared to the first one. This poor guy probably is a genuine employee and he looks pretty desperate. He’s not even asking for physical access to the office anymore.
This is how easily an organization’s entire network could be infected.
If the attacker approached the security officer and asked him straight off the bat to insert the flash drive into a network-connected computer, there’s no way the officer would comply.
This tactic is a clever example of the [anchoring bias](https://www.scribbr.com/research-bias/anchoring-bias/). It creates a context in which the security officer's decision-making is influenced by the initial, more extreme request. And so the subsequent smaller request seems harmless by comparison.
### Sunk cost bias
Our second mental trap that cybercriminals look to exploit is called sunk cost bias.
Think for a second about those infamous Nigerian scam emails that you’ve almost-certainly received at some point in the past decade or two.
They rely on their victim making an initial payment in the expectation of then receiving a large prize or reward. When there is no prize on the horizon, rational thinking and behavior would suggest the victim cut their losses, realize it was a scam, and admit to themselves that they’ve made a big mistake.
But in reality that’s not always what happens.
In many cases, the scammers request even more funds. And the victim, despite seeing zero return from their initial investment, continues to send money.
Why?
Well, they’ve convinced themselves that by investing more, they’re getting closer to receiving the promised reward. The big payoff.
This is [sunk cost bias](https://rationalwiki.org/wiki/Sunk_cost).
### Neglect of probability, illusion of superiority, and the framing effect
Our brains don't operate that well with probabilities because we often don’t have the innate perception of how they work.
Take the following example. Say one hundred people are given the option of entering two different prize draws:
In the first draw, the pot is $10 million and the chances of winning are one in 10 million. In the second draw, the pot is much smaller at $10,000, but the odds are stacked much more in their favor at one in 10,000. Still, the majority of the participants would choose to take part in the first game, mesmerized by the thought of becoming a multimillionaire.
Let’s go back to the infamous Nigerian email or text scams again. The attackers usually present opportunities that seem too good to be true, such as the possibility of receiving a large sum of money.
The rarity of this opportunity can play on an individual’s desire and desperation to the point that they overlook the low probability of it being genuine. This is an example of the [neglect of probability bias](https://meaningring.com/2016/03/28/neglect-of-probability-by-rolf-dobelli/) effect.
This mental trap is closely linked to another one - the [illusory superiority bias](https://www.tandfonline.com/doi/abs/10.1080/14792779343000040), or the belief that you’re better and more deserving of fortune than others. Be that when it comes to intelligence, ability, or morality.
“No wonder this exclusive offer has arrived in my inbox.”
Our decision making is also influenced by the way information is presented to us rather than just by the information itself.
We obviously prefer the sound of surgery with an 80% success rate than one that comes with a 20% death rate even though they both have the exact same outcome. This is called the “ [framing effect](https://thedecisionlab.com/biases/framing-effect)”. The same information can lead to different conclusions or actions, depending on whether it’s presented in a positive or negative light.
### The halo effect, ingroup bias and social conformity bias
At the heart of social engineering is good acting. And good acting relies heavily on [the Halo effect](https://thedecisionlab.com/biases/halo-effect). There are studies that prove we treat better-looking or more-professionally looking people better and tend to trust them more readily.
With good open source intelligence (OSINT), attackers can find out about a difficult experience their victim might have had in her life, be that losing a loved one, having relatives suffering from addiction problems, or the fact that she’s an immigrant who fled from war in her homeland. The harsher the experience, the stronger the [ingroup bias](https://rationalwiki.org/wiki/Other) will hit home when the attacker hints at a shared experience.
The ingroup bias has deep roots in our evolution as social animals, as we touched on earlier. Human beings want to empathize and connect with “their people” - this empathy and trust was vital for our ancestors’ ability to survive and prosper and for the idea of countries and religions to flourish.
Take a look at [this video](https://www.youtube.com/watch?v=p4WSiIMfr-Q) about the power of social conformity.
Having watched it, consider a scenario:
An employee possesses a security pass that attackers are aiming to copy.
Merely asking the employee to hand over the security pass would certainly result in non-compliance. But if the attackers knew that the employee was likely to be at a specific location - say at an airport - they could implement a more intricate scheme involving multiple actors.
One actor would assume the role of a security guard, while others would impersonate regular passengers sitting in the same waiting area as their target employee. The actor portraying the guard would then enter this area and initiate a 'security search'. As part of this orchestrated act, all the actor-passengers would obediently submit their belongings for inspection.
Observing this, the victim would likely follow suit, conforming to this perceived norm and unwittingly exposing the security pass for copying.
This is an example of the bandwagon bias (or social conformity) in action.
### Overconfidence bias
The overall effect of multiple biases is worsened by the [overconfidence bias](https://www.schwabassetmanagement.com/content/overconfidence-bias): we often tend to overestimate our abilities. For example, [65% of Americans think they have above-average intelligence](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6029792/). This means that even if we know that there are certain biases, we might believe we’re almost immune to them.
“Other people might be irrational and liable to fall for scams, but not me.”
According to the [UK authorities](https://www.att.org.uk/employers/welcome-employer-focus/pension-scams-rise), higher levels of education and overconfidence in financial abilities is one of the risk factors for social engineering. The more that we think we know about a topic, the higher the chance we can feel overconfident and fall prey to a carefully-crafted attack.
That’s why even those of us who work in cybersecurity aren’t completely immune to scams.
### How to overcome mental traps
Building awareness is vital: **people must be aware of these mental traps** if they’re not to fall foul of them.
That said, awareness alone isn’t enough. Even those with awareness can be overconfident and some biases can be accidentally reinforced.
Many mental traps are byproducts of heuristics which can be triggered when immediate action is required (what is known as System 1 thinking). And it just so happens that the modern world of smartphones and social media with all those notifications and distractions are priming you to embrace this mode of being.
A lot of our problematic biases can be mitigated simply by removing the speed constraint. Slow down and take your time. When you do so, your ability to think critically will improve, allowing for more deliberate and rational decision-making.
When we pause and reflect, we engage System 2 thinking, which can help us to identify and mitigate the influence of biases inherent in System 1's rapid processing.
Speed is not the only constraint we need to remove, however. Be self aware as soon as you’re reacting to a certain request with a warm, fuzzy feeling of social appreciation or a deep underlying feeling of self-exceptionalism.
When dealing with such urges, engaging in more deliberate, System 2 thinking can also be beneficial. These feelings are often associated with biases like the need for approval, the superiority bias, or the illusion of uniqueness.
Using structured decision-making techniques can help in overcoming mental traps. Techniques like creating a variety of options, weighing them against a set of criteria, and systematically analyzing these options can mitigate the impact of cognitive biases.
When presented with a request, write down the reason for it. Then list several options, starting with “comply” and ending with “do nothing”, and analyze the rationale and outcome for each action. While this might seem like a banal exercise, it can help you to stop bad habits that heighten the risk of you falling for a social engineering attack.
Not so long ago, we published an article about [boosting your social engineering awareness](https://licelus.com/insights/how-to-boost-your-social-engineering-awareness), which expands on this advice.
And if you want to explore the psychology behind **mental traps** a little bit more, here’s some further reading that we recommend:
- Thinking Fast and Slow by Kahneman
- Predictably Irrational by Ariely
- The Art of Thinking Clearly by Dobelli
- Influence: The Psychology of Persuasion by Cialdini
- Behave: The Biology of Humans at Our Best and Worst by Sapolsky
## Importance of Cybersecurity
[All insights](https://licelus.com/insights)
### Follow us
22 Feb 2024
### Why cybersecurity matters
URL: https://licelus.com/insights/why-cybersecurity-matters
# Why cybersecurity matters
Despite companies (globally) increasing their cybersecurity spending each year - [estimated at $71.1 billion in 2022](https://www.statista.com/statistics/991304/worldwide-cybersecurity-spending/) - the number of breaches also continues to rise.
This trend suggests that the current level of expenditure on training and improving security may not be enough, or that it's being spent on the wrong things.
It also tells us that a big part of the answer to “why cybersecurity matters” is financial. However, as we’ll explain in this article, cybersecurity matters for all kinds of reasons, from brand reputation to compliance.
Most important of all, perhaps, cybersecurity matters because it matters to your customers; your end users. And that means it should matter to all of us.
### The economic and reputational impact of cyber attacks
Statistics reveal that the average cost of a data breach in the United States in 2023 [reached $9.48 million](https://www.statista.com/statistics/273575/us-average-cost-incurred-by-a-data-breach/), while a [report by Hiscox indicates](https://www.hiscoxgroup.com/cyber-readiness) that more than half of UK firms experienced a cyber attack last year. Email phishing - arguably the simplest form of social engineering - remains the hackers' favorite go-to method.
Alarmingly, one in five firms subjected to attacks reported that the impact of those attacks was severe enough to jeopardise their business's future viability. Perhaps this shouldn’t surprise us, given that so many attacks are suffered by small businesses without the cybersecurity budget or know-how to learn from them and, indeed, without the overall financial means to survive them.
These figures represent only the direct financial losses, of course. Estimating the impact of a breach on brand reputation is significantly more challenging. But we do know that successful attacks are a major factor in negatively impacting a company's reputation, and we also know that [trust is more vital than ever for the modern consumer](https://cdn2.hubspot.net/hubfs/2749863/CONTENT/Content%20Marketing/The%20Value%20of%20a%20Trustworthy%20Brand%20Reputation%20-%20July%202019/The_Value_of_a_Trustworthy_Brand_Rep_US.pdf).
[Research in risk management](https://www.researchgate.net/publication/327877292_Reputation_Risk) consistently highlights reputational risk as the 'risk of all risks', placing it above other threats to business growth. Additionally, the mass media's eagerness to report on breaches further compounds the overall cost.
The decline in customer loyalty following a breach can lead to customers leaving permanently, making the acquisition of new clients significantly more costly and stressful.
Predicting when a company will fall victim to a cyber attack, the financial ramifications of a breach ( [could Equifax have realistically foreseen a $500 million payout?](https://consumer.ftc.gov/consumer-alerts/2019/07/equifax-data-breach-settlement-what-you-should-know)), or the subsequent impact on reputation is almost impossible. If a company has yet to suffer a major attack, or if the impacts of an incident were minimal, it can often be easy for leaders to attribute it to sheer luck, akin to the simple toss of a coin.
### The legal impact of cyber attacks
Numerous industries (but especially the financial sector) are subject to regulatory and compliance mandates concerning data security and privacy. Failure to adhere to these regulations can lead to significant fines, making investment in cybersecurity an essential step.
However, it's important to note that achieving compliance doesn’t equate to complete, holistic security. The investment required to meet compliance standards should be regarded as a baseline for minimum expenditure. There can be a tendency to see compliance as something of a box-ticking exercise rather than an opportunity to be really proactive and to set the company apart from competitors by truly embracing security.
### Predicting a security breach
Forecasting social engineering attacks is tricky, of course. Could a skilled hacker destroy a company's reputation through social engineering? Absolutely. The problem is that as humans we often don’t think completely rationally about probabilities - this is something that we covered in depth in [our previous article about mental traps](https://licelus.com/insights/beware-of-mental-traps).
It's common for us to irrationally [dismiss the likelihood of adverse events affecting us](https://thedecisionlab.com/biases/optimism-bias) or, conversely, to [overestimate certain risks based on past experiences](https://thedecisionlab.com/biases/pessimism-bias#).
When it comes down to it, security fundamentally relies on an implicit social contract underpinned by trust. For instance, you deposit money into a bank and trust that the bank will keep your money (and credentials) safe. If your bank were to gain a reputation for being vulnerable to losses, you likely wouldn’t hang around for long before switching to a competitor's more secure services.
The bank knows this as well. But other factors sometimes blur their view and skew priorities. For example, there is often pressure to launch products quickly which can lead to security considerations being overlooked or at the very least not being carefully analyzed. And again, budget limitations are a reality for many companies; it's impossible for them to allocate all of their resources to security.
### Reactive security vs. proactive security
Justifying an investment in cybersecurity often comes down to whether you want to employ a reactive or a proactive approach.
A reactive cybersecurity strategy typically involves allocating resources based on past incidents - a sort of effort-spent versus incidents ratio. For example, after incurring significant losses from mobile fraud, the CISO of a neo-bank might be tempted to invest three times as much in security this year to prevent future losses.
His justification is based on the expectation of reducing the likelihood of similar incidents occurring in the future. But his logic here is flawed, because it’s based purely on the financial implications of an attack rather than the more human, legal, or reputational impact.
After all, it’s more difficult to predict or quantify customer dissatisfaction or legal repercussions. Dissatisfied clients might sue the company or switch to a competitor, potentially causing irreversible damage.
To avoid the onset of client dissatisfaction in the first place, it's better to invest in protection measures proactively. Your company has not yet been compromised, but you’re determined to keep it that way and seek out enhanced protection.
This proactive approach gives you a much better chance of mitigating the negative repercussions of a successful attack that we’ve already covered in the paragraphs above.
### Benchmarking against industry standards
OK, so you’re convinced that you should embrace cybersecurity in a proactive manner. But what is the right level of investment?
This is really tricky and depends on a number of factors such as your industry, the type of software or application that you’re launching, and the vulnerabilities you’ve identified from running a threat model (more on this below).
Data on what other companies like you are allocating towards security can serve as a guide. For instance, in Germany in 2022, [statistics showed](https://www.statista.com/statistics/1363143/it-security-budget-companies-germany/) that around 16% of companies dedicated 5-10% of their total IT budget to IT security, while 42% of those companies allocated 10-20%.
If your organization spends less on security compared to the benchmarks you determine are the right ones for your company, then you may be at a disadvantage. You could face higher risks and more severe financial repercussions in the event of a breach.
It’s also worth noting that hackers don’t stand still and so you shouldn’t either. [80 percent of companies worldwide are expecting their cybersecurity budgets to increase in 2024](https://www.statista.com/statistics/1318365/cyber-budget-changes-for-global-companies/) for a good reason. They know that the threat landscape is constantly evolving and getting more complex; more dangerous. Simply repeating past spending patterns could result in your company falling behind in terms of security preparedness compared to its competitors.
If you have partnered with a cybersecurity company, make sure that their products are evolving accordingly and are tested regularly by third-party labs to make sure they stand up to the latest, most sophisticated attacks. If they’re standing still and acting in a complacent way, you should see this as a red flag.
### Threat modelling
As we mentioned earlier, understanding why cybersecurity matters for your particular organization is often easier once you’ve carried out a threat model.
Threat modelling can help you to understand the kind of cyber threats that exist in your landscape and the potential that those threats have to cause serious damage. Say you’re building a healthcare application and you realise that without the ability for your application to defend itself at runtime, it’s highly vulnerable to [tampering and reverse engineering](https://licelus.com/resources/guide-to-mobile-application-protection/threats/dynamic-analysis-and-tampering).
This discovery has the potential to not only guide you in the type of protection mechanisms you need to invest in. It also has the potential to save you time and money, not to mention maintaining your hard-earned reputation.
We recently published a deep-dive into [threat modelling](https://licelus.com/resources/knowledge_hub/threat-modelling) where you can explore this topic in more detail.
### Gaining a competitive advantage
For some reason this is often overlooked, but [enhanced security measures can serve as a significant market differentiator](https://licelus.com/insights/why-you-should-see-mobile-app-security-as-a-unique-selling-point). If you operate in a sector where data security is paramount, then being able to showcase strong security protocols can be a compelling factor in attracting and retaining customers.
And in the coming years - with [all the advancements in deep fakes](https://edition.cnn.com/2024/02/04/asia/deepfake-cfo-scam-hong-kong-intl-hnk/) and other AI-aided social engineering attacks - this competitive advantage is likely to be even more pronounced as it will matter a lot more to your prospects.
Collaborating with the marketing or PR team to analyse how competitors promote their security measures and determining the investment needed to surpass the industry average - or most competitors - is a potentially game-changing move. The marketing team would also likely appreciate having an additional unique selling proposition to elevate the product's market positioning!
Establishing a budget for security improvements with marketing value in mind could serve as a sensible starting point for minimum expenditure.
### Employee motivation and productivity
Cybersecurity matters not only to your customers and potential customers, but to your employees, too.
Training employees in security practices not only boosts their confidence in their roles but can also enhance productivity by reducing technology-related fears. Investing in meaningful training rather than superficial 'security theater' can help make sure that your employees are actively contributing to the organization's security posture. Don’t forget that those who you work with are the primary enforcers of any cybersecurity strategy.
The UK government recently [advocated for companies](https://www.ncsc.gov.uk/collection/10-steps/engagement-and-training) to recognize that people are central to effective cyber security strategies. We took a deep dive into this topic ourselves not so long ago in our article about [creating a company culture for security](https://licelus.com/insights/creating-a-company-culture-for-security).
Determining how much to invest in boosting employee motivation through security training is essential. Collaborate with HR to establish a comprehensive budget for security training is advisable, and consider this allocation as the baseline for your investment in developing a security-conscious workforce.
### Reducing your insurance premiums
Investing in robust security practices not only enhances protection but can also lead to financial benefits, such as reduced premiums on cyber insurance. Insurance providers often offer lower rates to organizations that demonstrate comprehensive security measures, including regular employee training and thorough system hardening.
According to the [UK Government's Cyber Security Breaches Survey 2023](https://www.gov.uk/government/statistics/cyber-security-breaches-survey-2023/cyber-security-breaches-survey-2023), 63% of medium-sized businesses and 55% of large businesses have cyber attack insurance. Notably, the cost of such insurance is typically lower for entities that invest in proactive security training.
It would be prudent to assess the baseline insurance costs and compare them with the costs for enhanced security scenarios. The savings from lower insurance costs can then be considered as a benchmark for the minimum investment in cybersecurity.
### Ethical considerations
Considering the ethical implications of cybersecurity underscores the fundamental question: How much do we value our customer’s safety?
[With one in three families in the UK having lost money to internet scams in 2022](https://dnsrf.org/blog/three-in-ten-families-have-lost-money-to-internet-scams/index.html), and numbers broadly similar in other markets, the likelihood is high that someone we know personally has been affected by them. Enhancing the cybersecurity training of employees not only safeguards organizational assets but also equips individuals with the knowledge to protect themselves against personal cyber threats.
Quantifying ethics and moral values presents a challenge, as these are inherently subjective and rooted in individual beliefs and societal norms. In this sense, ethical investment in cybersecurity can be likened to charitable giving, based on a commitment to doing what is deemed morally right, rather than on measurable returns. That said, if all of us were more knowledgeable in cyber risks, then surely that would have a massive long-term impact on the reduction in some of the more negative implications of cyber threats covered in this article.
The bottom line is that cybersecurity is not only a technical challenge but a human, societal one. The level of protection afforded to company assets is deeply intertwined with the motivation and ethical stance of the workforce and even the populace as a whole.
Here at Licel we believe passionately that it's vital that those of us involved in the creation of cybersecurity products cultivate a deep sense of empathy towards end-users. This empathy stems not just from a professional obligation but from a personal connection; we, the cybersecurity professionals, engineers, product managers, and CISOs are also end users who navigate these choppy digital waters daily.
We have firsthand experience of the unease that accompanies an unexpected pop-up on our smartphone screen or the anxiety of being locked out of an account with an accompanying notification telling us that the password has been changed when we know we haven’t changed it ourselves.
These aren’t abstract scenarios but realities that we have personally encountered.
Our families and friends could be forced to deal with minor inconveniences or significant emotional and financial turmoil due to cyberattacks. And really, what matters more than stopping that from happening?
### Why cybersecurity matters to all of us
In this article we’ve outlined a number of reasons why cybersecurity matters, from economic, to reputational, all the way to more human, emotional drivers.
So, try to see cybersecurity not just about meeting technical or compliance benchmarks but rather as a way of fundamentally reflecting your organization's values in the digital age.
How much are we collectively prepared to allocate towards enhancing security and contributing to a safer digital environment for everyone?
Adopting this mindset shifts the focus from viewing security investment as a cost to seeing it as an investment. Not just in your own company’s future but in the wider world that we want to create for tomorrow.
Cybersecurity isn’t just about balancing the books; it's about shaping a digital environment where safety, trust, and respect are paramount.
By investing in cybersecurity, we're not just protecting data; we're safeguarding our community's well-being and setting a standard for responsible digital citizenship.
And that’s something that should matter to all of us.
## Mobile Banking Trojans Threats
[All insights](https://licelus.com/insights)
### Follow us
27 Mar 2024
### The battle against mobile banking trojans
URL: https://licelus.com/insights/the-battle-against-mobile-banking-trojans
# The battle against mobile banking trojans
Mobile malware poses a massive threat to banking apps, and the stakes are just as high for both mobile banking customers and the banks themselves.
For end users - now more susceptible to being tricked than ever before - the impact of malware ranges from financial loss, to identity theft and having their sensitive personal data stolen. Attacks can result in long-term financial and emotional trauma.
Beyond financial losses and regulatory penalties, banks risk the permanent erosion of customer trust and the irreparable harm that can cause to their reputation and long-term viability.
Here at Licel, our threat intelligence platform, Alice, is constantly monitoring the threat landscape of the financial sector. What it tells us is that there are now more devices than you would imagine out there with dangerous forms of mobile banking trojans installed on them. And that poses a problem if your application is also on that device.
Threat monitoring combined with reliable anti-malware measures are absolutely vital in making applications (and the mobile device in general) trustworthy.
In this article we’ll explore the current state of play with mobile malware, we’ll tell you what some of the most sophisticated mobile banking trojans are capable of, and then we’ll explain how we tackle the mobile malware threat here at Licel.
### Mobile malware in the financial sector
The seriousness of the threat to the financial industry can be gauged by the fact that there are currently around one hundred thousand malware programs active. Almost all of them are designed to target applications and end user data in some way, though some of them are more dangerous than others.
Many forms of malware, including keyloggers and spyware, have broad targets and objectives. They are sent out into the wild in the hope they inadvertently get downloaded onto a victim’s device and can cause a little bit of chaos.
But it’s malware that specifically targets banking apps (mobile banking trojans) that you have to be most mindful of. Banking trojans are laser focused on their goal of targeting specific financial apps and SDKs and stealing funds and sensitive user data.
Some of them are designed in such a way that they can lie dormant until the target banking app is opened on an end user device. Others have even been programmed to override biometric authentication on a device.
This threat is made worse by the fact that the malware delivery mechanism is getting more polished. There are a variety of [ways in which malware finds its way onto a mobile device](https://licelus.com/insights/how-bad-actors-deliver-mobile-malware-into-your-device), but they all tend to rely on the end user of a device being tricked in some way. And a combination of [AI making phishing scams more convincing](https://licelus.com/insights/ai-and-social-engineering) and people being more digitally distracted than ever before means attacks are finding their target with more regularity.
Here at Licel we recently had a candid conversation with the CISO of a financial institution who told us that bad actors had managed to clone the company’s app and had then begun a kind of marketing campaign of sorts to convince people to download this bogus version laced with malware. The attackers used marketing materials the bank itself had created to advertise their malicious version. They then spent several months gathering intelligence about customers so that they could even more convincingly imitate the bank when they came to launch their attack.
This sophisticated strategy highlights that the fight against malware is multi-faceted, and that [education about social engineering](https://licelus.com/insights/how-to-boost-your-social-engineering-awareness) should be included as part of a holistic security approach alongside robust, technical defensive mechanisms (which we’ll cover later in this article).
### What are mobile banking trojans capable of?
Our threat intelligence platform, Alice, has identified countless banking trojans in the environment of our clients’ applications in the last year or so. But some usual suspects have appeared again and again in that time, including Octo, Godfather, Ermac, Anatsa, Phoenix, and EventBot.
The attack method for each tends to be similar: a seemingly-legitimate and benign application (often related to time management, cleaning, or battery optimization) is downloaded by the end user. But unbeknown to the victims, this is actually a trojan dropper app either with the malicious payload embedded or downloaded by request from a command and control center.
Whichever way it happens, the end result is the same: the malware is successfully installed on end users’ devices, almost always without them being aware of it.
Banking trojans targeting the Android platform will often look to exploit Accessibility Services - a set of functions with the noble intention of helping people with disabilities to make the most of their phone. It has become a key target because of the permissions that Accessibility Services provides - permissions such as gaining access to SMS texts and notifications, viewing their contact lists, recording users’ on-screen activity, making calls from the device, and writing to external storage.
It’s clear that, in the wrong hands, this service can result in sensitive personal data being gleaned much more easily.
Most of the sophisticated banking trojans we listed above are programmed to log keystrokes, carry out overlay attacks to capture credentials, harvest contact information, and even put in place measures that make it impossible for the malware to be uninstalled or for antivirus engines to detect it.
Remember, the ultimate goal of banking trojans is to steal money and, where possible, attackers want to perform on-device fraud from afar and avoid fraud-monitoring alarms. The more automated bad actors can make this process, the easier it is for them to scale their operations.
Let’s go back to our list of malware repeat offenders we mentioned earlier and take a look at the fraudulent activities that two of them (Anatsa and Godfather) are designed to carry out:
Anatsa has the ability to steal login credentials (via overlay attacks, keylogging, or logging all accessibility events) with the goal of stealing money and intercepting SMS messages to bypass 2FA. It can also change input fields in banking apps via accessibility functionality to perform Device Takeover Fraud (DTO) and achieve remote access capabilities.
The Godfather trojan uses an overlay HTML phishing page to steal end users’ login credentials and can spy on SMS messages and steal OTP passwords in order to bypass 2FA. It can even open remote VNC sessions to act as the device owner, performing malicious transactions from the user’s device.
### How we combat the banking trojan threat at Licel
Hopefully the paragraphs above have convinced you of the scale of the mobile malware threat.
The question is: what can be done about it?
At Licel, our anti-malware approach is two-pronged and involves both [DexProtector](https://licelus.com/products/dexprotector) (our app and SDK security solution for Android and iOS) and [Alice](https://licelus.com/products/alice-threat-intelligence) (our threat intelligence platform).
We mentioned earlier that Alice is constantly monitoring the threat landscape of our clients’ apps and SDKs. Part of its activity is all about discovering potential malware threats installed on end users’ devices. This is important because if one of their end users does have dangerous malware installed on their device, then there is clearly more scope for their application to be at risk (and for associated trust and reputational damage with that customer in the event of something going wrong).
That’s why we don’t only monitor. The anti-malware module within the DexProtector Runtime Engine scans devices for malware and potentially harmful apps; if it finds something, then depending on the configuration it either closes the app or it reports the incident containing the data of its findings to the host app. We work closely with our clients to coordinate exactly what action is required. And with the latest Alice anti-malware updates, they can even configure their app protection behavior based on the category of malware that we’ve detected.
We’ve implemented the functionalities above as we’re aware that increasing numbers of businesses and institutions are keen on implementing more proactive anti-malware measures. Earlier this month, mechanisms like those we’ve just described above were identified as [a key priority by a group of Malaysian financial companies](https://www.nst.com.my/news/nation/2024/03/1022571/banks-exploring-ways-mobile-banking-apps-better-address-malware-issues), for example.
DexProtector also carries out more direct protection measures to mitigate the impact of dangerous banking trojans. Its UI protection functionality stops bad actors from exploiting Accessibility Services capabilities such as screen capturing. When an application has DexProtector’s UI protection implemented, attackers only see a black screen when they attempt to screen grab.
Anti-malware capabilities are absolutely vital in preventing mobile fraud in the financial sector and safeguarding end user trust in digital banking. [Get in touch with us](https://licelus.com/talk-to-us) if you’re keen to explore how you can keep your application safe.
## Virtual Execution Environments
[All insights](https://licelus.com/insights)
### Follow us
28 Jun 2024
### Why virtual trusted execution environments are set to boost mobile payment security
URL: https://licelus.com/insights/why-virtual-trusted-execution-environments-are-set-to-boost-mobile-payment-security
# Why virtual trusted execution environments are set to boost mobile payment security
Mobile payments are so omnipresent these days that it feels like a trick of the mind when you see somebody paying with cash or even with a physical card.
The fact that we’ve become so used to mobile payments so quickly is an incredible thing. We do it almost without thinking. But there’s also a rather unsettling correlation between the normalcy of digital transactions and the sophistication of attacks that seek to intercept and exploit them. Remember, the mobile phone was not originally designed or intended to securely make and receive payments.
That’s why enhanced security is needed to protect the most sensitive mobile transactions and operations. And it doesn’t get much more advanced than virtual trusted execution environments (vTEEs) which provide dynamic, payment-industry-proven layers of security to stop evolving threats.
As we’ve just launched [our own vTEE here at Licel](https://licelus.com/products/vtee), we thought we’d explain why we believe that as our collective payment habits shift to mobile, the security paradigm must evolve, too.
### What is a vTEE and what can it do?
A vTEE is a secure, isolated execution environment that offers rich cryptographic and security features to trusted applications, enabling them to carry out sensitive mobile transactions and operations. It can be used to stop attackers from stealing ultra-sensitive data including payment credentials and tokenised cards.
Let’s take a look at the Licel vTEE for a moment to give you a better understanding of exactly how a vTEE can work and what it can do.
As you can see from the illustration above, the Licel vTEE operates within the mobile application itself, but it can still communicate with the Android or iOS operating systems. It comes with a secure storage area where your most sensitive key material and assets can be kept safely. But the truth is that the vTEE is much more dynamic than a safe. A good example of this dynamism is its Software-based Cryptographic Module (SBCM) which implements cryptographic algorithms for white-box cryptography and also offers cryptographic features like RSA, ECC, and AES.
One of the most integral components of the Licel vTEE is a Trusted Virtual Machine which sits within it. This virtual machine works almost like a mini operating system and is where your trusted applets reside. Importantly, this virtual machine is also connected to - and can leverage - our mobile app security solution, [DexProtector](https://licelus.com/products/dexprotector). That means that as well as built-in vTEE security mechanisms such as device binding and white-box cryptography, it can defend itself with DexProtector’s code and resource hardening, RASP, integrity control, and other measures.
The benefits to mobile payment security of being able to leverage all of these defensive mechanisms are pretty clear. Sensitive mobile transactions require multiple layers of security, and the vTEE can call on those different layers.
If you imagine for a second that your physical passport is a representation of an application, then you’ll be able to visualise the different anti-tampering measures it can leverage, such as watermarks, hologram images, and unique ID numbering. But by far the most impressive anti-tampering measure of all is the chip that is built into it that enables quick and easy verification. This chip is the vTEE inside your application.
### What’s the difference between a vTEE and a TEE?
Most trusted execution environments are physical bits of hardware. The “v” in vTEE stands for virtual, and there’s one key reason why we created a virtual trusted execution environment: it is much more agile and flexible than a legacy hardware TEE.
We should caveat this by making it clear that we’re big believers that the best technology embraces harmony between hardware and software. Indeed, without hardware it wouldn’t have been possible for us to create the vTEE. But it's also true that hardware TEEs tend to come up against the same issue time and again; upgrades and fixes can take a very long time if and when vulnerabilities are discovered.
This isn’t the case with a virtual TEE. While a TEE might be out of action for weeks or even months, a vTEE could be upgraded and be back in action in days or even hours.
This agility represents a significant reinforcement that can save you from huge time and financial expenditure, not to mention the associated reputational damage of being offline for so long.
### How vTEEs can revolutionise mobile payment security
There are two innovative payment technologies in particular that can benefit massively today from the depth of security that vTEEs can provide. One is SoftPOS solutions that allow vendors to accept payments on their mobile device, and the other is mobile wallets. Let’s take a look at both of these use cases.
[SoftPOS](https://licelus.com/resources/use-cases/softpos) (or software point of sale) solutions are booming.They provide a great deal of flexibility to vendors as they can use their own mobile device as a payment terminal rather than having to invest in and maintain a card reader.
A vTEE can greatly enhance SoftPOS security as it provides a secure enclave within the solution’s software architecture. This means that sensitive operations such as PIN entry and payment processing are conducted in an isolated and secure environment. This is vitally important as it means that sensitive credentials and payment information remain secure even if the device or OS are somehow compromised. The secure execution area also prevents malware from interfering with payment transactions.
[Mobile wallets](https://licelus.com/resources/use-cases/mobile-wallet) are completely commonplace already, and trends such as Apple opening up NFC in the EU are set to increase competition even further in this sector. But there are serious risks to sensitive data if wallets don’t use enhanced protection (like that offered by vTEEs.)
As with SoftPOS solutions, secure storage is a big part of this enhanced mobile payment security for wallets. vTEEs can securely store payment credentials, cryptographic keys, and other sensitive user data from unauthorised access and tampering. With sensitive operations like authentication and transaction signing taking place in a secure environment, the risk of mobile fraud is also significantly reduced.
As you might be aware if you’ve read our articles regularly, here at Licel we place a lot of value on integrity. So much so, that we think without integrity there’s actually no such thing as security. Adding yet more layers of integrity control - on top of those already offered by DexProtector - was a big motivation behind us developing our own vTEE. For both SoftPOS solutions and mobile wallets, the vTEE can be instrumental in making sure transactions are genuine and no tampering has taken place.
It’s also worth noting that a vTEE can be massively beneficial for both SoftPOS and mobile wallet developers from a regulatory point of view. For PCI MPoC (in the case of SoftPOS) and EMVCO SBMP and EMVCO SBMP TEE (for mobile wallets), trusted execution environments are listed as necessary defensive mechanisms to prevent attacks. And so utilising a vTEE can go a long way in achieving compliance and certification.
We had our vTEE put through its paces by an independent lab, the result of which was that we attained an EMVCo SBMP TEE Security Evaluation Certificate. If you’re looking for a vTEE for your solution, then our recommendation is to go with an [evaluated and approved](https://licelus.com/emvco-evaluated) product as it will save you a lot of time and money on your certification journey.
### Future use cases of vTEEs
The most obvious opportunities for vTEEs right now lie in mobile payment security for the reasons outlined above. However, it’s not hard to think of lots of other potential applications and solutions that would benefit from the enhanced data privacy, protection against tampering, and integrity of sensitive processes and information that vTEEs offer.
Digital IDs are a good example. Countries around the world are working hard to develop mobile-based IDs that could be used for accessing electronic Government services, ePrescriptions, and digital passports, among other things. Clearly, if an attacker were able to fraudulently tamper with such an ID, the results would be fairly catastrophic both for individual citizens and for the wider impact on trust in such digital initiatives. A vTEE could make sure that sensitive day-to-day operations carried out with Digital IDs are isolated and secure from outside interference.
vTEEs could also be used to provide a secure environment for training AI models and protecting data from tampering. It might also protect AI models from reverse engineering attempts by securing both the model and its parameters.
And what about AR and VR operations? vTEE functionality could be a perfect fit for the secure rendering of sensitive data for both and providing a secure environment for executing code while protecting against malware and other malicious activities.
Cyber attacks are getting more sophisticated year-on-year, and the stakes have never been higher in terms of losses to mobile fraud and what a successful attack can do to business reputations.
We see vTEEs as timely reinforcements to even the odds, applying several more layers of depth and integrity to existing mobile channel protection and future-proofing innovative mobile payment solutions.
We’re incredibly excited about their potential impact in the coming years.
Find out more about the Licel vTEE, and feel free to get in touch with us if you have further questions
[Licel vTEE](https://licelus.com/products/vtee)
## eKYC Fraud Solutions
[All insights](https://licelus.com/insights)
### Follow us
12 Sep 2024
### How to tackle the growing threat of eKYC fraud
URL: https://licelus.com/insights/how-to-tackle-the-growing-threat-of-ekyc-fraud
# How to tackle the growing threat of eKYC fraud
Have you ever come across one of those posts about the advancements in AI technology that shows you 5 or 6 human faces and then tells you that only one of them is real?
Your instinct is to assume you’ll easily be able to identify the real human face. But a minute or two goes by and you’re still not sure. It could be number three, you suppose. Or do the eyes seem just a little bit too far apart?
In the end, you give up. And the realization that there’s simply no way of knowing for sure is a pretty disconcerting one. It also helps to explain why identity fraud has become much more complex and difficult to prevent in the digital world.
In this article we’ll focus on one of the fastest-growing areas of digital fraud; eKYC fraud. We’ll tell you how attackers are exploiting virtual ID verification - particularly in the world of mobile banking - and then we’ll explain how we’re helping to protect our clients here at Licel.
### What is eKYC? And why is it booming?
Electronic Know Your Customer (eKYC) has become an integral part of modern digital business processes in recent years. It enables identities to be quickly and securely verified across a range of industries, from banking to telecoms.
Let’s take neobanks as a use case example to better understand how eKYC verification works:
When someone wants to apply for a bank account, banks need to know they are who they say they are. That’s why they might ask that person to share a picture of their passport or another form of ID. But banks will most likely also ask them to take a selfie or a video of them talking. That way they can make sure that the ID that the applicant provided earlier matches the live, in-application version of them. If the answer is yes, then they get verified and can begin using the bank’s services (often the very same day), whether that is opening an account or applying for a loan or a credit card.
This process used to be a lot more complex and time consuming. It almost always involved in-person checks and a lot of paperwork, and so the benefits of eKYC verification from an efficiency standpoint alone are obvious.
There are other benefits, too; eKYC helps to keep costs down as it reduces the need for face-to-face verification and the maintenance of physical records. Making sure that customer identities are verified accurately and securely can also help compliance and certification bids. And it can vastly improve user experience.
That being said, there’s a fine balance between user experience and security, as we’ll explore later.
### The emergence and growth of eKYC fraud
For all the benefits of eKYC that we’ve covered above, there are plenty of challenges, too. Fraudsters have begun to find ways of bypassing and abusing the eKYC verification process – often using stolen or counterfeit documents to do so.
Machine learning and AI tools have also made it possible for cybercriminals to pretend to be someone they’re not in ever-more convincing ways. Just two or three years ago, we all would have backed ourselves to identify fake, virtual photos like those I mentioned above, but these days it’s a much tougher task. Struggling to identify the real homo sapiens in a lineup filled with several AI-imagined human characters is one thing, but the stakes are often much higher.
Earlier this year, [a scammer tricked an employee of a Hong Kong bank into wiring $25 million to a bogus account](https://arstechnica.com/information-technology/2024/02/deepfake-scammer-walks-off-with-25-million-in-first-of-its-kind-ai-heist/ \"https://arstechnica.com/information-technology/2024/02/deepfake-scammer-walks-off-with-25-million-in-first-of-its-kind-ai-heist/\"). They did this via a video call, using deepfake versions of the CFO and other company stakeholders to convince the victim. This was the first high-profile case of such vast quantities of money being lost in this way, but it almost-certainly won’t be the last.
Banks are well aware of the dangers of AI-assisted fakes being used in the eKYC verification process, too. They are spending huge amounts on liveness checks with a view to making sure that end users are uploading real photos or videos of themselves, and are not injecting deepfakes.
Cyber threats are shape-shifting. Some of the security challenges that keep CISOs and CTOs up at night today weren’t even on their radar a few years ago.
### How does eKYC fraud happen?
If attackers have already stolen parts of somebody’s identity, then they can go a long way toward completing the eKYC verification process. Identity theft can happen a number of ways, but often people are tricked into sharing information about themselves as part of a wider phishing or social engineering campaign.
You might be surprised by the lengths that some fraudsters go to in order to steal the identity of people that they can then use for later attacks – including eKYC fraud. There was an attack recently in the Middle East where bad actors created a fake version of their new mobile banking app and had even mirrored the bank’s marketing campaign in their phishing campaign. This led to a number of people mistakenly downloading the bogus app which collected personally identifiable information and credentials that could then be used in eKYC fraud.
Some bad actors also use advanced design tools to tamper with identity documents submitted during the eKYC verification process. Related to this is synthetic identity fraud, where an attacker will use a combination of real and fake information. This might be using a real social security number, but using a fictitious name or date of birth, for example. In this way, the attacker can bypass more traditional fraud detection tools.
Deepfakes, voice spoofing, and fingerprinting fakes have taken the manipulation to even more sophisticated heights. They can now be so convincing (as the Hong Kong bank story above attests), that they can bypass liveness checks and facial recognition systems. Bad actors can also leverage AI tools to generate realistic-looking documents as well as people.
### The impact of eKYC fraud
The upshot of these trends is an increase in the number of successful instances of eKYC fraud. And the more that bad actors can get around anti-fraud systems that banks employ, the more money those banks will lose to credit card payments (and other fraudulent transactions) carried out by people who don’t actually exist.
An associated negative impact can also emerge if individuals become aware that their personal identification or credentials have been used. This can result in a sizeable hit on business reputations.
There are also regulatory fines to consider. A failure to comply with KYC (and security) specifications can result in weighty penalties; some of which are especially focused around dealing with money laundering. Banks with insufficient fraud-prevention measures might find themselves facing legal action.
What is more, additional regulations are also coming into force that will [punish banks even more severely](https://kpmg.com/uk/en/home/insights/2024/07/cdd-and-generative-ai-risks-of-kyc-fraud.html \"https://kpmg.com/uk/en/home/insights/2024/07/cdd-and-generative-ai-risks-of-kyc-fraud.html\") if it emerges that they failed to prevent the onboarding of a fraudulent account.
### How to stop eKYC fraud
As you’re probably aware if you’ve read this far, the threat of eKYC fraud is multi-layered. And so stopping it must be, too.
On the one hand, this involves minimizing the social engineering threat in the first place and making it as difficult as possible for fraudsters to trick people into sharing their personal information. On the other hand, it’s about identifying suspicious devices, stopping deepfakes and image-injection based spoofing, and preventing bad actors from using versions of your app that are outdated, insecure, or that have been tampered with.
As the example we shared earlier from the Middle East shows, social engineering is becoming more and more sophisticated. [Scammers are utilizing AI tools to make their phishing attempts more convincing than ever](https://licelus.com/insights/ai-and-social-engineering \"https://licelus.com/insights/ai-and-social-engineering\"). We all have a responsibility to be as clear as possible with end users about the threats that exist and how to recognize [when a fraudster is trying to trick them](https://licelus.com/insights/beware-of-mental-traps \"https://licelus.com/insights/beware-of-mental-traps\"). eKYC fraud often involves attackers using some form of stolen identity, so attempting to stop this at source is vitally important.
To explain how to stop some of the go-to e-KYC fraud techniques, we’ll tell you how we do it here at Licel. After all, we’re currently securing the mobile channel between banks and 310 million end users of banking applications.
When it comes to preventing deepfakes and image-injection based spoofing, there are two key defensive mechanisms that our clients lean on. The first is [DexProtector](https://licelus.com/products/dexprotector \"https://licelus.com/products/dexprotector\"); and more specifically, its runtime application self protection (RASP) engine, which is able to detect compromised devices (say a device that is jailbroken or rooted). It also prevents exploits based on modifying app functionalities, and it stops interference with the app in memory.
Then there’s our Device ID module, which provides your authorization servers with unique, tamperproof device identifiers. It enables you to both log devices that may have been used for fraudulent activities in the past and continue to detect suspicious user activity.
Our anti-malware module is also a vital defensive component that combines both DexProtector and our threat intelligence and threat monitoring solution, [Alice](https://licelus.com/products/alice-threat-intelligence \"https://licelus.com/products/alice-threat-intelligence\"). The latter constantly scans your application’s landscape for threats, including the latest [mobile banking trojans](https://licelus.com/insights/the-battle-against-mobile-banking-trojans \"https://licelus.com/insights/the-battle-against-mobile-banking-trojans\"). Alice receives and analyzes incident insights from apps secured by DexProtector before sharing these insights with you so that you’re one step ahead.
As we’ve mentioned above, fraudsters will also often use outdated, insecure, or tampered versions of your app to evade security controls. Our API protection provides ways to identify trusted endpoints and reject API requests from fraudulent endpoints, as well as untrusted versions of the app.
### Future-proofing eKYC verification
One of the ironies of the modern world is that, the more convenient technology makes our lives, the more threats we sometimes expose ourselves to.
While the banking onboarding process has become infinitely simpler and more efficient, these benefits have come at a cost. Bad actors are now using bogus forms of ID and verification material to obtain accounts when they shouldn’t, which has resulted in huge financial losses.
In the months and years ahead, cyber threats – including deepfakes, voice spoofing, and manipulation of AI models – aren’t going to go away. They’ll only get more sophisticated. And so conversations about finding the right balance between usability and security are set to grow louder, too.
Future-proofing eKYC verification is going to rely on finding this balance. Up to now, the scales have swung firmly on the side of usability and convenience. As with everything in life, it can take time for them to swing back the other way and then to settle somewhere in the middle.
What is clear is that, if we want to continue enjoying the convenience of eKYC, then we need to ensure the integrity of the entire process. Integrity is the watchword for us here at Licel; it always has been. We’ll continue to do our bit to make sure that it is maintained throughout the eKYC verification process and that our mobile banking clients can be sure that the person behind the black screen is who they say they are.
Find out how Licel solutions help you to detect and stop eKYC fraud at the source.
[A Guide to eKYC Fraud Prevention](https://licelus.com/resources/knowledge_hub/ekyc-fraud)
30 Oct 2024
### How malware spreads: investigating a dangerous infection across India
URL: https://licelus.com/insights/malware-spread-india
# How malware spreads: investigating a dangerous infection across India
#### The mobile malware problem
Mobile malware poses one of the most acute cybersecurity challenges for application developers and owners to solve today.
That’s because malware can result in personally identifiable information, banking credentials, login details, and OTP codes (among other things) being stolen. And the pain that this causes individual users who accidentally download a malicious payload can also cause business headaches further down the line; think reputational damage and regulatory fines.
However, malware is also often seen as something of an invisible threat that is hard to measure, quantify, and visualize.
Our threat intelligence solution, [Alice](https://licelus.com/products/alice-threat-intelligence), is helping to change that.
Alice helps our clients to understand the threats that float and flutter around their application so that they can plot a sound security strategy more easily. Its data (based on attacks that our mobile channel protection solution, DexProtector, is preventing) tells a coherent story about where threats are coming from and how they are evolving.
We’ll tell you one of these stories in the following paragraphs. For this particular one, we wanted Alice to focus on the Indian market; a dynamic landscape full of innovative mobile applications and, sadly, bad actors unleashing sophisticated threats.
#### Detecting the netflixmirror malware
We’ve been enhancing and updating both [Alice](https://licelus.com/products/alice-threat-intelligence) and [DexProtector](https://licelus.com/products/dexprotector) consistently over the past couple of years with a view to identifying specific forms of malware more effectively. This commitment to continuous improvement is illustrated neatly in the chart below which shows the number of malware detections by DexProtector’s Build ID, with the latest build at the top.
We’re committed to developing our detection capabilities in the months and years ahead in order to continue to spot and stop malicious malware variants as they emerge and before they can cause any lasting damage.
While Alice was able to detect lots of different forms of malware spreading in India during our sample time period of August 2024, one of them clearly stood out as the most dangerous and prolific.
The malware com.example.netflixmirror was detected on user devices more than 629,000 times.
The name itself is interesting as it reflects a pretty common trend with malicious malware variants; they will often be named in such a way that they don’t stand out as looking suspicious. Netflix is one of the most popular streaming services out there, while screen mirroring solutions are incredibly common, too.
Hijacking authentic technologies and digital platforms can give malware a false level of legitimacy and help it to slip under the radar.
The graph below shows us that the number of daily unique installs of apps affected by the netflixmirror malware in India grew rapidly throughout our sample month of August 2024.
But how exactly does a malware variant like this spread?
#### The infection takes root
Alice’s data can also be used to paint a picture of the correlation between incident count and first occurrence count per package. The graph below suggests that as the number of malware incident detections increases, so too do the number of first occurrences – there is clearly a proportional, linear relationship.
This might lead us to the conclusion that malware packages (including the netflixmirror variant) behave similarly in terms of how they spread. The data also hints at detection methods consistently identifying new infections – or first occurrences – at a similar rate across different malware packages and similar rates of both spread and detection, regardless of their total incident count.
But let’s come back to the netflixmirror malware.
The graphs above are useful for providing us with the context of malware detection, but we wanted to explore – and visualize – exactly how this malware was able to spread so rapidly across an entire country.
The video below gives you an idea of how the malware spawned in Mumbai, spreading to other locations in Maharashtra. Then it really snowballed, gaining traction in the fast-growing tech cities of Bengaluru and, especially, Hyderabad. At the end of our selected time period, the malware has extended its reach to almost every corner of the country and has taken root up north in the capital, New Delhi.
### How malware spreads
Social engineering is undoubtedly a big factor in the speed with which the netflixmirror malware was able to spread across India. As we said earlier, this malware was clearly named with a view to tricking people into thinking they were downloading something legitimate and authentic – at least for those who were aware they had downloaded it.
Imagine receiving an email, text, or message from a messaging app when you’re busy and on the move that references Netflix or screen sharing. Perhaps the messaging is framed around an update that enhances your viewing experience. It’s easy to imagine clicking on a link and ending up downloading a bogus, malware-laden app by mistake.
App users can also be directed to third-party app stores and pushed to download cloned versions of legitimate apps. They can be encouraged to forward on bogus promotions related to the app harboring the malware via messaging apps. And malware can also land on victims’ devices via compromised adverts and malicious QR codes.
All of these scenarios help to explain how dangerous malware variants can spread so quickly around a country with a huge population of young, digitally-savvy people.
#### Mitigation measures
Detecting malware is only half of the battle, of course.
Here at Licel, our Anti-Malware module leverages both Alice Threat Intelligence and DexProtector. That means our clients’ applications are integrated with malware and Potentially Harmful App (PHA) detection capabilities. This can be customized according to individual requirements and delivers instant “over-the-air” updates.
More directly, our UI Protection module can mitigate the most common techniques malware uses to steal sensitive personal information. For example, it prevents some of the go-to Accessibility Services exploits on Android such as screenshots, screen sharing, and screen recording.
In the case of this netflixmirror package, our solutions enabled our clients to prevent their apps from functioning on devices infected with the malware.
Mobile malware is a particular problem in the mobile banking industry.
Read [our use case](https://licelus.com/resources/use-cases/mobile-banking) to find out how we’re solving security challenges in this key sector.
## Understanding Trusted Applications
[All insights](https://licelus.com/insights)
15 Dec 2024
### What is a Trusted Application?
URL: https://licelus.com/insights/what-is-a-trusted-application
# What is a Trusted Application?
The more sensitive that our digital transactions and operations have become, the more it makes sense for us to think of the mobile ecosystem as being split into two worlds:
The **trusted** world, and the **untrusted** world.
In a recent talk about Trusted Applications and Trusted Execution Environments, our co-founder and CTO, Mikhail Dudarev, spoke about the concept of Trusted Execution. For something to be trusted, he said, means embracing **isolation**; removing the influence of the external world towards a component.
That is what a Trusted Application and Trusted Execution Environment can help you to achieve.
In this article, we’ll explain how.
#### Defining a Trusted Application
The digital world is anything but simple, of course. In the next breath of his talk, Mikhail also acknowledged that it can be quite limiting to not be able to communicate with the external, untrusted world.
We’ll explain the solution to this conundrum shortly. But first, let’s attempt to answer the question posed in the title of this article: what is a Trusted Application?
A Trusted Application is a specialized app that is designed to run within a Trusted Execution Environment (TEE). It exists to handle sensitive cryptographic operations such as encryption, decryption, hashing, signing, authentication, and secure storage. And it provides an extra layer of protection by running in an isolated and secure environment.
A Trusted Application is part of the trusted world concept that Mikhail was talking about; and indeed the wider concept of **Trusted Execution**. The main idea of this concept is to separate the execution environment between the trusted and untrusted worlds. Its goal is to bring security to untrusted devices.
In the image above you’ll see that either side of the Platform Hardware lie our two worlds. There’s the untrusted world, with its Rich OS and Client Application(s) operating within a Rich Execution Environment; and then there’s the trusted world, with its Trusted OS and Trusted Application(s) operating within a Trusted Execution Environment.
So, in the trusted world you have a Trusted Application that implements some sensitive code from within a safe and secure environment where this app can run. You also have the API (TEE API) which allows the application to communicate with the external world. This is a large part of the answer to the conundrum we referenced earlier.
##### This process aligns with the main characteristics of a TEE and, by association, of a Trusted Application:
The first one – which we’ve already covered – is **isolation**. Then there’s **confidentiality**; we want to prevent data that is owned by one Trusted Application from being obtained by another application. This is important because another key objective here is **integrity** – making sure that the Trusted Application has not been tampered with or modified and, also, making sure that the whole environment around the app is safe. Another characteristic of Trusted Applications and TEEs is **secure execution**. The idea here is that nobody be allowed to interfere with the app’s processes or carry out a side channel attack in order to understand what is happening inside the execution process. Without this secure execution, attackers could identify the sensitive logic of an application and extract private keys from the memory. Finally, there’s **controlled access**, which means that each Trusted Application only has access to its own resources and not those of other applications.
Hopefully these characteristics are already clarifying in your mind why a Trusted Application and TEE might be helpful. Particularly for verticals where applications are carrying out incredibly sensitive transactions or operations. After all, a Trusted Application might work with some critical business logic, or it might implement IP algorithms that need to be worked on in isolation. Think about [mobile wallet](https://licelus.com/resources/use-cases/mobile-wallet) solutions, for example, or [SoftPOS](https://licelus.com/resources/use-cases/softpos) solutions that enable vendors to accept payments on a mobile device.
Organizations in these sectors are already using [our own virtual TEE solution](https://licelus.com/products/vtee) (we’ll explain more about this later) to create and run Trusted Applications.
#### What level of Trusted Execution do you need?
The concept of TEEs has been around for longer than you think.
The first example of a Trusted Execution Environment is arguably Java Card. It was created in 1997 with the idea of ensuring an app firewall for hardware devices. If you still own a DVD player, take a look at the back of it and you’ll probably see a Java logo.
These days, Java Cards are in all of our phones because smart cards, e-sims, and bank cards all use Java Card technology. You might not think about it very often, but in the second that it takes for you to place your mobile device in the electromagnetic field and make a payment using an NFC terminal, a lot of magic happens. The Java operating system powers up and a special Java Card Applet (Trusted Application) is selected, which performs some security operations and returns a signed cryptogram to the payment server for processing.
Until recently, a TEE was almost always a hardware solution. And there are three main ways that TEE architecture can be implemented with hardware:
The most secure - but least used (because it’s expensive) - is using an external secure element like a SIM card to perform a sensitive operation. Another variant is when a TEE is embedded as a chip on your phone and shares some memory to communicate with your application or some Kernel drivers. The third way that TEE architecture can be implemented with hardware (and the most common in practice) is when a TEE is implemented directly on the processor. This could be either via ARM TrustZone or Intel Virtualization. If we take the former as an example, then a special register in an ARM processor is used to switch each operation and tell the processor exactly whether the operation is happening in the trusted world or the untrusted world.
These TEE implementations exist to solve a persistent challenge for mobile app developers; how to work with cryptographic operations and keys in a secure way. Imagine if some secret keys were stolen from your device and then used by attackers on another device to access banking systems or other sensitive operations, for example.
It was in response to critical challenges like this that Google initially released the Android Hardware Keystore, where they guaranteed that all operations involving secret keys would take place in an isolated environment, albeit stopping short of guaranteeing security. Then, from Android 9, Google introduced StrongBox.
Android StrongBox uses the second TEE implementation variant (with a separate chip) that we covered above. It operates in the secure, trusted world, with a TEE on a chip, and a Trusted Application called Keymaster which operates with cryptographic keys. Then there’s a layer that communicates from the client application to the trusted world.
##### So, is StrongBox strong enough?
If you choose a cipher and encrypt some bytes using this cipher (as with the code example below), then Android StrongBox guarantees that these keys can’t be extracted from the trusted execution element. The only public thing that might be exposed is plainBytes, but that isn’t concerning here. We care more about encrypted bytes.
In this example we can be satisfied that StrongBox **is** strong enough.
```java
Cipher cipher = Cipher.getInstance(\"AES\");
cipher.init(Cipher.ENCRYPT_MODE, key);
byte[] encryptedBytes = cipher.doFinal(plainBytes);
```
**key** is never exposed outside
**plainBytes** could be exposed
However, if we add two simple lines of code and make the encryption process slightly less straightforward, or if we want to decrypt data and then re-encrypt it using a different key, then enough has changed here from an application security perspective. In the code example below, we’re less sure about the strength of Android StrongBox.
```java
// decrypt data
Cipher cipher = Cipher.getInstance(\"AES\");
cipher.init(Cipher.DECRYPT_MODE, decyptionKey);
byte[] decryptedBytes = cipher.doFinal(encryptedBytes);
// re-encrypt data
cipher.init(Cipher.ENCRYPT_MODE, encryptionKey);
byte[] reencryptedBytes = cipher.doFinal(decryptedBytes);
```
**decyptionKey**, **encryptionKey** is never exposed outside
sensitive **decryptedBytes** could be exposed
You see, when we re-encrypt data, we’ve decrypted bytes in the application memory. And when these decrypted bytes are transferred from secure elements through different interfaces to application memory, they can be hooked and dumped millions of times using simple debuggers like Frida. An attacker could obtain this data and influence your application processes.
In conclusion, then, StrongBox is strong enough to secure some primitive cryptographic operations. But when it comes to protecting sensitive cryptographic algorithms, it isn’t strong enough.
Keep in mind, too, that the example above is a fairly simple one. If you imagine some complex payment schemes where you need to make transactions, then the situation is even more complicated and you risk completely losing control of the execution of your code.
#### Enhanced security with Virtual Trusted Execution Environments
The example above highlights that traditional TEEs come with some limitations. Not all cryptographic algorithms are supported, and it’s a closed platform which means you can’t extend to or create new Trusted Applications.
Hardware TEEs also tend to be vendor locked. Each vendor – Google, Apple, or Samsung, for example – have their own implementations and different limitations. And this can make things pretty complicated.
There are also performance issues to consider with legacy TEEs. If we’re talking about the third type of architecture (ARM TrustZone) that we covered earlier, then these can be pretty fast. But embedded secure elements cannot be fast by design because it’s a separate processor.
The idea of our vTEE was to take the Trusted Execution Environment from the phone – from a hardware platform – and to put it into a mobile application. This means that during the integration phase and the protection phase, the vTEE is like a trusted virtual machine that executes the Trusted Application, deals with secure storage, and works with cryptography. So, your app contains its own TEE as well as a Trusted Application.
The image below should help you to visualize how it works.
Circling back to the key characteristics of a TEE from earlier in this article, there’s plenty of synergy here, too, because the most important characteristics of the Licel vTEE are **isolation**, **controlled access**, and **integrity**.
A vTEE brings the benefits of cross-platform compatibility, too. So, by definition the vTEE is a software implementation with only a little bit of hardware dependency. This means that a Trusted Application created using the Licel vTEE could run inside mobile apps for the Android and iOS platforms.
And because it’s a software-based implementation, the vTEE allows you to create your Trusted Application based on different techniques. You can write a native application, or you can write Java applications that utilize Java Card API, to implement its functionality.
The nature of a virtual TEE also makes it scalable. There’s no mobile platform vendor lock, so you can deploy it on a wide range of devices from different regions. It’s pretty much open to developers to decide how they influence or create real security components for mobile applications.
So, you see that there are some significant advantages of a Virtual Trusted Execution Environment over a traditional TEE. However, at Licel we’re great believers that the best tech solutions involve some kind of combination of both hardware and software elements. We see our vTEE as a helpful reinforcement in the marketplace rather than a complete changing of the guard.
Whether you opt for a traditional TEE or a virtual one like ours, we hope that if you’ve read this far then you now have a much better idea about what a Trusted Application is - and you understand why it’s so important to the future of secure app development.
Licel’s vTEE has now been EMVCo evaluated and approved for both major mobile platforms; Android and iOS.
[Read our press release](https://licelus.com/company/news/licel-vtee-achieves-emvco-approval-for-android-and-ios)
## Mobile Banking Security Threats
[All insights](https://licelus.com/insights)
### Follow us
24 Feb 2025
### Mobile Banking Security Threats: Understanding the Risks and Solutions
URL: https://licelus.com/insights/mobile-banking-security-threats
# Mobile Banking Security Threats: Understanding the Risks and Solutions
According to McKinsey, the share of consumers actively using mobile for their banking needs [climbed 18% between 2020 and 2023, to 57%](https://www.mckinsey.com/industries/financial-services/our-insights/the-state-of-retail-banking-profitability-and-growth-in-the-era-of-digital-and-ai \"Mobile-first integrated distribution strategy\").
Given the number of touchpoints on the mobile channel, it’s not surprising that McKinsey recommends banks prioritize apps for their consumer interactions. Especially when you consider that the banks who are leaders in mobile are also the leaders in retail banking overall.
For banks, maintaining their pre-eminence isn’t only down to making sure these mobile touchpoints are as seamless as possible, or making sure the UX is clearer than it is on rival banking applications. Security is also a vital consideration.
And it’s security that we’ll be focusing on in this article. We’ll take a look at some of the most sophisticated mobile banking security threats out there, we’ll explore the impact of successful attacks both on end users and on the banks themselves, and we’ll explain the level of security required for banks if they want to repel modern threats and maintain their hard-earned reputation in the sector.
This article isn’t about fearmongering, however. We’re not portraying mobile banking as the Wild West, rife with bandits running riot, compromizing mobile banking apps at will and making off with your funds.
Mobile banking is relatively safe for most of us, because most banks acknowledge the threats that exist and equip their applications with the robust protection mechanisms required to defend themselves.
The problem is that this isn’t true of all banks, and attacks are getting ever more sophisticated and menacing – partly as a result of AI. Some analysts would argue, justifiably, that even one customer losing their credentials or funds is one too many.
The truth is that, despite many of us using mobile banking apps for a decade or more, it still sometimes feels like security on the device is assumed more than it is prioritized or even demanded. But things are changing. In a world full of hyper-realistic forgeries powered by increasingly influential AI models, assuming anything is no longer sufficient. What is more, new regulations are setting strict penalties for banks that fail to adequately protect their customers.
Here at Licel, we’ve spent the last 14 years or so working with banks worldwide – both traditional and digital – to fortify their apps against attacks. This work has convinced us of the severity of the security threats facing mobile banking applications. But it has also reinforced our belief that there are actionable solutions to the challenges that banks face.
Let’s take a look at some of those challenges and solutions now.
### Mobile banking trojans
Malware that is designed specifically to target mobile banking applications are known as mobile banking trojans. A couple of years ago [Kaspersky experts detected nearly 200,000 of them](https://www.kaspersky.com/about/press-releases/200000-new-mobile-banking-trojan-installers-discovered-double-the-2021 \"200,000 new mobile banking Trojan installers discovered, double the 2021\"). It’s an incredible and alarming number.
Mobile banking trojans often arrive on a user’s device via a seemingly innocuous – and often quite boring-looking – apps such as file managers. Once installed, these apps can then request the permission to install other packages that are vital for the trojan to operate.
Some trojans – as the name hints at – can lie in wait, dormant, after being invited inside the city walls (i.e., when the payload has been delivered and downloaded) until the time is just right for them to strike. This often means when a mobile banking app is opened by the victim.
Then there’s spyware, which haunts the end user constantly, delivering a live feed of their private activity on the device to attackers. This includes what they’re doing on their mobile banking application, of course.
Trojans are often designed to exploit Accessibility Services – on Android devices at least. This tool, designed to help people with disabilities to be able to use their mobile devices, can enable trojans to overlay fake screens made to look exactly like those in the legitimate application. It can also help them to log keystrokes – and thus discover their victims’ login credentials and card details.
Some particularly sophisticated varieties of trojan can even use Accessibility Services to override or disable security mechanisms such as antivirus applications.
The danger to end users here is clear: if they aren’t careful, then they could end up with a hidden menace on their devices capable of stealing their credentials, or worse; stealing significant amounts of money from their accounts.
Some banking customers are less cautious than others and, as a result, they might be in a position that makes a payload arriving on their device more likely. This includes rooting their device and downloading apps away from recognized platforms such as the App Store or Play Store, for example.
But others customers can just be unlucky. They might fall for a social engineering scam and click on a link they shouldn’t, for example. This is something that can unfortunately happen to any of us – even those of us who think we’re tech savvy and unlikely to fall for the [mental traps](https://licelus.com/insights/beware-of-mental-traps \"Beware of mental traps\") that scammers set for us.
In the end, we probably need to accept that malware will continue to land on end users’ devices, [and then spread quickly to others](https://licelus.com/insights/malware-spread-india \"Malware spread india\"). So, what can be done about it?
Intelligence is vital. Ideally, banks should make use of a comprehensive threat and device intelligence solution capable of detecting both malware and Potentially Harmful Apps (PHAs). This will flag indicators of possible interference worthy of investigation by the bank’s security analysts.
Another incredibly effective countermeasure is called device binding. Linking a user’s account to a specific device helps to prevent trojans from stealing or modifying user data via remote access attacks (where a malware variant tries to gain remote access to a device to steal sensitive information).
Banks must also enforce UI Protection. This stops some of the go-to Accessibility Services exploits that we’ve outlined above and protects against screen capture (attackers can still attempt them, but the end result will be a black screen). It also minimizes the threat of IP theft and remote access fraud.
### Account Takeovers
Malware can also be used by bad actors to initiate an account takeover. After all, the user credentials they attempt to extract via Accessibility Services exploits can then be used to fraudulently access the victim’s account.
The objective of an account takeover is to take control of a user’s bank account to steal funds, make unauthorized or illegal transactions, and to open new accounts or access additional banking services such as credit cards and loans.
Malware isn’t the only attack vector open to fraudsters to achieve this aim, of course. They can also physically steal a victim’s phone and access their account that way. Or, more typically, they can carry out credential abuse by tricking their victim into voluntarily giving up their login details. This might be via a social engineering campaign, or as a result of the victim mistakenly downloading a bogus, cloned version of the app after being convinced that it is an updated version of the genuine one. Attackers can then harvest login credentials and other sensitive information from this fake application.
Whatever the attack vector, the end result is always the same for the victim; a deeply traumatic experience. As for the bank itself, the more customers suffer account takeovers, the more their reputation is likely to diminish.
So, what must banks do to prevent account takeovers from succeeding?
The anti-malware mechanisms that we covered in the previous section ring true here, too, given that malware is a key attack vector for account takeovers. As for credential abuse, there are several protection mechanisms to keep in mind:
Once again, device intelligence is vital. A robust intelligence solution can use a device or session identification mechanism to detect when an account is being accessed by a device that isn’t associated with that given user. Banks need to make sure that their apps are capable of analyzing device attributes and user behavior to spot anomalies that might be indicative of bad actors carrying out credential stuffing, brute force attacks, or session hijacking. Once detected, action can then be taken to prevent the fraudulent device from accessing the application. And binding a users’s account to a specific device can also help to stop bad actors from stealing or modifying authentication data.
Another threat to be protected against is man-in-the-middle attacks. This is where attackers hijack a network - often an unprotected one without a password - with a view to intercepting authentication data. Imagine you’re in the airport and you want to send a payment to the hotel before your arrival. So, you log onto the free airport wifi and open your mobile banking application. At this point an attacker on the network could hijack your connection and steal your credentials. It really isn’t worth the risk.
The danger of credentials being stolen in all of these scenarios also reinforces the importance of multi-factor authentication (MFA) given that, when enforced, user credentials alone aren’t enough to access the bank account. Please do make sure that you enable MFA for this reason.
### eKYC fraud
Another big challenge facing banks is [eKYC fraud](https://licelus.com/insights/how-to-tackle-the-growing-threat-of-ekyc-fraud \"How to tackle the growing threat of eKYC fraud\"). This is where attackers attempt to bypass or exploit the eKYC (electronic Know-Your-Customer) checks that banks carry out before onboarding new customers.
With the advent of AI, it is becoming easier for bad actors to generate fake ID documents and even photos and videos to help them pass these checks and convince the bank that they are indeed dealing with a real person.
One common approach is for attackers to use a virtual camera and faked faces in order to pass the eKYC check. [Deepfakes use AI models to effectively trick the eKYC system into thinking that it’s the real person](https://www.trendmicro.com/vinfo/th/security/news/cyber-attacks/ai-vs-ai-deepfakes-and-ekyc \"AI vs AI: DeepFakes and eKYC\"). Some people pay for a more sophisticated fake, but it’s also possible to trick some eKYC systems with a fairly rudimentary, low-resolution video based off of a passport photo. Right now, it feels like some automatic eKYC models aren’t up to the task of differentiating between real homo sapiens and bogus, AI powered versions.
This is a very big problem, because pass the eKYC checks, and the fraudster can obtain a bank account, credit card account, apply for a loan, and so on. This can then result in the bank in question losing significant quantities of money (and time) as a direct result of eKYC fraud, not to mention the time and money required to firefight and deal with the fallout afterwards.
Banks also run the risk of regulatory fines if it comes to light that they have failed to comply with KYC (and security) specifications. Banks without robust fraud prevention measures in place could find themselves facing legal action, too, given that some eKYC fraud might be linked to money laundering.
eKYC fraud can, like other attacks covered in this article, also impact end user trust and the bank’s reputation. Particularly if it emerges that an attacker has used a customer’s credentials.
Stopping eKYC fraud requires multiple layers of interconnected protection. It’s about identifying suspicious devices, stopping deepfakes and image-injection based spoofing, and preventing fraudsters from using outdated, insecure, or tempered-with versions of a bank’s application.
Because the eKYC process can be interfered with and tricked, as we explained above, ideally the checks should be carried out in an isolated and secure execution environment that cannot be tampered with. And eKYC data must also be encrypted if it is stored on the device to stop unauthorized access or modification – including by malware.
We also recommend that banks equip their applications with protections against network and man-in-the-middle attacks that target eKYC data transmission. Recommended protection mechanisms include TLS Certificate Pinning and Certificate Transparency, which both help to verify that the app is communicating with the legitimate backend server.
Finally, as with the other attack examples, banks should use a threat and device intelligence solution that means their application can analyze both device attributes and user behavior to detect anomalies that may point to evidence of identity fraud.
### Social engineering
All three of the mobile banking security threats we’ve covered above tend to have some form of social engineering element to them.
Mobile banking trojan payloads often arrive on a victim’s phone via a link in a phishing email, or via a bogus application that they have been tricked into downloading. Account takeovers are sometimes facilitated by a user sharing their credentials (perhaps after the attacker claims to be a banking employee in order to overcome initial resistance). And eKYC fraud, too, can be made easier if banking customers share their personal information.
So, social engineering is a constant threat that can enable and expand the reach of other attacks and needs to be tackled at the same time. The difficulty, of course, is that social engineering isn’t a technical attack that can be stopped with robust, technical solutions. Social engineering targets human emotions and so it is much less predictable.
Sometimes our instincts lead us to behave in a way that might not be the safest from a security perspective. We’ve been hard-wired to react to situations almost without thinking – holding the door open for someone, for example, the desire to help people, or the instinct to rely on authoritative voices. All of these can be exploited by bad actors to trick us and steal from us.
[Social engineering isn’t a new concept](https://licelus.com/insights/the-psychology-of-social-engineering \"The psychology of social engineering\"); it’s been with us for thousands of years. It’s just the delivery method that has changed. We’re now getting tricked via our favourite device that we naturally associate with spontaneity, fun, and trust. All in all, it’s the perfect storm.
And that’s before you add the impact of AI into the mix. At the very least, [AI models have made phishing messages much more convincing and effective](https://licelus.com/insights/ai-and-social-engineering \"AI and social engineering\"). Do you remember the days when it was quite easy to spot a scam message because of the quantity of grammar and spelling mistakes? Those days are over. Now you can train your AI assistant to write personalized imitations of official bank communications in the style of the world’s finest copywriter.
More complex scams that might previously have required bad actors to invest significant funds into employing and training scammers in a call center can now be done via AI-powered voice assistants, designed to trick banking users into transferring funds, sharing their account details, or revealing authentication codes.
And if the attackers think that their target banking customers might be more likely to comply if they were asked by someone with a specific accent – say a well-educated, softly-spoken English lady from the Home Counties – then that too can be arranged thanks to AI.
Without a doubt, the storm clouds have darkened as a result of AI. And it’s up to banks to calm the waters:
A secure, verified, communication channel within the app itself can go a long way in stopping end users being tricked by fake customer support scams. And repeated warnings about ignoring messages – however convincing they are – that appear to be from the bank but are actually from unverified sources, can hammer home the message.
Banks can also set some rules within the app that require additional authentication for high-risk transactions that involve large sums or a new payee. Some forward-thinking banks have even set up a sort of cooling off period of several hours before a transaction can be approved and finalized. They should also consider enforcing the ability to detect active voice calls while the mobile banking application is in use as an additional layer of protection for the user and to prevent them being manipulated.
The thing is, social engineers rely on you acting impulsively, without thinking. They’re desperate for you to embrace the instinctive, almost-tick-like behaviors that we learn from a very young age. Take the advantage of time away from the attacker, and things tend to become clearer. We’re much more likely to think logically about a given situation.
Remember, if you have even the slightest doubt in your mind about making a transaction, pause and take a step back. Speak with friends or family members, perhaps, and then ask yourself an important question: do I trust this person?
### Navigating mobile banking security threats
The impact of AI on banking app attacks reminds us that nothing stays the same for very long. Technology trends are fluid. They’re always evolving. And attacks evolve with them. That means that mobile channel protection solutions also need to be updated and enhanced to counter the latest, most sophisticated threats.
This is another important reason why banks should use a reliable threat and device intelligence solution. Their security analysts can dig into the data to understand the trends around different types of attacks, which in turn can help them to create a more solid security strategy in the long run.
Here at Licel, we’re firm believers in the concept of [continuous security](https://licelus.com/resources/guide-to-mobile-application-protection/practice/continuous-security \"Continuous security\"). That’s why we have our products evaluated by external laboratories and [approved by respected industry bodies like EMVCo](https://licelus.com/company/news/dexprotector-achieves-emvco-approval-for-5th-consecutive-year \"DexProtector achieves EMVCo approval for 5th consecutive year\"). We want to be completely sure that our solutions are ready to deal with the latest threats – including those that have been enhanced by AI.
Banks also need to make sure that they are also alert to how attack trends are evolving and don’t get complacent that security solutions that have worked in the past will continue to be effective now and in the future.
If they’re not alert, then they’ll end up wasting significant amounts of time and resources dealing with the fallout of fraud, potentially fall foul of industry regulations, and suffer a loss of trust among their customers that will hit their business reputation hard.
The choice between all of that and making an investment in reliable mobile channel protection really should be an easy one to make.
If you’re interested in a wider view of the threats facing mobile banking applications and how Licel solutions help to stop them, check out our mobile banking use case.
[Read our use case](https://licelus.com/resources/use-cases/mobile-banking)
## Asia's Mobile Payment Landscape
[All insights](https://licelus.com/insights)
### Follow us
01 Jun 2025
### Asia’s Mobile Payment Revolution: What the rest of the world can learn – and why security must catch up fast.
URL: https://licelus.com/insights/asia-s-mobile-payment-revolution
# Asia’s Mobile Payment Revolution: What the rest of the world can learn – and why security must catch up fast.
Asia is reshaping the future of digital payments. From QR-code ubiquity, to super app ecosystems and interoperable payment channels across borders, the region has embraced the immediacy of mobile devices more fully than any other.
This has led analysts to wonder whether mobile payment trends there might be a signal marker for the next chapter in mobile finance in other parts of the world.
Asia’s unique flavor of super app usage and innovative biometric authentication might not be quite so simple to replicate in other regions, for reasons we’ll explore later, but leaders and innovators around the world are watching on closely. For those seeking to build the digital infrastructure of the future, Asia is arguably the most interesting place to look for inspiration.
But where innovation moves fast, new threats follow - novel attack vectors are emerging and evolving all the time. The Asian mobile payment landscape provides us with insights about the type of protection mechanisms that are required for mobile apps to defend themselves today. And it offers us clues about the kind of security that will be required in the future.
We'll unpack all of this in the paragraphs below.
### Examining Asia’s mobile payment landscape
Asia isn’t one homogenous market, of course. It’s a patchwork of different cultures, economies, user behaviors, and regulatory frameworks. We know that daily digital habits aren’t the same in Delhi, Bangkok, Shanghai, and Seoul.
That said, when it comes to digital payments, there are some unifying themes that have emerged in recent years:
Perhaps the most obvious is Asia’s mobile-first behavior. In some SE Asian countries in particular, many users leapfrogged desktop internet access altogether. A high proportion of young, digitally-savvy citizens means that the mobile device has been - and remains – people’s main portal to the online world. And that helps to make mobile apps the go-to for almost every activity; including payments.
When the World Economic Forum carried out some research into the global adoption of e-wallets, for example, [nine of the top 10 were Asian countries](https://www.weforum.org/stories/2023/11/asean-instant-cross-border-payments-paynow-promptpay/), with Thailand, Vietnam, and India making up the top three.
QR codedominance is another trend that links the majority of Asian markets. QR code-based payments are the method of choice for small street food vendors and large retail chains alike. They offer a simple, low-cost, and efficient transaction method without the need for heavier infrastructure demanded by more traditional POS systems. This reduces barriers to entry and lessens friction, opening up the digital economy to everyone. History has taught us that the simplest tech for users to get to grips with will win out and dominate, one way or another. But it’s also true that the most intuitive, immediate tech habits are not always the safest.
Asia is also famous for its super apps. Platforms like WeChat, Alipay, Gojek, and Grab bundle messaging, e-commerce, transportation, food delivery, and payments into one seamless experience. This has obvious benefits for end users who can manage and sync a range of day-to-day digital activities using a single application. We’ll explore super apps and why they haven’t become quite as common in other markets later.
Unlike in other regions, there’s also more maturity when it comes to payment interoperability across countries in Asia. There’s a strong desire to reduce friction and make cross-border transactions easier and cheaper for people to make.
These trends have resulted in mobile payments in Asia looking quite different compared with other regions.
### Payment interoperability and regional integration
A big trend in recent years in Southeast Asia has been the push for interoperability between national QR code systems. Central banks and payment authorities are working together to connect systems across borders, enabling travelers to make payments in foreign countries using their domestic wallets.
One example is the linkage between Thailand’s PromptPay and Singapore’s PayNow systems; a scheme that allows individuals to make real-time, low-cost transfers of up to around US $700 per day. There are still costs applied to make transactions in Thailand (it’s free in Singapore), and there is a small foreign exchange markup applied by the banks issuing the transfer, but the overall fee is much lower than what senders used to have to pay (up to 10% of the total amount). And the speed is a massive game changer; historically cross-border transfers might have taken several working days to process.
Other countries, including Malaysia, Indonesia, and the Philippines, are also collaborating through ASEAN initiatives to expand this network. The World Economic Forum forecasts the value of gross digital payments across the six largest ASEAN economies to rise to [close to $1.2 trillion by 2025](https://www.weforum.org/stories/2023/11/asean-instant-cross-border-payments-paynow-promptpay/). And so there is a great incentive to facilitate these transactions.
This interoperability of mobile payments in Asia has practical benefits for tourism, trade, and remittances, but it’s also a sign of something much deeper: there’s a shared commitment in the region to embracing seamless, mobile-native financial ecosystems that make finance easier for people.
The world is changing, and becoming more global than ever in outlook. From businesses operating in different continents to digital nomads moving countries several times a year, frictionless payments across borders are now expected or even demanded by consumers - particularly from those who have seen what is possible with mobile payments in Asia. But the reality in other regions is often a bit of a let down. There is often a lot of legacy complexity when it comes to traversing payment networks and connections around the world. Whether other regions like Latin America and Europe can match the seamless direction of travel in Asia remains to be seen.
### Asian super apps are redefining finance
Asian super apps like Alipay, WeChat Pay, Gojek, and Grab have redefined what a single application is capable of, by combining daily smartphone activities like social interactions, e-commerce, and financial services.
These apps offer frictionless in-app payments alongside other functionalities and services such as lending. The vast quantity of data that they process (about a range of activities – not only financial) means that they can leverage insights to personalize financial offers in real-time. They provide the convenience of a single interface for day-to-day interactions and transactions, removing the need to interact with traditional banks at all to some extent.
As we said earlier, some Asian consumers skipped desktop internet access altogether, and traditional financial institutions are also less entrenched than in other markets. The upshot of this is the meteoric rise of platforms like WeChat in China (which is integrated into the daily lives of over a billion users). Asian super apps are more than just wallets: they’re financial ecosystems.
Super apps make everything so seamless and convenient that there is very little need or incentive for users to leave. They can chat with their friends, order food, and check their bank account in a few seconds. The benefits to developers of super apps are just as impressive; the amount of data they can collect about a vast array of activities means they have a detailed window into the digital lives of millions (and sometimes even billions) of people. This is incredibly valuable.
And so, the question that is often asked is: Why aren’t super apps a thing in the rest of the world?
Why isn’t there a super app in the US, for example?
The answer might have more to do with history and culture than we think. Confucian values of harmony, hierarchy, and communal benefit dominate in Asia. And that means there tends to be more acceptance of centralization – either from government, private enterprises, or even digital platforms – so long as they offer convenience and make life easier. In the West, on the other hand, a culture that encourages debate, autonomy, and a healthy skepticism of central power bases (going back to Ancient Greek philosophers who were writing around the same time as Confucius) makes it harder for a company like Amazon or Meta to replicate what WeChat has achieved in China. These organizations are already the focus of antitrust laws, after all.
### The security and compliance implications of Asian mobile payment trends
So, what do all of these Asian mobile payment trends mean for security?
The obvious danger of super apps from a security perspective is that there’s a broader attack surface; in theory there’s a lot more at risk. One compromised set of credentials or API might result in users’ banking credentials, digital identification, and healthcare data all being at risk, all at once. Attackers might look to reverse engineer a super app in order to discover (and even steal) IP, which is one of the reasons why robust encryption and obfuscation of application assets and logic is so important.
Another growing threat is unauthorized API access – whether that’s attackers exploiting older, outdated apps to circumvent security controls, or carrying out API requests from non-mobile endpoints, allowing them to avoid device-based security checks. [Mobile API protection](https://licelus.com/resources/knowledge_hub/mobile-api-protection) is therefore vital, as it allows you to verify the integrity and legitimacy of the application initiating an API request.
Device attestation and anti-malware protection is also vitally important to keep super apps safe from malware and other, evolving, on-device threats. Without it, malware can spread rapidly – [as was the case with this example we investigated in India](https://licelus.com/insights/malware-spread-india). The combination of the protection mechanisms above (and others) can help to maintain end user trust, which is crucial for super app success - whichever region you’re operating in.
QR codepayments also come with a number of threats to be aware of. The most obvious of these is that some QR codes might not be what they seem. Fake and malicious QR codes can be generated fairly easily, with the intention of redirecting unsuspecting scanners to a bogus page where they might be instructed to click on a link or download a fake app. There’s also the danger of UI manipulation (where QR data is altered before it’s displayed or processed), and fake apps pretending to be legitimate payment tools.
There are different protection measures required to maintain the integrity of QR as a trusted payment method. One is runtime application self-protection (also known as RASP) which is able to detect and prevent emulators, debuggers, and repackaging tools – all of which can help attackers to carry out [fraud](https://licelus.com/resources/guide-to-mobile-application-protection/threats/mobile-app-fraud) via fake, cloned apps. Integrity verification and device binding can also be employed to prevent app impersonation, and UI protection can help to ensure fake or malicious scans don’t cause the damage intended.
The low barrier to attack with QR systems means that it’s vital security exists within the app itself rather than around it.
Cross border interoperability also comes with its own risks. The most significant is the trust gap between different mobile devices, platforms, and OS variants in diverse markets, meaning that there’s a higher risk of sensitive data exposure during transit and transactions. That’s where a device and hardware-agnostic [virtual trusted execution environment](https://licelus.com/insights/why-virtual-trusted-execution-environments-are-set-to-boost-mobile-payment-security) (vTEE) can be hugely helpful, as it provides a secure, isolated environment for sensitive transactions to take place, mitigating the security weaknesses that are rife within complex, cross-border payment landscapes. Mobile wallet providers can make use of [Trusted Applications](https://licelus.com/insights/what-is-a-trusted-application) within a vTEE, which brings strong security even to untrusted devices; and no device is more inherently untrusted as the mobile phone.
There are also varying regulatory requirements in place for mobile payments in different countries, but there are some which are universally respected and approved, such as [PCI](https://licelus.com/resources/knowledge_hub/pci-mpoc) and EMVCo. So, it’s vital for wallet providers to make sure that their solution is approved by an industry body like this.
### And the future?
Asian innovators have proved willing to test out new payment methods with a view to making them even more seamless and convenient. Take the [palm payment pilot projects](https://www.instagram.com/reel/DHEEAuqpVmj/?igsh=QkFIaWhHX3pGdA%3D%3D) gaining traction across the region, for example.
Other biometric payments using facial recognition - and even voice payments - are being trialled, too.
But sometimes there’s a disconnect between convenience and security. As payment experiences become more seamless, they can also become more abstract; and that makes them harder to secure via traditional means. You can cancel your card, but you can’t reset your palm.
A trend we’re witnessing right now and anticipate seeing more of in the future is the stakes getting higher and damage getting harder to undo when tech transactions and interactions are simplified too much.
Change is so rapid these days that it can seem like a trick of the mind that scanning a QR code to buy street food once felt futuristic. It may feel quaint before we know it. But whatever replaces it - in Asia or beyond - must be grounded in security, not just convenience. Because there’s nothing convenient about losing your savings - or your reputation.
Curious how to secure your app in an increasingly mobile-first world?
30 Sep 2025
### The rise of NFC Proxy Malware attacks
URL: https://licelus.com/insights/the-rise-of-nfc-proxy-malware-attacks
# The rise of NFC Proxy Malware attacks
Not long ago, a friend of ours, Mike, was walking along the Southbank of the River Thames and came across a street food market. He bought some lunch, tapping to pay on the vendor’s phone. Around half an hour later, as he crossed the Millenium Bridge heading towards the dome of St Paul’s Cathedral, his Android phone buzzed and vibrated in his pocket several times.
When Mike glanced at his device’s screen, he was confused. His mobile wallet was notifying him of 10 successful payments worth $50 each for topping up TikTok advertizements. He hadn’t consciously made any such payment; he didn’t even use TikTok.
What had just happened?
He didn’t know it at the time, but Mike had just fallen victim to an NFC Proxy Malware attack. His device wasn’t infected, but the vendor’s device was.
Mobile payments have never been so seamless or intuitive; transactions are mostly taps these days. Mobile wallets, mobile banking, and SoftPOS solutions are all booming, and NFC Proxy Malware attacks exploit how simple and frictionless payments have become.
Mike got the money refunded to his bank account in the end. But the fact that he has reverted to tapping with a physical card rather than his mobile device is telling. As is his refusal to tap to pay on another mobile device (known as SoftPOS) rather than via a payment dongle. Preventing attacks like this one in the coming months and years is likely to shape how much confidence people have in everyday digital transactions.
#### What is NFC Proxy Malware?
NFC Proxy Malware manipulates the communication channel between applications capable of performing NFC payments. This could be from an app on the payer’s device and either a payment terminal or another application on the vendor’s device that enables SoftPOS payments. You might think of it as a man-in-the-middle (MitM) attack for the contactless age.
This is how it works:
The payload arrives on a device [via a malicious application](https://licelus.com/insights/how-bad-actors-deliver-mobile-malware-into-your-device), perhaps as a result of a successful phishing campaign. It then positions itself between the mobile app and the NFC interface, and when the victim initiates a transaction, the malware is capable of either replaying previously captured transactions (NFC Replay Attack), modifying transaction amounts or merchant data, or redirecting payment flows to fraudulent endpoints, including other mobile devices (NFC Relay Attack).
What makes this attack particularly disconcerting is that the malware turns your smartphone against you in a sense; rerouting transactions after silently impersonating you without your knowledge.
#### Why is it gaining in popularity?
In short, because of the massive shift to mobile payments in recent years. Obviously there are geographical differences around the world, but by and large NFC plays a huge role in the modern-day payment landscape; whether that’s Apple Pay, Google Pay, other [mobile wallets](https://licelus.com/resources/use-cases/mobile-wallet), or [SoftPOS solutions](https://licelus.com/resources/use-cases/softpos) that allow people to accept payments on their device.
Crucially though, this NFC technology is used on billions of devices around the world, and not all of those devices are secure. The average end user of a smartphone is unaware that floating around them are unseen threats in the shape of rooted and jailbroken devices, and emulators imitating smartphones from a computer.
Thousands of these attempts are reported every second by our [threat and device intelligence solution, Alice](https://licelus.com/products/alice-threat-intelligence). This reality of a murky and untrustworthy mobile channel complicates the picture massively, as it means attackers can target environments where traditional security assumptions simply don’t apply.
Then there are the low barriers to entry for attackers, allied with the potential for quick rewards. Proxy malware frameworks and templates are now sold openly in underground forums, while there’s a great deal of flexibility for attackers to target either unsuspecting individuals who end up with mysterious transactions to their name (like Mike), or wider merchant networks and ecosystems.
#### Real-world risks
One of the reasons why NFC Proxy Malware attacks have security analysts worried is that many backend systems simply aren’t built to detect the kind of localized interference that define them. From the server’s perspective, bogus transactions that are carried out this way can appear completely normal and above board.
Perhaps the most common type of attack is the **NFC Replay Attack**, [where a captured transaction is resent](https://www.eset.com/uk/about/newsroom/press-releases/eset-research-discovers-ngate-android-malware-which-relays-nfc-traffic-to-steal-victims-cash-from-atms/). In this scenario, the victim rarely notices until later. There’s even a chance they might never notice it if the purchase amount is relatively small and they dismiss the payment notification, assuming it to simply be a notification of their own transaction.
Another scenario is **transaction manipulation**. Here, the malware alters the payment amount or merchant ID on the fly. Again, the goal here is to potentially carry out the attack without detection.
In SoftPOS environments, wider **merchant abuse** is a real threat. In theory, entire networks of devices could be exploited to carry out widespread fraud. [As this article explains](https://www.malwarebytes.com/blog/news/2025/04/android-malware-turns-phones-into-malicious-tap-to-pay-machines), devices can be used as a kind of cloned card for contactless payments.
#### What’s at stake?
NFC proxy malware targets the in-device NFC transaction path, intercepting or altering data before it’s bound into the usual payment cryptograms. That means transport-level protections like TLS don’t stop it. And because the manipulation occurs locally on the merchant device, backend fraud systems that depend on network or behavioral signals are much less likely to detect it. If the payment app can’t cryptographically attest its runtime and environment, it has no reliable way to know if the transaction has been tampered with.
These attacks are particularly dangerous because they violate something deeper than technical specifications alone: end user trust. The average end user feels very secure and comfortable using their mobile device for everyday activities, including payments. They trust that a tap means a safe, complete, and authorized transaction. If NFC Proxy Malware – or other similar attacks – continue to gain traction, quietly rerouting payments, then that trust will erode incredibly quickly. And then the entire mobile payment ecosystem could potentially feel the impact.
### How to protect against NFC Proxy Malware
Protecting against Proxy Malware requires multiple layers of security. It’s not enough to only think about the protection of sensitive data in transit, but rather the protection of the application and the environment around the device itself.
The following should be seen as core pillars of an effective defensive strategy:
**Application Integrity Control** is vital to make sure the application hasn’t been tampered with. Anti-repackaging techniques, signature validation, and integrity checks are also crucial in stopping modified or cloned versions of an app from reaching production.
**Runtime Application Self Protection (RASP)** detects and responds to real-time threats like debuggers, hooking frameworks (Frida, Xposed, Magisk), and code injection or runtime manipulation. This matters because it makes it much harder for malware to observe or modify NFC transaction logic.
**Device Attestation** can identify whether the app is running on a compromised device. Rooted, jailbroken, or virtualized environments are the most common hosts for proxy malware, so being able to flag suspicious devices is vitally important.
**Secure Cryptography and Storage**, including white-box cryptography, device binding, and secure key storage all help to make sure that sensitive transactions and operations like transaction signing can’t be observed or modified.
If your app stores any kind of payment tokens, cryptographic material, or transaction logic, then it must be protected against both extraction and tampering.
**Trusted Execution** ensures that sensitive code runs inside a secure environment (like [a virtual Trusted Execution Environment](https://licelus.com/insights/why-virtual-trusted-execution-environments-are-set-to-boost-mobile-payment-security)). That way it’s isolated from malware on the device.
The two protection mechanisms above enable the creation of a secure channel between devices, which works to protect against NFC Proxy Malware attacks, much in the same way that TLS helps to prevent classic man-in-the-middle attacks.
**Threat Intelligence and Monitoring** helps to track and flag emerging malware variants across your user base. It can monitor how apps are being run, what devices they’re running on, and whether expected behavior patterns are being violated. These insights can then be shared with bank and payment platform analysts to help them to respond to threats more effectively.
Finally, **Anti-Malware** mechanisms are vital in stopping this kind of attack. These include integrated malware and Potentially Harmful App detection capabilities that can check for known malware signatures, alongside heuristic checks which flag indicators of potential interference by malware or PHAs.
In recent years we’ve written frequently on this blog about the emotional and psychological impact of mobile-based attacks on end users.
Pretty much since the mobile phone became a mass-market device and grew rapidly in popularity around 25 years ago, it has become a safe space for people to retreat to. A place people associate with their friends and loved ones.
That’s why any attack that involves the mobile device feels particularly personal.
But NFC Proxy Malware attacks clearly illustrate the glaring disconnect between the importance we place on the device - and how attached we are to it – and how dangerous the environment around it is. Hackers see the phone as a gold mine, and with good reason. It’s our go-to for all of our banking and payment needs, as well as the hub of our social lives. And the more serious organizations get about protecting their mobile applications, the more creative attackers become to get around the defenses.
Mobile channel security is quickly resembling something of an arms race, and this latest weapon is gaining traction fast.
NFC Proxy Malware represents a new, silent threat for the digital age. But by employing a combination of the protection mechanisms above, we can collectively ensure that end users like Mike can carry on using their mobile devices to carry out digital payments with confidence.
Read our SoftPOS use case to find out how to protect this growing mobile payment method and achieve PCI MPoC compliance.
[Read our use case](https://licelus.com/resources/use-cases/softpos)
## Trust in Digital Identity
[All insights](https://licelus.com/insights)
26 Oct 2025
### A Tunnel Under the Castle Walls: Why Trust Cannot Be Assumed in the Digital ID Era
URL: https://licelus.com/insights/why-trust-cannot-be-assumed-in-the-digital-id-era
# A Tunnel Under the Castle Walls: Why Trust Cannot Be Assumed in the Digital ID Era
A shortened version of this article was originally published [on the TechUK website](https://www.techuk.org/resource/a-tunnel-under-the-castle-walls-why-trust-cannot-be-assumed-in-the-digital-id-era.html?utm_source=LinkedIn&utm_medium=social&utm_campaign=Orlo) as part of their Digital ID Campaign week.
Every hour, Licel systems process over 300,000 live threat intelligence events. This gives us a front-row view not only of how malware spreads and mutates, but also of how trust in the digital world can be undermined and quietly erode.
We see camera injection attacks bypassing eKYC controls, social engineering fused with remote access tools, maliciously modified apps siphoning sensitive data, and rerouted comms that trick users into signing something they never intended to sign. These aren’t fringe cases, but rather are becoming the new normal.
This is a problem, because most societies are built on trust by default. We tend to trust the systems we use and trust that those systems will protect us. But trust in the digital world cannot be assumed. It has to be engineered
Taking all of this together, if you asked us here at Licel today to swap our physical passports for digital versions, we wouldn’t hesitate to say: only when security is treated as the foundation of Digital ID initiatives.
#### The New Reality of Digital Identity
The world is entering an exciting new phase of identity. Digital IDs that are stored on smartphones are quickly being planned and rolled out by government task forces around the world. These national identity schemes will be used to prove who we are, and to streamline access to public services and the digital economy.
The potential is immense. Faster verification, improved accessibility and efficiency, and seamless cross-border interactions, to name only a few. But alongside this great promise is a new reality; where our digital identity lives inside mobile applications that by their very nature exist in an unpredictable, untrustworthy, and often hostile environment.
Think about your physical passport for a second and how you look after it when you’re on a holiday or business trip. It’s always close to hand, in your backpack or in your handbag. And when you arrive at your hotel, it’s probably one of the first items you lock away in the safe in your room. There are threats in the physical world around us, of course; there are those who would seek to distract you so they can steal your passport from you. But it’s a physical thing that you can touch and protect. You can be vigilant of threats against it. What is more, your physical passport comes with hundreds of years worth of anti-tampering measures that have evolved over time - whether that’s the hologram image, the Common Criteria (CC) EAL6+ secure chip or the unique ID number. It’s a tricky thing to fake.
A digital passport that exists inside an app on your smartphone faces very different kinds of threats. These ones aren’t physical, but rather they exist in the ether, floating in the dark spaces between the mobile application, the operating system, and the backend. These include mobile malware, remote access tools, and zero-day exploits. In other words, compromised environments that enable an attacker to use your most sensitive personal data without even having to steal it.
The danger isn’t that Digital ID initiatives are misguided - far from it. It’s more that it seems that security at the mobile application level isn’t yet treated with the same rigour as backend or architectural security. And without it, the entire chain of trust can be undermined.
Imagine that you’ve built an impressive-looking castle, but have failed to examine the soil around it. That soil could be just the right quality and consistency to enable attackers to construct a tunnel under the castle walls, all the way to the crown jewels.
#### The Dark Spaces: The Digital ID Threat Landscape
The success of Digital ID initiatives will arguably rest on whether citizens believe that their identities are safe. This is a legitimate concern. After all, digital identities on personal devices can become exposed to:
- **Tampering** - attackers modify apps to inject malicious code or steal and misuse cryptographic keys.
- **Malware interference** - malware strains can silently observe Digital ID interactions and signatures, and siphon credentials.
- **Synthetic enrolment** - sophisticated [eKYC Fraud](https://licelus.com/resources/knowledge_hub/ekyc-fraud) using deepfakes and virtual camera apps can create bogus citizens in the database.
- **NFC-based fraud** - contactless [scans via NFC interfaces](https://licelus.com/insights/the-rise-of-nfc-proxy-malware-attacks) can be manipulated and relayed to other devices around the world.
The threats above can be prevented, but only if we see the mobile channel as a critical component of trust. Citizens don’t see - and are almost certainly unaware of - backend systems and encryption protocols. What they do see and experience is the mobile application; that’s why it’s so important that it is able to defend itself and is capable of proving its integrity every time that it runs.
Without robust protection mechanisms, blind spots and dark spaces can emerge and grow in size. The clear and obvious danger of that happening is that once a Digital ID system is breached, trust is very difficult to rebuild. This is especially true when you consider that there is already scepticism about individual data privacy before initiatives have even got off the ground.
We’re living through an interesting intersection in our recent digital history. It feels like the more negative impact of sharing almost every facet of our lives on social media for the last decade or two has led people to withdraw to some degree and begin sharing less widely than before. It has also led people to value their privacy a lot more.
This trend is happening at the same time that cyber threats increase in number and sophistication. In [Eurosmart’s position paper on security considerations for the European Digital Identity Wallet](https://www.eurosmart.com/eurosmarts-position-paper-on-security-considerations-for-the-european-digital-identity-wallet/), they highlighted that around 2,900 new vulnerabilities were emerging each month.
Here at Licel, we sometimes get the impression that there’s an idea about security being primarily about patching bugs. But this isn’t the case at all. It’s a fundamental architectural issue, especially with National Digital ID projects where there is so much planned investment and so much is at stake.
#### A Manifesto for Secure Digital ID Initiatives: Building a Foundation of Trust
We’ve spent the last 15 years in the field, building security solutions that solve real-world problems and protect the entire mobile channel. This experience has led us to believe the following principles should underpin every secure Digital ID initiative.
- **Secure Enrolment.** We work with financial institutions around the world to help them battle eKYC Fraud. This threat could also endanger the success of Digital ID initiatives, which is why it’s vital that biometric data and personal identifiers be integrity verified and secured from the device to the backend.
- **Integrity Across the Lifecycle.** Runtime Application Self-Protection (RASP) and integrity checks are absolutely vital for identifying and preventing some of the threats we mentioned earlier that float and flicker around mobile applications (malware and compromised environments).
- **Trusted Execution.** Personal identification, credentials, and cryptographic keys and secrets must be robustly protected. Sensitive operations should be performed inside a trusted, isolated environment.
- **Visibility is vital.** Real-time threat and device intelligence is crucial for painting a thorough picture of the threat landscape and how it’s evolving over time. Without it, it’s difficult to get a clear view of where attacks are coming from.
- **Privacy and Transparency.** Security isn’t only about preventing attacks, but about maintaining the confidence of citizens that their identity and data belongs to them. Open communication and education is crucial.
#### A Shared Mission
The regulatory frameworks for Digital ID already exist: eIDAS 2.0, ICAO DOC 9303, ISO/IEC 18013-5. These standards set the baseline for interoperability and assurance, but compliance alone doesn’t equal security.
We’re convinced that to build sustainable trust, security has to be embedded from the inside out. And that begins with the Digital ID application on each citizen’s device. A holistic approach (what we at Licel call mobile channel protection) that combines protection mechanisms such as runtime security, verified threat and device intelligence, and trusted execution, can go beyond compliance to build lasting end-user trust.
Digital ID initiatives are some of the most ambitious digital infrastructure projects of the modern world. They have the potential to completely revolutionise the way that government, private enterprise, and individual citizens interact. That’s why it’s so important that they are built on solid foundations if we want them to stand the test of time.
Trust cannot be assumed, but it can be built. Here at Licel we’re excited to be a part of the conversation and we stand ready to help Digital ID fulfil its enormous promise and potential.
Find out more about our vision and guiding principles for creating secure Digital Identity solutions that build lasting trust with citizen end users.
[Read our use case](https://licelus.com/resources/use-cases/digital-id-protection)
## Secure Your Identity
[All insights](https://licelus.com/insights)
26 Nov 2025
### How Not to Lose Your Identity in 2035
URL: https://licelus.com/insights/how-not-to-lose-your-identity-in-2035
# How Not to Lose Your Identity in 2035
### The surprising journey from the sci-fi Multi Pass to real-world, secure Digital Identity solutions.
This article is inspired by [a talk](https://www.youtube.com/watch?si=d8WzEewvoj3kz6E0&v=jyrIyWvIjug&feature=youtu.be) delivered by Licel co-founder and CTO, Mikhail Dudarev, at Droidcon London 2025.
Rewatching sci-fi movies from the 1990s can be quite a disorienting experience sometimes – especially for those of us old enough to remember seeing them when they were first released. What seemed at the time to be impossible-to-imagine dates far into the future are often now, well, the present day. And while some predictions have fallen flat, others have aged remarkably well.
The 1997 cult sci-fi classic, **The Fifth Element**, is set in the 23rd century, and so we have a while to wait yet to know whether yellow cabs will hover as high as the tallest skyscrapers in New York City. Other predictions from the movie, however, appear to have come to pass already. Take the famous Multi Pass, for example, flashed by protagonist Leeloo Dallas to prove who she is and to unlock access to places and services. It feels a lot closer to reality than fiction.
The Multi Pass moment in the film The Fifth Element.
Today, identity documents are moving onto the smartphone at remarkable speed. Driver’s licences, visas, health records, and hand written signatures used to exist in plastic cards, paper booklets, and government databases. The fact they are moving to mobile apps marks a profound and exciting shift. But while identity is moving from hardware to software, trust will have to travel with it; and that might be a trickier journey, because trust simply cannot be assumed in the digital age.
In the following paragraphs, we’ll do a bit of future thinking ourselves. We’ll take a look at the trajectory of Digital ID applications in the next decade and set out what is required to secure identities; first of humans and then of the AI agents we’ll increasingly rely upon to carry out digital tasks for us.
### When fiction meets reality: the modern digital identity ecosystem
The more you examine the Multi Pass from The Fifth Element, the clearer it becomes; what appeared at the time to be a visual gag might – even if by accident rather than by design – have been a blueprint for how deeply integrated future digital identity ecosystems could become. It’s surprisingly prophetic.
Modern identity schemes such as European Digital Identity Wallets, digital driving licenses, digital travel credentials, or ePassports, all follow strict international specifications designed to make identity secure and verifiable across borders. The overlap between these and the fields on the Multi Pass is remarkable.
For example:
- The 3D hologram on the Multi Pass maps neatly with ICAO Doc 9303 requirements for biometric facial imagery
- Personal data like name, date of birth, and nationality is a pretty close match for DG1 and DG11 data groups in ePassports
- Driving license permissions correspond to the ISO/IEC 18013-5 mobile driving license standard
- Travel access permissions are formalized through Digital Travel Credentials (DTC Types 1 and 3) under ICAO
- Payment system linkage echoes the direction of EUDIW and the Digital Euro, where regulated private sector services (including payments) can rely on government-issued credentials
What once looked futuristic is now being actively implemented by governments, integrators, and wallet providers around the world.
Today’s emerging digital identity wallets won’t just prove who you are. They will unlock access to services, authenticate payments and sign ups, validate your legal status, and sign binding agreements – all from the convenience of a device you already carry everywhere.
Your eyes might have been drawn to the health status field on the Multi Pass, which reads “Viral State: Low.” One suspects that this detail would have been interpreted differently by viewers of the movie either before or after the coronavirus pandemic. Before, it might have seemed unnecessary or even an invasion of privacy to have such a field on your ID document. But having lived through that strange time, we can probably all remember having to carry some form of proof either of having had a vaccine against the virus or of receiving a negative result from a test.
It’s also a reminder of what’s at stake from a security perspective. Identity data is sensitive, sure, but health data is incredibly sensitive. We might be willing to share some of our personal data, while we would want other data to be completely hidden all of the time. Health data falls squarely in that second category.
This is why designing a Digital ID app is so complex. It isn’t simply a case of creating a digital version of the Multi Pass – of placing some UI over a credential – but rather of building a complete ecosystem of cryptography, secure storage, attestation, and controlled interactions with the physical world.
The way we choose to design and build Digital Identity solutions in the next decade will likely determine [whether citizen end users can trust them or not](https://licelus.com/insights/why-trust-cannot-be-assumed-in-the-digital-id-era).
### What does a Digital ID application actually do?
Something else that makes the design and delivery of a Digital ID app challenging is that it has to carry out three completely different - and equally critical - functions. And each of them requires highly advanced security mechanisms.
The first of these is the **enrolment** stage. Remember; when the Digital ID app is downloaded from an app store, it is essentially an empty vessel. Enrolment is where a blank mobile app becomes a verified identity. This involves biometrics, document checks, NFC passport reading, and the approval of the backend. But this is also the stage where deepfakes, camera injection malware and virtual camera apps can facilitate [eKYC fraud](https://licelus.com/resources/knowledge_hub/ekyc-fraud), potentially enabling attackers to bypass verification altogether and create fake citizens within the database.
The second use case of a Digital ID app is **verification**. This is when you present your ID – or at least parts of it – quickly and privately. Imagine you’re at the airport, preparing to board a flight, or you’re at the car rental agency to pick up a pre-booked vehicle. There are security risks associated with presenting your identity, however. These include overlay attacks, [NFC relay attacks](https://licelus.com/insights/the-rise-of-nfc-proxy-malware-attacks), and malware that can modify what is being shown or sent.
Finally, there’s the act of **signing**. This is potentially one of the biggest efficiency savings people can look forward to with a Digital ID app; the idea of using it to make a digital signature, payment, or legal authorization quickly and easily. Strong protection for private keys and secure execution is absolutely vital if the act of signing or making transactions is to be done safely, because if an attacker were able to extract or misuse keys, then they could impersonate a user easily.
### Building Trusted Identity: the foundations
For each of these three functions, there are some key principles that need to be realized if we want to put the foundations in place for building trusted identity solutions:
**Trusted enrolment** (that can combat the threat of eKYC fraud) requires a combination of liveness checks and attestation. If either the device or the human using that device cannot be verified or trusted, then that identity shouldn’t be enrolled. A physical ID document is also sometimes required to be read via an NFC interface, which opens up the NFC relay attack vector again.
**Key protection** needs a combination of secure storage and device binding, because non-exportable cryptographic keys are the backbone of Digital ID authenticity (and therefore the amount of trust citizens will have in it). If keys can leak, identities can be copied, and trust will break down.
**Tamper resistance** relies on integrity verification and runtime checks. The upshot of identification moving to mobile apps is that they will be operating in an untrusted environment where threats like hooking and dynamic instrumentation tools float in the ether. These threats need to be detected and then stopped.
**Verifiable operations** are also a must. Digital ID systems have to be able – via cryptographic proofs and attestation – to prove that each operation (signing, authentication, presentation of credentials) has been carried out by the genuine app, on a trusted device, and in an uncompromised runtime environment.
### The technical building blocks of digital trust
So, we’ve set out the key principles for building trusted identity. But how to actually go about achieving it? That’s where vital mobile channel protection mechanisms come into play. They should be seen by governments and integrators as non-negotiable if they want to deliver tamper-resistant digital identity solutions that citizen end users can buy into and trust.
**Trusted capture and document verification** is a good place to start. Mechanisms must be put in place that can verify that document scans are authentic, the capture pipeline hasn’t been manipulated, and liveness and anti-spoofing checks cannot be bypassed.
Keys for signing, authentication, and credential validation must be **stored in a secure form and operated in a secure environment** - and they should be bound to the device and app instance. This secure storage and secure environment implementation must be CC EAL4+ (VAN.5) certified.
A **secure execution environment** (be that a TEE or a virtual TEE) is also vital, providing a secure vault for document signing, credential presentation, operations involving private keys, and other sensitive transactions and operations. This isolated, self-defending space is incredibly important to offset Digital ID moving to an untrustworthy, mobile environment.
A trusted execution environment should also be reinforced by **RASP (runtime application self protection) and integrity checks**, which help to make sure that the application hasn’t been modified, that dynamic instrumentation tools like Frida are detected, and that the integrity of the app is intact both before and during operations.
**Mutual TLS and end-to-end encryption** is also important to make sure that the server is communicating with a legitimate, unmodified app, that the app is connected to the correct backend, and that data is protected both in transit and at rest.
Real time visibility and the ability to make more nuanced security decisions completes the loop, and that’s where **threat telemetry** comes in. This provides visibility into malware activity, tampering attempts, and attack trends over time, all of which can help to improve long-term security posture.
All of the security mechanisms above are vital for Digital ID protection, but one in particular is worthy of further exploration; the concept of trusted execution and, in particular, how a virtual trusted execution environment (vTEE) can help to secure Digital ID initiatives in the years to come.
Let’s dig a little deeper.
### The concept of trusted execution
The main concern about our digital identities moving to the smartphone is that the mobile channel is inherently untrusted. And so we have to somehow bring security to a place that isn’t secure by default or design. The key concept of trusted execution is therefore to divide the execution environment between two worlds; the trusted world and the untrusted world.
It might help to think of a trusted execution environment as a secure room within a larger, riskier building. It’s a protected space where private keys can be stored, and sensitive operations and transactions can take place. If the world outside is noisy and chaotic, the trusted execution environment is calm and peaceful. It’s like plugging into your noise-cancelling headphones; the chaos outside is still there, but it can’t touch you.
Inside the trusted execution environment – in this quieter, trusted world – [a trusted application](https://licelus.com/insights/what-is-a-trusted-application) operates. A specialized app designed to run in that environment, it handles sensitive operations like encryption, decryption, authentication, and secure storage. The fact that the trusted application is running in an isolated and secure environment gives it an extra layer of protection. You might think of it as the Common Criteria (CC) EAL 4+ (VAN.5) secure chip of the digital world.
In a wider sense, the concept of trusted execution is the mechanism that brings the security guarantees of a physical passport - with its hundreds of years of security and anti-fraud measures – to a device that wasn’t built for security and also runs hundreds of different apps, about 50 open browser tabs, and, potentially, some dormant malware.
It combines the key factors of isolation, confidentiality, integrity, secure execution, and controlled access that are so integral to every global Digital ID framework, including eIDAS 2.0 / EUDI Wallet, and ISO/IEC identity standards.
### Why a Virtual Trusted Execution Environment (vTEE) is ideally placed to secure Digital ID apps
An EMVCo Virtual Trusted Execution Environment (vTEE) is a purely software solution that operates in the same way and achieves the same goals as any TEE, but has little to zero specific hardware support. The fact that it is a software TEE actually gives it several advantages over hardware TEEs when it comes to securing Digital Identity apps, such as:
- Cross-platform compatibility
- Allows custom trusted applications with enhanced functionality to be run
- Scalability, developer friendly, and flexible
- No vendor lock-in, making for easier deployment
When evaluated under frameworks such as EMVCo SBMP TEE, virtual TEEs are held to rigorous security requirements, even though the implementation isn’t tied to a hardware enclave.
The image below illustrates how the Licel vTEE ( [itself EMVCo evaluated and approved for both Android and iOS](https://licelus.com/company/news/the-licel-vtee-earns-second-consecutive-emvco-security-approval-for-ios)) works. Operating inside the client application, it helps to make the untrusted world (the wider mobile channel) trusted via mechanisms such as secure storage, while its Trusted Virtual Machine (VM) can host trusted applications.
This security matters for Digital ID applications because the [Licel vTEE](https://licelus.com/products/vtee) makes sure that enrolment, credential storage, PACE/EAC flows, digital signatures, and cryptographic operations can take place in a secure, integrity-controlled environment. Even on devices that don’t have strong hardware.
Another way to think of it is that trust is no longer dependent on the device itself when there’s a secure, reliable enclave inside the application.
### Talking to Digital ID apps
You might be reading this article and thinking “I probably won’t be designing and building a Digital ID app myself.” However, if you’re involved in developing other applications such as mobile banking, healthcare, or travel apps, then it’s likely that your app will have to communicate with a Digital ID app in some way. In the coming years, Digital ID won’t sit in isolation but will be a universal trust anchor that other apps will rely on. A kind of secure, portable identity core inside the device that other apps will request proof from.
These other apps will ask questions of it such as:
- Is this person really who they claim to be?
- Does this person have the right (age, license type, residency status) to be making this request?
- Can you (the Digital ID wallet) sign this transaction or consent form?
The thing is, other applications will only trust and rely on the Digital ID application to answer these questions and carry out these tasks if they know there are robust security layers underpinning it that can withstand malware, OS-level manipulation, and device compromises. Building secure Digital ID apps and systems therefore matters even to teams who will never build one.
As the table below highlights, there are already several international standards that define how apps request identity data, verify credentials, or obtain digital signatures from a Digital ID wallet. These frameworks ensure consistency, privacy, and cross-border compatibility.
##### Standards for Communication
### When not only humans need their identity protected
If Digital ID is to become the universal trust layer on the device, what does that mean for the future of identity? And how do we ensure that trust holds over time?
These would be big, important questions if we were only talking about protecting human identities. But a time is fast approaching when autonomous AI agents, acting on your behalf, will also need to prove who they are and what they are permitted to do.
A bit like the Multi Pass from The Fifth Element predicting the future of identification at the beginning of this piece, other sci-fi movies have predicted that AI entities (albeit physical ones) would be carrying out day-to-day tasks for us. **I, Robot** is one example – set in 2035 for what it’s worth. And again, what was once far-fetched sci-fi is now becoming an accepted part of our world. After all, AI systems are already logging into services, initiating transactions, and interacting with mobile apps and cloud infrastructure. But right now there aren’t tamper-proof, standardized ways to make sure that the legitimate AI agent is making a request, on whose behalf, and whether it has permission to do so. This could increasingly cause problems in the near future as the threat landscape becomes even more chaotic with fraudulent, spoofed, or cloned AI assistants initiating harmful transactions or acting without visibility or accountability, to name but two potential risks.
**How to go about naming and identifying our AI agents, though?**
Humans have spent millennia developing naming systems that encode roles, lineage, and accountability, even if we don’t tend to think of it as such. In Ancient Rome, for example, a full name wasn’t just a label, but a structured identity. Let’s take one of Rome’s most famous citizens; Gaius (personal identifier) Julius (broader clan or community) Caeser (specific family branch). Naming our AI agents so we can verify their identity safely can lean on similar conventions, while also incorporating something even more fundamental: cryptographic truth.
An AI agent’s **unique ID** could be its non-reusable personal identifier; the equivalent of a human first name. The question “ **who created me?**” would be the clan – the organization, model family, or platform. And another question “ **on whose authority do I act?**” is the equivalent of the family branch; the specific project or permission scope. The additional layer and, arguably, the most important question here is “ **have I been tampered with?**” which requires a cryptographic proof of identity, verified in real time. An AI agent’s identity must be non-spoofable, non-exportable, bound to a device or a secure runtime, and cryptographically verifiable before any action is taken.
The same foundations that are required to protect human Digital IDs are the ones we need to secure those of AI agents. If those agents are going to sign documents, request credentials, authorize payments, or act on behalf of people, then we need trusted execution (TEE or vTEE), device binding and cryptographic identity, runtime integrity checks, trusted signals for behavioral verification, and secure channels for presenting and verifying credentials.
### From the Multi Pass to the future of secure Digital Identity
In the Fifth Element, the Multi Pass acts as a universal credential; something that is very close to what governments and integrators around the world are currently working on. Albeit the modern Digital Identity is far more complex. The Multi Pass is still a physical card, but modern identity is moving from hardware to software, and it isn’t a foregone conclusion that end user trust will make the same journey quite as smoothly. Not when millions of consumer devices are compromised, tampered, untrusted.
In such an environment, trusted execution is the key to making the untrusted trusted; making the unsecured secured. Whether delivered by more traditional hardware TEEs or software-based vTEEs, trusted execution is the minimum requirement if secure Digital Identities are to be realized. It’s a requirement that is also set out across the growing ecosystem of interoperable specifications around the world.
Getting the secure foundations of Digital ID in place now is vital, because trusted execution, verifiable credentials, and cryptographic proofs won’t just form the backbone of human ID verification, but will also work for AI agents in the near future.
Securing our Digital Identity is one of the most exciting challenges of our time. Let’s make sure that we get it right.
Find out more about how Licel is helping to lay the foundations for the next decade of digital trust.
[Read our use case](https://licelus.com/resources/use-cases/digital-id-protection)
## Closing the Mobile Trust Gap
[All insights](https://licelus.com/insights)
### Follow us
18 Dec 2025
### Mobile API Protection: From afterthought to necessity
URL: https://licelus.com/insights/api-protection-from-afterthought-to-necessity
# Mobile API Protection: From afterthought to necessity
At Licel, we’ve been providing security and anti-fraud solutions for mobile apps since the introduction of DexProtector in 2013.
Over those 12 years and more, organizations have become increasingly aware of the importance of building security into their apps on both Android and iOS.
From obfuscation and encryption, to runtime application self-protection, anti-tampering and anti-hooking, through to root detection, emulator detection, and a whole range of device attestation mechanisms: these have gone from specialized technologies to essential items on mobile security checklists.
Meanwhile, backend and infrastructure teams have built up their own world of protections: web application firewalls, API gateways, rate limiting, DDoS mitigations, hardened identity and access layers.
And when it comes to security in the interfaces and interactions between the mobile app and the backend, since TLS became the standard for securing app-to-backend network connections, security teams were primarily tasked with solving one particular problem: how does the app know it is really communicating with the genuine backend, and not with an attacker in the middle?
For this, public key pinning became the de facto standard method for the app to authenticate the server.
But there is a mirror image to this problem which initially received less attention, although in many ways it constitutes at least half of [the problem of trust in the mobile channel](http://licelus.com/insights/why-trusted-signals-are-the-key-to-closing-the-widening-mobile-trust-gap): how does the server authenticate the app?
Most organizations have tried various solutions over time: API keys, shared secrets used for request signing, client certificates presented for mutual TLS authentication, and more.
In principle, these controls look like the natural counterpart to pinning, because they seem to complete the symmetry: the app authenticates the server, and the server authenticates the app.
In practice, though, these mechanisms have a fundamental limitation: what the server is authenticating is not an app but a credential: a string, or a signature or certificate produced with a key that the app holds.
This is a particularly significant issue in mobile security, because attackers in the mobile channel have endless opportunities to observe, analyze, and manipulate apps, and to extract data from them.
That means if an API key or shared secret can be extracted once, whether through dynamic analysis, memory dumps, man-in-the-middle attacks, or simply being stolen from somewhere it was handled unsafely, then it stops being a trust signal and becomes a free passport to the server-side, something that any arbitrary client can present just as effectively as the genuine app.
In other words, these approaches may not provide a high-confidence proof that the request is coming from a legitimate, untampered, up-to-date version of the mobile app, as opposed to a bot, script, emulator, or impostor that has copied or been given that credential.
And there’s also a second, related concern: in many cases, outdated app versions continue to be served by the backend long after they should.
Since in-app security and anti-fraud controls are continuously being refined and enhanced and extended, older app versions are easier targets, and often carry weaknesses or vulnerabilities that have been mitigated in subsequent updates.
Attackers and fraudsters, unsurprisingly, don’t insist on fighting against the latest, strongest release if the backend continues to accept traffic from an older, weaker one, and the result is that the trust model is quietly undermined: if the backend still serves their requests, attackers will simply exploit the weakest viable version.
And in many organizations, the problem is compounded because the ‘mobile API’ isn’t even a distinct surface: the mobile app sometimes shares the same public endpoints as the web client, or reaches into shared internal services. That makes mobile-specific enforcement much harder.
Real fraud campaigns exploit these gaps.
The following are some concrete examples of how they do so, based on what we have seen and heard from organizations around the world. Some details have been changed to preserve anonymity.
### Case 1: ‘Sleeper mode’ trojan targets Middle Eastern bank
A bank in the Middle East launched a new mobile app with a major marketing push. Customers were encouraged to download it, enrol, and start using it for everyday transactions.
Fraudsters noticed the marketing and saw this as a great opportunity. They quickly created and circulated their own impostor version of the new app, using phishing campaigns and direct downloads to spread the cloned app as far and wide as possible.
To the bank’s unsuspecting customers, this impostor app looked normal. The UI was identical to the original one, for one thing. But more importantly, the app just worked. Balance checks were available and accurate. Paying bills worked. Transfers arrived as expected, on time, to their intended recipients.
In other words, the ‘cloned’ app was communicating with the bank’s real APIs just like the genuine original.
The problem was that the app also happened to be collecting data and reporting it to the fraudsters’ servers in parallel. Data such as user credentials; OTP flows; device characteristics; where the customer was when they performed transfers; when the customer usually logged in; who they paid and how much.
This went on for months, and still the fraudsters did not cash out. They captured as much data as possible from as many customers as possible.
And then the fraudsters’ campaign switched to phase two.
At this point, transactions started appearing that could go unnoticed; the amounts were relatively small, the payees looked plausible, the timings were aligned with the customer’s typical activity window.
There was nothing to trigger a fraud engine’s red flags, nothing strong enough to block transactions or close accounts, until finally the bank’s fraud team became aware of a flurry of disputed transactions.
### Case 2: Credential stuffing that looks like ordinary mobile traffic
A bank in Latin America noticed a growing number of disputed transactions, performed via applications on both Android and iOS.
From the security team’s point of view, the transactions looked legitimate. The API calls were correctly formed and payloads looked normal.
As they pieced together the broad timeline, though, a hypothesis emerged that fit the shape of what they were seeing: a quiet credential stuffing campaign aimed at the same authentication endpoints the mobile app uses. Not loud or involving brute-force in the classic sense; credential dumps tested carefully, a few attempts per account, spread over time and across multiple plausible IP addresses, with requests shaped to resemble normal mobile logins.
There was no immediate, dramatic cash-out. Instead, the access was used patiently, to learn enough about each account to move later without standing out: long-lived access and low-friction fraud.
The fraudsters might have used real instances of the mobile app, on genuine mobile devices, for this campaign, but the bank’s behavioral analytics and emulator detection would have made it very difficult. Targeting the mobile APIs directly, and bypassing the app, provided the easier route to account takeovers.
### Case 3: Version rollback enables fraudsters to spoof ID verification
A bank in Western Europe had been steadily reinforcing its mobile onboarding controls and eKYC procedures in an attempt to reduce money mule account creation with synthetic and stolen identities.
ID verification and liveness checks were already in place, but were still being bypassed through code injection and deepfake technologies. The bank had therefore decided to ramp up their integration of RASP and anti-tampering protections.
Fraudsters noticed the change quickly, and instead of trying to defeat the new protections head-on, they took the easier route: they simply rolled back to an earlier version.
When the bank’s fraud team realized that incidents were surging again after an initial decline, they analyzed the data from onboardings. One detail kept recurring: a surprising number of the mule accounts were created with an older and less used, but still supported, version of the app.
The bank’s next move was to get more restrictive about supported versions: gradually limiting service for older builds, prompting harder for updates, and adding backend checks to enforce minimum versions for onboarding.
For a while, it worked. Then incidents began climbing again.
When the fraud team dug deeper, they found indicators through threat intelligence that mule accounts were still being created from older, unprotected app builds; fraudsters had simply adapted by spoofing the app’s version identifiers, so simple version gating at the API layer was ineffective.
Of course, some additional mitigations, spread across the client-side and the server-side, would have made things more difficult for the fraudsters.
In all three examples, their reconnaissance would have been harder if endpoints were well hidden and there were strong defenses in place against analysis of the mobile app’s network communications.
Certainly, if the Middle Eastern bank had implemented robust obfuscation and encryption of code and assets, and proper anti-repackaging mechanisms, it would have made it a lot more difficult for the fraudsters to ship a ‘cloned’ version of the app convincing enough to fool the bank’s customers. More customer education campaigns might have been valuable as well.
And perhaps more effective fraud telemetry and analysis, both in-app and server-side, identifying inconsistencies and anomalies in behavior and transactions, could have flagged the automations and unauthorized activities.
Finally, traditional ‘app authentication’ measures, leveraging API keys, request signing, or mutual TLS, could certainly have made life more difficult for the fraudsters.
But these mitigations are not quite enough, either individually or collectively.
Public endpoints will always remain public, and determined attackers are likely to find their targets.
Customers can be tricked by impostor apps that are only superficially similar to the real thing.
In-app fraud telemetry components can be tampered with, and fed fraudulent data, especially on compromised devices.
And, as we have seen, traditional app authentication measures authenticate a credential, not an application. If the secret (the API key or signing key or certificate) can be extracted, it can be abused by an untrustworthy client.
Which brings us back to the core point: trust in the mobile channel can’t depend on insecure apps or static secrets, because the mobile client is a target that attackers will have ample opportunity to observe, instrument, and manipulate.
Traditional app authentication mechanisms mostly answer: 'Does this caller have the right credential?'
But to establish trust in the mobile channel, the backend actually needs answers to at least three questions:
- The question of authenticity: Is this request coming from a genuine version of our app on a genuine mobile device, and not from a script, bot, emulator, or impostor?
- The question of currency: Is this request coming from a recent version of the app, implementing up-to-date security controls?
- The question of integrity: Is this request untampered, and is it coming from an untampered app, running in a trustworthy environment?
Mobile platforms provide some building blocks towards these answers. Google’s Play Integrity API can supply signals intended to help distinguish genuine installs and risky environments, and Apple’s App Attest can help an app instance prove it’s legitimate.
They have value, but they don’t automatically solve the whole problem of binding API access to proofs of authenticity, currency, and integrity, across all sensitive endpoints, in a way that fraudsters can’t simply bypass.
That’s what DexProtector’s Mobile API Protection capability is designed to do: it gives the backend a way to reject requests from tampered, repackaged, automated, downgraded, or otherwise untrusted clients, even if those clients can perfectly imitate the request format.
The solution is implemented through an in-app Mobile API Protection component integrated by DexProtector, cryptographically bound to the app, and secured by the DexProtector Runtime Engine (DRE).
During integration with DexProtector at build-time, a secret is encrypted and integrated into the app. The DRE, being the first component initialized, runs integrity and RASP checks immediately. Only if those checks pass does the Mobile API Protection component mint and sign a short-lived DRE Session Token that the app can attach to API requests and the backend can verify.
That detail is what makes it different from request signing or mutual TLS authentication. The backend isn’t authenticating a credential in isolation. It’s verifying proof that was generated inside the protected runtime environment, after initial and ongoing integrity and attestation checks, and specifically for the current session.
This is how Mobile API Protection increases the reliability of other signals from the app used in authorization decisions.
Device attestation data, telemetry from fraud SDKs: these only have true value when the backend can be sure that they’re coming from a genuine, untampered app instance, not from something that’s simply learned how to mimic its traffic.
And it directly addresses the rollback problem: since outdated builds can’t mint valid tokens, ‘supported version’ stops being a string the client can spoof and becomes an enforceable property of the request.
This makes Mobile API Protection more than just another capability alongside RASP and attestation. It is the binding between the client-side and the server-side that makes security and anti-fraud controls actually enforceable at the moment when they matter: when the backend is deciding to authorize an action.
Find out more about how DexProtector ensures your backend only accepts requests from genuine, untampered mobile apps.
[Mobile API Protection from DexProtector](https://licelus.com/resources/knowledge_hub/mobile-api-protection)
### Our latest articles
[View all](https://licelus.com/insights)
- [
**Why trusted signals are the key to closing the widening mobile trust gap**
The threat landscape](https://licelus.com/insights/why-trusted-signals-are-the-key-to-closing-the-widening-mobile-trust-gap)
- [
**How Not to Lose Your Identity in 2035**
The threat landscape](https://licelus.com/insights/how-not-to-lose-your-identity-in-2035)
- [
**The rise of NFC Proxy Malware attacks**
The threat landscape](https://licelus.com/insights/the-rise-of-nfc-proxy-malware-attacks)
## Insights — Further Articles
### Is AI an Angel or a Demon? Finding the Right Security Balance in the Post-AI Era
[All insights](https://licelus.com/insights)
### Follow us
23 Jul 2026
### Is AI an Angel or a Demon? Finding the Right Security Balance in the Post-AI Era
URL: https://licelus.com/insights/can-ai-reverse-engineer-a-mobile-app
# Is AI an Angel or a Demon? Finding the Right Security Balance in the Post-AI Era
Almost three years ago, we published an article about [AI and social engineering](https://licelus.com/insights/ai-and-social-engineering).
At the time, we discussed how AI could help attackers create convincing messages, impersonate trusted people, automate OSINT and build synthetic identities. We were already well on the way toward a world in which it would become increasingly difficult to distinguish a genuine person, company or communication from a bogus one.
Still, what looked sophisticated in 2023 has now become routine.
Modern AI tools can write convincing messages in any language, reproduce a person’s communication style, generate voices and images, analyze large volumes of information, and operate software tools with increasingly limited human supervision. The attacker no longer needs a separate specialist for every stage of an operation. An AI agent can help with reconnaissance, code analysis, scripting, infrastructure configuration and the interpretation of results.
Put another way, the implications for mobile security go beyond AI being able to produce more convincing phishing emails.
AI can help an attacker to analyze your mobile application, understand how it communicates with your backend, and identify where trust can be manipulated across the entire mobile channel.
Your application code is not the only thing under attack; it’s just one wall under strain within a growing room where the target is trust itself, and the relationship between the user, device, application and backend.
In the following paragraphs we’ll explain how we believe security can best be implemented for the whole mobile channel in what’s already being referred to as the post-AI era.
### Mobile threats in the post-AI era
Post-AI doesn’t necessarily mean the world that comes after artificial intelligence, but rather the period after AI has stopped being a novelty.
And it seems we’re already there, because AI has become a standard engineering tool already. Developers use it to generate code, write tests, review pull requests, explain unfamiliar frameworks and configure infrastructure. Security teams use it to analyze logs, investigate incidents, identify vulnerabilities and process threat intelligence.
What’s sometimes overlooked, however, is that attackers can use exactly the same capabilities to increase their own efficiency.
So, returning to the title of this piece, is AI an angel or a demon? The truth is the underlying technology is neither good nor evil. Its impact depends on who operates it, what information it receives, which tools it can access and what objectives it is given.
For a security engineer, AI can identify a dangerous API, explain a memory-safety problem or help to produce a more complete protection configuration.
For an attacker, the same model can examine decompiled application code, identify security-critical functions, generate instrumentation scripts and explain how the application constructs authenticated backend requests.
Government cybersecurity guidance now recognizes that frontier AI models can help discover software vulnerabilities and allow malicious actors to operate at greater speed and scale. At the same time, defenders can use the same capabilities to strengthen code and improve vulnerability management.
### Can modern AI really reverse engineer a mobile application?
Partially, and the nuance matters. Modern AI can meaningfully accelerate reverse engineering by explaining decompiled code, identifying cryptographic, networking, and authentication logic, and generating scripts for tools like Ghidra and IDA. What it cannot do is take a well-protected APK, AAB, IPA, or XCArchive and automatically return the source code, cryptographic keys, and a working backend exploit. AI doesn't replace a skilled reverse engineer; rather it multiplies one, chiefly by generating and testing hypotheses far faster than a person working alone ever could.
An AI model is not a magic button that accepts any heavily protected APK, AAB, IPA or XCArchive and immediately returns the complete source code, cryptographic keys and a working backend exploit.
Reverse engineering remains a difficult undertaking. Mobile applications combine multiple languages, optimization stages and runtime environments. A single application may contain Kotlin, Java, Swift, Objective-C, C++, Rust, JavaScript, Dart, native libraries and third-party frameworks. Important behavior may only become visible at runtime. Code may depend on remote configuration, device state, backend responses and hardware-backed operations.
Obfuscation, code encryption, control-flow transformation, anti-debugging, integrity verification and runtime protections make this work significantly harder.
But an attacker doesn’t need AI to understand every instruction perfectly. They simply need it to reduce the cost of reaching the next useful result.
Recent research has moved beyond asking whether an LLM can explain a short piece of decompiled code. New benchmarks now evaluate whether tool-enabled agents can analyze binaries, recover validation logic and solve purpose-built reverse-engineering tasks. The results show that modern agents can already complete a meaningful proportion of these tasks when they are connected to standard analysis tools.
AI can therefore accelerate the repetitive and time-consuming parts of reverse engineering in the following ways: classifying functions and code regions; explaining decompiled or disassembled code; identifying cryptographic, networking and authentication logic; tracing relationships between classes, methods and native functions; generating scripts for tools such as Ghidra, IDA or dynamic instrumentation frameworks; comparing different application releases; identifying API endpoints and request formats; locating integrity checks and anti-analysis mechanisms; creating hypotheses and automatically testing them; and summarizing thousands of lines of analysis into a practical attack plan.
Does AI always produce a correct answer? No, it doesn’t. What it does do is generate and test hypotheses much faster than a human working alone ever could. And so a skilled reverse engineer is not replaced by AI. Rather their potential is multiplied by it.
### Why you can’t rely on model safeguards
The major hosted AI providers are well aware of the potential for misuse. They apply usage policies, model-level safeguards, access controls and monitoring intended to prevent their systems from assisting with clearly malicious activity.
These controls are important, but they cannot be treated as part of your application’s security model.
Firstly, model behavior is not perfectly predictable. The distinction between legitimate security research and malicious reverse engineering can be difficult to determine from a prompt alone.
Secondly, attackers can divide an operation into many apparently innocent tasks. Asking a model to explain an assembly function, describe a cryptographic construction or produce a debugging script may each have legitimate purposes. The malicious objective only becomes visible when the outputs are combined.
Thirdly, not every capable model is accessible exclusively through a controlled cloud service. Open-weight models can be downloaded and operated locally. Once model weights are running in infrastructure controlled by the operator, there is no hosted provider sitting between the user and the model to perform real-time policy enforcement.
That’s not to say that this type of AI model is bad. Indeed, these models are extremely important for research, independence, privacy and technological progress. It simply means that one cannot rely on the AI provider to spot and rebuff an attack. It isn’t a reliable security control. It’s a better bet to assume in your risk model that a capable attacker will be able to access an AI model that will analyze the material they provide.
### A modern AI-assisted attack begins with your application code
Most sophisticated mobile attacks still begin in a familiar place: the application package. The attacker downloads an Android APK or extracts it from an installed device. On iOS, they may obtain a decrypted IPA from a compromised environment. They can also target an SDK, framework or library distributed to your customers.
The first objective is usually not to exploit the backend immediately. It is to understand how the application expects a legitimate user and device to behave. An AI-assisted analysis may look for authentication and enrollment flows; API endpoints and undocumented operations; request-signing algorithms; embedded certificates, public keys and secrets; device and installation identifiers; anti-fraud signals; root, jailbreak, emulator and hooking checks; integrity-verification logic; native security components and JNI boundaries; feature flags and remote configuration; transaction limits and business rules; and third-party SDKs that handle identity, payments or cryptography.
From there, static analysis becomes dynamic analysis. The attacker can run the application in a controlled environment, attach instrumentation, intercept functions, modify return values and observe sensitive data while it is being processed. AI can help generate scripts, interpret traces, correlate runtime behavior with decompiled code, and adjust the next experiment.
Eventually, the attacker may no longer need to interact with the original user interface at all. Once the application’s protocol, signing process and trust signals are sufficiently understood, the attacker can attempt to reproduce or manipulate its communication with the backend. Requests may contain valid credentials and use the correct structure. From the server’s perspective, they can look like requests from a genuine application.
This is how an attack that starts with application code analysis can expand into the compromise of the complete mobile channel. The backend itself may never be directly exploited. Instead, it is likely to be persuaded to trust a client that is no longer trustworthy.
### The curious case of context bombs
The security community has already started developing creative ways to defend against autonomous AI attackers. One particularly interesting - and slightly amusing - example is the concept of a context bomb.
The idea is to place carefully designed content inside a decoy resource, such as a canary secret. When an attacking AI agent discovers and reads the resource, the content interferes with the agent’s reasoning or triggers its safety mechanisms. At the same time, the defender receives an alert that the decoy has been accessed. In simple terms, the attacker’s AI opens what appears to be a valuable secret and suddenly decides that it should stop what it is doing.
Tracebit tested this technique against several agentic models in a controlled cloud environment. According to its published results, adding a single context bomb to a canary secret substantially reduced the agents’ ability to complete attack paths. The researchers also found that different models reacted to different sensitive subjects.
It’s an intelligent experiment and a good example of turning an AI system’s own behavior against it. But we shouldn’t confuse an inventive defensive technique with a durable security boundary. A context bomb only works when the agent encounters it. It may depend on the model, system prompt, safety policy and provider. An attacker can pre-process or filter retrieved content. A locally modified model may react differently. And a human attacker may simply ignore it. Most importantly, a context bomb doesn’t prevent your application from being decompiled, modified, instrumented or impersonated. It’s a tripwire, a distraction, and a potential agent-disruption mechanism. It isn’t application integrity.
### Classical mobile app protection matters more, not less
While it might be tempting to assume that traditional application protection becomes irrelevant when attackers have AI, the opposite is actually true. AI works best when it has clean, structured and meaningful context. Readable class names, recognizable control flow, obvious API clients and unprotected string constants give the model high-quality material to analyze. A weakly protected application effectively prepares its own documentation for the attacker.
This is why Android and iOS obfuscation remains a foundational security control. However, renaming classes and methods alone is not sufficient. Modern application protection needs to combine multiple mechanisms: code and symbol obfuscation; string and resource encryption; code encryption and runtime restoration; control-flow transformations; native-code protection; application and component integrity verification; anti-tampering and anti-repackaging controls; protection of embedded databases, AI models and sensitive assets; runtime checks and enforcement; and hardened network communication.
The objective is not to make reverse engineering mathematically impossible. No client-side protection can make that guarantee on a device controlled by an attacker. Rather the objective is to remove useful context, increase uncertainty, prevent automated analysis from producing reliable results and make every stage of the attack more expensive for a bad actor - even with the help of AI. The stronger the protection, the more likely an AI model is to produce a confident but incorrect interpretation. For once, an AI hallucination can work in the defender’s favor.
### Why static protection alone is not enough
An application does not remain encrypted and obfuscated while it performs every operation. At some point, instructions must execute and data must be processed. This is why application protection must extend into the runtime environment. A serious Runtime Application Self-Protection (RASP) layer should detect and respond to debuggers; hooking and instrumentation frameworks; code injection; rooted or jailbroken devices; emulators and virtualized environments; modified operating-system components; malicious applications; overlays and remote-access tools; integrity violations; unexpected changes to executable memory; and other conditions indicating that execution can no longer be trusted.
Detection without enforcement is not enough. Depending on the risk and business process, the application should be able to terminate, restrict sensitive functionality, invalidate a session, require additional verification, or report a tamper-protected security signal to the backend. That’s why our own mobile application protection solution, [DexProtector](https://licelus.com/products/dexprotector), combines static code and resource hardening, application integrity, runtime protection and communication hardening for Android and iOS applications and SDKs.
### You need to protect the whole mobile channel
An AI-assisted attacker will not respect the boundaries between your mobile development team, fraud team, API team and security operations center. And so your protection architecture shouldn’t respect those boundaries either. [Mobile Channel Protection](https://licelus.com/resources/mobile-channel-protection) secures the complete interaction between the user, device, application and backend. It requires several layers working together: protect the application package (the final APK, AAB, IPA or XCArchive that will actually be distributed); protect the runtime environment (continuously verify the app runs where its execution and decisions can be trusted); bind the application to the backend so that [Mobile API Protection](https://licelus.com/resources/knowledge_hub/mobile-api-protection) can verify a request originates from a legitimate and untampered application instance; generate trusted security intelligence via [Alice Threat Intelligence](https://licelus.com/products/alice-threat-intelligence); and isolate the most sensitive operations inside the [Licel vTEE](https://licelus.com/products/vtee).
### Finding the right security balance in the post-AI era
It’s clear that we can and should use AI to improve mobile security. We should use it to review code, draft and sanity-check protection configurations, generate negative test cases, investigate incidents, and process security intelligence at a scale that would be impossible for a human team alone. But we must also build our applications on the assumption that attackers have access to the same capabilities. The answer is not to prohibit AI or hope that every model provider will stop every malicious request. The answer is to reduce the quality of the attacker’s context, protect application execution, verify integrity at the backend and continuously validate signals across the complete mobile channel. The angel and the demon are both using the same technology. Security effectiveness will increasingly depend on which side has the better architecture.
### 15 Years in the Most Watched Room in the House
[All insights](https://licelus.com/insights)
### Follow us
30 Jun 2026
### 15 Years in the Most Watched Room in the House
URL: https://licelus.com/insights/15-years-in-the-most-watched-room-in-the-house
# 15 Years in the Most Watched Room in the House
## How fifteen years of watching mobile attacks evolve changed the way we talk about protecting them.
There’s a particular type of horror film that tends to stick with you long after the credits roll. It’s the kind that never – or at least rarely – shows you the monster. Instead, you’re introduced to a normal couple in an ordinary living room on a typical evening, working through their boring, everyday, relatable problems. But something beneath the scene refuses to settle. An object on the mantel has moved and neither of them can figure out where it’s gone. There’s a lingering sense that a conversation they held in private wasn’t entirely private. And in the corner of the room, so faint that you might even have imagined it, a thin vertical line of murky white light appears that wasn’t there a second ago.
Nothing particularly significant or scary happens at first, and that’s kind of the point. The dread isn’t in any single nightmarish event but rather in the heaviness of the room itself and the conversations between the people in it. The anxiety you feel watching it is close to how it feels to carry your life around on a mobile device — that low, ambient, but swelling buzz that accompanies the suspicion that you’re being watched, that you’ve shared something you probably shouldn’t have, and that the phone in your pocket knows more about you than it admits. After fifteen years spent watching the mobile threat landscape, we’d suggest that it isn’t paranoia. It’s simply an accurate reading of the room.
### A room that was never built for this
Since Licel was born at the end of June 2011, the phone has quietly become the place where everything converges. Identity, finance, healthcare; the dozens of small acts of digital trust that hold an ordinary day together. Tasks that used to be spread across your wallet, desk drawer, and bank branch all now happen on a single device. Convenience won; completely, and probably for good.
The room where everything of value is kept is also the room most worth watching if you have malicious intentions. The mobile channel – the whole interaction between a person, their device, the apps they rely on everyday, and the systems that those apps talk to – has organically become the most contested space most people own, without anyone really deciding that it should. The phone wasn’t designed to carry all of the sensitive tasks that we now rely on it for; at least not securely. The unease we feel is just a quiet recognition of exactly that. Mobile attacks today are subtle and sophisticated, and mostly invisible from the end user’s point of view.
### Fifteen years of watching the weather change
If the room is the thing that stays still, the weather is everything that’s moved around it. We started out at a time when apps were just beginning to gain traction. Mobile threats were cruder and easier to picture back then. A bad actor would typically carry out a static attack: pulling an app apart, reading its secrets, and building a convincing copy of it.
The first thing that changed was the tooling. Attackers stopped needing to dismantle an app statically at all and started simply leaning on it, observing it while it ran. What we call dynamic attacks often involve hooking into the application, and rewriting its behavior in real time on the device in front of them. The economics changed too. What had once required real skill increasingly became a matter of supply: kits, services, and shortcuts meant that fraud stopped being only something you did and became something you could buy.
Then the world changed profoundly. The COVID-19 pandemic was the final push for moving nearly all of our daily activities onto screens, and primarily onto the one in our pocket. It also handed attackers a population that was more anxious, isolated, and primed to act on urgent messages from supposed authorities. The lever was never the technology. It was the fear; the heaviness that was already in the room.
Most recently, the line between the technical and the human has all but collapsed. AI gives attackers a face that passes a video call, a voice that sounds exactly like a daughter or a director, and a synthetic identity convincing enough to be enrolled as a real one. In the identity-verification bypasses we now see in the field, a fabricated video can be [injected directly into the camera feed an app trusts](https://licelus.com/resources/knowledge_hub/ekyc-fraud), so the face that clears a liveness check was never in front of the phone at all. Behind each attack is a person: an end user opening what looks like an official message, [trusting a face on a screen their own eyes have no reason to doubt](https://licelus.com/insights/when-trust-becomes-the-attack-surface). The weather kept changing, year after year. The person caught in it never did.
### You can’t secure a feeling
Every successful attack we’ve witnessed, across every era, has come down to the same combination: a technical opening and a human being persuaded to walk through the door it opens. The device has always been the route rather than the destination. And the things attackers have reached for in people are nothing new; trust, urgency, deference to authority, a simple instinct to be helpful. These aren’t flaws to be trained away; they are how human beings have been built to operate for as long as there have been human beings.
The usual response is to ask people to be more careful, to spot the signs and slow down. But you can’t patch a reflex. So the sustainable answer is a different one. If trust can no longer be guaranteed by a person's judgment in the moment on the device – and it can’t – then it has to be protected somewhere more reliable: in the mobile channel itself. If the integrity of the application can be assured, then it cannot be cloned or quietly rewritten. If its most sensitive operations can be carried out in an isolated environment, the keys to a digital life cannot be lifted out of it.
### Why we protect the mobile channel
Over the past fifteen years, our own language has slowly changed: from protecting an application to protecting the whole mobile channel. The wall still matters. If anything it matters even more, because everything else now leans on it. But a wall is not a room. A mobile interaction isn't code sitting still in an app store; it's that code running on a device you don't own, in an environment you can't see, talking to a backend that has to decide – often in milliseconds – whether to believe what it's hearing. And if any part of that interaction can be quietly altered – the runtime instrumented, the device's identity faked, the request forged on its way out – then [the backend is trusting a story it has no way of checking](https://licelus.com/resources/knowledge_hub/protecting-mobile-apis-from-bot-attacks). What the channel needs is completeness, not coverage: every protective layer needs to be intact because each one is what makes the next worth trusting.
None of this, in the end, is really about walls or rooms. It's about the person inside. The whole point of protecting the mobile channel is to take the weight off the one part of the system that was never built to carry it: the human being holding the phone. What we’ve learned about keeping that room trustworthy is set out in full on our [Mobile Channel Protection page](https://licelus.com/resources/mobile-channel-protection).
### When Trust Becomes the Attack Surface
[All insights](https://licelus.com/insights)
### Follow us
31 Mar 2026
### When Trust Becomes the Attack Surface
URL: https://licelus.com/insights/when-trust-becomes-the-attack-surface
# When Trust Becomes the Attack Surface
## Why modern fraud succeeds not through ignorance, but through pressure, context, and manipulated decisions
For a long time, scams were seen as a failure of knowledge. If someone was deceived, it was assumed they had missed something obvious like an unusual email address, a poorly worded message, or a detail that didn’t quite fit. But that explanation no longer holds.
Today, many of the most effective attacks succeed not because people lack awareness, but because they are required to make high-stakes trust decisions inside systems that provide limited context, under conditions shaped by urgency, pressure, and manipulation.
A few months ago, a friend of ours was contacted about what appeared to be a legitimate job opportunity. After several rounds of credible email exchanges and a convincing video interview, she was invited to a final stage assessment. As part of the process, she was asked to log in via a familiar identity provider and approve a notification on her phone to continue. Moments after approving the request, the call ended and attempts to contact the company went unanswered. Several anxious days passed until she received an email from her credit score provider to tell her that her application for a bank account and loan had been approved, and that she owed a substantial fee from recent credit card transactions. What had appeared to be a routine step in a structured hiring process had, in reality, been a carefully constructed attack designed to trigger a single, time-sensitive action.
Viewed within the context of months of job searching, a seemingly credible process, a familiar interface, and a real-time request framed as standard procedure, it becomes a decision made under pressure, with incomplete information, inside a system that offered few reliable signals of risk. This isn’t an edge case but part of a broader shift in how fraud works today.
### The exploitation of trust under pressure
Scams are succeeding largely because they align with our own moral reflexes and how we’re expected to behave in modern systems. A lot of attacks these days are the digital equivalent of holding the door open for somebody behind you who appears legitimate. In the digital world decisions are compressed into seconds, often without the context needed to evaluate them properly. People assume a baseline of legitimacy in all digital platforms, interfaces, and communications that appear familiar; the reality is that we all rely on signals that are increasingly easy to spoof. Social engineering works not because people are careless, but because they are responding to situations that have been carefully engineered to appear legitimate. All of us are operating in a digital economy where trust and integrity have become an attack surface. See also [Beware of mental traps](https://licelus.com/insights/beware-of-mental-traps).
### The mobile device: the new trust anchor
The increased power of the smartphone and a prioritization of convenience above all else has resulted in almost all of our daily activities now being mobile-based. From identity, to banking, to authentication and approval, through to messaging, it all converges there. The mobile device has quietly become the identity token of the digital economy. But the mobile channel is anything but trustworthy – it’s one of the most hostile (and most targeted) environments. It’s where OTPs are intercepted, where attackers carry out account takeovers and [eKYC fraud](https://licelus.com/resources/knowledge_hub/ekyc-fraud), and where [malware](https://licelus.com/resources/knowledge_hub/mobile-app-malware-protection) exploits accessibility services and overlays to capture credentials.
### The industrialization of deception
Good people operate on trust, while attackers operate on optimization. Mobile channel trends – combined with rapid advances in AI – have enabled bad actors to optimize and scale fraud with increasing efficiency. Automation, AI-generated phishing kits, voice cloning, and deepfakes have improved both reach and plausibility. At the same time, the systems themselves have become more complex; more steps, more approvals, more signals, but not necessarily more clarity for the user. This creates conditions for verification fatigue: users become used to approving requests without scrutiny. Urgency, information gaps, and heightened emotional states can all degrade decision quality. Global instability doesn’t create fraud, but it amplifies the conditions under which it thrives.
### Protecting trust in an adversarial world
People are now routinely asked to make security-critical choices in environments defined by urgency, incomplete information, and increasingly sophisticated deception. The response cannot be to expect perfect judgment from users operating under this pressure, nor to remove trust entirely. Instead, a shift is required in how systems are designed; away from models that depend on momentary user decisions, and toward models that remain resilient even when those decisions are manipulated. This is particularly important in the mobile channel, where identity, authentication, and approval increasingly converge on a single device. As we explored in [The Mobile Authentication Illusion](https://licelus.com/insights/the-mobile-authentication-illusion), adding more steps does not necessarily create more security, especially when those steps rely on the same environment that may already be compromised.
### Future-proofing digital trust
Human advancement has relied on trust. What has changed in recent years is the environment in which trust is exercised. Scammers are scaling deception by exploiting system design, human psychology, and contextual pressure. The response cannot be to abandon trust, but to build systems that are resilient to its exploitation. Our work has always focused on defending the integrity of the mobile channel, because we know that is where modern-day high-stakes decisions are made - and where they must be protected.
### The Mobile Authentication Illusion
[All insights](https://licelus.com/insights)
### Follow us
28 Jan 2026
### The Mobile Authentication Illusion
URL: https://licelus.com/insights/the-mobile-authentication-illusion
# The Mobile Authentication Illusion
## Why More MFA Doesn’t Mean More Security
There are two fundamental flaws in mobile authentication today. The first is that we seem to have forgotten the main principle of authentication; that the second factor should live on a different device (out-of-band). Our obsession with – and reliance on – the mobile device means that we tend to be using it to carry out sensitive transactions and operations, and receive multiple factors of authentication there as well. The second flaw is that authentication checks tend to be quite static and shallow; they are nowhere near substantial enough for the complexity and sophistication of threats around modern-day mobile devices.
If you can’t trust the device, then you can’t trust the factors of authentication that arrive on it. Until we recognize this and accept the need to rely on layered, trusted, tamper-proofed signals about the wider security of the device, the application, and the environment around it, then we’ll never have true authentication. Instead we’ll be left with the illusion of mobile authentication.
### The second factor has stopped being a second factor
Authentication used to mean separation; the second factor lived somewhere else. But the mobile device – and our increasing dependence on it – has collapsed those old boundaries. Today, most authentication journeys begin and end on the same device. We now live with a seemingly never-ending layering of factor upon factor of authentication (SMS OTPs and push notifications, email codes and magic links, authenticator apps, passkeys, OS-level biometrics, facial recognition and liveness checks, callbacks and human verification, NFC scans). It’s as if trust has been patched over a number of years rather than being redesigned or engineered fully.
### Abracadabra
All of this layering gives an illusion of authentication and security. Instead of the three distinct factors of authentication – something you know, something you have, and something you are – you end up with one potentially compromised environment wearing three different costumes. It doesn’t matter how many factors you have if they all execute in the same compromised environment. The question that authentication currently asks is “did they authenticate successfully?” But should we not instead be asking whether we can trust the environment from which signals are arriving? Can we trust the signals that this device is producing right now?
### Meeting Henry
Imagine you’ve arranged to meet someone called Henry, whom you met once before. On the day, someone shows up who matches a photo reasonably well. Close enough. But most of us wouldn’t stop there; we’d ask questions, expect recognition, and seek continuity in behavior and shared history. In mobile security it has somehow become acceptable not to probe for this wider context. If a single expected value (a hash, a signature, an identifier) matches, then the app is automatically treated as genuine. An attacker doesn’t need to be Henry; they just need to resemble him closely enough to pass a cursory glance. Real trust comes from coherence across various independent signals and from noticing when something doesn’t quite add up.
### Even supposedly strong mobile authentication can be flawed
Even methods like NFC scans of a passport can be exploited if the integrity of the mobile device cannot be authenticated. Malware is capable of replaying data without the passport even being required, redirecting payment flows to fraudulent endpoints. We call these [NFC Relay (or NFC Proxy Malware) Attacks](https://licelus.com/insights/the-rise-of-nfc-proxy-malware-attacks). Phishing-resistant is not the same as compromise-resistant. Passkeys and push OTPs are excellent against phishing, but they don’t protect against device compromise; if the device is already under an attacker’s control, then the strongest factor can be repurposed into a willing accomplice.
### The Mobile Authentication Illusion doesn’t end at the API
There’s a second illusion: [how the backend can authenticate the mobile app itself](https://licelus.com/insights/api-protection-from-afterthought-to-necessity). Most mobile backends rely on API keys, shared secrets, signed requests, client certificates, and access tokens. In reality, the backend isn’t authenticating an app at all but a credential. Once an API key, signing secret, or token is extracted – via reverse engineering, runtime instrumentation, memory dumping, or reusing an older version of the app – any script, bot, emulator, or modified client can present it just as convincingly as the genuine app. True Mobile API trust, like true authentication, requires more than possessing a secret. It requires evidence that the request is coming from a genuine, tamper-proofed, up-to-date app, running in a trustworthy environment.
### Authentication when the user isn’t human
Autonomous AI agents are already logging into services, calling APIs, signing requests, and initiating transactions on behalf of people or organizations, using the same mechanisms humans rely on: keys, tokens, certificates, and delegated credentials. The uncomfortable question is: how do we know which AI agent is making a request, on whose authority, and whether it has been modified or cloned? We asked these questions in [how not to lose your identity in 2035](https://licelus.com/insights/how-not-to-lose-your-identity-in-2035).
### Why the future of authentication should be quieter, not louder
Secure mobile authentication shouldn’t be about adding more and more layers, but rather making it easier to trust the layers we’ve already created. That means allowing for risk-based decisions and context-aware enforcement, which can only be achieved if we can verify the integrity of the mobile channel. Authentication isn’t flawed because we don’t have enough factors; it’s flawed because we’ve stopped asking whether we can trust them in the first place. Smart, future-proofed security is about trusting fewer things much more deeply. See [Mobile API Protection from DexProtector](https://licelus.com/resources/knowledge_hub/mobile-api-protection).
## Knowledge Hub
### Protecting Mobile APIs From Bot Attacks: Why Request Signing Alone Is No Longer Enough
URL: https://licelus.com/resources/knowledge_hub/protecting-mobile-apis-from-bot-attacks
# Protecting Mobile APIs From Bot Attacks: Why Request Signing Alone Is No Longer Enough
Protecting mobile APIs from bot attacks means doing more than signing requests. It means verifying that every request is coming from a genuine, untampered application and not from a script, bot, or compromised client. Mobile APIs are a primary target for modern fraud and bot attacks, and the mobile application itself is often where those attacks begin — the easiest place to study business logic, reconstruct request formats, extract embedded secrets, and automate abuse at scale.
### The traditional model: signing requests with embedded secrets
For years the standard pattern was to embed secret material inside the app and use it to calculate a request signature (often an X-Signature header). The backend verifies the signature and assumes the request came from a genuine application. The problem is that the mobile application runs in an environment you don't control — a single fact that changes everything. The secret may be embedded as a hardcoded symmetric key, a bundled file, a PKCS#12 container, a runtime-loaded private key, or a static secret used to derive a signing key. This architecture is easy to deploy but its core assumption ("only our app can produce valid signatures") doesn't hold under real-world attack conditions.
### Why attackers start with the mobile app and not the backend
Attackers begin by attacking the client, because the client gives them three things: the request structure, the signing logic, and the signing material.
Stage one — understanding request structure through MITM: if the app doesn't enforce robust network trust controls such as Public Key Pinning and Certificate Transparency, an attacker can intercept traffic and learn the API's request method, URL structure, headers, mandatory fields, sequencing, and replay behavior. Tools like Burp Suite, mitmproxy, and Charles Proxy make this accessible. DexProtector applies reinforced Public Key Pinning and Certificate Transparency controls, extending protection beyond what the OS provides.
Stage two — static extraction of embedded secret material: the attacker decompiles the APK/AAB (jadx, apktool, Ghidra) or analyzes the IPA (Hopper, IDA, class-dump), searching for hardcoded keys, bundled certificates, PKCS#12 containers, and code paths that initialize signing. DexProtector's static protection (String Encryption, Hide Access, Class Encryption, Resource Encryption) is designed to make this extraction prohibitively complex, and DexProtector Studio can visualize embedded secrets and suggest an optimal configuration.
Stage three — dynamic tracing and API hooking: even when a secret is obscured statically, the app must eventually use it. Using Frida, Xposed, or Cydia Substrate, attackers trace cryptographic API calls (javax.crypto.Mac, java.security.Signature, SecKeyCreateSignature, CCHmac) to observe when the key is loaded and what is signed. Advanced attackers may run custom AOSP firmware to patch framework-level crypto. DexProtector's runtime (RASP-style) protection raises the cost of instrumentation, increases detection risk, and disrupts common hooking workflows.
### TikTok's multi-layered signing: why it still gets broken
TikTok chains multiple cryptographic operations (custom hash functions, XOR-based transformations, multiple encryption rounds) producing signatures through headers like X-Gorgon, X-Khronos, and X-Ladon. This genuinely raises the cost of reverse engineering, yet it has been reverse engineered and circumvented — commonly by instrumenting the native libraries at runtime and invoking them directly. If the signing logic runs in the attacker's environment, complexity alone is not a security boundary; it is a time delay. Complexity buys time, not immunity.
### When the app itself becomes a signing oracle
Even with strong hardening, if the signing operation is still controlled by the client environment, the attacker may not need to steal the secret at all. They can run the genuine public app on their own device and manipulate it — via instrumentation, accessibility services, automation frameworks, or modified system components — into producing valid signed requests. The app still produces a technically valid signature, but inside an environment controlled by the attacker. The question is not only "can the attacker steal the key?" but "can the attacker make the app sign on their behalf?"
### Binding requests to app integrity, not just to a secret
The architectural response is to treat request authentication as a combination of request integrity and application integrity. The backend should verify not only that the request was signed correctly, but that it was generated by a genuine application instance that passed relevant security checks at the time the request was made. This is where Mobile API Protection changes the model: the backend can validate a richer token representing application authenticity, package identity, signing identity, app version compliance, runtime integrity results, device and environment trust indicators, anti-tamper outcomes, and anti-replay properties — and correlate it with Alice Threat Intelligence telemetry.
JWT-style protected request assertions add: freshness (short-lived tokens reduce replay value), server-verifiable integrity evidence, better policy control (reject outdated versions, tampered builds, rooted/jailbroken devices at the API level), clearer anti-fraud linkage, and easier evolution (change server-side validation without redesigning the app protocol). Adjusting the request structure when deploying Mobile API Protection makes previously captured request templates, replay scripts, and signature-generation tooling obsolete in one step.
### Where the Licel vTEE fits
The Licel vTEE moves especially sensitive logic and material (key handling, request authorization logic, token generation, challenge-response flows, transaction binding, anti-replay metadata generation) into a more isolated execution model inside the app. Without the vTEE, the attacker hooks the app process and observes the signing operation from the same context; with the vTEE, the most sensitive operations happen in a separated context that is significantly harder to instrument.
### A practical layered defense model
Layer 1: protect the network channel (Public Key Pinning, Certificate Transparency). Layer 2: harden the app against static analysis (String/Class/Resource Encryption, Hide Access). Layer 3: resist runtime manipulation (RASP, anti-hooking). Layer 4: verify app integrity on the backend (Mobile API Protection). Layer 5: isolate the most sensitive logic (Licel vTEE). Layer 6: connect trusted mobile signals to fraud decisions (telemetry into anti-fraud models, rate limits, session controls, step-up authentication). A mobile API should trust a request only when it is correctly formed, cryptographically valid, and backed by evidence that it originated from a genuine, untampered application instance operating under acceptable runtime conditions. No client-side defense is permanently unbreakable; the goal is economic — make attacks cost more than they are worth, and ensure that when one layer is bypassed, the next layer catches it.
### Mobile App Malware Protection for Banking and Payment Applications
URL: https://licelus.com/resources/knowledge_hub/mobile-app-malware-protection
# Mobile App Malware Protection for Banking and Payment Applications
Mobile malware has evolved into a structural risk for banking and wallet apps. It has helped attackers scale already-growing threats like eKYC and payment fraud, and account takeovers. Simply scanning for malicious apps isn't enough. A multi-layered defense — including runtime integrity, resistant execution, and trusted signals to enable risk-based decision making — is required to mitigate malware's impact.
### Backend fraud systems can't see the full picture
The presence of malware isn't always obvious to the server. Even if a device's environment were compromised, the device fingerprint, OTP, biometrics, and API requests could still appear valid and pass. Modern mobile banking trojans and remote access tools no longer need to break authentication flows; they operate inside legitimate sessions, observing inputs, manipulating flows, replaying data, or redirecting transactions — all while appearing legitimate to the backend. This is why runtime integrity is a prerequisite for malware detection and prevention. See [Mobile API Protection](https://licelus.com/resources/knowledge_hub/mobile-api-protection) and [eKYC Fraud Prevention](https://licelus.com/resources/knowledge_hub/ekyc-fraud).
### Prevention: reducing malware's leverage at runtime
The best place to start is inside the app itself. [DexProtector](https://licelus.com/products/dexprotector) enforces runtime integrity controls, making it much harder for malware to instrument application logic, hook security functions, inject code, run in emulated or virtualized environments, carry out overlay attacks and screen capture, or repackage/modify the app binary. Mechanisms detecting rooted and jailbroken devices and custom firmware reduce malware's exposure further.
### Detection: identifying potentially harmful applications
[Alice Threat Intelligence](https://licelus.com/products/alice-threat-intelligence) complements prevention via an embedded malware and potentially harmful app database, over-the-air (OTA) database updates, customizable categorization and enforcement policies, and reporting of malware detection events. Alice's detection signals can be trusted because they've already been tamper-proofed by DexProtector.
### Intelligence at scale: from detection to decision
Tamper-proof signals enable SOC teams and fraud engines to enrich fraud scoring systems, trigger step-up authentication, delay high-value transactions, investigate emerging malware campaigns, perform forensic analysis, and feed SIEMs (Google SecOps, Microsoft Sentinel, Splunk Cloud). Because security events include install, session, and device ID, they enable end-to-end tracking and risk-based decisions rather than blanket lockouts.
### Isolation: additional protection for high-assurance environments
Mobile wallets, SoftPOS solutions, and Digital ID apps must prevent any leakage of cryptographic keys. [The Licel vTEE](https://licelus.com/products/vtee) provides a secure and trusted execution environment for the storage of cryptographic material and cryptographic calculations, so even if a device is compromised, critical cryptographic processes remain protected.
### Compliance considerations
Modern mobile security standards assume resilience against malware — EMVCo SBMP, PCI MPoC, OWASP MASVS, MAS TRM (Singapore), RBI Digital Payment Security Controls (India), GLBA Safeguards Rule (USA), HKMA (Hong Kong), and Circular-50-2024-TT-NHNN/77-2025-TT-NHNN (Vietnam) all emphasise protection against runtime tampering, malware interference, and hostile execution environments. Effective mitigation requires runtime integrity enforcement, resistant execution, isolated protection for critical operations, trusted sensors and monitoring, structured threat telemetry, and intelligent detection. See the [Mobile Banking Case Study](https://licelus.com/resources/knowledge_hub/mobile_banking).
### EMVCo SBMP Security Requirements: How Licel solutions can help you achieve EMVCo SBMP compliance
URL: https://licelus.com/resources/knowledge_hub/emvco-sbmp-security-requirements
# EMVCo SBMP Security Requirements
### What is EMVCo SBMP?
EMVCo SBMP is EMVCo's security evaluation process for Software-Based Mobile Payment solutions — a globally-recognised framework that evaluates and certifies the security of mobile applications that rely on software to protect sensitive data and processes. Licel solutions (DexProtector, the Licel vTEE, and Alice Threat and Device Intelligence) help app developers achieve EMVCo SBMP compliance by enabling trusted execution of sensitive operations on consumer devices, extending protection beyond what platform APIs or hardware security alone can offer. In January 2025, version 1.5 of the EMVCo SBMP requirements was released, extending its focus to ecosystem-wide app-based financial interactions.
### The Licel solutions
DexProtector: a no-code security solution for Android and iOS applications, SDKs, and libraries. Core mechanisms include integrity control, obfuscation, encryption, anti-tampering/debugging, root detection, anti-instrumentation, anti-emulation, and SSL Pinning, plus anti-malware, UI protection, API protection, and Device Intelligence. Evaluated and approved by EMVCo for 6 consecutive years. The Licel vTEE: a secure environment for trusted applications, evaluated and approved under EMVCo's SBMP for TEE category for both Android and iOS — currently the only TEE of any kind (hardware or software) approved under EMVCo SBMP TEE. Alice Threat and Device Intelligence: real-time reporting drawing on hundreds of device and environment parameters.
### Why Licel for EMVCo SBMP compliance?
Evaluated and approved by EMVCo for 6 years running; designed to fulfill SBMP Software Protection Tool and vTEE requirements; full coverage of mobile channel protection (app, device, and backend); faster compliance, lower costs, and less development complexity.
### Mapping requirements to solutions (selected)
2.4 Consumer Device Platform — Basic Platform: DexProtector's binary protection, obfuscation, encryption, virtualisation and isolation; the Licel vTEE's white-box cryptography and virtual TEE isolate cryptographic operations and key material. Enhanced Platform: the Licel vTEE runs Trusted Applications on both Android and iOS. See [What is a Trusted Application?](https://licelus.com/insights/what-is-a-trusted-application).
3.1 Application Design and Development — Secure Communication Channels: DexProtector's Public Key Pinning and Certificate Transparency prevent MITM. Platform Security: DexProtector's RASP Engine and Alice detect rooted devices and instrumentation tools (e.g. Frida) and report anomalies. Application and Device Attestation: DexProtector integrity control plus a proprietary attestation engine anchored in the hardware-backed keystore, augmented by Alice's device intelligence.
3.3 User Enrolment / 3.4 Provisioning and Credential Issuance: RASP + Alice determine device trust before releasing protected data; the Licel vTEE carries out device binding to a specific device using unique keys.
3.6 Monitoring and Reporting: Alice increases observability, identifies malware and compromised devices, and assesses per-session risk in real time and retrospectively via the Alice API.
3.7 Mobile Application Security and Management: DexProtector's RASP engine enables runtime self-protection and integrity verification; the Anti-Malware module checks known signatures plus heuristics; the UI Protection Module prevents screen capture and reduces remote access fraud. 3.7.1 Update Mechanism: the Licel vTEE includes downgrade and replay attack protection; DexProtector's Mobile API Protection secures backend APIs.
4. Mobile Application Security Architecture: DexProtector (obfuscation, encryption, RASP, integrity control) combined with the Licel vTEE (white-box cryptography, virtual TEE) protect payment credentials, tokenised cards, and protected health information. Payment Threats (4.2.3): Anti-Malware, UI Protection, RASP, Alice, and the Device ID module make cloning much harder — data is cryptographically bound to the legitimate device.
6. Attacks: Licel solutions counter bypassing platform security controls, reverse engineering source code, modifying application code (DexProtector signs the app with dynamically reconstructed keys), exploiting interfaces between components, extracting assets in runtime, and modifying application code flow — largely via RASP detection of debuggers, emulators, and DBI tools such as Frida, plus vTEE isolation.
### EMVCo SBMP compliance made easier
By integrating pre-validated security frameworks that align with EMVCo SBMP requirements, organizations reduce the time and costs of their own security assessments, speed up time-to-market, deal with evolving threats (Licel re-tests its solutions at least annually), and position themselves as leaders in secure mobile solutions.
### Mobile Banking App Security: A Case Study
URL: https://licelus.com/resources/knowledge_hub/mobile_banking
# Mobile Banking App Security: A Case Study
Our client is a leading digital bank in Europe with 13.5 million users. Almost all of the bank's transactions are conducted via its mobile application; there are no physical branches. Robust security is a must if the bank wants to maintain customer trust and its hard-earned reputation.
### The challenge
Four key goals: prevent Account Takeovers (ATO) — attackers using stolen or phished credentials to access accounts from a different device; address mobile banking fraud — bad actors circumventing ID verification to open accounts fraudulently and take out loans or credit; combat malware and phishing — increasingly sophisticated malware, banking trojans, remote access tools (RATs), and AI-powered social engineering; and keep on top of how attacks are evolving with a reliable threat and device intelligence solution.
### The solution — Mobile Banking App Security in Action
The bank implemented [DexProtector](https://licelus.com/products/dexprotector) and [Alice Threat Intelligence](https://licelus.com/products/alice-threat-intelligence) across its Android and iOS applications.
1. Preventing Account Takeovers: Licel's Device Intelligence identifies login attempts from unrecognised or untrustworthy devices, going beyond a simplistic identifier/fingerprint. Example: an attacker with phished credentials attempts access from an unrecognized device; the bank queries the Alice API to evaluate the session risk profile and prevents the ATO.
2. Stopping mobile banking fraud: Licel solutions identify suspicious devices, stop deepfakes and image-injection spoofing, prevent use of outdated/tampered app versions, encrypt on-device data, and ensure eKYC checks take place in a secure environment. Example: an attacker uses a virtual camera app to spoof biometric verification; DexProtector's RASP engine and Anti-Malware module detect it and prevent the eKYC bypass.
3. Mitigating malware: the Anti-Malware module checks known signatures plus heuristics; the UI Protection Module prevents screen capture and reduces remote access fraud. Example: dormant malware attempts to access sensitive app data when the app opens; Licel detects and reports it, enabling the bank to restrict activity and block transactions.
4. Threat monitoring: Alice monitors real-time threat data, updates defenses against emerging vectors, and surfaces suspicious patterns; analysts retrieve incidents filtered by User ID or Session ID to enrich the existing fraud monitoring system.
### The impact of Licel solutions
More granular and sophisticated protection (apps protected against cloning, runtime attacks — particularly Frida — and injections via Android cloud emulators; better root/jailbreak/emulator detection); stronger device identification and verification (verifying requests come from legitimate app versions, securing the request-signing key via code encryption); more threat intelligence for better fraud prevention (significant reduction in successful eKYC fraud attempts and Account Takeovers); and easy implementation (DexProtector set up on both iOS and Android with all required protection mechanisms in around one month).
### Android and iOS Obfuscation Done Right: Protecting the Final Container
URL: https://licelus.com/resources/knowledge_hub/android-ios-obfuscator-apk-aab-ipa-xcarchive
# Android and iOS Obfuscation Done Right: Protecting the Final Container
There's a simple test that separates a real Android or iOS obfuscator from a source-level tool with good marketing: ask what artifact it actually protects. If the answer is "your source code" or "your Gradle module," you have a partial solution. The artifact your users download — and the artifact attackers reverse engineer — is the final container: the APK or AAB on Android, the IPA or XCArchive on iOS. If your protection never sees that container, it cannot guarantee its integrity. This is the principle DexProtector has been built around for fifteen years: you cannot protect the integrity of what you don't see.
### Why post-build obfuscation matters
Most obfuscation tools operate at the source or intermediate-representation level. They rename classes, perhaps encrypt some strings, then hand the result back to your build pipeline where signing, packaging, resource processing, and third-party tooling continue to modify the artifact — so whatever integrity guarantees existed at obfuscation are gone by the time the app ships. A post-build obfuscator takes your finished, ready-to-ship container (APK, AAB, IPA, or XCArchive) and applies protection directly to it: code hardening (obfuscation, encryption, and virtualization of Dalvik bytecode, native libraries, and iOS binaries); resource and asset encryption in the final package; integrity control with dynamic cryptographic key calculations derived from the protected container itself (modify, repackage, patch, or resign it and the app stops working); and runtime defense via the embedded DexProtector Runtime Engine (DRE) providing RASP.
### AAB protection: the container Google actually distributes
Since Google Play made the Android App Bundle mandatory, "AAB protect" has become its own discipline. An AAB is not an APK: Play generates device-specific APKs from it, so naive protection breaks — integrity checks computed against the bundle don't match the split APKs users receive. A proper AAB protector understands the bundle format natively: protecting base and feature modules, surviving Play's split generation, and still delivering integrity verification on the device-specific APKs. DexProtector supports AAB as a first-class input; the same applies to APKs for sideloaded, enterprise, and alternative-store distribution.
### IPA and XCArchive obfuscation on iOS
iOS is often assumed "safe enough" out of the box, but decrypted IPAs circulate within hours of release, and Frida and similar dynamic instrumentation frameworks work just as well on iOS as on Android. An iOS obfuscator operating on the final container (the IPA or XCArchive produced in Xcode) can apply protections source-level Swift/Objective-C obfuscation cannot: obfuscation and encryption of the actual Mach-O binaries that ship (including frameworks and extensions); integrity control bound to the final signed artifact; RASP via the embedded DRE (jailbreak detection, anti-instrumentation, anti-debugging, environment checks); and secure network communications (SSL pinning and certificate transparency) hardened into the shipped binary. Working with the XCArchive drops into your existing release pipeline with no source changes and no SDK to integrate.
### On-premises by design
The entire obfuscation and protection process for Android and iOS runs fully on-premises, inside your own environment, with no reliance on any cloud service. Your unprotected APK, AAB, IPA, or XCArchive never crosses your network boundary. This matters for confidentiality of the unprotected artifact, compliance and data residency (banks, payment providers, and public-sector bodies often cannot ship pre-release binaries to external processors), availability and pipeline independence (air-gapped if needed), and avoiding a silent call-home dependency that is itself an attack surface.
### Scale, evaluation, and how to choose
Stability and speed are security features: DexProtector runs on 12 billion+ protected app installation instances worldwide, so instability is not an option and performance overhead is measured obsessively. It has been evaluated and approved by independent security laboratories for six consecutive years under EMVCo's software-based mobile payment security program. Questions to cut through the noise when comparing tools: does it protect the final container (APK, AAB, IPA, XCArchive) or only source/intermediate code; does the process run entirely on-premises with no cloud upload; is integrity verification bound to the shipped artifact so repackaging kills the app; does it include runtime protection (RASP); has it been independently and repeatedly evaluated by accredited labs; and who runs it in production, at what scale, and for how long? (Note: R8/ProGuard shrink and rename for size, not security — a build tool, not an Android obfuscator in the security sense.)
### Protecting an SDK Is Harder Than Protecting an App. Here's How to Do It.
URL: https://licelus.com/resources/knowledge_hub/android-ios-sdk-obfuscator-aar-protection
# Protecting an SDK Is Harder Than Protecting an App
If you develop a payments SDK, an authentication library, a SoftPOS kernel, or any commercial Android AAR or iOS framework, you face a security problem SDK integrators never will: your code ships inside binaries you don't control, on devices you'll never see, integrated by development teams working across different environments, toolchains, and security practices. The application's build process and security measures are outside your control — you cannot assume the app will be properly obfuscated or signed — and yet your SDK often contains exactly what attackers want: payment logic, cryptographic key handling, fraud-detection heuristics, proprietary algorithms, licensing checks. One published bypass of your SDK affects every customer who embedded it.
### What makes SDK protection different
1. An SDK is not the final container. It is incorporated into a host application, so its protections must coexist with the app's own security controls and any other integrated SDKs; it cannot guarantee the app is resistant to static analysis, and it can be removed, replaced, or bypassed by an attacker who repackages the integrating application. 2. Integration friction must be zero. Customers integrate via Gradle, CocoaPods, or Swift Package Manager; if protection changes the public API surface, breaks ProGuard/R8 consumer rules, or requires host-side initialization, adoption suffers. The protected artifact must be a drop-in replacement. 3. Runtime defense can't assume a friendly host. An attacker builds a minimal harness app, drops your AAR or framework in, and instruments it at leisure with Frida or a debugger; an obfuscator that depends on the host app's protections protects nothing.
### How DexProtector protects AAR libraries and iOS frameworks
DexProtector applies protection directly to the SDK artifact intended for distribution (a release Android AAR, XCFramework, or static/dynamic iOS framework), returning a hardened version that preserves the existing integration process: code obfuscation and encryption of the SDK's classes, native libraries, and resources with the public API preserved exactly; class encryption, string encryption, and hide access so decompiling the host app reveals nothing usable; resource encryption for sensitive assets (embedded databases, AI models, media); RASP via the embedded DRE so the protected library detects hooking frameworks, debuggers, emulators, root/jailbreak, and tampering independently — even inside an untrusted host; secure communication hardening (pinning and certificate transparency enforced from inside the library); and integrity control with cryptographic binding between protected code/assets and the DRE, enforcing a chain of trust from build-time to runtime. The same pipeline covers Android (AAR) and iOS (frameworks and XCFrameworks), and the entire process runs on-premises with no cloud dependency.
### Telemetry, isolation, and evidence
Because the DRE is already inside every protected SDK instance, enabling [Alice Threat Intelligence](https://licelus.com/products/alice-threat-intelligence) is a configuration step, giving SDK vendors the aggregate threat picture across their entire customer base (Alice RDA, a forthcoming real-time device attestation service, will extend this into per-device trust signals). For SDKs handling the most sensitive operations (payment credentials, PIN entry, key management in SoftPOS kernels), the [Licel vTEE](https://licelus.com/products/vtee) provides a virtual trusted execution environment evaluated under EMVCo's TEE security program. DexProtector has been independently evaluated and approved for six consecutive years under EMVCo SBMP SPT and runs on 12 billion+ protected app and SDK instances worldwide.
### A practical checklist for SDK vendors
When evaluating an AAR obfuscator or iOS SDK obfuscator, verify: 1. Drop-in output (protected AAR/framework integrates identically to the unprotected one). 2. Self-contained RASP (the SDK defends itself inside an attacker's harness app). 3. Native code coverage (.so libraries or native iOS code, not just managed code). 4. On-premises protection (never uploaded to a vendor cloud). 5. No consumer-rule conflicts (coexists with the customer's R8/ProGuard configs and other protection tools). 6. Evidence (independent lab evaluations, named industries, production scale).
## Resources — Mobile Channel Protection
### Mobile Channel Protection
URL: https://licelus.com/resources/mobile-channel-protection
# Mobile Channel Protection
## Securing the entire interaction between user, device, application, and backend.
In short: mobile app protection secures the code inside the app; mobile channel protection secures the entire interaction — the application, the device, the runtime environment, and the communication with backend systems. As mobile fraud increasingly begins on the device rather than the backend, securing the code alone isn't enough anymore.
Mobile fraud often begins on the device rather than the backend, and the protections most organizations rely on were designed for a different era, when securing the application's code was enough to secure the interaction. Mobile Channel Protection is the practice of securing every layer of the interaction between a user, their device, a mobile application, and the backend system it communicates with. It ensures the integrity, confidentiality, and authenticity of mobile interactions across the application itself, its runtime environment, and its communication flows with backend systems.
### The Evolution of Mobile Threats
Mobile threats have evolved, with the attack surface expanding from the application itself, to the runtime environment, to the entire communication channel between app and backend — a shift from static attacks, to runtime attacks, to mobile channel attacks. Attackers first focused on the application binary (decompiling, repackaging, cloning). As static protections like encryption and obfuscation improved, attacks became dynamic, targeting apps while running via instrumentation tools, debuggers, hooking tools, emulators, and malware. Today, the most sophisticated attacks target the entire interaction between app and backend — mobile API manipulation, session hijacking, and combined attacks blending malware with social engineering — meaning even a well-protected app can be part of a compromised mobile channel. In many ways the target today has become trust itself. Security has evolved from protecting code, to protecting execution, to protecting the entire mobile channel.
### How is Mobile Channel Protection Different from Mobile App Protection?
Traditional mobile application security focuses on securing the code inside the app; reverse engineering protection, and preventing tampering and repackaging. This is essential and must remain a foundation stone, but it only addresses part of the problem. A mobile app communicates constantly with backend systems, processes sensitive data at runtime, and operates in environments neither the developer nor the organization controls. Think of traditional app protection as securing everything inside a coffee cup; mobile channel protection means stepping back to see the whole picture — the cup, the table it sits on, the room, and everything that could affect what's inside. If an app can be compromised, its runtime manipulated, its signing logic traced, and its API requests forged, then the backend cannot trust what it receives.
### The Layers of Mobile Channel Protection
Why static protection still matters: static protection (code obfuscation, encryption, hardening of the application package/container) prevents attackers from decompiling, analyzing, and understanding the app's code, logic, and embedded secrets. It is the foundation of backend trust. If an attacker can understand your app, they can do far more than copy it.
Runtime integrity — what RASP really means: RASP operates while a mobile application is running. A complete view of runtime integrity: RASP should detect and respond to anything unexpected during execution — debugging and dynamic instrumentation tools, hooking and code injection, rooted and jailbroken devices, emulators and virtualized environments, malware, overlays, and remote access tools. Critically, RASP doesn't just detect but also enforces: it can restrict functionality, alert backend systems, or prevent execution entirely.
Communication integrity — why backend trust depends on what comes before: the security of the communication channel depends entirely on the static and dynamic protection layers beneath it. Most organizations protect their mobile APIs using request signing (embedding a secret in the app), but if the app can be reverse engineered the secret can be extracted; if the runtime can be manipulated the signing logic can be traced. Communication integrity is the output of everything that precedes it. See [protecting mobile APIs from bot attacks](https://licelus.com/resources/knowledge_hub/protecting-mobile-apis-from-bot-attacks).
Device trust and integrity: the mobile device has become the primary trust anchor, but device identity can be faked — device IDs spoofed, emulators presenting as real devices, install IDs replicated. Even hardware-backed trust signals are not immune: Android attestation keys have historically been reused across large batches of devices and leaked over the years, and on some devices a request to store material in hardware silently falls back to software. Ironically, devices have become more vulnerable at the same time that we've made them more central to digital trust.
### Cross-Validation and Trusted Signals
Every layer of the mobile channel generates signals — the application produces integrity signals, the runtime produces environment signals, and the communication layer produces behavioral signals. Together they form a picture of whether a session is genuine, but only if those signals can be trusted, correlated, and acted upon in real time. If a session reaches your backend but no tamper-proofed, cryptographically verifiable signal exists, it is not a legitimate app. This cross-validation lets teams block a high-risk session outright, delay a high-value transaction pending verification, or flag a device for step-up authentication.
### How Mobile Channel Protection Works Across All States
Data at rest (protecting logic before it runs): code protection, obfuscation, and encryption. Data in use (protecting execution as it happens): RASP, runtime integrity checks, vTEE and white-box cryptography. Data in transit (protecting interactions with the backend): [Mobile API protection](https://licelus.com/resources/knowledge_hub/mobile-api-protection), SSL pinning / Certificate Transparency, and interception prevention. Static protection enables runtime trust, runtime integrity enables communication trust, and communication trust enables backend trust. Remove one layer and everything weakens.
### The Licel Approach: Integrity, Intelligence, and Isolation
Integrity — the app defends and verifies itself: [DexProtector](https://licelus.com/products/dexprotector) provides the foundational layer via mobile app shielding, RASP, anti-tampering controls, and communication hardening. Independently evaluated by EMVCo under SBMP SPT for six consecutive years. Intelligence — trusted signals inform smarter decisions: [Alice Threat Intelligence](https://licelus.com/products/alice-threat-intelligence) converts tamper-proofed signals into real-time intelligence via the Alice Dashboard, the Enterprise API, or the real-time data stream, enabling a move from "refund and react" to "detect and block." Isolation — critical operations take place in a secure vault: [the Licel vTEE](https://licelus.com/products/vtee) provides a virtual Trusted Execution Environment for the most sensitive operations (device binding, key handling, token generation, request signing, cryptographic logic), independently evaluated and approved by EMVCo under SBMP TEE for two consecutive years.
### What Mobile Channel Protection Makes Possible
Fraud becomes uneconomic to execute at scale; authentication can be both stronger and lighter; the backend gains a reason to trust what it receives; and compliance becomes evidence-based rather than process-based (supporting obligations under frameworks such as PSD2). At its core, mobile channel protection is about closing the gap between what the backend assumes and what is actually happening on the device.
## The Layers Bulletin
URL: https://licelus.com/layers-bulletin/
The Layers Bulletin is a monthly digest of Licel product updates, threat intelligence, and mobile app security trends. Individual issues:
- [Why Mobile App Protection Is Even More Vital in the AI Era — 30 Jul 2026](https://licelus.com/layers-bulletin/layers-bulletin-july-2026)
- [A Wall is not a Room; 15 Years of Watching the Mobile Channel Grow — 28 Jun 2026](https://licelus.com/layers-bulletin/layers-bulletin-june-2026)
- [Mobile Channel Protection in Practice: the Licel vTEE Earns EMVCo Approval Again — 28 May 2026](https://licelus.com/layers-bulletin/layers-bulletin-may-2026)
- [How We're Securing a Changing Mobile Device Ecosystem — 28 Apr 2026](https://licelus.com/layers-bulletin/layers-bulletin-april-2026)
- [DexProtector is Fully Compatible with Android 17 Beta 3 — 31 Mar 2026](https://licelus.com/layers-bulletin/layers-bulletin-march-2026)
- [Preparing for Android 17: What it Means for Mobile Trust — 27 Feb 2026](https://licelus.com/layers-bulletin/layers-bulletin-february-2026)
- [Consistent, Verified Trust Under Pressure — 30 Jan 2026](https://licelus.com/layers-bulletin/layers-bulletin-january-2026)
- [Why You Need Trusted Signals in the Age of Mobile Fraud — 19 Dec 2025](https://licelus.com/layers-bulletin/layers-bulletin-december-2025)
- [How Not to Lose Your Identity in 2035 — 27 Nov 2025](https://licelus.com/layers-bulletin/layers-bulletin-november-2025)
- [Innovation and Integrity; 12 years of building protection that lasts — 29 Oct 2025](https://licelus.com/layers-bulletin/layers-bulletin-october-2025)
- [Layers of insights, from product updates to real-world threat intel — 30 Sep 2025](https://licelus.com/layers-bulletin/layers-bulletin-september-2025)
### Layers Bulletin — July 2026: Why Mobile App Protection Is Even More Vital in the AI Era
URL: https://licelus.com/layers-bulletin/layers-bulletin-july-2026
30/07/2026 · 4 min to read
# Why Mobile App Protection Is Even More Vital in the AI Era
A weakly protected application effectively prepares its own documentation for the attacker. That line is from our latest article that explores security in the AI world. Can AI reverse engineer a mobile application? It isn't a magic button that can turn protected binaries back into source code. But what it can do is reduce the cost of reaching the next useful result; especially if the material it's given is clean, readable, and structured. The answer isn't to prohibit AI, or to rely on model providers to monitor and refuse malicious-looking prompts. Instead, it's to give bad actors less to work with in the first place by protecting how the app executes, and validating signals across the whole mobile channel.
Two conditions a serious runtime layer has to detect are sharpened in the latest DexProtector releases this month: new iOS runtime checks expand detection of virtualized and simulated environments, and enhanced Android protections strengthen defense against runtime code injection. Protection becomes more complicated when you develop an SDK rather than an app. Attackers targeting SDKs don't even need to work with the final app; they can build a minimal harness around it and instrument it at their leisure.
### What's new with Licel's solutions? Enhanced Protection and Precision
This month's DexProtector releases deliver stronger protection and more precise security insights across iOS and Android. On iOS, new runtime checks expand detection of virtualized and simulated environments, and network security mechanisms have been refined with optimized Public Key Pinning and Certificate Transparency checks for hostnames resolving to multiple IPv4 and IPv6 addresses. Alice reporting now includes additional component information, making it easier to identify and filter events originating from extension processes. On Android, enhanced protections provide stronger defense against runtime code injection attacks, and the latest updates improve compatibility for applications targeting Android 17 and those using custom AppComponentFactory implementations.
### SDK Protection: How to Secure Your Most Sensitive Asset in its Most Exposed Form
The difference between an exposed mobile application and an exposed SDK is often the blast radius — one published bypass affects every customer who has embedded it. Because an SDK is incorporated into a host application, an SDK developer has to accept a certain loss of control. SDKs often contain the very things bad actors want to attack, such as payment logic and cryptographic operations. See the Knowledge Hub guide "[Protecting an SDK Is Harder Than Protecting an App](https://licelus.com/resources/knowledge_hub/android-ios-sdk-obfuscator-aar-protection)," which includes a checklist of six non-negotiable requirements to demand when evaluating Android or iOS protection tools and obfuscators.
### Is AI an Angel or a Demon? Finding the Right Security Balance
On its own, AI can't completely dissect your application and understand every instruction perfectly. But it can help attackers reach their goals more quickly, efficiently, and cheaply. The modern attacker, assisted by AI, won't respect the boundaries between your mobile development team, fraud team, API team, and security operations center — so your protection architecture shouldn't either. See the long read: [Is AI an Angel or a Demon?](https://licelus.com/insights/can-ai-reverse-engineer-a-mobile-app)
### Layers Bulletin — June 2026: A Wall is not a Room; 15 Years of Watching the Mobile Channel Grow
URL: https://licelus.com/layers-bulletin/layers-bulletin-june-2026
28/06/2026 · 4 min to read
# A Wall is not a Room; 15 Years of Watching the Mobile Channel Grow
When Licel began in 2011, protecting a mobile app mostly meant protecting its code. Fifteen years of watching the threat landscape widen has taught us that the app was only ever one wall of a much larger room - what we call the mobile channel - and that room keeps growing. The work we committed to in 2011, and have recommitted to every year since, is to keep that whole room trustworthy as the attacks against it grow more subtle.
### What's new with Licel's solutions? See More of the Room: DexProtector Studio
Studio is the offline, on-premises companion to DexProtector. It lets developers and security engineers see inside an app or SDK, surface the sensitive material, and configure protection, all without anything leaving their environment. Its built-in AppCare analysis already flags vulnerable dependencies, secrets, and sensitive assets. With the latest update, Studio now also maps an app's use of sensitive platform APIs, showing how security-critical functionality is implemented and what most needs protecting. The result is a smarter, faster path to mobile channel security: less manual guesswork, more targeted protection, and a DexProtector configuration focused on the areas that matter most.
### Keeping Pace With Android 17 and iOS 27
This month we released DexProtector 16.1.85 and 16.1.87, tested and working cleanly with both Android 17 and iOS 27, alongside security, compatibility, and reliability improvements. They strengthen runtime protection, extend network communication hardening and code protection on iOS, improve Android compatibility with modern packaging requirements including 16 KB alignment, and add new Alice reporting capabilities. To maintain the strongest available protection, we recommend regularly updating applications in production with the latest version of DexProtector — at least once per month. We also recommend enforcing a minimum supported application version at the backend; DexProtector's Mobile API Protection capability enables you to restrict access from outdated app versions, helping prevent rollback-based attacks.
### 15 Years of Watching the Same Room
When we started in 2011, securing a mobile app mostly meant securing its code. With each passing year, we've seen the attack surface widen, from dynamic instrumentation tools manipulating apps at runtime to AI-enhanced tools enabling attackers to pass eKYC checks. Eventually we were forced to say out loud what we'd been seeing: the app itself was only ever one wall of a room that kept getting larger. See the anniversary piece: [15 Years in the Most Watched Room in the House](https://licelus.com/insights/15-years-in-the-most-watched-room-in-the-house).
### Android and iOS App Obfuscation: The Importance of Protecting the Final Container
Protecting the wall is still as vital as ever — perhaps more so, because everything else now leans on it. DexProtector protects the final container: the finished, ready-to-ship APK, AAB, IPA, or XCArchive, rather than source or intermediate code that later build steps can still disturb. It's the only version of your app you can be certain matches what reaches your users. See the guide "[Android and iOS Obfuscation Done Right: Protecting the Final Container](https://licelus.com/resources/knowledge_hub/android-ios-obfuscator-apk-aab-ipa-xcarchive)," covering the AAB splits that break naive Android protection, the decrypted iOS binaries that circulate within hours of release, and why running protection on-premises rather than in the cloud matters.
### Layers Bulletin — May 2026: Mobile Channel Protection in Practice: the Licel vTEE Earns EMVCo Approval Again
URL: https://licelus.com/layers-bulletin/layers-bulletin-may-2026
28/05/2026 · 4 min to read
# Mobile Channel Protection in Practice: the Licel vTEE Earns EMVCo Approval Again
Last month we introduced mobile channel protection. This month we're showing what it looks like in practice, zooming in on one specific layer: Isolation. Mobile channel protection comes down to three things: Integrity (the application can defend and verify itself), Isolation (critical operations take place in a secure vault), and Intelligence (converting tamper-proof signals into smarter security decisions). Each addresses a different layer of the mobile channel, but together they form a system where the output of each strengthens the next.
### Licel vTEE Achieves Second Consecutive Cross-Platform EMVCo Approval
The mobile device is now many things at once — a bank branch, a wallet, an identity document, and a payment terminal. Sensitive mobile operations such as device binding, key handling, token generation, and request signing can take place in an isolated, trusted execution environment. Until recently, isolation meant hardware (secure elements and TEEs on the device); these remain useful, but in today's fragmented mobile ecosystem hardware can be inconsistently available and slow to adapt. The Licel vTEE is a virtual Trusted Execution Environment — not a replacement for hardware, but a layered, software-based augmentation of it. It has just received a second consecutive [EMVCo SBMP TEE approval across both Android and iOS](https://licelus.com/company/news/licel-vtee-renews-emvco-sbmp-tee-approval).
### DexProtector's Mobile API Protection Feature Available to All Enterprise Customers
If any layer of the mobile channel is compromised, the backend cannot trust what it receives. Mobile API Protection is the communication layer of mobile channel protection; the security of the channel between a mobile app and its backend depends entirely on the static and dynamic protection layers beneath it. DexProtector's Mobile API Protection feature will be available to all DexProtector Enterprise customers from the next release. See [protecting mobile APIs from bot attacks](https://licelus.com/resources/knowledge_hub/protecting-mobile-apis-from-bot-attacks).
### What is Mobile Channel Protection?
Mobile channel protection isn't a feature, a control, or a category we've invented. It's the practice of treating mobile security as a system rather than a checklist, where trust is engineered into the application, the runtime, the device, and the communication channel. See the full argument at [Mobile Channel Protection](https://licelus.com/resources/mobile-channel-protection).
### Layers Bulletin — April 2026: How We're Securing a Changing Mobile Device Ecosystem
URL: https://licelus.com/layers-bulletin/layers-bulletin-april-2026
28/04/2026 · 5 min to read
# How We're Securing a Changing Mobile Device Ecosystem
Mobile threats have evolved to target the entire channel — from the user, to the device, to the application, and the backend. The mobile device ecosystem is probably the most diverse in the IT world: not only smartphones, but smart sensors, TVs, home appliances, smart watches, and tablets, across Android, iOS, and newer ecosystems such as HarmonyOS NEXT.
### Protecting the Whole Mobile Channel
As the mobile device ecosystem grows, so does the attack surface. Attackers are no longer focused only on the application package; they also target the backend, the communication channel, device integrity, user sessions, and the telemetry that financial institutions and mobile payment providers use to make real-time decisions. The increase in bot attacks targeting backend systems combines automation, reverse engineering, API abuse, device farms, emulators, and modified application flows, and no single defense addresses all of them. DexProtector's Mobile API Protection feature will be available to all DexProtector Enterprise customers from the next release. See the deep dive: [the anatomy of mobile API bot attacks](https://licelus.com/resources/knowledge_hub/protecting-mobile-apis-from-bot-attacks).
### Android 4.4 Support
When DexProtector launched 15 years ago it supported Android 4.x; the latest version supports modern releases such as Android 17 QPR1 and iOS 26. Based on device insights from Alice Threat Intelligence since November 2025, the number of Android 4.4 devices observed is now close to zero, so Android 4.4 support in the mobile channel protection solution will begin to be discontinued from November 2026. Organizations still depending on Android 4.4 should contact support at primary@licelus.com.
### Mobile Malware Detection: New Visibility for Alice Threat Intelligence Customers
Malware remains a main threat factor for mobile applications and devices, especially in banking, payments, and identity use cases, and particularly on Android. Anti-Malware functionality can be used in monitoring mode or active prevention mode. From the next DexProtector release, all Alice Threat Intelligence customers will automatically receive information about detected malware on their end users' devices.
### The Latest Alice Threat Intelligence Updates
The latest release introduces updates to the Alice interface to make investigation workflows faster, new functionality in the Alice Globe view, advanced classification of diagnostics information, and a new Subscriptions page with usage statistics (including for the Alice Enterprise API).
### Attack trends: Protecting Mobile APIs from Bot Attacks
TikTok's API request signing mechanism is often cited as one of the more complex signing implementations in production, and yet it has been reverse engineered and circumvented by developers working in the open. If the signing logic runs in the attacker's environment, complexity buys time but not immunity. Mobile APIs should not blindly trust requests simply because they have been correctly signed; integrity verification is required to confirm the request was generated by a genuine, untampered app instance operating under acceptable runtime conditions. See [Protecting Mobile APIs From Bot Attacks](https://licelus.com/resources/knowledge_hub/protecting-mobile-apis-from-bot-attacks).
### Layers Bulletin — March 2026: DexProtector is Fully Compatible with Android 17 Beta 3
URL: https://licelus.com/layers-bulletin/layers-bulletin-march-2026
31/03/2026 · 5 min to read
# DexProtector is Fully Compatible with Android 17 Beta 3
DexProtector's improved integrity controls and runtime protection mechanisms enable it to tamper-proof the millions of signals that Alice shares with clients every day. SOC teams use these insights about existing and emerging threats to make smart security decisions in a world where it's increasingly difficult to know what's real and what isn't.
### Introducing DexProtector 16.1.31
The latest version comes with full support for Android 17 Beta 3, improved methods for safeguarding eKYC processes, and extended support for payment app compliance. Device integrity checks have been enhanced to prevent camera injection attacks during eKYC, and new detections comply with the latest banking app compliance requirements in Asia (such as Circular-77-2025-TT-NHNN from the State Bank of Vietnam). Key enhancements: support for the Resource Encryption mechanism for Android 17 Beta 3; new checks for Android system frameworks for tampering/injection; new detection for Android device settings allowing ADB connections via USB or WiFi; mechanisms to prevent attacks using remote Android devices for key attestation; and improved detection of cloud-based Android emulators. Other Android enhancements include support for Android Gradle Plugin 9 and support for integrating protected AARs as individual Dynamic Feature Modules (DFM) — important for payment SDKs supporting multiple schemes. iOS enhancements include support for protecting binaries linked with the OSS ld64.lld linker, support for multiple DexProtector-protected frameworks within a protected app, and a new check for the Dopamine jailbreak.
### Alice Threat Intelligence: How Millions of Trusted Signals Translate into Better Decision-Making
Each day, Alice logs around 250 million security events across 192 countries, relating to threats such as app tampering, debugging attempts, and root or jailbreak activity on Android and iOS. Trusted signals are collected from applications and libraries protected with DexProtector, providing visibility into known and emerging attack techniques. DexProtector protects billions of installed app instances worldwide and serves as a critical frontline layer against mobile fraud including eKYC abuse and account takeover. To make Alice's signals actionable, the Alice Data Streaming feature enables streaming and correlation of device attestation data with a specific user, session, or Device ID.
### Attack trends: When Trust Becomes the Attack Surface
Many of the most effective attacks succeed not because people lack awareness, but because they are required to make high-stakes trust decisions inside systems that provide limited context, under conditions shaped by urgency, pressure, and manipulation. The signals end users rely on to judge legitimacy — interfaces, messages, identities — are becoming easier to replicate and harder to verify. A shift is required away from models that depend on momentary user decisions and toward models that remain resilient even when those decisions are manipulated. See the essay: [When Trust Becomes the Attack Surface](https://licelus.com/insights/when-trust-becomes-the-attack-surface).
### Layers Bulletin — February 2026: Preparing for Android 17: What it Means for Mobile Trust
URL: https://licelus.com/layers-bulletin/layers-bulletin-february-2026
27/02/2026 · 4 min to read
# Preparing for Android 17: What it Means for Mobile Trust
Android 17 is launching later this year, bringing new platform-level security expectations including mandatory Certificate Transparency enforcement for applications targeting the latest SDK. Each new Android release subtly reshapes the trust boundary between applications, devices, and the backend.
### Looking Forward to Android 17
Because the DexProtector Runtime Engine works very close to the system (especially for RASP and device attestation checks), new platform updates can require targeted changes to maintain full compatibility. Licel tests very early in the Android release cycle and coordinates closely with Google. Testing of the latest DexProtector versions with Android 17 Beta 1 and Beta 2 has been very positive, confirming full compatibility. Android 17 enables Certificate Transparency (CT) by default for HTTPS connections in apps targeting API level 37 or higher. Licel introduced CT-based verification in DexProtector 12.0.11 back in 2021, and DexProtector's CT checks apply across Android versions from 4.4 through to the latest releases regardless of targetSdkVersion. A new enhancement adds over-the-air (OTA) updates for CT log lists, allowing protected apps to stay aligned with the latest trusted CT logs automatically.
### Attack trends: GhostSpy and the Shifting Malware Threat
There has been a structural shift in mobile malware: banking trojans can now operate inside trusted sessions, so it isn't always obvious to the server that a device's environment has been compromised. The banking trojan GhostSpy, tracked by Alice spreading rapidly in recent months, is capable of stealing banking credentials, capturing screen content and automating clicks (even in screenshot-restricted apps), hiding the real UI, keylogging, reading 2FA codes from authenticator apps by reconstructing their UI via Accessibility Services, performing unauthorized transactions via Accessibility Services abuse, spying via screen capture (bypassing FLAG_SECURE), and sending phishing messages to spread further. This is the operational reality of malware in 2026: enforcement cannot be blanket and blunt; it must be informed by visibility and trusted runtime data.
### Mobile App Malware Protection for Banking and Payment Applications
GhostSpy illustrates an evolving malware threat that requires a layered defense of runtime integrity, resistant execution, and trusted signals. Malware in 2026 is more automated, modular, and commoditized — no longer just a detection and prevention problem but an operational risk management problem. Backend-based detection isn't enough; you need tamper-proof signals you can trust to categorize threat levels, track prevalence over time, and adjust enforcement dynamically. See [Mobile App Malware Protection](https://licelus.com/resources/knowledge_hub/mobile-app-malware-protection).
### Layers Bulletin — January 2026: Consistent, Verified Trust Under Pressure
URL: https://licelus.com/layers-bulletin/layers-bulletin-january-2026
30/01/2026 · 5 min to read
# Consistent, Verified Trust Under Pressure
The mobile channel has never been more important, and it has never been so contested. Fraud techniques are constantly evolving, regulatory expectations are rising, and attackers are becoming increasingly skilled at manipulating client-side environments. One question we keep coming back to: which signals can we genuinely trust? In a world of sophisticated mobile threats, trust cannot be implicit; it has to be continuously earned, verified, and reinforced.
### Introducing DexProtector 16.1
Version 16.1 brings significant improvements to the DexProtector Runtime Engine (DRE), detection and evasion mechanisms, and network security. Version 16.1.6 incorporates new self-protection mechanisms that help the DRE withstand analysis and tampering, providing the strongest foundation for RASP, attestation, and anti-fraud measures at runtime, plus improved detection and evasion of process tracing utilities. Version 16.1.9 reinforces device attestation to mitigate spoofing via modules such as TrickyStore and introduces new detections for Frida modules on iOS. For apps using Certificate Transparency, 16.1.6 adds compatibility with the newer tiled log format. A new network security policy option enforces recommended secure cipher suites, and Public Key Pinning and Certificate Transparency checks are extended to TLS over raw TCP socket connections. 16.1.6 also added support for .NET 9 (Xamarin).
### DexProtector Achieves EMVCo SBMP Evaluation and Approval for the Sixth Year in a Row
DexProtector has been evaluated by independent labs (Applus+ Laboratories) and approved under EMVCo SBMP for the sixth consecutive year, under the SBMP SPT category. EMVCo is a global technical body collectively owned by payment giants such as Mastercard, Visa, Discover, JCB, UnionPay, and AMEX, and re-evaluates solutions against evolving requirements year after year. This approval provides independent confirmation that DexProtector continues to deliver reliable, certifiable protection against tampering, reverse engineering, and hostile runtime environments — and can help shorten wallet and payment SDK developers' own evaluation processes.
### Attack trends: The Mobile Authentication Illusion
Mobile authentication isn't flawed because we don't have enough factors of authentication, but rather because we've stopped asking whether we can trust those factors in the first place. Checks are too static and too shallow, and our reliance on the mobile device has blinded us to the long-agreed principle that the second factor should live on a different device altogether. See the article: [The Mobile Authentication Illusion](https://licelus.com/insights/the-mobile-authentication-illusion).
### Layers Bulletin — December 2025: Why You Need Trusted Signals in the Age of Mobile Fraud
URL: https://licelus.com/layers-bulletin/layers-bulletin-december-2025
19/12/2025 · 5 min to read
# Why You Need Trusted Signals in the Age of Mobile Fraud
In a mobile channel full of threats and increasingly sophisticated fraud, how can we know which signals we can really trust? At the same time that organizations rely more heavily on client-side signals to authenticate the user, collect telemetry, and detect fraud, attackers have become skilled at spoofing these signals. Deepfakes, malware, emulators, and automated attacks all exploit the same weakness: people being over-reliant on assumptions about device and runtime integrity.
### DexProtector 16 and context-aware device attestation
Early releases of DexProtector 16 in early 2026 include a revamped core on Android and more advanced device attestation mechanisms across both platforms. Device attestation identifies indications that a device may be compromised — root or jailbreak, custom firmware, emulators, malware, potentially harmful apps, and tools designed to hide their presence — even when the app itself hasn't been directly tampered with. As concealment and spoofing toolkits have proliferated (Magisk and its forks, APatch, KernelSU on Android; palera1n, checkra1n, Dopamine, Roothide on iOS), it makes less sense to talk about 'root detection' or 'jailbreak detection' as a single concept. DexProtector 16 continues a shift toward a context-aware attestation approach: delivering granular signals that support risk-based decisions rather than blanket verdicts. Early releases extend coverage for Dopamine2-roothide, Magisk forks, TrickyStore, and specific image injection techniques used to bypass ID verification. A fundamental principle: the app's own integrity must be assured for detection signals to be trustworthy.
### Attack trends: Why Trusted Signals Are the Key to Closing the Widening Mobile Trust Gap
For too long there has been an assumption that certain signals — camera input, biometric checks, device model — are inherently reliable. Attackers can spoof and tamper with these signals with precision and at scale, opening a widening gap between what the backend assumes to be true and what is actually happening inside the mobile application. See the end-of-year trends article: [Why trusted signals are the key to closing the widening mobile trust gap](https://licelus.com/insights/why-trusted-signals-are-the-key-to-closing-the-widening-mobile-trust-gap).
### Mobile API Protection: From Afterthought to Necessity
A significant and underplayed aspect of trust in the mobile channel is how the server can authenticate a mobile application. What the server authenticates is not an app but a credential — a string, signature, or certificate produced with a key the app holds. Trust can't depend on insecure apps or static secrets, because the mobile client is a target that attackers can observe, instrument, and manipulate; and many backends continue to serve outdated app versions. To establish real trust, backend systems need evidence: is this a genuine app, is it up to date, and is it running with integrity? See [Mobile API Protection: From Afterthought to Necessity](https://licelus.com/insights/api-protection-from-afterthought-to-necessity).
### Layers Bulletin — November 2025: How Not to Lose Your Identity in 2035
URL: https://licelus.com/layers-bulletin/layers-bulletin-november-2025
27/11/2025 · 4 min to read
# How Not to Lose Your Identity in 2035
What will trust in the mobile world need to look like a decade from now? This edition unpacks what the latest EMVCo security approval for the Licel vTEE signals for the future of secure mobile services, and shares a vision for digital identity trust in the next decade.
### DexProtector
DexProtector 15.0.9.88 introduces significant performance improvements for iOS (especially app startup times) and a new UI protection feature for Android: virtual touch detection. Bots, malware, and remote access tools interfere with apps by triggering input events that can be hard to distinguish from real user interactions, often combined with Accessibility Services, screen sharing, and root privileges. DexProtected apps can now block virtual input, terminate to stop further threats (such as screen capture through virtual displays), and report to Alice for further analysis. Virtual touch detection is available to all DexProtector Enterprise customers.
### The Licel vTEE
The Licel vTEE has earned its second consecutive EMVCo security approval for the iOS platform under the SBMP TEE program, confirming it continues to meet the highest international standards for mobile payment security. A key benefit is that it is hardware-agnostic: developers can write their most sensitive code — for cryptographic operations, key management, and biometric authentication — once, and deploy it consistently and securely across all major mobile operating systems (Android, iOS, and emerging platforms like HarmonyOS). See the [press release](https://licelus.com/company/news/the-licel-vtee-earns-second-consecutive-emvco-security-approval-for-ios).
### Attack trends: How Not to Lose Your Identity in 2035
At Droidcon London, Licel co-founder and CTO Mikhail Dudarev gave a talk exploring what digital identity will need to withstand by 2035 — not just for humans, but also the AI agents that will increasingly act on our behalf — using the Multi Pass ID from The Fifth Element as a lens on identity. See the article: [How Not to Lose Your Identity in 2035](https://licelus.com/insights/how-not-to-lose-your-identity-in-2035). Licel was a gold sponsor of Droidcon London and supported the PCI SSC Asia Pacific Community Forum in Bangkok.
### Layers Bulletin — October 2025: Innovation and Integrity; 12 years of building protection that lasts
URL: https://licelus.com/layers-bulletin/layers-bulletin-october-2025
29/10/2025 · 5 min to read
# Innovation and Integrity; 12 years of building protection that lasts
This month marks twelve years since the first commercial licence for DexProtector. A lot has changed in the mobile threat landscape since then, but the mission hasn't.
### DexProtector
Fraudsters exploiting rooted devices and modified firmware continuously update their toolset; recent weeks saw an increase in modules (such as TrickyStore) aiming to defy hardware attestation, so the latest version introduces enhanced mechanisms for stricter hardware attestation. New UI Protection capabilities specifically mitigate virtual display tools (e.g. scrcpy, Vysor) and overlay injection attacks with configurable responses. New Automatic Protection capabilities begin with Automatic Protection for Manifest Classes, ensuring all classes declared in the Android Manifest are automatically targeted for key code protection. DexProtector's Mobile API Protection capability is now available for iOS in addition to Android, delivering unified, policy-driven API integrity and attestation across platforms.
### Alice Threat Intelligence
The latest version introduces a redesigned Dashboard UI providing real-time visualizations of prevented attacks and correlated threat activity across devices. A new Alice Incidents Data Feed enables integration with enterprise SIEM/SOAR platforms through a dedicated, real-time data streaming interface for high incident volumes.
### Attack trends: The growing need for Mobile API Protection on iOS
Recent months saw significant uptake of DexProtector's Mobile API Protection to mitigate botnets, bonus program abuse, and [fraudulent communication with hardware NFC digital wallets](https://licelus.com/insights/the-rise-of-nfc-proxy-malware-attacks). Apple's introduction of app side-loading in the EU earlier this year made iOS an increasingly attractive target, introducing risks such as app tampering and cloning previously associated with more open ecosystems. DexProtector's Mobile API Protection technology enables client backend servers to check a JWT token; if verification fails, the request came from a tampered version, clone, or bot rather than the authentic app. See [Mobile API Protection](https://licelus.com/resources/knowledge_hub/mobile-api-protection).
### Our guiding principles for secure Digital Identity
As identity moves to the smartphone, the attack surface changes dramatically. True Digital ID Protection starts with making sure every mobile interaction, operation, and transaction happens within a secure, tamper-proof environment. Licel provides layered, certifiable protection across the mobile channel, from code hardening and runtime integrity control to cryptographically secure operations and real-time threat and device intelligence. See [Digital ID Protection](https://licelus.com/resources/use-cases/digital-id-protection).
### Licel achieves the respected CSA Cyber Trust Mark
Licel has achieved the highest level (Advocate) of the Cyber Security Agency (CSA) of Singapore's Cyber Trust Mark Certificate for DexProtector, the Licel vTEE, and Alice Threat Intelligence — alongside ongoing EMVCo evaluation and approval and ISO/IEC 27001:2022 compliance.
### Layers Bulletin — September 2025: Layers of insights, from product updates to real-world threat intel
URL: https://licelus.com/layers-bulletin/layers-bulletin-september-2025
30/09/2025 · 5 min to read
# Layers of insights, from product updates to real-world threat intel
Welcome to the first edition of the Layers Bulletin, a new and improved monthly update from Licel. Each month we tell you about the latest features across our products and how they are evolving to protect the whole mobile channel, plus insights from the field and from our threat and device intelligence platform, Alice.
### DexProtector
The latest version enhances iOS jailbreak detection (including Dopamine-based jailbreaks), introduces new checks for TrollStore and for Corellium virtual devices, and adds specific detections for camera injection attacks. For Android, enhanced detections cover TrickyStore and unlocked bootloaders for Google Pixel devices, and DexProtector's adaptive custom firmware check now triggers further attestation when bootloader anomalies are detected.
### Alice Threat Intelligence
As DexProtector's integrity control measures evolve, Alice's data becomes even more trustworthy. Alice's attack and threat incident reports for iOS now include more granular data, including app response, Developer Mode detection, and Jailbreak status, and the app version reporting scheme has been refactored for clarity.
### NFC Proxy Malware attacks & Glossary
Attackers are targeting the technologies that make payments seamless; a trending example is NFC Proxy Malware, which sits between the application and a POS reader, manipulating or intercepting sensitive communications. See [The rise of NFC Proxy Malware attacks](https://licelus.com/insights/the-rise-of-nfc-proxy-malware-attacks). Licel also launched the [Mobile Application Security Glossary](https://licelus.com/resources/glossary), a curated explainer of key threats, attack techniques, and protection mechanisms.
### Attack trends: LiveContainer — a signpost to future exploits?
LiveContainer is an in-app virtual container for iOS, working like Android dual-account apps such as Parallel Space and GBox (the attack vector used by Android malware like FjordPhantom across Southeast Asia). It enables iOS applications to run inside it without installation, provides an alternative means for sideloading, and offers tweak injection capabilities to tamper with apps. There is no sandboxing inside the virtual container, so apps can sniff or steal data from other apps. As Apple closes off jailbreak loopholes on iOS < 16.7, fraudsters need other avenues; tools like LiveContainer are set to gain traction, and Licel has implemented protection measures against it in the latest DexProtector version.
### Insights from Alice Threat Intelligence data
Attacks prevented (past-month snapshot): bootloader tampering for Android dominates, representing more than half of all incidents, though only 13% of installs are affected (suggesting repeated exploitation of the same devices). Root detections and jailbreaks account for a third of incidents but affect 73% of installs, making root the most widespread compromise method. Malware and manual installations of modified apps combined equate to just over 10% of incidents but are potentially very damaging. Emulators, debuggers, and hooks account for smaller percentages but represent some of the most dangerous vectors, indicating active attempts to reverse-engineer, modify, or hook the application.
Mobile malware trends: notable samples flagged by Alice include banking trojans (the majority), plus spyware, remote access trojans (RATs), and ransomware. In Europe, banking trojans such as Octo (Coper), Sharkbot, Hydra, and Anatsa are prominent. Anatsa abuses Android's Accessibility Services to read any screen's content (including credentials and 2FA codes), implement keyloggers, and perform actions on behalf of the user. The mobile threat ecosystem is now dominated by highly sophisticated, multi-functional banking trojans primarily using Accessibility Services as their go-to attack vector, making a defensive strategy rooted in threat and device intelligence more important than ever.
## Products — Additional Pages
### Alice Threat Intelligence (product page)
URL: https://licelus.com/products/alice-threat-intelligence
# Alice Threat Intelligence
## Tamper-proof mobile threat intelligence you can rely on
Alice is a mobile app telemetry solution that provides visibility into what is happening on end user devices, enabling you to make smarter security decisions.
### Trusted sensors that empower real decisions
Alice ingests signals from trusted in-app sensors — secured by DexProtector — and turns those signals into actionable intelligence for fraud scoring, risk assessment, and analysis by SOC teams. It provides organizations with greater visibility over their mobile apps, and enables security teams and anti-fraud engines to identify suspicious activity across users, devices, and sessions. See the unseen: understand the real mobile threat landscape surrounding your application, from malware to tampering attempts. Act with confidence: use verified, tamper-proof signals to inform fraud scoring, policy enforcement, and customer protection. React in real time: make dynamic, nuanced, risk-based decisions based on trusted insights. Low friction, high trust: Alice integrates in hours, runs silently, and is built to meet both compliance and sovereignty needs.
Yesterday, if you suspected a fraudulent transaction from a mobile app, you might have had no choice but to block the user's account. With Alice, you can make a more nuanced decision: its trusted signals might tell you that a device's environment has been compromised, so instead of blocking the user you can delay one high-value transaction by 12 hours and trigger a step-up authentication — stopping the potential crime without disrupting the innocent end user.
### Signals you can trust
It's impossible to trust a signal from a mobile device when you can't control its integrity. Alice gathers its intelligence from applications protected by [DexProtector](https://licelus.com/products/dexprotector), which means every signal originates from a trusted, tamper-proof sensor that attackers can't spoof, modify, or intercept: tamper-proof data from protected mobile applications; verified environment and device integrity; and fewer false positives and false negatives for high-confidence intelligence.
### Mobile fraud detection and prevention
Alice's real-time visibility into the health of your mobile channel helps in the fight against mobile fraud: monitor malware activity (identify infected or high-risk devices in time to act); track suspicious behavior (map trusted signals over time to identify repeat offenders and emerging patterns); inform mobile fraud prevention (feed Alice data into your fraud scoring system or risk engine); and improve your wider security posture.
### EDR and XDR for mobile apps
The mobile app environment is a visibility gap in both Endpoint Detection and Response (EDR) and Extended Detection and Response (XDR). Alice fills this gap by sharing verified mobile threat intelligence from within the application itself — the mobile channel is the fastest growing endpoint surface and the most exposed. Alice integrates easily into SIEM tools and enables SOC teams to see new threat patterns across the whole mobile channel for faster, more confident incident responses.
### Maximum visibility and value: three ways to consume Alice
Alice Web Dashboard: visualize threats and emerging trends, monitor attacks, and understand the security posture of your user base. Enterprise API: integrate Alice's trusted insights into your own risk systems, dashboards, or fraud detection workflows. The Alice Data Stream: get a real-time feed of global threat data direct from the Licel ecosystem, with intelligence about malware strains, attack types, and device trends.
### From trusted signals to business-critical actions
Anti-Malware: Alice draws on a comprehensive malware database to detect and classify thousands of strains, with real-time over-the-air updates protecting even against newly discovered threats. Device Attestation and Intelligence: Alice paints a detailed picture of the devices interacting with your apps (OS version, modifications), confirming device integrity and authenticity and tracking suspicious activity over time. User ID Linking: Alice can connect device signals with behavior and session data over time using individual user IDs, without revealing Personally Identifiable Information (PII).
### Maintain your own data sovereignty
Alice has no cloud dependencies and can work fully on-premises if you need it to. If you would rather keep all telemetry and analysis within your infrastructure, it's completely up to you how your data is processed, stored, and shared.
### CryptoModule (product page)
URL: https://licelus.com/products/dexprotector/cryptomodule
# CryptoModule
## White box cryptography to secure your keys and tokens.
White box cryptography is a vital facet of app security. It protects cryptographic keys and operations in hostile or untrusted environments; without it, attackers might access your app and inspect, analyze, or even modify the cryptographic algorithm. Typical use cases: eWallets, SoftPOS, M2FA authenticator apps, Digital IDs, eKeys (hotel keys and car keys), ePasses (travel cards and tickets), and IoT hubs.
### White box cryptography
CryptoModule's sophisticated white box cryptography secures your app's cryptographic keys on the device. Your keys are bound to that particular device and can't be stolen — even if a bad actor is running your app on a rooted device.
### Software-based security module
CryptoModule is a software-based security module which provides a safe place for sensitive transactions to take place. It works in a similar way to hardware secure enclaves and chips used to create secure environments, but because it is virtual it's much easier to update.
### What does CryptoModule give you?
If you think of your application as the bank, then CryptoModule is the vault. Keys and tokens kept secure at every stage: CryptoModule protects your cryptographic keys while they're in use, stored, and in transit — even if a device is rooted or jailbroken. Integrates and updates fast: because it's a software solution, it operates independently from key stores and secure enclaves, so it's easier to set up and faster to update.
### Crypto API Virtualization mode
When your app invokes a crypto function, it's based on a cryptographic library call, and hackers can hook this call to look around and attempt an attack. With CryptoModule in place, that initial hook isn't possible, because CryptoModule has already moved the cryptographic library calls to the safety of the virtual machine.
### SmartCard mode
You can also use CryptoModule a bit like a smart card. This mode is transparent, so you can control everything that happens within the app, including implementing specific logic. When the app sends an APDU command to the smart card and gets a reply, CryptoModule can respond for the app, and vice versa; when a terminal sends an APDU command back to the app, that command is handled by CryptoModule in its secure environment.
### The ideal security solution for SoftPOS systems
Protection against key extraction and rooted or jailbroken devices is vital for SoftPOS systems that rely on secure communications, making CryptoModule the perfect partner for device-to-device payments. It meets industry standards including PCI DSS, DUKPT, EMVCo, and FIPS 140-2, and integrates automatically into DexProtector.
### What's Changed Since You Last Looked (Mobile Channel Protection overview)
URL: https://licelus.com/whats-changed
# Mobile Channel Protection from Licel: What's changed since you last looked
DexProtector and Alice have evolved significantly over the past year, alongside continued independent validation. Protect the whole channel — stronger by design: expanded coverage of modern evasion toolkits, Mobile API Protection on both platforms, and a re-engineered runtime engine. Understand the device — context-aware attestation: a shift away from blanket root and jailbreak detection to more granular, risk-based signals for more nuanced, meaningful decisions. Enable better decisions — operational at scale: 250 million security events logged daily across 192 countries, with real-time SIEM/SOAR integration and automatic malware visibility for all customers. DexProtector has been evaluated and approved by EMVCo for a sixth consecutive year. See [Mobile Channel Protection](https://licelus.com/resources/mobile-channel-protection).
## Modern App Security Solutions
### App security made for the modern world.
URL: https://licelus.com/insights/how-not-to-lose-your-identity-in-2035
# App security made for the modern world.
For Android and iOS apps and SDKs, Java applications and libraries.
We're helping to make global payment data secure
[Certified: ISO/IEC 27001:2022](https://licelus.com/company/news/licel-is-iso-iec-27001-2022-compliant)
## Our powerful app protection products make your app or SDK safe to use in a world full of fast-shifting cyber threats.
## Interconnected layers of protection interact closely with both the app and the operating system. Together they form a solid shield against damaging attacks.
- ### Code and resource hardening
The act of obfuscating, encrypting, virtualizing, and isolating your app’s code and resources.
- ### Secure runtime environment
RASP checks to make sure your app isn’t exposed to harmful threats in its environment.
- ### Secure network communications
SSL pinning and certificate transparency to prevent man-in-the-middle attacks.
- ### Application integrity
Dynamic cryptographic key calculations at runtime stop your app from working if it has been tampered with.
### Our layers of app security provide unbeatable protection against a variety of threats.
### Static attacks
Bad actors will try to decompile your app to examine its code, reverse engineer its logic, discover vulnerabilities to exploit, and design malware to target it. Our products use encryption, obfuscation, and virtualization to make the decompiled code impossible to understand.
### Dynamic attacks
These days, most reverse engineering attempts are dynamic and take place during runtime execution. Our products use Runtime Application Self Protection (RASP) which spots dynamic instrumentation tools like Frida and dangerous mobile malware. Then it stops them from working.
### Network-based attacks
If the communication channel between your app and the server isn’t protected, it can be targeted. And sensitive data and assets can then be stolen. Our products secure this channel, keeping your app safe from man-in-the-middle attacks and preventing data being funnelled to a bogus server.
### Why Licel?
We helped to define the world of app security. Now we’re working hard to shape its future. Forward-thinking businesses see us as trust enablers who empower them to focus on what they do best.
#### 310 million mobile banking users protected
#### 450,000 smart home networks secured
#### 135,000 smart car keys made safe for drivers across the globe
#### 83 million patient medical records protected from sensitive data harvesting
### Supported platforms
-
-
-
-
-
-
-
-
-
-
-
-
- and many [more](https://licelus.com/products/dexprotector/docs/android/implementations-and-integrations#dexprotecting-cross-platform-applications)
## Prevent strategic, reputational, operational and compliance risks.
App protection doesn’t only secure your application. By stopping attacks, it also protects your reputation and the trust you’ve built up with your end users. And it means you avoid revenue loss, penalties, and compliance violations.
### DexProtector
Dynamic protection for iOS and Android apps and SDKs.
[learn more](https://licelus.com/products/dexprotector)
### Stringer Java Obfuscator
Java code protection for standalone, desktop, and enterprise apps.
[learn
more](https://licelus.com/products/stringer-java-obfuscator)
### Alice Threat Intelligence
Real time threat
intelligence for apps.
[learn
more](https://licelus.com/products/alice-threat-intelligence)
### vTEE
Unmatched protection for sensitive mobile operations.
[learn
more](https://licelus.com/products/vtee)
## Cyber threats are constantly evolving, so our products can’t and don’t stand still. They’re regularly being refined, evaluated by independent labs, and [approved](https://licelus.com/emvco-evaluated) by industry bodies.
## The state of mobile app security report
In recent years our mobile phone usage has evolved dramatically. We’re asking more and more of everyday
mobile apps, but are they as secure as we need them to be?
[read report](https://licelus.com/resources/state-of-mobile-app-security)
## A guide to mobile application protection
Attacks against mobile apps are getting more dangerous. To defend against them you need to know how and why
attackers target them and what you can do to stop them succeeding.
[read
guide](https://licelus.com/resources/guide-to-mobile-application-protection)
**How Not to Lose Your Identity in 2035**
The threat landscape](https://licelus.com/insights/how-not-to-lose-your-identity-in-2035)
## News
Older news items (archive):
- [**Introducing Alice**](https://licelus.com/company/news/introducing-alice)
- [**Licel vTEE achieves EMVCo approval for Android and iOS**](https://licelus.com/company/news/licel-vtee-achieves-emvco-approval-for-android-and-ios)
- [**Licel's vTEE achieves EMVCo Security Evaluation Certificate**](https://licelus.com/company/news/licel-s-vtee-achieves-emvco-security-evaluation-certificate)
- [**DexProtector achieves EMVCo certification for a landmark fourth consecutive year**](https://licelus.com/company/news/dexprotector-achieves-emvco-certification-for-landmark-fourth-consecutive-year)
- [**EMVCo extends DexProtector's app security certification**](https://licelus.com/company/news/emvco-extends-dexprotector-s-app-security-certification)
- [**DexProtector's iOS certification: a timely boost for the security of mobile applications**](https://licelus.com/company/news/dexprotector-s-ios-certification-a-timely-boost-for-the-security-of-mobile-applications)
- [**DexProtector certified by EMVCo to secure the growing world of mobile payment apps**](https://licelus.com/company/news/dexprotector-certified-by-emvco-to-secure-the-growing-world-of-mobile-payment-apps)
- [**DexProtector's arrival on Bitrise: a vital step toward safer mobile apps**](https://licelus.com/company/news/dexprotector-s-arrival-on-bitrise-a-vital-step-toward-safer-mobile-apps)
- [**Licel becomes a member of techUK**](https://licelus.com/company/news/licel-becomes-a-member-of-techuk)
- [**Licel joins the Grow London Global programme to unlock growth opportunities**](https://licelus.com/company/news/licel-joins-the-grow-london-global-programme-to-unlock-growth-opportunities)
- [**Licel release their Guide to Mobile Application Protection**](https://licelus.com/company/news/licel-release-their-guide-to-mobile-application-protection)
- [**New report reveals app security isn't being taken seriously enough**](https://licelus.com/company/news/new-report-reveals-app-security-isn-t-being-taken-seriously-enough)
- [**Strategic advisors help to drive Licel's ambitious growth targets**](https://licelus.com/company/news/strategic-advisors-help-to-drive-licel-s-ambitious-growth-targets)
- [**The UK government Code of Practice to encourage app security**](https://licelus.com/company/news/the-uk-government-code-of-practice-to-encourage-app-security)
- [**What Bitcode deprecation means for DexProtector**](https://licelus.com/company/news/what-bitcode-deprecation-means-for-dexprotector)
Recent news items:
- [**Licel vTEE Renews EMVCo SBMP TEE Approval**](https://licelus.com/company/news/licel-vtee-renews-emvco-sbmp-tee-approval)
- [**DexProtector Evaluated and Approved by EMVCo for Sixth Consecutive Year**](https://licelus.com/company/news/dexprotector-evaluated-and-approved-by-emvco-for-sixth-consecutive-year)
- [**Licel vTEE celebrates EMVCo SBMP TEE evaluation and approval once again**](https://licelus.com/company/news/licel-vtee-celebrates-emvco-sbmp-tee-evaluation-and-approval-once-again)
- [**Licel joins GlobalPlatform to support digital security standards development**](https://licelus.com/company/news/licel-joins-globalplatform-to-support-digital-security-standards-development)
- [**Licel partners with PCI Security Standards Council to help make global payment data secure**](https://licelus.com/company/news/licel-partners-with-pci-security-standards-council)
- [20 Nov 2025 **The Licel vTEE earns second consecutive EMVCo security approval for iOS.**](https://licelus.com/company/news/the-licel-vtee-earns-second-consecutive-emvco-security-approval-for-ios)
- [20 Nov 2025 **Licel awarded the highest tier of CSA’s Cyber Trust Mark Certification for its Mobile Security Solutions**](https://licelus.com/company/news/licel-awarded-the-highest-tier-of-csa-s-cyber-trust-mark-certification-for-its-mobile-security-solutions)
- [22 Aug 2025 **Licel is ISO/IEC 27001:2022 compliant**](https://licelus.com/company/news/licel-is-iso-iec-27001-2022-compliant)