Ingenext Boost Modules [aftermarket]

[Mash]

The only way for them aka any manufacturer to stop modules like this is to encrypt the canbus. That horse left the barn years ago. It was flagged as an issue back in the 90s by security researchers who concluded it was virtually impossible due to a few factors. One being the. Speed of the bus and the. Amount of horsepower needed to encrypt and decrypt on the fly for each piece on the bus. And it’s only gotten worse with what they do now on the internal car networks. Automotive security just sucks

This is not true.
1. Encrypted data takes same bandwidth.
2. All modules already encrypting and decrypting software updates and validating digital signature, so they can use lightweight encryption if they want and securely exchange symmetric key updates on a regular basis.

It's just a matter of priorities and with that it's also going to cripple data logging.

 

[SteelClouds]

From a security report in 2021 - security of can bus is crap to put it bluntly.

3. Vulnerability Assessment of the CAN Protocol​

It is essential to have a vulnerability assessment of a network to highlight security problems. Therefore, the vulnerability assessment of the CAN protocol can be carried out based on confidentiality, integrity, and availability.

Confidentiality means providing the data only to authorised people. However, the CAN protocol does not have inherent cryptographic methods to ensure confidentiality. This allows an intruder to access sensitive user data and cause an invasion of privacy.

Integrity is the accuracy, completeness, and validity of the data. The CAN bus has a CRC for verification of integrity against the transmission errors, but it cannot prevent data injected by malicious parties, which breaks the integrity. The protocol does not have a comprehensive integrity check and fails to sustain integrity.

Availability means that authorised users can use the system at all times. Given the nature of priority-based messaging, if a message with the highest priority is transmitted/inserted, the network will be inaccessible by the lower priority nodes, and availability is violated.

The CAN bus failed to pass all three essential security criteria. Thus, it is a clear indication that the CAN protocol does not have any security measurements against the attacks
Summary of the Controlled Area Network (CAN) bus attacks.

Reference​	DoS​	Modification 1​	Access Type​	Notes/Root Cause​
[11]​	Y​	N​	OBD II​	Does not require full CAN messages​
[20]​	N​	Y​	OBD II, CD, Bluetooth, GSM​	Systematical experimental attacks. Indirect access via the car service computer​
[21]​	N​	Y​	In-direct OBD II​	Attack via a smartphone app​
[22]​	Y​	Y​	Multiple remote sources​	Remote attack analysis of 21 commercial cars​
[13]​	N​	Y​	Wi-Fi, GSM​	Access CAN network via a browser exploit​
[16]​	Y​	N​	OBD II, compromised ECU​	SAE J1939 data-link layer exploits​
[23]​	N​	Y​	Wi-Fi, GSM​	Ransomware attack over the air​
[24]​	N​	Y​	TPMS​	Remotely sending false TPMS data​

And to what we were discussing about encryption
Methods to secure the CAN bus.

Proposed Method​	Benefits​	Disadvantages​
Network Segmentation​	Limit access to the end-user​	Increased cost, Difficulty in maintenance​
Encryption​	Hardened attacks, Confidential data transmission​	Increased computational power, Increased traffic, Weak encryption due to frame size​
Authentication​	Secure data transmission​	Increased computational power, Increased traffic​
Intrusion Detection​	Detect anomalies and attacks​	Complicated algorithm design, Cannot guarantee the security​

Source: Evaluation of CAN Bus Security Challenges.

 

[SteelClouds]

I forgot to add the first conclusion

7. Conclusions​

The CAN protocol facilitating ECUs in modern vehicles is not geared up and well-protected against the complex and evolving nature of cyberattacks. The existing security features incorporated in vehicles are not fit and adequate to resist and defy them. This is attributable to the lack of encryption and authentication mechanisms, which provide multiple opportunities for several types of attacks to materialize and as a result, jeopardize the individual data privacy and the safety of the vehicle occupants. These blemish the manufacturers’ reputation and downgrade vehicle reliability, followed by substantial financial losses.

 

[Knightshade]

The only way for them aka any manufacturer to stop modules like this is to encrypt the canbus. That horse left the barn years ago. It was flagged as an issue back in the 90s by security researchers who concluded it was virtually impossible due to a few factors. One being the. Speed of the bus and the. Amount of horsepower needed to encrypt and decrypt on the fly for each piece on the bus. And it’s only gotten worse with what they do now on the internal car networks. Automotive security just sucks

There's a much easier way to "stop" such a module.

Since they can easily detect it, if they do, they throw the car into limp mode with a message saying improper signals detected, please bring your vehicle in for service.

They haven't done this- but there's no technical reason they couldn't trivially do so.

(the legality of doing it will be YMMV by jurisdiction of course)

 

[SteelClouds]

Since they can easily detect it, if they do, they throw the car into limp mode with a message saying improper signals detected, please bring your vehicle in for service.

