Mobile API Anti-abuse Protection: AppiCrypt® Is a New SafetyNet and DeviceCheck Attestation Alternative
The excellence in mobile security has allowed us to develop a ground-breaking enhancement for mobile API security. Let’s look at the AppiCrypt®, a powerful tool that provides proof of app and device integrity for backends. We will explain common questions about these similar technologies and the application domains they can cover.
There has been a long-standing need to protect APIs against malicious requests and reverse-engineering attempts for the past years. APIs have become an attractive target for cybercriminals trying to seize business assets through information scraping, password brute force attacks, DDoS attacks, MitM attacks, fake accounts, remote code executions, and JSON denial-of-service attacks.
The mobile-first strategy heavily depends on the protection of both the application and API sides. API keys used within your application can be easily retrieved and misused. You need to remember that the mobile application installed on the users’ mobile devices is running in an uncontrolled and untrusted environment. It doesn’t matter whether it’s a renowned device brand like Samsung Galaxy or a EMV POS terminal. There are multiple ways your app may leak secrets.
The basics: API keys, client authentication, and pinning
From the API perspective, all calls must be performed over a secure channel between the client app and the API service. You will primarily utilize HTTPS and TLS in the majority of cases. Static and preferably dynamic certificate pinning (SSL pinning) can be used to provide verification of the backend.
The only thing missing is the verification of the authenticity of the client. The most popular choice (check this awesome write-up) is sending the API key within the requests header. Such authentication is often hardcoded into the clients code. Unfortunately, simple reverse engineering is enough to steal both API keys and client authentication secrets.
Once you acknowledge it is not secure enough, you can defer MitM by using SSL pinning and strengthen your application self-protection by using Runtime Application Self-Protection (RASP) suite like a freeRASP to mitigate more attack vectors from within the App. The device is deeply inspected to determine whether it is rooted, jailbroken, or an emulator. Subsequently, the application is scanned to ensure it hasn’t been tampered with, reverse-engineered, run with debugger or repackaged. Both phases are needed to determine whether the application’s backends are communicating with a legitimate application running on an approved/genuine mobile device.
App authenticity and integrity of the device and the application can be additionally verified by remote attestation services like SafetyNet for Google Play enabled Android phones or DeviceCheck for iOS are good technologies but they have significant drawbacks that we will review later in detail. The good things are that they address API vulnerabilities that WAF and API gateway solutions cannot address as they miss endpoint integrity controls.
AppiCrypt® App and Device Attestation
An AppiCrypt® is a technique that ensures cryptographic evidence or proof of client App authenticity and integrity. On top of that, it provides device identity with security risk scoring for fraud prevention, enabling more sophisticated techniques like channel binding, device binding to users, step-up authentication, and others.
AppiCrypt® technology is the innovative solution that stands for App Integrity Cryptogram. Thanks to this technology, you can implement the idea of mobile endpoint protection in the concept of zero trust. AppiCrypt is the cryptographic integrity proof of both mobile OS and App that can help prevent mobile API abuse and eliminate the intrinsic weakness of standalone RASP protection.
Generally speaking, the RASP is always just mitigation of Reverse Engineering risk by making the attacker’s job more difficult. Conceptually, the attacker can cut off the RASP part from the app by tampering. So it depends mainly on the attackers’ experience, efforts, and resources available to break the RASP protection.
AppiCrypt solves similar problems as device attestation services like SafetyNet and DeviceCheck. In contrast to such attestation solutions, it doesn’t depend on external web services and doesn’t introduce any outage risk due to external party service unavailability. AppiCrypt solves significant security problems with minimum integration efforts on both application and backend sides.
The idea behind this technology is not just to protect API against attackers trying to impersonate legit App calls but also to let your backend know that RASP controls were overcome or turned off by attackers. So gateway can easily block the session if the App integrity is compromised, and only in the case that RASP control passed API calls can be processed by backends. Moreover, AppiCrypt is enhanced with fine-grained application security intelligence for backends (like UI overlays, accessibility service usage, etc. ).
SafetyNet Attestation is not your savior
You’ve most probably heard about Google SafetyNet. Google’s attestation tool got quite popular because it is preinstalled on common devices equipped with Google Mobile Services. Like the AppiCrypt, it helps determine the overall integrity of the device. Make no mistake. SafetyNet, nor AppiCrypt, cannot replace proper Security Development Lifecycle (SDL), and both serve as additional security layers.
SafetyNet’s attestation information provides generalized binary conclusions about the device’s eligibility. The two checks are Basic integrity (“basicIntegrity”: true/false) and CTS profile match check based on (“ctsProfileMatch”: true/false). Yet the second one is only relevant to devices that have been Google-certified. Unfortunately, this gives no clue if you want to support specific platforms (i.e., EMV POS Terminal) or use-cases (i.e., Gaming Emulators) that Google considers inappropriate. The thing is, many users use unlocked devices because they are cheaper to get from 3rd party resellers, so you can’t rely on SafetyNet’s boolean result. Keep in mind that many devices (i.e., affordable Xiaomi models) are shipped with GMS but didn’t pass Google certification. Finally, it gives no threat signals also.
Common SafetyNet Disadvantages
- It works only if Google Play Services and good network connectivity are available.
- It has a high response time caused by network latency and processing time
- SafetyNet Attestation fails under many conditions based on network, quota, and other transient problems.
- You need to implement verification of the SafetyNet’s result on your backend.
- It doesn’t involve many checks (i.e., tapjacking, accessibility service abuse, screen lock status)
- Google has no security process to ensure that an OEM ROM is clean. Hence, SafetyNet won’t guarantee you the safety of OEM ROM.
AppiCrypt vs. SafetyNet Pros and Cons
Pros of AppiCrypt
- Universal across all platforms (Android with or without Google Services, iOS, Flutter)
- Verification serverless component ready to use (i.e., AWS lambda authorizer)
- Suited for demanding business (Fin-Tech, Healthcare, Gaming, Government)
- Fine-grained threat signals
- Reaction based on device identifiers, GPS emulation status, and screen lock status
- Attestation even in lousy network connection without quota issues and other transient problems
- Supports devices with an unlocked bootloader
- Supports devices with a custom system ROMs
- Supports devices for which the manufactured didn’t apply for, or pass, Google certification
- Supports devices with a system image built directly from the Android Open Source Program source files.
- Low latency
- Zero dependencies on Google servers middleware means no single point of failure.
Pros of SafetyNet
- Free quota allotment (per project) for calling the SafetyNet Attestation API is 10,000 requests per day and five requests per minute.
- Developed and supported by the official Android team
- Checks verified boot
AppiCrypt vs. SafetyNet Application Domains
The true strength of AppiCrypt lies in its ability to protect multiple application domains. Be it an iPhone, iPad, Amazon Fire Tablet, EMV POS Terminal, or Kiosk, you can use the same AppiCrypt and its backend component. If you need protection in every possible environment, the AppiCrypt is right for you.
To be fair, the SafetyNet also has some advantages over AppiCrypt. SafetyNet’s deep system integration allows for boot integrity checks thanks to better access to the trusted execution environment (TEE). After all, it’s developed directly by the Android team.
AppiCrypt application domains:
- Virtually every Android device
- iOS (iPhone, iPad)
- Flutter apps
- Huawei & Honor Devices since Huawei lost Google
- EMV POS Terminals
- Performance Critical Apps
- Amazon Fire Tablets
- Self-service Tablets
- Kiosks
- Gaming Emulators
- Non-Google Areas (China)
- Devices with custom ROMs
Enterprise Services
AppiCrypt is courtesy of Talsec. If you are looking for a solution tailored to your specific needs, contact us at https://talsec.app. We provide enhanced RASP protection with malware detection and detailed configurable threat reactions, immediate alerts, and penetration testing of your product to our commercial customers with a self-hosted cloud platform. To get the most advanced protection compliant with PSD2 RT and eIDAS and support from our experts, contact us via https://talsec.app/contact.
written by Tomáš Soukal, Mobile Dev and Security Consultant at Talsec
https://talsec.app | info@talsec.app | Read also 5 Things John Learned Fighting Hackers of His App — A must-read for PM’s and CISO’s
