SMART TECH AND IoT Security and privacy:
can an OEM protect one without protecting the other?
Tyler Baker, VP, engineering (Qualcomm Innovation Center) T
he contrasting urgency and importance of security and privacy in the consumer and industrial world can be shown in the simple example of an automobile with advanced assisted driving capabilities. Inadequate protection for user privacy could mean that an unauthorised third party could snoop on a log of the car’s journeys as the data is in transit between the vehicle and, for example, the driver’s insurer. This might feel intrusive, but usually it will have no important consequences for the driver. Inadequate security protection, on the other hand, could allow a malicious actor to take over or corrupt the vehicle’s driver assistance system, compromising the driver’s ability to maintain safe operation. The conclusion seems cut-and-dried; privacy protection is a nice to-have, but security protection is a must-have. Except this is not really true, for at least two reasons. First off, just because an instance of a breach of privacy might not have important safety consequences does not mean that it is not harmful. If a consumer, when buying a car, does not have the clear and explicit understanding that personal data, such as the routes and times of their journeys, their driving style and so on, risk falling into the wrong hands, then the car maker should be under a duty to keep them private. The same should go for any other connected device. After all, no one likes the feeling that they are being spied on.
Secondly, in other settings than a consumer’s car, a breach of privacy can have extremely serious consequences. This is even more true of industrial or commercial systems than of consumer products. For example, the control system of an energy generation plant could send data about its spare generation capacity over the energy company’s network. This private information could be commercially valuable to competitors. It could even be used by malicious actors to time a cyber-attack on a nation’s power grid to cause maximum harm or inconvenience.
28 APRIL 2025 | ELECTRONICS FOR ENGINEERS
Keeping it clean: the value of data sanitation
OEMs have at least a moral duty to protect privacy as much as security. The basic principles of data privacy are straightforward. If security protection is about keeping people out of an embedded device, privacy protection safeguards the data inside the device. This means: • Collecting and storing no more data than is necessary for the device to perform its functions
• Anonymising the data that are collected or stored
• Encrypting data at rest and before transmission
This can be thought of as data sanitation; cleaning up data stores and eliminating the accumulation of ‘waste’, or unnecessary data, to reduce the size of the attack surface open to malicious actors.
Privacy protection features built into the FoundriesFactory platform
OEMs could be forgiven for feeling weary about the concept of privacy. After all, is it not just one more thing to implement, on top of security, which is already a big enough task?
In fact, privacy protection features add surprisingly little overhead for users of the FoundriesFactory platform, who already security best practices and the latest regulations, such as the European Union’s Cyber Resilience Act. Secure boot, CVE readiness, security focused over-the-air updates and more are integral parts of the FoundriesFactory development and device
It is a straightforward process to activate alongside the security-focused features. For example, the Linux microPlatform (LmP) operating system, which underpins the FoundriesFactory platform, can randomisation in the Linux kernel. If a hostile actor were to breach a device’s security protection, the easiest way to inspect the data on the device would be to study the processor’s memory. The LmP uses features in the Linux kernel to break up sequences of data stored in this memory into chunks and then to randomise the locations in which the third party to recombine the data into their original sequence.
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
