Things You Must Know For Vehicle Hacking: PART 3
IN-VEHICLE CYBERSECURITY SOLUTIONS: SECURITY IN-DEPTH(hopefully)
< Hold Your Horses! They Are Fortified! />
We learned so much from our previous mistakes or the genius of the attackers. Since we carried all the ethernet to the vehicle domain, all this know-how is also transferred along.
In this post, I will be talking about the main security countermeasures revolving around this precious network. But first things first, let's start with the silver rule:
Considering the OSI model, security applied on a specific layer secures both the layer itself and the layers above it.
This means roughly securing the Data-Link layer will not only protect the layer2 but also layer 3 and above.
Now let’s talk about the golden rule:
A security measure, at its best, should aim to cover all 3 legs of the CIA triad: Confidentiality, Integrity, and Availability (and bonus: replay protection).
Not: I will not deal with TLS here but TLS is also widely used in the ecosystem.
< MACSec />
There is a need to protect data that is transmitted over the in-vehicle ethernet that is connecting ECUs together. Data security protocols like MACSec are often deployed in Ethernet Local Area Networks(LAN) that support mission-critical applications.
MACSec pertaining to the IEEE 802.1AE standard prevents layer 2 security threats such as passive wiretapping, intrusion, Man-In-The-Middle, and replay attacks by offering line-rate encryption and protection of traffic passing over layer 1 and/or layer 2 links.
Although it is desirable, it is not practical to secure the entire network against physical access by determined attackers. MACSec allows only authorized systems that attach to and interconnect LANs in a network to maintain confidentiality and integrity of data and take measures against data theft.
Two sides are using MACSec, the transmit side that decorates the frame and the receive side that verifies and receives it.
Technically, on the transmit side of the link, MACSec adds ‘Mac Security Tag’ (SecTag, 8 to 16 bytes) and ‘Integrity Check Value’ (ICV, 8 to 16 bytes) to the packet and can optionally encrypt the packet. On the receive side of the link, the MACSec engine can identify and decrypt the packet, check integrity, provide ‘replay protection’, and remove SecTag and ICV. Invalid frames are discarded or monitored.
Beware that the general network structure always takes the invalid/malformed PDU into consideration. For a refresher, we had mentioned Cyclical Redundancy Check (CRC) on the IP header which does the same thing.
Where does MACSec fit within the OSI model?
On layer 1, there is the Automotive Ethernet Physical Layer (AEPL) which is the layer that connects the physical layer of the vehicle to the network. these are like 100baseT, 1000baseT etc.
On the next layer, which is Layer 2, there is IEEE Ethernet MAC+ VLAN(802.1Q) + AVB(802.1Qav) + TSN + MACSec. Hence, MACSec is a layer 2 protocol that is sitting on top of bare metal.
Since MACsec encrypts data on a hop-by-hop basis, it successfully protects against the hub, bridge, and injection-based attacks.
On layer 3, there is IPv4 and IPv6 which are protected by IPSec.
This is an encrypted ethernet frame shielded by MACSec. As can be seen, we have Security Tag, Integrity Check Value, and obfuscated protected data.
As for the possible MACSec use case within the ethernet network, if a hacker taps into the MACSec disabled network, the flowing data can be obtained by the hacker and can be used to perform attacks. Hackers can target switches, can tap into the network, or can monitor the device.
if MACSec is enabled, tapping or eavesdropping, or replay attacks are not possible since packets are numbered, and encrypted. However, hackers can disrupt the network using a DOS attack if DOS prevention is disabled. in this case, neither the hacker nor the vehicle can receive the packets. if DOS prevention is Enabled, the Video stream (i.e.) remains disturbed but DOS does not propagate through the Ethernet PHY. MACSec is cost-effective and could be used in combination with other technologies like IPsec, TLS, etc.
However, MACSec is not unbreakable. When weaker forms of EAP algorithm are used, MACSec is proven to be bypassable. Early on it was bypassed through packet injection attack, then it was patched, and now it is again bypassed using Bate n Switch Attack all because of vendor-preferred weaker protection. (human is the first layer of defense and offense)
If you want to read more on that, please follow the link.
< IPSec />
As IP is a layer 3 protocol, IPSec aptly operates in Layer 3. The main purpose of IPSec is to provide a secure tunnel between two computers in a public medium like the internet.
It can help mitigate malicious endeavors like eavesdropping, theft, and replay attacks. Also, it checks whether the data is corrupted on the way.
Basically, IPSec has 2 modes:
- In tunnel mode, everything is encapsulated in an IPsec datagram. when data is transmitted, the layer 3 devices only use the IPsec header to route the packet. This is used basically in the site-to-site VPN and remote access VPN.
- In transport mode, all of the data is protected but the original IP header is not. Payload is protected by IPsec. This is used generally in P2P applications.
Two IPSec protocols can use these two modes. These Protocols are:
- Authentication Header (AH): This protocol protects the IP addresses of the computers involved in data exchange to ensure that bits of data are not lost, changed, or damaged during transmission. AH also verifies that the person who sent the data actually sent it, protecting the tunnel from infiltration by unauthorized users.
- Encapsulating Security Payload (ESP): The ESP protocol provides the encryption part of the IPSec, which ensures the confidentiality of data traffic between devices. ESP encrypts the data packets/payload and authenticates the payload and its origin within the IPSec protocol suite. This protocol effectively scrambles internet traffic, so that anyone looking at the tunnel can’t see what’s there.
IPSec provides the following security services:
- Data encryption: The IPsec sender encrypts the packet before transmitting it through the network.
- Data integrity: The IPsec receiver authenticates the packet sent by the sender to ensure that the data has not been tampered with during transmission.
- Data source authentication: IPsec at the receiving end can authenticate whether the sending end of the IPsec message is legal.
- Anti-replay: The IPsec receiver can detect and refuse to receive outdated or duplicate messages.
IPSec mainly uses encryption and verification methods. The authentication mechanism enables the data receiver of IP communication to confirm the true identity of the data sender and whether the data has been tampered with during transmission. The encryption mechanism guarantees the confidentiality of the data by encrypting the data to prevent the data from being eavesdropped on during transmission. To provide security services for IP data packets.
The AH protocol provides data source authentication, data integrity verification, and anti-message replay functions. It can protect communications from tampering, but it cannot prevent eavesdropping. It is suitable for transmitting non-confidential data. The working principle of AH is to add an identity authentication message header to each data packet, which is inserted behind the standard IP header to provide integrity protection for the data.
The ESP protocol provides encryption, data source authentication, data integrity verification, and anti-message replay functions. The working principle of ESP is to add an ESP header to the standard IP header of each data packet and to append an ESP tail to the data packet. Common encryption algorithms are DES, 3DES, AES, etc.
In actual network communication, you can use these two protocols at the same time or choose to use one of them according to actual security requirements. Both AH and ESP can provide authentication services, but the authentication services provided by AH are stronger than those provided by ESP.
Without going much deeper into details, I have to give a brief introduction regarding the building blocks of the IPSec protocol. This will build the basis for the part where we will see how to possibly exploit it.
< IPSec building Blocks />
The first building block is security protocols which are ESP and AH which add the headers that can be seen above.
After the headers, the second one is Security Association (SA).
Security Association in the IPsec suite is a unidirectional connection that gives devices the capability to use AH or ESP services. for bidirectional communications, a pair of SA is needed.
For SA to be established, the following steps are needed:
- SPI: Security Parameter Index. It is a unique number that is used to identify the SA.
- Security Protocol Identifier: It is a number that identifies the protocol that is used in the SA. (50 for AH or 51 for ESP)
- Destination IP Address
For the third block, key management is either done manually or automated using IKEv1 or IKEv2. IKE (Internet Key Exchange) is a protocol that is used to establish key management between two computers. The default one is IKEv2 since IKEv1 is officially deprecated.
Fourth and last building block is Crypto Algorithm. These are used for Encryption, Authentication, Integrity, and Pseudorandom Number Generation.
For SA establishment, there are a couple of different protocols that are used.
- ISAKMP (Internet Security Association Key Management Protocol): Used for procedures and formats to establish SA. It helps us build the SA.
- OAKLEY (One-Way Authentication Key Exchange Protocol): gives key-exchange mechanism. Used to exchange keys over an insecure connection using Diffie-Hellman.
- SKEME (Security Key Exchange Method): gives anonymity and reputability through key-exchange techniques.
- IKE (Internet Key Exchange): Uses a combination of ISAKMP, OAKLEY, and SKEME
<IPSec Mechanism />
For authentication, IKEv2 uses ‘ Pre-Shared Key’ (PSK) and `Certificate Authentication`. Apart from that uses EAP.
Compared to IKEv1, wants exact parameters must be agreed upon and only one set per SA, IKEv2 allows multiple sets within each SA and works in 2 consecutive modes:
- IKE_SA_INIT(phase 1) :
- 6 different proposals are sent.
- proposals containing algorithms, SA parameters, and keying material are sent to confirm available functionality.
- first 2 packets on Wireshark(1–2).
This phase is responsible for establishing ISAKMP SA for the parent SAs. These are used to securely transmit the information to build the child SA.(IPsec SA)
- IKE_AUTH(phase 2) :
- IPsec Sa’s are established.
- creation of first child SA.
- Authenticate and validate the pairs.
- Next 2 Packets on Wireshark(3–4).
This phase is responsible for establishing IPsec SAs which are child SAs. After the 4th packet, all set to go.
Let’s dissect an IPSec packet and see what is inside:
<Exploiting IPSec />
As can be seen, the first 2 packets propagate each other their SPI values, in cleartext. Also, packet 2 has a ‘message ID’ which is used for identifying the packet and following the request. Message-ID can be also used to detect and fight against replay attacks.
Since ISAKMP and NAT do not work very well together, we can check the NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP fields in the payloads option. These two packets will send and compare these values, if they are different, then it means that there is a NAT.
As for the last 2 packets, if the Identity is not correctly set in the VPN, the traffic can be decrypted and fully qualified traffic notation can be seen. This information can be found in the `IKE_AUTH` packets that had to be encrypted!
To decrypt the IKEv2 packets, we need the cleartext initiator and the responder SPI values from the second packet that I just showed above.
The second way to get it if we could not capture these packets is to get encryption keys that are only visible during IKE SA creation. A software called strongswan can be used to get these keys.
this is only possible if one of the ends of the VPN logs them. adding them to Wireshark will enable Wireshark to show the plaintext traffic.
After these 2 phases are completed, Wireshark will show the rest of the traffic as ESP.
Real data is carried in the ESP packets. So breaking through it will yield the result we want to achieve.
To break through the ESP shield, we need SPIs from both endpoints, which we saw above, we need encryption and authentication algorithms which are also sent in cleartext, and also IKE SA encryption and authentication keys. These last ones are not visible in the packet so we need to get them using good old strongswan. This is the most difficult phase.
< SecOC />
As mentioned earlier, although there is also TLS in the list, I will skip it for now and will focus on a more vehicle-specific security implementation.
SecOC ( Secure Onboard Communication), is an AUTOSAR specified module that is responsible for generating and verifying secure messages passed between ECUs over the in-vehicle communication network( AUTOSAR is a worldwide partnership of defines standards for software architecture).
In the OSI Model, it operates above the transport layer, which is why it is mainly independent of the underlying network protocols. Besides TCP, for example, it can also be used with the UDP transport protocol, which is most commonly used in vehicles.
SecOC is not limited to working with ethernet-oriented technologies unlike MacSec, IPSec, and TLS. It is also compatible with Canbus and FlexRay for example and adds integrity and authenticity to the communication by being attached to the outgoing message. Beware, there is no confidentiality mentioned!
In-vehicle communication vulnerabilities can be prevented(OK prevented is a big word, but can be deterred maybe?) by using SecOC in the communication network. SecOC adds security to the outgoing message to achieve integrity and authenticity of the message. It is specified to check the authenticity of a single transmitted PDU (Protocol Data Unit) in order to detect attacks such as replay attacks, message tampering, and denial of service attacks. With SecOC implementation enabled, the attacker must know the sender’s secret key in order to spoof a message.
How does it operate?
On the sender ECU, the SecOC module is sitting between PDURouter, CryptoService Manager, and the counter.
1- PDU Router receives a PDU from an upper layer.
2- passes the message to SecOC module to add authentication
3- SecOC obtains Freshness Value from the counter.
4- SECOC then generates an authenticator using services from CryptoService Manager. This authenticator is freshness value + secret key using the secret key
5- SecOC then attaches the freshness value and authenticator to the PDU Frame and returns it to the PDU router. 6- PDU router then passes it to the destination interface.
On the receiver ECU:
1- PDU router receives a secured PDU with authentication added from the network interface.
2- This frame is sent to the SecOC module for authentication
3- SecOC module strips the authenticator and freshness value from the secure frame and the freshness value is compared with the current counter value in the counter module.
4- If the received frame is not a fresh one then it is considered a replay attack and discarded.
5- Through CSM, a new authenticator is generated using the secret key and freshness value for comparison with the received authenticator value. since the freshness value and secret key are the same, the keys are expected to be the same.
6- If auth is successful, then PDU is sent back to PDUR for further processing.
CAN bus has the limitation. Classical CAN frames provide a payload size of only 8 bytes. The PDU along with freshness value and authenticator cannot be supported in one frame. This leaves 2 options:
- Truncate these fields to shorten the length.
- Send authenticator in another frame. (available in Autosar) Between the two, the tradeoff are the security level and impact on busload.
However, Networks like CAN FD, Flexray, and Ethernet do not have payload limits.
So, we can roughly visualize the general defense-in-depth implementation as the following illustration shows:
In the next post, I will be talking about general security architecture and in-vehicle IDS/IPS systems.
Until next time...
PS: If you haven’t already, please take a look at the other chapters: