# US 2019/0379682 A1 · Protecting vehicle buses from cyber-attacks

> Agents: this data is available as JSON from the patentgrep API and MCP server — see https://patentgrep.com/llms.txt

- Number: US 2019/0379682 A1
- Document ID: US20190379682A1
- Status: Published application
- Kind: A1
- Application number: 16/435,337
- Filed: 2019-06-07
- Published: 2019-12-12
- Earliest claimed: 2018-06-08
- Assignees: NVIDIA Corporation
- Applicants: NVIDIA Corporation
- Inventors: Mark Overby; Rick Dingle; Nicola Di Miscio; Varadharajan Kannan; Yong Zhang; Francesco Saracino
- Web page: https://patentgrep.com/patent/US20190379682A1

## CPC

- H04L 63/14: {for detecting or protecting against malicious traffic}
- H04L 63/1416: {Event detection, e.g. attack signature detection}
- G06F 9/45533: {Hypervisors; Virtual machine monitors}
- G06F 9/45558: {Hypervisor-specific management and integration aspects}
- G06F 13/4068: {Electrical coupling}
- G06F 21/53: by executing in a restricted environment, e.g. sandbox or secure virtual machine
- G06F 21/606: {by securing the transmission between two devices or processes}
- G06N 3/045: Combinations of networks
- G06N 3/063: using electronic means
- G06N 3/08: Learning methods
- G06N 20/00: Machine learning
- H04L 9/002: {Countermeasures against attacks on cryptographic mechanisms (network architectures or network communication protocols for protection against malicious traffic H04L63/1441)}
- H04L 9/14: using a plurality of keys or algorithms
- H04L 9/3247: {involving digital signatures}
- H04L 9/3265: {using certificate chains, trees or paths; Hierarchical trust model}
- H04L 12/40: Bus networks
- H04L 12/40013: {Details regarding a bus controller}
- H04L 12/4641: {Virtual LANs, VLANs, e.g. virtual private networks [VPN] (LAN interconnection over a bridge based backbone H04L12/462; encapsulation techniques H04L12/4633; routing of packets H04L45/00; packet switches H04L49/00; virtual private networks for security H04L63/0272)}
- H04L 47/24: Traffic characterised by specific attributes, e.g. priority or QoS
- H04L 61/2585: through application level gateway [ALG]
- H04L 63/1408: {by monitoring network traffic (monitoring network traffic per se H04L43/00)}
- H04L 63/1425: {Traffic logging, e.g. anomaly detection}
- H04L 63/1441: {Countermeasures against malicious traffic (countermeasures against attacks on cryptographic mechanisms H04L9/002)}
- H04L 63/20: {for managing network security; network security policies in general (filtering policies H04L63/0227)}
- H04L 67/10: in which an application is distributed across nodes in the network (software deployment G06F8/60; multiprogramming arrangements G06F9/46)
- H04L 67/30: Profiles
- H04L 67/568: Storing data temporarily at an intermediate stage, e.g. caching
- H04L 67/61: taking into account QoS or priority requirements
- H04W 4/40: for vehicles, e.g. vehicle-to-pedestrians [V2P]
- H04W 4/48: for in-vehicle communication
- H04W 12/121: Wireless intrusion detection systems [WIDS]; Wireless intrusion prevention systems [WIPS]
- H04W 12/122: Counter-measures against attacks; Protection against rogue devices
- G06F 21/602: {Providing cryptographic facilities or services}
- G06F 2009/45587: {Isolation or security of virtual machine instances}
- G06F 2009/45595: {Network integration; Enabling network access in virtual machine instances}
- H04L 9/50: {using hash chains, e.g. blockchains or hash trees}
- H04L 61/2514: between local and global IP addresses
- H04L 61/5014: using dynamic host configuration protocol [DHCP] or bootstrap protocol [BOOTP]
- H04L 63/1458: {Denial of Service}
- H04L 63/166: {at the transport layer}
- H04L 67/12: specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
- H04L 2012/40215: {Controller Area Network CAN}
- H04L 2012/40273: {the transportation system being a vehicle}
- H04L 2209/76: Proxy, i.e. using intermediary entity to perform cryptographic operations
- H04L 2209/805: Lightweight hardware, e.g. radio-frequency identification [RFID] or sensor
- H04L 2209/84: Vehicles
- H04L: TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION (arrangements common to telegraphic and telephonic communication H04M)
- G06F: ELECTRIC DIGITAL DATA PROCESSING (computer systems based on specific computational models G06N)
- G06N: COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
- H04W: WIRELESS COMMUNICATION NETWORKS (broadcast communication H04H; communication systems using wireless links for non-selective communication, e.g. wireless extensions H04M1/72)

## Abstract

Various approaches are disclosed for protecting vehicle buses from cyber-attacks. Disclosed approaches provide for an embedded system having a hypervisor that provides a virtualized environment supporting any number of guest OSes. The virtualized environment may include a security engine on an internal communication channel between the guest OS and an external vehicle bus of a vehicle to analyze network traffic to protect the guest OS from other guest OSes or other network components, and to protect those network components from the guest OS. Each guest OS may have its own security engine customized for the guest OS to account for what is typical or expected traffic for the guest OS (e.g., using machine learning, anomaly detection, etc.). Also disclosed are approaches for corrupting a message being transmitted on a vehicle bus to prevent devices from acting on the message

