4 ms·

Wouldnt it be possible to have the CAN chip only send data to the iot microprocessor? So not attaching the Tx but only Rx. As far as I understand CAN it is a bu

by rahkiin 10y ago

Wouldnt it be possible to have the CAN chip only send data to the iot microprocessor? So not attaching the Tx but only Rx. As far as I understand CAN it is a bus everything is dropped on, without an actual request-response system. Now everything from the car could be read but nothing can be controlled.

jasonkostempski 10y ago
This. One-way communication needs to make a comeback in a big way.
- paulmd 10y ago
  This is fundamentally impossible in a CAN bus, and is stupid and functionality-limiting anyway. Everyone likes it when the radio turns off when the ignition does, these systems need to be able to talk to each other to get the functionality you expect. What you need is to move away from the non-authenticated bus paradigm entirely, to a network-based system where some devices may be assumed to be hostile (which is what you have, like it or not). This inherently involves authentication and privilege systems, so that the pedal controllers can prove to the brake controllers who they are, so that when the radio/head unit tries to interface with the brake controllers the brake controllers can go "woah, hey, you're not supposed to be touching the brakes". This at least would require escalation from a trivial system like the head unit to a more crucial system, which is a more typical model for exploits in computer OSs. This is a workable threat model. "Trust everyone all the time" is no longer, and hasn't been since we allowed external connectivity to automobile systems.
yetihehe 10y ago
CAN is a request-response bus, you send a query, get ACK, then queried chip sends response. If you need to read something, you query for it. You can do queries like "start giving me rpm data every 1s", but you need to query for this, also ecu has limited resources for such queries, so you need to switch between different sets of data. Of course if something else requests such data you can listen for it too.
joezydeco 10y ago
Most designs have a CAN transceiver that takes TTL/UART and implements the differential signalling used on the CAN bus. I've used the TJA1048 before in designs: http://www.nxp.com/documents/data_sheet/TJA1048.pdf http://www.nxp.com/documents/data_sheet/TJA1048.pdf You could certainly clip the TX line and make it receive-only if you wanted. But there's always one person in the room that says "hey, why not leave it in in case we change our mind about software?", or perhaps it's more "hey, let's copy the reference design and move on".
tyingq 10y ago
Not possible, as you need the request/response model to get the interesting information. You send "010D" (mode one, PID 0D) to get the vehicle speed value. That's "read only", but you need to send data to get data. What does seem to be a hole is that the dongle exposes general CAN bus communications, as well as OBD-II commands/modes that are NOT read only. Here's a chart (from wikipedia) of the different OBD-II modes: http://imgur.com/a/YpGNU http://imgur.com/a/YpGNU It's fairly obvious which ones would be somewhat safe to expose. They would need to block the others in the dongle, and block general CAN bus access as well. I believe the high level problem is that the dongle exposes everything, and they are doing the parsing in software on your phone or laptop. Well, and auto makers not having a separate CAN bus for the OBD-II connector to talk to the ECU. I believe some vehicles do, and some don't.

by rahkiin 10y ago

jasonkostempski 10y ago

This. One-way communication needs to make a comeback in a big way.

paulmd 10y ago
This is fundamentally impossible in a CAN bus, and is stupid and functionality-limiting anyway. Everyone likes it when the radio turns off when the ignition does, these systems need to be able to talk to each other to get the functionality you expect. What you need is to move away from the non-authenticated bus paradigm entirely, to a network-based system where some devices may be assumed to be hostile (which is what you have, like it or not). This inherently involves authentication and privilege systems, so that the pedal controllers can prove to the brake controllers who they are, so that when the radio/head unit tries to interface with the brake controllers the brake controllers can go "woah, hey, you're not supposed to be touching the brakes". This at least would require escalation from a trivial system like the head unit to a more crucial system, which is a more typical model for exploits in computer OSs. This is a workable threat model. "Trust everyone all the time" is no longer, and hasn't been since we allowed external connectivity to automobile systems.

yetihehe 10y ago

CAN is a request-response bus, you send a query, get ACK, then queried chip sends response. If you need to read something, you query for it. You can do queries like "start giving me rpm data every 1s", but you need to query for this, also ecu has limited resources for such queries, so you need to switch between different sets of data. Of course if something else requests such data you can listen for it too.

joezydeco 10y ago

Most designs have a CAN transceiver that takes TTL/UART and implements the differential signalling used on the CAN bus. I've used the TJA1048 before in designs: http://www.nxp.com/documents/data_sheet/TJA1048.pdf http://www.nxp.com/documents/data_sheet/TJA1048.pdf You could certainly clip the TX line and make it receive-only if you wanted. But there's always one person in the room that says "hey, why not leave it in in case we change our mind about software?", or perhaps it's more "hey, let's copy the reference design and move on".

tyingq 10y ago

Not possible, as you need the request/response model to get the interesting information. You send "010D" (mode one, PID 0D) to get the vehicle speed value. That's "read only", but you need to send data to get data. What does seem to be a hole is that the dongle exposes general CAN bus communications, as well as OBD-II commands/modes that are NOT read only. Here's a chart (from wikipedia) of the different OBD-II modes: http://imgur.com/a/YpGNU http://imgur.com/a/YpGNU It's fairly obvious which ones would be somewhat safe to expose. They would need to block the others in the dongle, and block general CAN bus access as well. I believe the high level problem is that the dongle exposes everything, and they are doing the parsing in software on your phone or laptop. Well, and auto makers not having a separate CAN bus for the OBD-II connector to talk to the ECU. I believe some vehicles do, and some don't.