Embedded Security Should be Thought Through Thoroughly afresh

As I write this, a lot has been happening around us. Apple’s secure enclave processor firmware has been decrypted, face recognition based secure identification of iPhone X has been hacked with relatively inexpensive masks apparently, Uber data breach compromised privacy of 57 million people, Equifax breach compromised even a larger number of people, and new Android Trojan malware were discovered in Google play store. These are but a few examples which have been published in the media. A lot more are happening and being suppressed. News reports suggest that Uber might have paid hackers to suppressed data breach. Other reports indicate that even an India telecom provider might have paid hackers for similar reasons. In India, cloud of suspicion over electronic voting machines, popularly known as EVMs have gathered after a few reports on all votes automatically going to a specific party surfaced. Even today itself, reports of that sort of compromise are coming in – as there is a hotly contested regional election taking place in India today. While the Election Commission of India has denied any such possibilities, but they have not been forthcoming in offering experts to open these EVM machines, probe its hardware, firmware and possible attack surfaces leaving a section of politicians and public suspicious. Given that twitter bots, and social media bots in millions had been unleashed to sway public opinions, creating and propagating fake news, and challenging the normal democratic processes, it is a scary new world that we are faced with today. Continually extending our digital foot print, and moving all political, business, financial, social, and transactional activities to the digital world in search of efficiency – are we not exposing ourselves to an unknown future?

Why are these relevant to embedded computing? I seem to be obsessed with cyber security over all other challenges germane to embedded computing. Is it intentional to attract more research in the embedded security domain? My answer is that subconsciously possibly, but there is a good logical reason for the fear and concern. Furthermore, most devices that we find vulnerable as well as affecting our lives and society are embedded computing devices. Be it mobile phone, voting machines, automotive, avionic control, Internet of things (IoT) based automation, sensors and control systems in utilities, or medical devices such as pacemakers or insulin pumps.

While large scale data breach usually concerns IT systems, even there we saw tangled web of cyber physical sensor network security affecting IT security. Take for example, the Target data breach. The network for HVAC system monitoring was breached and became the conduit to propagate malware to point-of-sales machines, which led to stealing of credit card information while being swiped for authorization.

Compounding all these vulnerabilities, and mounting threats, insider threats are also increasing – through social engineering and other human centric processes. A high privilege system administrator might compromise individuals unless the system is designed to be robust against insider attacks. We have evolved our IT systems with the assumption of trusted central authority, or trusted third party, and only became aware of the large percentage of internal attack incidents in major breaches.

Our Computing stack also has been designed to trust lower abstraction layer – and only in last two decades or so, we became conscious enough to evolve the notion of ‘trusted computing’. Notion of a ‘root of trust’ anchored boot strapping of trusted computation is a powerful one – and that is where enclave processor, HSM (hardware security module), Intel SGX (Software Guard Extensions), Cisco network enclave and similar concepts originated.

However, these enclaves based security architectures need to be proven secure, and while the recent hack of the firmware encryption of Apple enclave processor does not compromise the private keys or the enclave’s security, it seems to have created a lot of concern. The existence of Trojan malware laced apps in Google play has raised similar concerns. Notwithstanding the sandboxing in Android, if an unpatched version of Android is on the mobile, even the dirtyCOW vulnerability in the Linux kernel could break the sandboxing. So, upgrading of Android to the most recent version is becoming very urgent for all users.

In terms of internal attackers, thwarting malicious behavior by privileged users is finding some solutions in block chain technology. Immutable logging with public verifiability can provide some deterrence to malicious activities by a privileged user. Also using block chain to implement a distributed DNS (Domain Name Service) or a distributed PKI (Public Key Infrastructure) could be seen as alternative to dependence on trusted third party – when the trust in third parties – especially in the hands of untrusted entities are at all time low.

There was a time, we trusted the hardware, and the Operating system and only assumed applications being downloaded or purchased are untrustworthy. From there, today, we cannot trust any vendor or a manufacturer, given that outsourcing nature of the business, and given the increasing number of threats and enhanced attack surface. Even with the proliferation of IoT devices, we cannot even trust the devices around us, as we say in case of Mirai botnet – given the vulnerable devices of questionable security. We cannot trust our medical devices – our pacemakers or insulin pumps. We are unable to trust our democracy when executed through electronic voting.

It is thus high time, that embedded security takes precedence over optimization – be it cost, power, or latency. However, the choice cannot always be made – as real-time requirements often comes in the way. Therefore, new methods and techniques for trust anchoring are necessary. Sandboxing, authentication, security certificates, anti-malware scanning – none of them are enough security.

Even though, we get a reasonable number of embedded security based submissions in this journal, I think out-of-the-box solutions are required, and more provable security solutions are needed.