#TRUSTING OBSCURITY HOW TO#
#TRUSTING OBSCURITY ANDROID#
#TRUSTING OBSCURITY CODE#

#TRUSTING OBSCURITY CODE#

Finally, on top of pure in-app protections, Build38 uses a cloud platform that monitors the app to identify app and code modifications.With certain runtime checks such as root/jailbreak, emulator, debugger or app re-packaging, we prevent dynamic analysis.With whitebox cryptography we make sure that cryptographic keys are never in plain in memory (not even while they are being used at runtime!).Our in-house compiler obfuscates T.A.K’s binary code, making static analysis a lot harder.But this is also true the other way around: if we don’t protect the key it doesn’t matter which protocol we use.Īt 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: Of course, app shielding on its own is not enough: we need well-known and tested primitives and protocols behind.

Mobile Apps need more than just App Shielding! 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).

#TRUSTING OBSCURITY HOW TO#

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.Ĭan 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. And we hide the key behind a different painting. So, what do we do? We hide the safe behind a painting.

#TRUSTING OBSCURITY ANDROID#

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. 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. This is exactly what happens in mobile apps. But what if this is not possible? What if we had to store the key close to the safe? In both cases, the security of the system relies on the assumption that the key is kept in a safe place. 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. Let’s try to find a more specific scenario. The right answer is in the last sentence: “ should never be the only security mechanism.” Security experts have rejected this view as far back as 1851, and advise that obscurity should never be the only security mechanism.” 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. Which kind of relates to a broader topic known as “security through obscurity”. 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.” In this case, it depends on the execution environment.īut let’s back up for a moment. As with everything in life, the right wording is “it depends”. Well… I have to say that I (somehow) disagree. If you have a secure enough lock, it shouldn’t matter who can see it. Think of shielding code like hiding a safe behind a painting. Wired magazine recently published an article with the following statement:

Trusting obscurity