Written by Here at Consult Hyperion, we are often involved in design implementation and testing of secure systems on devices such as smart cards and mobile phones for payments, banking and other applications where security is critical.
These applications are particularly vulnerable because the device phone or card could be in the attacker’s hand for a considerable period of time unsupervised.
In such situations the application must be designed from the start with security in mind – security critical elements are identified, secure development practices are used, but in addition to these standard secure development steps, additional measure are often required to protect against attacks which may at first seem like magic.
Some of these possible attacks include the ability of an attacker to alter the execution of code, by skipping a single or multiple steps, causing it to not behave as expected or by using a side channel to gain access to secret information. These attacks are akin to Jedi mind tricks being played on the application such as ‘this IS the PIN you were expecting’, ‘you don’t need my PIN’ or simply reading the victims mind.
At first it would seem that if an attacker can perform such tricks that security is an impossibility, the attacker can bypass any check you could design. In reality though an attacker may not be able to reliably complete such an attack particularly easily. They may not be able to repeat the same trick in rapid succession, may require lots of practice to perform the trick. Additionally, to perform the attack successfully the attacker must decide what trick to use, when and where to use it, and avoid detection whilst they probe the system for a successful attack. It is the knowledge of these attacks, their constraints, and the limitations that an application developer can use to build robust defences.
The defences against these attacks vary but include:
- Integrity checks on code or data to show that the application is performing as designed
- Masking / encryption or obfuscation of critical data
- Use of randomisation to perturb monitoring of side channels
- Re-evaluation of validation or critical results / decision
- Limiting lifetime of sensitive data especially keys
All this comes at a cost in terms of complexity, time, and effort, and is not functionality ever needed in a standard application. Indeed, these practices are almost the antithesis of normal practices which aim to build efficient code. They present a particular challenge in constrained environments such as smart cards which are extremely limited in terms of speed and memory space. To successfully implement these defences in a constrained environment requires a deep understanding of the platform and its technology.
A recent application I have worked on required 3-4 times the code and considerably more complexity versus a more naïve (but entirely functional) implementation, and all this in a smartcard with only a few kilobytes of code on processors running at a few mHz with limited power.
Next time you pull out a contactless card to pay for something, take a moment to marvel at the secure engineering that has gone into making such a complex device, secure, reliable and simple to use.
Consult Hyperion has helped many of the world’s leading payment organisations with specifying, certifying and testing their applications. We understand the practices needed to build safe and secure applications. Our in house development team, Hyperlab, have over thirty years experience of working with clients to ensure the data of their customers is protected. If you’d like to understand more, we’d love to hear from you. Follow us on @chyppings (Twitter & LinkedIn) or drop an email to info@chyp.com.
