I’m going to come clean right away – the title of this article is a lie. Obfuscation IS at least partly security through obscurity. However, that doesn’t mean it’s a bad idea. The thing is, security by obscurity is an often-misunderstood term.
Here’s an example. Suppose you are trying to protect your money, and you have two choices: put it in a safe or bury . Obviously, you should choose the safe – it’s a carefully designed, rigorously tested device for keeping out intruders, while buried money is vulnerable to anyone who knows the location and has a shovel. Burying your money is a classic example of security through obscurity, because as soon as somebody knows what you did, they can undo it.
But hang on! There’s a third choice. What if you put your money in a safe AND bury it? You get all the benefits of a solid security technique and add a significant practical barrier – thieves have to find your safe before they can even start to crack it. Burying your money is only a bad idea if that’s the one thing you do to protect it. Security through obscurity isn’t bad, it’s security only through obscurity that’s risky.
Let’s bring this back to software obfuscation. There are hundreds of recommendations for writing secure software, and you should always follow them. What’s more, you should constantly be vigilant about rooting out and addressing security vulnerabilities in your code. But… if you layer obfuscation on top of these security practices, you’re making your software that much more unattractive to would-be attackers. If you use an automated obfuscation tool such as Irdeto’s Cloakware Software Protection, you can get the best of both worlds – you can write and review clean, well-organized code, and still give your attackers an incomprehensible mess. Obfuscation as just one tool in your security belt can give you a real boost in practice.
Now, I also said in the beginning of this blog that obfuscation is only partly security through obscurity. Again, this term usually means that the strength of the technique relies entirely on people not knowing about it. In fact, there are many examples of obfuscation that are difficult to undo even when they’re well understood. Here’s a simple example – it’s impossible to recover comments on code once they’ve been removed.
Although it’s not as advanced as cryptology, the study of obfuscation via code transformation is becoming much more rigorous. Recent results on indistinguishability obfuscation could take us in promising new directions. And a random seed can be used to drive the obfuscation process, acting much like a cryptographic key. It’s like putting your money in a safe, and then putting that safe in a lockbox, and then burying the whole thing.
Finally, there’s the possibility that an attacker who has control of the device where your software is running can deliberately modify the application to weaken its security – for example, changing your safe fopen_s call to an unsafe fopen call. The analogy breaks down here, but it’s as though you put your money in a safe that was sabotaged during manufacturing to have a faulty lock. Obfuscation is actually the primary defense against such an attack; it’s not covering up flaws that you could have addressed, it’s preventing the deliberate introduction of flaws after the fact.
Follow us here to stay up to date! You can also read more here to get the latest content about Trusted Software!
Click here to get in touch with Irdeto’s Trusted Software team to learn more!