I've seen that done with some "tuner" modules.. normally when they are screwing around with the boost levels

 

[Mash]

I forgot to add the first conclusion

7. Conclusions​

The CAN protocol facilitating ECUs in modern vehicles is not geared up and well-protected against the complex and evolving nature of cyberattacks. The existing security features incorporated in vehicles are not fit and adequate to resist and defy them. This is attributable to the lack of encryption and authentication mechanisms, which provide multiple opportunities for several types of attacks to materialize and as a result, jeopardize the individual data privacy and the safety of the vehicle occupants. These blemish the manufacturers’ reputation and downgrade vehicle reliability, followed by substantial financial losses.

None of that is about Tesla.

They can change protocol to whatever they want just with an update. They have software implementation of CAN over serial bus. And they have encrypted and signed Ethernet connection for all the heavy duty stuff.

 

[SteelClouds]

I think a lot of it applies to Tesla. This was from a security thesis paper about how to hack Tesla M3 specifically and ID various attack vectors.

Virtually all chassis, body, motor and charging communication is via a can connection. Ethernet is used for Autopilot ( makes sense given the amount of data) along with external connections ( think over the air updates and such things) and cameras.

Interesting quote in the document "Car uses 3 main separated CAN networks connected via security gateway. These networks are used for parts that control driving and safety of the car."

2nd most interesting quote "CAN network does not encrypt communication by design 3.1.4. Connecting to this network means that attacker can see all traffic. He can also send messages to the network if he wants"

3rd interesting point - "Traffic on BroadR-Reach network is without any protection. Communication on this network is exposed similarly as traffic on older CAN bus network. Despite better technology no encryption is used on local network. To exploit this vulnerability dissembling of the dashboard and dedicated hardware is needed but its potential is still huge."

No encryption on the ethernet was found.. however, you do need to pretty much take the car apart to get to it.. I bet someone did a risk based assessment and decide that if someone was taking the car apart to access the ethernet, there were much bigger issues at play.

My point to all of this is the can protocol is insecure and not easily fixed. It was never designed to be a secure protocol and it was never designed or intended to be used the way it is being used today. Like a good many things. The plus side is we get cool things like Ghost adapters and Bonus adapters ( I use that myself)

I will also admit this paper is somewhat dated.. ie.. 2017. But, I have yet to find anything that says much has changed.

 

[Knightshade]

But again- nothing NEEDS to change. If Tesla wants to cripple the car upon detecting the thing, it can. And it's easily detected.

