It's a pity that I'm interested in Internet of vehicles security, but I don't have a real car to practice. In order to solve this problem, the author combines his own practical experience of vehicle networking security to build an experimental environment highly close to the real vehicle. This environment uses the current popular multi domain architecture and realizes real security functions, including VLAN and firewall, for your learning and reference.

Domain architecture

Explanation of domain schema:

1) The experimental environment realizes two classic communication domains, VCU and HU. VCU can be understood as vehicle control domain, while HU is information and entertainment domain. The two domains communicate through Ethernet;

2) VCU domain realizes body CAN (BDCAN) and automatic driving CAN (ASCAN), which are connected through gateway to simulate body CAN message sent to automatic driving module;

3) The HU domain realizes the instrument CAN (ICCAN) and camera CAN (CAMCAN), which are respectively connected with BDCAN and ASCAN through Ethernet, and the first connection (BDCAN  -> ICCAN) analog body data is displayed on the instrument panel, and the data collected by the second connection (CAMCAN - > ASCAN) analog camera is transmitted to the automatic driving module;

4) The first connection and the second connection are isolated through VLAN.

Vehicle function

Simulate vehicle functions through ICSim[1]. ICSim is an open source vehicle instrument simulator. The simulator includes two modules: controls and ICSim. Controls is responsible for generating simulated vehicle data and sending it to the virtual CAN interface in the form of CAN message. ICSim reads the CAN message from the virtual CAN interface and updates the status of corresponding parts on the instrument, such as vehicle speed Door status, etc.

(ICSim instrument and operation interface)

In our architecture, ICSim and controls are connected to two different cans respectively. ICSim is connected to ICCAN in HU domain, which represents the real instrument panel; Controls is connected to the BDCAN in the VCU domain, representing real body parts. The VCU domain and HU domain are connected through Ethernet, and the CAN message generated by controls is transmitted to ICSim through Ethernet. This implementation is very close to the real vehicle domain architecture, because the instruments of some models are indeed divided into HU domain. Ethernet, as the communication protocol between VCU and HU, is also a popular domain architecture at present.

Create vcanic and vcanbd as follows:

sudo ip link add name vcanic type vcan
sudo ip link set dev vcanic up

sudo ip link add name vcanbd type vcan
sudo ip link set dev vcanbd up

Next, bind ICSim to vcanic in HU domain and controls to vcambd in VCU domain:

./icsim vcanic
./controls vcanbd

At this time, the message generated by the controls representing body parts CAN not reach ICSim smoothly, because the two CAN buses of vcanic and vcanbd are not connected yet. We will connect the two CAN buses through Ethernet, which will also mean the connection between VCU and HU.

CAN-ETH communication

The open source project cannelloni[2] is used to realize Ethernet. Cannelloni's core principle is to transmit CAN messages through UDP protocol, as shown in the figure below:

(the picture is from the paper mapping can to Ethernet communication channels within virtualized embedded environments)

Because our experiment is conducted on one machine, we will distinguish the two independent communication domains of VCU and HU through different ports. Combined with the requirements of dividing the broadcast domain, we will create a virtual network card with vlan id through vconfig.

VLAN partition broadcast domain

Considering that the message type transmitted through Ethernet includes ADAS (automatic driving) message with high security requirements, our idea is to divide the broadcast domain according to different security levels of the message, and divide the general control message and automatic driving message into different networks through VLAN, which can not be accessed to each other.

First, create a virtual network card with vlan id on the real network card:

$ sudo vconfig add enp0s31f6 20
$ sudo vconfig add enp0s31f6 30

The creation results are as follows:

$ ip link
(Irrelevant network cards are omitted here)
5: enp0s31f6.20@enp0s31f6: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 70:85:c2:7f:31:ef brd ff:ff:ff:ff:ff:ff
6: enp0s31f6.30@enp0s31f6: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 70:85:c2:7f:31:ef brd ff:ff:ff:ff:ff:ff

Add an ip address to the network card and start the network card:

$ sudo ifconfig enp0s31f6.20 192.168.20.100 netmask 255.255.255.0 broadcast 192.168.20.255 up
$ sudo ifconfig enp0s31f6.30 192.168.30.100 netmask 255.255.255.0 broadcast 192.168.30.255 up

The effects after successful startup are as follows:

