Embedded Technology
Thinking embedded security from the outset
By Tyler Baker, CTO at
Foundries.io A
recent survey placed Tesla as top of the most in-demand car brands. There’s little surprise at this: a growth rate of more than 157 per cent in 2021
led to Tesla becoming the first electric car manufacturer to sell more than one million vehicles. However, there have been reports that it’s possible to gain control of Tesla cars, something that will concern any user looking to take the plunge.
The vehicles may be impressive examples of modern engineering but there’s always a danger with any new product (this doesn’t just apply to Tesla) that there’s pressure from other sides of the business to get products out of the door as quickly as possible: maybe to meet sales deadlines. As such, there’s a great temptation to cut corners to do this and, very often, the last thing to be considered is security. While it may be true that there is some protection added to the final product, the underlying chipset remains unprotected.
What can happen in these instances is that cryptographic keys are not kept private – in other words, while there will be some level of security, the encryption key is left in plain text and remains an easy target for cyber-criminals.
That’s why it’s important to provide security right from the outset and not treat it as an add-on to be provided at the last moment.
Electronic bank vault
That’s why we talk about the concept of a hardware secure enclave, something that’s akin to an electronic bank vault, offering an additional layer of security. There are two ways to meet this type of protection: either on a discrete chip or on the SOC itself. If security is embedded at SOC level most of the recent ARM chips have this ability if there’s EMMC flash memory on the chip. That’s because they use the replay protected memory block (RPMB), an effective secure unit
26 March 2022
built into EMMC, which offers a way to store data in a protected manner and which can only be read by an authenticated process. The way we do it is to use the generic OP-TEE, so there’s a whole ARM-trusted firmware to provide trust.
OP-TEE offers several advantages: isolation from a non-secure operating system while, at the same time, offering support for different architectures and operating systems. As such, we can derive keys from a secure storage inside the SOC. And those keys are never exposed, so there’s no way for a user to access them. That’s all great until users come up against attacks like Spectre and Meltdown. These are memory-cache attacks and will compromise the SOC at the most basic level. If this happens, then the RPMB will be exposed and the whole system is at risk. So, that’s where the second type of protection comes into play: the use of discrete protection, away from the SOC itself. If you really want to provide protection against these memory cache
Components in Electronics
attacks, then these discrete security elements are all off chip.
There is still plenty of functionality: it has elements like secure storage and cryptographic acceleration, and we provide a generic interface to access it.
Not everyone will feel obliged to go down this discrete chip route. SOC security is good enough for about 90 per cent of users, but there’s always that 10 per cent who would like something a bit better. We can do this by wiring the hardware security element to the development board. By doing this, we can provide things out of the box – it requires a lot of domain specific knowledge to do that.
Updating security
There’s one other element to be considered, beyond the underlying security, and that’s how to make sure that the system remains secure: how does it stay up to date?
It’s something that’s not been easy to do with embedded systems as it necessitates sending patches to a mailing list. There’s not
always a secure boot, so someone could get access and compromise the whole set-up. We like to think of ourselves as an Android for embedded systems – a sort of standard platform that can be used to add additional functionality.
Just like we think about security from the outset, we also think about how companies can maintain those security levels: we want to make it easier to build secure products that are updatable, something that companies have traditionally done poorly. Ask yourself how many domestic products with embedded systems you’ve updated in the past 20 years. There won’t be many. So, the issue facing Tesla and every other manufacturer of these advanced vehicles (or any other vendor with embedded systems) is how secure those systems are? And, if not secure, what are you going to do about it? The answer is to think about security right from the outset and at chip level – it should not be an afterthought.
https://foundries.io/ www.cieonline.co.uk
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52 |
Page 53 |
Page 54