Further while there was no encryption in 2017 for the ethernet portion, that was as you say quite dated info (and multiple HW upgrades ago so there's much more power in both the driving and media computers in new cars today)- and they do run (at least some) encryption now and for the last couple years.

https://twitter.com/x/status/1280475999973650433

 

[Mash]

I think a lot of it applies to Tesla. This was from a security thesis paper about how to hack Tesla M3 specifically and ID various attack vectors.

Virtually all chassis, body, motor and charging communication is via a can connection. Ethernet is used for Autopilot ( makes sense given the amount of data) along with external connections ( think over the air updates and such things) and cameras.

Interesting quote in the document "Car uses 3 main separated CAN networks connected via security gateway. These networks are used for parts that control driving and safety of the car."

2nd most interesting quote "CAN network does not encrypt communication by design 3.1.4. Connecting to this network means that attacker can see all traffic. He can also send messages to the network if he wants"

3rd interesting point - "Traffic on BroadR-Reach network is without any protection. Communication on this network is exposed similarly as traffic on older CAN bus network. Despite better technology no encryption is used on local network. To exploit this vulnerability dissembling of the dashboard and dedicated hardware is needed but its potential is still huge."

No encryption on the ethernet was found.. however, you do need to pretty much take the car apart to get to it.. I bet someone did a risk based assessment and decide that if someone was taking the car apart to access the ethernet, there were much bigger issues at play.

My point to all of this is the can protocol is insecure and not easily fixed. It was never designed to be a secure protocol and it was never designed or intended to be used the way it is being used today. Like a good many things. The plus side is we get cool things like Ghost adapters and Bonus adapters ( I use that myself)

I will also admit this paper is somewhat dated.. ie.. 2017. But, I have yet to find anything that says much has changed.

View attachment 846067

CAN protocol doesn't have encryption defined, but Tesla can move to any proprietary protocol they want. They don't use as I know any 3rd party CAN devices or HW CAN bus MCU. Also, I want to correct my statement - they had encrypted and signed payload over Ethernet, doesn't mean they used Ethernet itself encrypted.

 

[ph0ton]

AFAIK it would be impossible to change to an arbitrary protocol. The very nature of signals over CAN is voltage pulses so the circuitry would need to be overhauled to send and receive other signals. I don't think the modules are running FPGAs in the CAN bus so they are stuck with the same signaling basis as vanilla CAN.

That being said, due to the broadcast nature of the signals, there is no really good way to hide a module putting out non-factory commands. I agree with the person who commented earlier that Tesla could easily detect the module and disable the car accordingly.

I'm not sure if there is enough spare compute to effectively detect *any* module but it seems plausible to me to at least cross-check the ID on the network against a blacklist.

 

[Knightshade]

I'm not sure if there is enough spare compute to effectively detect *any* module but it seems plausible to me to at least cross-check the ID on the network against a blacklist.

You don't even need to do that for something like the boost hack.

The car knows how quickly it accelerated. if it ever exceeds a value the config back on Teslas servers say it should be capable of, there's a 3rd party hack present.

 

[Mash]

AFAIK it would be impossible to change to an arbitrary protocol. The very nature of signals over CAN is voltage pulses so the circuitry would need to be overhauled to send and receive other signals. I don't think the modules are running FPGAs in the CAN bus so they are stuck with the same signaling basis as vanilla CAN.

That being said, due to the broadcast nature of the signals, there is no really good way to hide a module putting out non-factory commands. I agree with the person who commented earlier that Tesla could easily detect the module and disable the car accordingly.

I'm not sure if there is enough spare compute to effectively detect *any* module but it seems plausible to me to at least cross-check the ID on the network against a blacklist.

CAN bus is serial multiplex message protocol. While keeping the same connection speed and basic principles you can encrypt the message itself. That doesn't require any FPGA or hardware change to work. The assumption that it's impossible to implement encryption is baseless wishful thinking.

 

[ph0ton]

CAN bus is serial multiplex message protocol. While keeping the same connection speed and basic principles you can encrypt the message itself. That doesn't require any FPGA or hardware change to work. The assumption that it's impossible to implement encryption is baseless wishful thinking.

That's not changing the protocol, that's just encapsulating the data field of a frame.

The issue is that with 64 bytes to work with and a lot of bandwidth already being used, implementing encryption is difficult (module processing power notwithstanding) on the CAN bus. If it were true that the protocol itself could be changed, then indeed it would be possible to encrypt traffic arbitrarily, but as I argued it is not possible to do that either.

I agree that it's not impossible to set up encryption but there are a lot of good arguments it isn't possible with the resources in the current hardware.

 

[MentalNomad]

That's not changing the protocol, that's just encapsulating the data field of a frame.

The issue is that with 64 bytes to work with and a lot of bandwidth already being used, implementing encryption is difficult (module processing power notwithstanding) on the CAN bus. If it were true that the protocol itself could be changed, then indeed it would be possible to encrypt traffic arbitrarily, but as I argued it is not possible to do that either.

I agree that it's not impossible to set up encryption but there are a lot of good arguments it isn't possible with the resources in the current hardware.

 

[MentalNomad]

It's worth remembering that you can't just turn on encryption on the bus - everything attached to the bus needs to be able to process it.

The main computer can easily add encryption, but not so much the window motor controller, for example. Many small items on the bus are not made with microprocessors that can handle encryption, assuming they're capable of being reprogrammed over the CAN bus, in the first place.

Adding encryption would likely be a rip-and-replace activity.

But, like the previous posts said, the stbus that matters isn't easily accessible without ripping open the dash. The easy-access bus in the shouldn't access critical stuff.

 

[SteelClouds]

It's worth remembering that you can't just turn on encryption on the bus - everything attached to the bus needs to be able to process it.

And.. the best part... you break all diagnostics and the ability to monitor anything unless you have the magic key :/ Which poses a problem when you have a few million cars. Its virtually impossible to have a unique key for each car and managing even a few keys can be problematic. So you are left with a common key which renders the entire thing moot.

 

[Bizzwhizz]

Anyone here with an Ingenext module (mine is Boost SR) and the 2022.20.8 update *missing* the seat belt pretensioner update feature…? Or does anyone with the module have this feature showing as expected? Trying to work out why it’s not showing.

Hope Tesla haven’t not deployed it to cars with non standard acceleration or something because the feature doesn’t work correctly with them…

Edit - I do indeed have HW3. Hope there’s some others out there with this feature in 20.8 meaning it is not because of the module!

 

[MP3Mike]

Anyone here with an Ingenext module and the 2022.20.8 update *missing* the seat belt pretensioner update feature…? Or does anyone with the module have this feature showing as expected? Trying to work out why it’s not showing.

What AP computer do you have? HW2.5 or HW3/FSD? (That feature requires the HW3/FSD computer.)

 

[Bizzwhizz]

What AP computer do you have? HW2.5 or HW3/FSD? (That feature requires the HW3/FSD computer.)

HW3. It is meant for all cars with HW3 according to Elon.

 

[MP3Mike]

HW3. It is meant for all cars with HW3 according to Elon.

I wonder if it is only available in the US at this point. (Does that change require regulatory approval?)