Things You Must Know For Vehicle Hacking: PART 2
VEHICLE INTERNAL NETWORKING: The Advent of Automotive Ethernet
If everything was good and working, why a new tech-stack was needed you may ask. Well, things changed in IT very much very quickly. Now we are talking about semi-autonomous/autonomous vehicles, vehicles that encode/decode and process hi-fi audio and video in real-time and build decisions upon these processes. Also, cars, pretty much like all IoT devices, are getting more interconnected than ever, including their cloud connections.
In this blog post, I will be talking about automotive networking in general, the OSI model, and the novelties that came with the new tech stack. In a later post, I will delve into cybersecurity measurements that are aligned with each layer in the OSI model.
<New Friend, Good Old Ethernet/>
We all know and use ethernet. It is a veteran technology, there are lots of protocols and systems running in and around it. It is the backbone of our daily lives. More than that, it is a really muscular, flexible, and open-minded infrastructure. Never mind that it is old, it is still smoking hot and fresh.
Well since we treat our vehicles now as the IoT devices, which are running on the ethernet mainly, why not we use all the know-how on vehicles too? Yes, we should.
The primary problem the automotive-ethernet solves in the vehicle network is the bandwidth problem. Keep the MOST aside, all the aforementioned bus techs are running on the lower bandwidth and have smaller payload capacities.
One thing to remember is that automotive ethernet is a bit different compared to regular ethernet. But the difference mainly lies in the physical layer. Regular ethernet uses standard 4 wires but this creates some speed problems. See, In vehicles, low power consumption is important. Also, the requirement for ECU(Electronic Control Unit) is to be able to completely wake up from sleep in under 100 milliseconds. Hence the change in the physical layer is required.
Another difference is ethernet primarily is a Point-to-Point technology. Bus in the vehicle context is not a very good option. Hence, using switches, automotive-ethernet geared towards the star topology, with one exception that uses the bus.
In the original ethernet configuration, there are two problems which are collisions and arbitration which cause inefficiency. The impact of this is not the same for a person who is sitting in front of a pc and the person sitting in front of the wheel. Hence, automotive-ethernet optimizes the traffic flow and uses buffering to eliminate collisions.
in Bus systems like CAN, and FlexRay, there is a binary state at a given time on the physical layer. Whereas in ethernet, more than 2 logical states can be passed. In Gigabit ethernet this is 5 different states(PAM-5). In the automotive physical layer of 100/1000mbps, there are 3 different states(PAM-3). Think of the magnitude of the aggregated change!
Before jumping on the OSI model, I want to tell you about one particular thing about the automotive ethernet. Normally for a drastic change to happen, or say for such adaptation to happen there needs to be a huge infrastructural change. But thanks to how the original ethernet skeleton is designed, only a single minor change can carry all the novelties along into the vehicle.
MAC stays constant and all the layers under the Physical layer also stay constant. This MAC table, once connected, hosts all the addresses, etc, and statically keeps these. So it gives the ability to easily swap the Ethernet PHY and MAC stays the same, also all the other layers are intact. This gives the ability to change and adapt over time. Automotive ethernet is an adaptation of it where only the physical layer is changed. Hence talking about `Automotive Ethernet` basically means a change in the Physical layer only!
More than that, by using MII (Media Independent Interface), different physical interfaces can be used with any MAC!.
Quick bite: ethernet is also full-duplex! which means one node can communicate data in one direction at full speed and at the same time the other node can communicate data in the other direction at full speed Which means, let's say 2 nodes communicating in two directions at full speed, at 100BaseT connection, it makes 100 * 2 = 200 Mbit per second data transfer. as for gigabit, that is 2 Gigabits aggregate data. From 10mbit/s to gigabit speeds!
<OSI Model: From Electrical Signal to Application/>
What the OSI model is and why it is needed? The OSI model (Open Sytems Interconnection) is a design-compatibility standard that aims to maximize the compatibility of the devices. It is vendor/manufacturer agnostic and revolves around the encapsulation principle. The term encapsulation is used to describe the process of adding headers and trailers around some data. Starting from the Application layer, all the way down to the physical one.
Probably you have seen the movie Lord of War. I love the intro scene where you follow a bullet from the factory all the way to the muzzle through which it flew. Let’s do a similar journey starting from the physical layer to the top.
At the end of this journey, you will have a good understanding of the network model which lay the grounds for the next post in the series where we will be talking about vehicle-specific cybersecurity standards and issues.
Off we go. (but we start from PHY level, so we will decapsulate the data)
<First Steps: Physical Layer and Data Link Layer/>
An electronic current hit our machine at hand. It currently carries signals that need to be converted and a header/trail decorated so it can be more useful. These signals firstly hit on the physical layer which is the bottom layer of the OSI model and we call it bits. The only way to secure what we have so far is actually enabling physical access to the machine.
Next up, this transmission is sent up to the upper floor (hypothetically) which is the Data-Link layer. In the data link layer lives the Ethernet Frame and MAC Addresses. Remember this layer as where MAC and switches live(switches can also live on the third floor but just keep it simple). DLL handles error notification, network topology, and flow control. This means the Data Link layer ensures that messages are delivered to the proper device on a LAN using hardware (MAC) addresses and translates messages from the Network layer into bits for the Physical layer to transmit. So we know that so far we enabled the following features:
- Device Addressing
- Message Formatting
- Error Detection
- Quality of Service
What we built so far is called an Ethernet frame. An ethernet frame contains (not only but still, KISS principle) dest/src MAC addresses, Data (which can be 46 to 1500 bytes!! compare it with 8 bytes limitation of CAN!), Cyclical Redundancy Check field to check the quality of the frames and taking action if necessary, 802.1Q Tag (VLAN Tag)which is in most cases, especially in WWW it is not used but in Automative Ethernet especially in real-time transmission and protocols that use this real-time transmission do use this for Routing and QoS purposes.
Cyclical Redundancy Check makes sure that the receiver received all the prior bits in the correct order. note that if a receiving node receives a frame with a bad CRC like a short frame, long frame, or a fragment of a frame, it should drop the frame, and don’t tell anybody that you dropped it. So at the low level, there is no re-transmission. But this problem will be handled shortly when we come to Layer 4.
A Comparison: In a given time of 110 milliseconds, the ethernet can transmit 12.336 bits at 100mbps whereas CAN can transmit only 8 bytes of data.
Although I mentioned that this is the layer of MAC addresses and Switches, I will not go into details about these, so as not to digress.
<Connected physically, Connected Logically: Network Layer/>
We have the data, we formed it into an Ethernet frame, we added MAC src/dest addresses and other fields, and we want to fire it away. But how? How let’s say a distant machine will be within reach and all the path is going to be traversed? Do not forget, we know WHICH device it is, because we already know the MAC address, but we don't know WHERE this device is. For that end, we use an Internet Protocol(IP) address.
IP address, unlike a MAC address, is not physical and hardcoded into the interface but it is logical and volatile. So a packet on the third floor knows the IP address of the src/dest addresses. Just as floor 2 hosts switches, floor 3 hosts routers, which are the devices that connect the networks to each other. (switches build up the networks).
An IP header has interesting fields as well. Version number (since IP has 2 versions), Differentiated Services Code Point for traffic management, Explicit Congestion Notification for QoS purposes, Time To Live(TTL), and many more.
One quick bite-sized note is that unlike the name suggests, Time to Live is not a derivation of time. It is actually the decrementing hop number of a packet in the network. An IP packet, each time hits a router is decremented by one. This is required to ensure no looping in the network and redundancy is prevented. (We will talk about Spanning Tree Protocol (IEEE 802.1D) later on)
Take a look at this screenshot below :
The default TTL value for Windows OS is 128. So I can assume that my packet traveled 11 hops before reaching the destination. Also, I conclude that the server responding to my icmp.opcode==8 with icmp.opcode==0 is a Windows Machine.
IP is essentially lossy, non-trustable, stateless protocol. This means it does not keep a record of what has been happening around this particular packet. Also, it is not secure by itself. For this, we use other protocols and security countermeasures to ensure both state-keeping and confidentiality.
Internet Protocol hosts many useful technologies we use. Of them are IPSec(we will be covering it in-depth in the next post), ICMP(we just used with ping), IGMP, and NAT for subnetting.
But still, we have a problem that needs to be solved. I want a secure and stateful network. How Do I achieve this? To that end, we need to climb the stairs a bit more.
Let’s go to the transport layer.
<Love me tender, Never let me go: Transport Layer/>
So far we have managed to convert electronic signals to packets, added their both physical and logical addresses, and decorated them with lots of QoS options. Now they are ready to be sent over. With a small hunch. Okay, we know the physical address, but that address has many many rooms we can knock-on.
An IP address identifies a device, be it ECU or a NIC on a PC. Protocols on the transport layer, on the other hand, use Ports to identify software processes. When we combine the IP: Port, we have a socket at hand. Sockets uniquely id an internet connection between specific processes on two different IP addresses.
Transport Layer protocols are numerous. Newly emerging QUIC, IPSec Protocols AH, ESP, etc. But without a dispute, two first-class citizens of layer 4 are TCP and UDP.
I won’t go deeper into these 2 protocols since this is not a CCNA blogpost. But keep the following points in your mind since we will be using them in the next posts:
- TCP adds state to the stateless IP. This means it logs and preserves the connection state. It is connection-oriented, hence it can retransmit the segments that are dropper/ not acknowledged. It can see and control the connection based on the buffer it has and can propagate various options. It guarantees the segment order and turns ethernet into a reliable, connection-oriented stream. It is good for absolute delivery.
Let's compare a TCP segment and IP packet headers.
Check the screenshot. This is a basic SYN packet sent by the client to the server. SYN, as you know is the first step in the three-way-handshake.
Seeing is not like reading. Take your time to cross-analyze the two headers. As you can see, an IP packet does not have many options whereas when TCP sits on top of it, the whole picture changes. We will be talking about the security implications of this, later on, just try to wrap your head around the novelties TCP brings.
Next up is UDP.
- UDP by design is a fire-and-forget type of protocol. IT is lighter than TCP and unreliable by design. You generally use UDP for things that you do not track their states, say media streaming. It does not guarantee order or delivery. It is connectionless. UDP generally does not seek a special recipient, it is more generous than that for it is used in broadcasted or multicasted networks. It is good for timely delivery.
Let’s see a UDP segment dissected:
That simple.
For vehicle purposes, both TCP ( and TLS on top of it) and UDP(for DNS and DHCP) are extensively used. Also, both of the protocols are used (although UDP is much dominant protocol here) for Diagnostics over IP(DoIP) purposes.
Lots of attack vectors are more easily understood if the underlying technology is well studied as deserved. These possible attacks could span from SYN Flood Attacks, DNS Cache Poisoning Attacks, ARP spoofing attacks, and replay attacks to more complex ones.
I will be covering some of these attacks in a vehicle-specific context. But I believe we covered a good amount of knowledge pertaining to automotive ethernet at the main building blocks of it.
For vehicle purposes, the main players are the bottom 4 layers. Although we will be talking about application layer protection soon, I won’t be going through the next of the OSI model since there is not much need.
Here I am leaving the generic AUTOSAR network stack representation.
Until next time.
PS: If you haven’t already, please take a look at the other chapters: