Wired magazine recently published an article with the following statement:
Think of shielding code like hiding a safe behind a painting. If you have a secure enough lock, it shouldn’t matter who can see it.
Well… I have to say that I (somehow) disagree. As with everything in life, the right wording is “it depends”. In this case, it depends on the execution environment.
But let’s back up for a moment. What is app shielding? OWASP, a global non-profit organisation focused on improving the security of software, describes app shielding as “a set of technologies that typically modify an application’s binary code to make it more resistant to reverse-engineering, tampering, invasive monitoring and intrusion.”
Which kind of relates to a broader topic known as “security through obscurity”. From Wikipedia: “Security through obscurity (or security by obscurity) is the reliance in security engineering on design or implementation secrecy as the main method of providing security to a system or component. Security experts have rejected this view as far back as 1851, and advise that obscurity should never be the only security mechanism.”
[Spoiler alert] The right answer is in the last sentence: “[…] should never be the only security mechanism.”
An analogy
Let’s try to find a more specific scenario. The example of the safe proposed in Wired’s article is a good analogy of a cryptographic protocol: the safe would be the protocol itself, the safe’s key (eitherphysical or a passcode) would be the cryptographic key, and the content of the safe would be the data to be protected with encryption. In both cases, the security of the system relies on the assumption that the key is kept in a safe place. But what if this is not possible? What if we had to store the key close to the safe?
This is exactly what happens in mobile apps. If we want to use cryptography (and we need to), we also need to store the keys somewhere in the smartphone so we can use them. Even if we use the latest cryptographic engines (available only in new, high-end devices; such as the hardware-backed KeyStore in Android or the Secure Enclave in iOS), this only solves the problem for a fraction of our user base – and that’s not good enough.
So, what do we do? We hide the safe behind a painting. And we hide the key behind a different painting. Additionally, we implement as many mechanisms as possible, in order to make it very time consuming for a thief to find both the key and the safe – so much time consuming, that the police will be there before he can find both of them.
Can you see the analogy? This is the goal of app shielding: we put as many hurdles as possible in order to force the hacker to spend a lot of time finding the key and knowing how to use it. So much time that we have time to react. And “react” means, for example, that we crash the app process (which makes it very difficult to keep searching), or we delete the user data (emptying the safe, in case it is ever open), or we even change the key itself (frustrating an otherwise successful search).
Mobile Apps need more than just App Shielding!
Of course, app shielding on its own is not enough: we need well-known and tested primitives and protocols behind. But this is also true the other way around: if we don’t protect the key it doesn’t matter which protocol we use.
At Build38, our Trusted Application Kit (T.A.K) uses all sorts of app shielding techniques to protect our customer’s assets – that’s also the reason why we like to call it In-App protection:
- Our in-house compiler obfuscates T.A.K’s binary code, making static analysis a lot harder.
- With whitebox cryptography we make sure that cryptographic keys are never in plain in memory (not even while they are being used at runtime!).
- With certain runtime checks such as root/jailbreak, emulator, debugger or app re-packaging, we prevent dynamic analysis.
- Finally, on top of pure in-app protections, Build38 uses a cloud platform that monitors the app to identify app and code modifications. The platform allows integration into SOC, SIEM and analytic systems.
All of this together allows us to provide the most comprehensive set of security features, which in turn enables app developers to focus on writing amazing apps , no matter the smartphone they are deployed on.
