Runtime Self-Protection in a Trusted Blockchain-inspired Ledger Clifford Liem Cloakware MU, Irdeto Canada
[email protected]
Eslam AbdAllah Queen’s University
[email protected]
Chidinma Okoye Concordia University
[email protected]
John O’Connor Cloakware MU, Irdeto Canada
[email protected]
Md Swawibe UI Alam Queen’s University
[email protected]
Stacy Janes Cloakware MU, Irdeto Canada
[email protected]
Abstract With the auto industry moving to more and more computing units, connected infotainment, pairing of onboard equipment to mobile devices, cloud connectivity, V2V, V2X, and autonomous functions, architects and developers need all the help they can get to address security and safety concerns in the systems. In the past, the world of enterprise IT and mobile devices has seen its share of security failures and rebounds; however, the auto industry cannot afford to fall into the same pitfalls when greater things like safety are at stake. In this paper, we present a number of software protection technologies and their application to a trusted distributed environment. We show how layered robustness approaches like runtime application self-protection, white-box cryptography, program transforms, and a secure environment can be applied and orchestrated in a distributed network to establish trust in its leaf components. Furthermore, while on-board diagnostics like OBD2 and UDS are important, diagnostics over IP (DoIP) is becoming essential in a connected car. The natural extension to this is to enable security analytics through the telemetry connections, paving the way for analysis of the data to determine trends over the fleet. Finally, in this paper, we show a proof-of-concept network running on iMX6 and R-Car M2/3 boards demonstrating the main concepts being put forth, running on different OS’s, including Ubuntu, Android, and Automotive Grade Linux (AGL), which shows the flexibility of the approach.
1. Motivation As we look at the rapid evolution of the modern-day vehicle, connected computing units are becoming an essential part. Software has become the go-to alternative for the best-in-class car features. More and more, the systems are becoming a local network of connected computing devices connected through in-vehicle ethernet, but also including an IP to CAN interface, handling an array of traditional ECUs. Additionally, we are seeing LIN and FlexRay; however, adoption is moving slower in these cases.
Not only are there In-Vehicle Infotainment (IVI) head units, but often, new computing units are showing up including shared entertainment units, ethernet gateways, antenna units, assisted and automated driving units. Form factors include hypervisor-controlled and bare metal. The situation is compounded with more computing units like connected mobile phones and tablets attaching to the system over USB, Wi-Fi, and Bluetooth, making the job of securing all the attached pieces a more difficult job. Recent events have shown that connected vehicles are vulnerable to attack. One of the first demonstrations was the Jeep Cherokee hack by Miller and Valasek [1], controlling the car’s functions remotely (e.g. A/C, radio, wipers, transmission) purely through an internet connection. A similar hack was done by the Keen Security Lab on the Tesla Model S [2], where the researchers were able to take over the infotainment unit, change the instrument cluster screens, remotely unlock doors, open the trunk, fold the side mirrors, activate the brakes while the vehicle was in motion, move the power seats, and activate signal lamps. Even a simple attack like moving the seats completely forward and turning up the radio full volume would probably be enough annoyance to wreak havoc with drivers. Other examples include invasions of privacy with connected vehicles and devices [3], which one could argue is not a severe security breach, but this may be enough to cause consumer backlash and brand degradation. Any connected computing unit in a vehicle has the potential to throw a monkey wrench into the system. Consider a rooted Android phone with a piece of malware connecting to the system, or a compromised downloaded App on the head unit, or a USB stick containing a clever, self-propagating piece of malware. However, potentially bigger problems are the V2V, V2I connections and the connections to the cloud, which increase the origin possibilities of malicious intrusions. Malware can spread quickly through an IoT infrastructure, as was shown in the recent attack on the Philips Hue light bulbs, where a worm could infect a whole city given a dense enough population of lights [4]. Malware has gotten better at becoming stealthier [5], and with the big targets of 1
automobiles, commercial vehicles, and fleets, attackers will become increasingly adept and clever at direct compromises and inserting malware into vehicle systems. As we consider security and safety conditions for operating software in systems such as these, it is important to be able to systematically identify compromises of parts of the system so that mitigations and fail-safe actions can take place. As systems become more and more distributed, trust in software components and trust in communicating data is harder and harder to come by, as any single component or piece of data may be compromised. Processors, software, and/or data can be attacked in any part of a distributed system. Establishing trust in the system is a problem that grows exponentially with the number of nodes and is augmented by the number of risk characteristics for each node. Risk characteristics are the aspects of each sub-system that may reduce the trust that a sub-system is operating as expected. For example, some of these risk characteristics can include: compromised integrity of the code or data; presence of debuggers or rooting utilities; known vulnerabilities detected over time; outdated software versions; frequent spikes beyond the normal operating parameters (e.g. open ports with high throughput, massive draw of CPU cycles, persistent and unusually high use of memory). In this paper, we present an approach to maintaining a robust and integral distributed system through a novel use of software protection technologies (e.g. anti-reversing and software hardening techniques) matched with distributed ledger technology. We begin with a review of the individual software protection techniques, followed by a description of distributed consensus networks, and ending with a description of a proof-of-concept working system. Figure 1 shows an overall flow of data through the system.
2. Software Protection Technologies A decade or two ago, the predominant view in the IT industry was that software security should center on approaches like perimeter blocking (e.g. firewalls), signature-based identification (e.g. virus scanners), and compliance-driven security (e.g. FIPS 140-2 certification). While these approaches have evolved over time, they are still in practice. Meanwhile, the computing world has changed drastically over recent years. We now have apps running on smartphones, virtual machines, containers, powerful scripts running on browsers, and millions of IoT devices all connecting to the cloud, which in turn run a multitude of back-end services. We have virtual private networks, content in the cloud and fully distributed applications. All of these things are also now moving to the vehicle! The modern vehicle and architectures for autonomous vehicles are starting to resemble a local area network with units for driving functions, shared entertainment, and constant data connections to external infrastructure like the cloud. Will we continue to solve security problems with old ways of thinking? Do we really think that firewalls blocking traffic coming into the network is a sufficient solution? Is virus scanning/intrusion detection going to offer a compelling approach to ridding us of malware? Is public key infrastructure (PKI) a sufficient way to think about encryption? Historical approaches to software security are losing the battle against determined attackers and hobbyists wanting to modify their car with simulators, inexpensive boards, and the scads of information on wikis and forums. Today’s applications that run in hostile environment need the best in software protection technology. This includes run-time self-protection, white-box cryptography, program transforms, and OS-level secure execution protecting the software from ill-meaning adversaries.
Figure 1. Overall Flow of Distributed Trust System.
2
Tamper-resistant software techniques combined with diversity, monitoring, and rapid deployment of updates can provide an arsenal of defenses for security from the inside out.
2.1 Runtime Application Self-Protection 2.1.1 Integrity Verification Attackers have moved well past defeating static methods of verifying modification of software. For example, checksums (e.g. CRC32, MD5) of files sitting on disk may offer an assurance of uncorrupted files on download; however, from a security perspective this is only a foundation. Attackers have many ways to counter this type of check including recalculating the checksum of the file or modifying the code performing the check in memory. At a minimum, protection techniques must be capable of securing applications at runtime. Integrity verification is the automatic form of making sure that the executing code is the same as the code that is originally deployed and ensuring that this is true even in memory at runtime. This tamper resistance technique covers the program by first signing the code segments with a set of digital signatures. In the native form, these signatures reside in a protected, encrypted voucher, either in a separate file or concatenated directly to the binary. The developer has control over the failure-response. For example, a typical response is to cripple the program if the integrity check fails. Another response is to simply log the event, while another response might be to alert another part of the system which invokes a failure response like triggering a limp home mode (LHM). In a connected scenario, events may be aggregated locally then combined and sent to the network for analysis over a fleet. This data becomes essential in reacting to compromises and eventually in predicting where issues may originate. Our methodology also includes a way to renew security by preparing diverse instances ahead-oftime, ready to deploy at any hint of a perceived vulnerability.
2.1.2 Anti-Hooking, Anti-Debug, and Root Detection On Linux-based systems, history has shown that it is often sufficient for an attacker to gain root privileges to have unlimited power to make changes to a running system. Hackers will use a stockpile of tools to directly attack running applications, including debuggers and disassemblers like IDAPro and radare2. Even in cases which are further locked down with techniques like sandboxing (i.e. DAC) and mandatory access control (i.e. MAC) like SMACK (e.g. AGL) and SELinux (e.g. Android), attackers can exploit the system. For example, in Android, attackers are much more clever, creating hooking utilities like CydiaSubstrate and the Xposed
framework, allowing them to alter behavior at any points of interest even while the apps are running. Defenses for these types of direct attacks include features like root detection, which can identify if a device has been rooted and then take appropriate actions. In addition, antihooking techniques can determine if methods or functions have been redirected to sources unintended by the software author. There are also anti-debug techniques that can infringe on the regular operation of debuggers by using up their needed resources, including making generous use of signals or denying attachments with ptrace. These defenses layered with other software protection techniques can oppose and frustrate the effectiveness of many attack tools.
2.2 White-Box Crypto: hiding keys at runtime The white-box context describes an attack environment where the adversary has full visibility and control over the running software. A threat in this context is also known as a Man-at-the-End (MATE) attack. This presents a very challenging environment for protecting cryptographic algorithms. While cryptography is commonly used in everyday products, very little attention is being placed on securing the running software in a hostile environment like an open, unprotected platform where an attacker has full visibility. If an intruder can pull a key out of a static database or simply set a break-point in a running program to reveal a key, then all is lost, especially if that key is an important base key of the system, and markedly if that same key is used by every instance of the software running in every vehicle. This is known as a class attack, as it compromises all pieces of software in all its deployments. White-box cryptography is a way to implement algorithms like AES, RSA, and ECC so that keys remain hidden at all times, even when executing. They use advanced techniques like table-based and table-less computation and altered data representations. The can also form a barrier to sophisticated attacks like Fault Injection and Differential Computation Analysis (DCA) [7]. Some white-box implementations also employ a fixed-key variant, which means the key is indelibly linked or bakedinto the code, allowing for further concealment of the key. Even during running code, keys are never revealed in the execution. The concealment is complete and includes both full and round keys, where attacks commonly start. Ensuring the highest value digital assets are protected with a strong white-box crypto implementation should be paramount in any application system, as this is often the root-of-trust for the entire security system.
3