## Claims

### Claim 1

An embedded system comprising:
a hypervisor that supports virtualized components with isolated execution environments on partitions of a virtualized environment;
a communication channel of the virtualized environment to a network interface that provides a guest operating system (OS) on a first of the partitions with connectivity to at least one electronic control unit (ECU) on an external vehicle bus of a vehicle; and
a security manager on a second of the partitions comprising a security engine on the communication channel between the guest OS and the network interface that monitors communications over the communication channel for potential threats and determines a security response upon determining a security event from the communications.

### Claim 2 (depends on 1)

The embedded system of claim 1, wherein the security response is performed on a communication being sent by the guest OS to the network interface.

### Claim 3 (depends on 1)

The embedded system of claim 1, wherein the security response includes one or more of notifying the guest OS of the security event, logging the security event, or initiating a safe mode of operation.

### Claim 4 (depends on 1)

The embedded system of claim 1, wherein the security response includes transmitting data to cause a message blocking circuit to corrupt a message being communicated on the external vehicle bus.

### Claim 5 (depends on 1)

The embedded system of claim 1, wherein the network interface is a physical interface to the external vehicle bus and the virtualized environment further comprises a communications manager on a third of the partitions that includes a virtualized hardware interface to the network interface.

### Claim 6 (depends on 1)

The embedded system of claim 1, wherein the external vehicle bus is a Controller Area Network (CAN) bus.

### Claim 7 (depends on 1)

The embedded system of claim 1, wherein the security manager is positioned above the guest OS in a chain of trust of a certificate chain.

### Claim 8 (depends on 1)

The embedded system of claim 1, wherein the determining of the security event from the communications is based on performing machine learning on or more of historical traffic frequency or historical traffic patterns over the communication channel.

### Claim 9

An embedded system comprising:
a hypervisor that supports virtualized components with isolated execution environments on partitions of a virtualized environment;
a first communication channel of the virtualized environment that provides a first guest operating system (OS) on a first of the partitions with connectivity to an internal vehicle bus of the virtualized environment;
a second communication channel of the virtualized environment that provides a second guest operating system (OS) on a second of the partitions with connectivity to the internal vehicle bus of the virtualized environment; and
a security manager on a third of the partitions comprising a security engine that monitors communications between the first guest OS and the second guest OS over the first communication channel for potential threats and determines a security response upon determining a security event from the communications.

### Claim 10 (depends on 9)

The embedded system of claim 9, wherein the internal vehicle bus is a Controller Area Network (CAN) bus.

### Claim 11 (depends on 9)

The embedded system of claim 9, wherein the second communication channel includes a different security services engine that monitors the communications between the first guest OS and the second guest OS over the internal vehicle bus for potential threats and determines a different security response upon determining a security event from the communications.

### Claim 12 (depends on 9)

The embedded system of claim 9, wherein the determining of the security event from the communications is based on performing machine learning on or more of historical traffic frequency or historical traffic patterns between the first guest OS and the second guest OS over the internal vehicle bus.

### Claim 13 (depends on 9)

The embedded system of claim 9, wherein the internal vehicle bus provides the first guest OS with connectivity to an electronic control unit (ECU) on an external vehicle bus of a vehicle over the first communication channel, and provides the second guest OS with connectivity to the ECU on the external vehicle bus of the vehicle over the second communication channel.

### Claim 14

A hardware device comprising:
a first register configured to store a message identifier (ID) of a Controller Area Network (CAN) message, the message ID to be received from a CAN bus during transmission of the CAN message;
a second register configured to store a reference message ID;
at least one logic gate coupled to the first register and the second register and configured to generate an output signal indicative of a result of a comparison between the message ID of the CAN message and the reference message ID; and
an interference circuit configured to, responsive to the output signal, perform corruption of the CAN message being transmitted on the CAN bus.

### Claim 15 (depends on 14)

The hardware device of claim 14, wherein the corruption comprises raising arbitration on the CAN bus, and based on the arbitration, writing an erroneous value to a Cyclic Redundancy Check (CRC) field of the CAN message on the CAN bus.

### Claim 16 (depends on 14)

The hardware device of claim 14, wherein the corruption is performed based on the result of the comparison that the message ID matches the reference message ID.

### Claim 17 (depends on 14)

The hardware device of claim 14, wherein the comparison is between the message ID and each of a plurality of reference message IDs.

### Claim 18 (depends on 14)

The hardware device of claim 14, wherein the first register and the interference circuit are coupled to the CAN bus in a vehicle.

### Claim 19 (depends on 14)

The hardware device of claim 14, wherein the interference circuit includes a programmable window of time over which the corruption is performed

### Claim 20 (depends on 14)

The hardware device of claim 14, wherein the corruption is performed over a window of time that is time synced to a CAN controller data frame.