Security by design – Protecting IP in an IoT deviceProfiles
The Device Chronicle interviews Benoit Ferault, Head of Product Marketing, Quarkslab on protecting IP and secrets within the firmware of embedded devices in a security by design approach.
Quarkslab focuses on the problem of security in the embedded world with a security by design approach. The Paris-headquartered company provides specialised products and services to help digital product developers to obfuscate source code, protect encryption keys and API for products as well as maintain the best ratio between performance and security. At the root of the company is research, and in practice this means reverse engineering for often very sensitive projects and industries. Based on the knowledge gained from research and experience, the company develops solutions to combat reverse engineering, hacking and so on. The flagship solution Quarks AppShield focuses on protecting device firmware, and any intellectual property secrets that are integral to the firmware in the way they are embedded. Benoit says “A security foundation is created and it’s important that companies developing IoT enabled products have a service to simply enable this as it is likely they are more concentrated on proving the business model first than deploying security by design.”
Assuring secure IP through security by design
Benoît says what’s crucial is that Quarkslab as a service provider can bring a set of tools that make it easy for software developers to secure their device. It enables the secure version of the firmware and the embedded IP or “secrets” are protected. The use of obfuscation and whitebox cryptography techniques enables to hide secrets within the firmware binary. Basically it turns the binary into a puzzle in which things can be hidden, and it will deter attackers by the complexity of solving it but also because traps are hidden in the puzzle which will sound an alarm. These can be supplemented by other techniques to instrument the firmware with not only to make it harder for reverse engineers but also to prevent and detect attacks. Sometimes secrets and keys are provisioned directly into the chipset but if the device doesn’t allow for that, or that it needs to be more agile, then Quarkslab can provide a software method to achieve unique firmware by customizing in a way that unique identifiers are dynamically provisioned into the firmware. The solution evolves as the device provider situation evolves where over a period of 10 years, you will have a mix of versions of the devices and yet the device provider will always need proven security. Quarkslab leverages hardware security components such as a keystore or TPM (Trusted Platform Module) if either are available in the embedded hardware. Benoît says “If either are present, we will use them. If they are not present we will find a different means to secure the secrets. We abstract it to another layer.” Benoît is also adamant that doing a proper TLS integration and knowing where to put the key is very hard for a regular software engineer. It’s very helpful for the people to help get the proper security in place. This involves doing a secure TLS integration.”
Security by design across heterogenous IoT device fleets
Concerning embedded hardware, looking forward, Benoît foresees IoT device fleets blending highly constrained hardware and then less constrained hardware. But common across all will be the need for security by design rather than just bolting on security at the tail end of the product development. “Security design as a concept has been there for years. IoT adds cost and if you have to put a Trusted Platform Module in the device, it creates additional cost. There may be push from the business to move it out to the next generation of products or maybe even the third or fourth generation products. Even if the device providers have invested in TPM, technical errors can be made such as provisioning all the devices in the fleet with the same, single unique key. In this way, the key can be shared with a mobile device and then malicious actors would be able to extract the key. There is a lack of understanding and a lack of security expertise, and the understanding of the complexity in provisioning keys and secrets per device. This is complex and you need to be able to deal with it. Where do we keep the key? How do we generate the keys and so on? If you look at the point of properly doing an integration of TLS with a secret that you’ve provisioned into your firmware and that’s something we’re facing in the record business. It’s complex. It’s very complex and most people don’t do it properly. Because the point is the weakness is very often at the border into the configuration and integration with security components. And the attacks usually happen at that level because that’s where the weaknesses are, and it’s logical, because it requires certain skills, a certain understanding to make it work properly. This is one of the things that Quarkslab provides. This means it is as secure as possible and requires as little knowledge as possible from the developer.
Use cases for the technology
There are many use cases: In video and audio systems you have codec IP protection which was mentioned above. Then there are tiny motors developers want to use in their robots. Biometric systems are another area where IP protection is needed. The key use case is IP protection and the theft of the IP. Quarkslab has projects where they are helping a company protect its IP for a digital signal processor. Benoît explains that the client needs to work with a number of hardware manufacturers. They need to embed their IP in 3rd party hardware and “they’re scared to death to see it being stolen.” Benoît continues “I think the media is talking a lot about ransomware and all that, but actually the IP protection is very important as large investments are made in building this IP. It is a kind of supply chain attack to steal the IP; because as you get your manufacturing done, you need to ship your software to a plant in a 3rd party country and you don’t know what’s going to happen in the hands of the 3rd party. This process is very critical for the companies we talk to, we do see a lot of issues arising.”
Unique, per device, firmware is another challenge, if for instance you provide a service which enables the GPS to pinpoint location more quickly. But due to a poor set up, the provider is unable to know if it’s a legitimate device that is querying the system. After that, they discover that 3rd parties are using their server and now they’re scrambling to try to fight it back. The main question which arises is how they’re going to roll back things to be able that only the legitimate devices and GPS modules can connect to their server. This type of attack can mean serious loss of potential revenues. IP is stolen and a 3rd party is reusing it without paying licenses and royalties. “So all of a sudden, you find a 3rd party provider offering, for instance, codecs that function just like the original as they have stolen the firmware and have looked at, and understood the software mechanism.”
AI throws up a new set of challenges
The Quarkslab team has been working on projects where AI has brought a new set of attacks. This involves extraction at different stages of the inference process and being able to understand what are the different results from the inference process, and then being able to basically steal the AI model. AI will be a tremendous challenge in terms of IP protection. There are a number of things happening from explainable to reliable and secure AI that software developers need to be able to understand. What can be protected? There is the privacy issue for which homomorphic encryption and differential privacy are being explored and used. It’s growing up as a field and research area which Quarkslab are working on.
Importance of robust and secure OTA updates
Benoît is adamant that device providers should have integrated device management and OTA software updates. “As generic firmware is being outputted by the engineering team, then you will want customization to reflect certain specific settings of the device. You will want to know exactly which firmware is where and if somebody cracks your firmware, which device it originated on. You also need to have an understanding of what the security state of the device is. So in conclusion, device management and OTA is a really critical integration place for security. You need to understand the challenges around device management as well as upholding security; which translates into having components such as an OTA updating infrastructure that can adapt to this. OTA updating also provides flexibility, as you may need to provision a unique key, secrets, tokens or security countermeasure with all your firmware and you need a transport mechanism to enable the swift and comprehensive execution of this task.
We wish Benoît and his colleagues at Quarkslab as they work to protect IP on edge devices.