$ ifconfig
((irrelevant network card is omitted here)
enp0s31f6.20: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.20.100  netmask 255.255.255.0  broadcast 192.168.20.255
        inet6 fe80::7285:c2ff:fe7f:31ef  prefixlen 64  scopeid 0x20<link>
        ether 70:85:c2:7f:31:ef  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 81  bytes 12838 (12.8 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
enp0s31f6.30: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.30.100  netmask 255.255.255.0  broadcast 192.168.30.255
        inet6 fe80::7285:c2ff:fe7f:31ef  prefixlen 64  scopeid 0x20<link>
        ether 70:85:c2:7f:31:ef  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 81  bytes 12838 (12.8 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Test the connectivity of the following two VLAN s:

$ ping 192.168.20.100 -I enp0s31f6.30
PING 192.168.20.100 (192.168.20.100) from 192.168.30.100 enp0s31f6.30: 56(84) bytes of data.
^C
--- 192.168.20.100 ping statistics ---
70 packets transmitted, 0 received, 100% packet loss, time 70637ms
pipe 4

$ ping 192.168.30.100 -I enp0s31f6.20
PING 192.168.30.100 (192.168.30.100) from 192.168.20.100 enp0s31f6.20: 56(84) bytes of data.
^C
--- 192.168.30.100 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4100ms
pipe 4

VLAN division is successful. Then we use cannelloni to connect BDCAN (vcanbd) and ICCAN (vcanic):

$ cannelloni -I vcanbd -R 192.168.20.100 -r 20001 -l 20000
INFO:udpthread.cpp[INFO:146]:run:UDPThread up and running
canthread.cpp[108]:run:CANThread up and running


$ cannelloni -I vcanic -R 192.168.20.100 -r 20000 -l 20001 -p
INFO:udpthread.cpp[146]:run:UDPThread up and running
INFO:canthread.cpp[108]:run:CANThread up and running

After connection, the CAN message CAN be sent to ICSim through the operation of controls, and the instrument panel CAN also display the status. By connecting ASCAN and CAMCAN in the same way, the communication between VCU domain and HU domain CAN be completely opened. In the actual communication scenario, we may configure the service capability according to the similar minimum permission principle. For example, in the communication scenario between VCU and HU, we may think that the HU domain only needs the ability to receive the body CAN message from VCU, not the ability to send the body CAN message; On the contrary, the camera data generated by the HU domain needs to be transmitted to the ADAS module of the VCU via Ethernet. At this time, the HU domain may need the ability to send camera messages instead of receiving them. In order to meet this demand, we added a network firewall in the experiment.

  firewall

Establish firewalls in VCU domain and HU domain respectively through iptables rules to filter Ethernet messages with risks, so as to achieve the following two purposes:

1. Messages generated by body parts can only be transmitted to HU by VCU;
2. The message collected by the camera can only be transmitted from HU to VCU.

Taking HU as an example, the flow direction of messages is controlled through the following rules:

$ sudo iptables -A INPUT -d 192.168.20.100 -j LOG --log-prefix='[hu-normal-in]' --log-ip-options
$ sudo iptables -A INPUT -p udp -d 192.168.20.100 -s 192.168.20.100 --dport 20001 --sport 20000 -j ACCEPT
$ sudo iptables -A INPUT -d 192.168.20.100 -j DROP

  So far, the communication between VCU and HU has been completely opened, and we have added firewall rules, but the communication within VCU has not been solved. Because ADAS module may also need the data of body parts to make automatic driving decisions, we need to connect BDCAN and ASCAN through gateway.

CAN gateway function

Simple CAN gateway function CAN be realized by using cangw, which connects body CAN (BDCAN) and ADAS CAN (ADASCAN), and the CAN message generated by the body is routed to ADAS module through the gateway. (in fact, the combination of functions of cangw and cannelloni is very close to the real CAN gateway, which also supports LIN, Flexray, etc.)

  The gateway is configured as follows:

$ sudo cangw -A -s vcanbd -d vcanas -e
$ sudo cangw -A -s vcanas -d vcanbd -e

cangw also supports the configuration of message filtering rules and integrity verification. Readers can continue to explore, and the functions of camera module and ADAS module can also continue to be improved.

  reference resources

[1].GitHub - zombieCraig/ICSim: Instrument Cluster Simulator

[2].GitHub - mguentner/cannelloni: a SocketCAN over Ethernet tunnel

Reprint, please state the source!