That’s not what’s happening. The value in a CAN bus control is that you can significantly reduce the wiring requirements.

Old school blinkers and headlights would require separate power wires for every function: Blinker, low beams, high beams. Those separate wires would each be snaked through long wiring harnesses back to relays somewhere else in a central location.

With CAN, you can run a single large gauge power and ground pair and use the CAN bus to tell the remote module what to do with tiny signal wires. It may not sound like a big deal, but cars have a lot of electronic pieces all over. Simplifying wiring can add up to a significant weight and cost reduction. You now also have the ability to add more monitoring, such as simple sensors to detect when a bulb has failed

Vehicle manufacturing is ruthlessly optimized. Vehicle manufacturers wouldn’t add complexity to common systems if it didn’t pay off.

You make it sound as though this intended to be a benefit to the consumer or the end product. Having worked on and around cars, and being friends with people who do for a living, I am really unconvinced that the manufacturers do a lot of this for any consumer-friendly reason, rather than simply trying to squeeze a buck out of you.

I can absolutely tell you that Volvo, for example, does what the GP is talking about, and then some. On an old school GM or Toyota, if you break a simple switch or knob, or things that really should just be simple devices, you can just pull it out, go to the junkyard or a parts retailer, and put the new one in and be on your way. Not so for Volvo (and I'm sure this has caught on in other manufacturers): if your switch or control or whatever fails, and its hooked up to the CAN-bus, whatever replacement you find simply won't work until you've gone to the dealership (if they even let you use a part that didn't come from there at all) and gotten them to flash the part and whatever other crap needs flashing like a BCM to get them to be compatible (I think just flashing the serial number of a BCM or whatever it needs to play nice with to the switch), at the tune of a couple hundred or more dollars each time.

So in essence, a stupid simple part, that should have been $5-10 that the manufacturer likely never would have seen a dollar from in the aftermarket, is now a $200+ dollar flash at the dealership, using the manufacturer scan tool, and also increasingly requires only parts the manufacturer can generate. So no, I really am extremely skeptical, given what occurs *today* that 95+% of the junk on CAN bus is there for any reason other than to boost dealership and manufacturer profits for no other reason than the fact they can.

It's like putting everything over IP (VoIP, video over IP, audio over IP, etc.) and then just running Ethernet throughout your building. From an engineering perspective, it's just way easier. Routing wires -- on a circuit board, in a building, in a car, in anything -- is just a real PITA.

Now it's definitely true that having to flash something on the CAN bus to make it work is possibly due to greed, but the original idea of putting things on one bus is not.

The "consumer friendly" part is competing on price; they don't care about repair cost, in fact parts for repair is just recurring revenue on top on (till before pandemic) slim margins on selling the car

Isn't that what's supposed to happen in capitalism? Everyone working is getting paid, supply matching demand, prices reducing and ostensibly zero profit for established sectors.

It's often the case that consumers will seek out the lowest price no matter how high the cost.

I bought a $20 OBD2/J2534 cable, downloaded an easily-available ["pirated"] copy of Honda HDS, and seemingly had access to all the functionality a dealer would have. From looking at the Honda website, I could have paid by the day/week/etc for official access to flashing tools or the newer iHDS, which I might have needed for a newer car.

If I had wanted to reflash any of the modules, I probably would have wanted a better cable (though it's hard to know if module manufacturers really have such shoddy update processes that interrupting the flashing can really brick a device, or if that's just persistent superstition like so much in the car world). But I was able to replace the VSA/ABS module and perform the necessary "dealer reset" procedures no problem. I just wish I had obtained this setup before I went about misdiagnosing the problem based on a document that claimed to be the OEM service manual but actually wasn't. Luckily the part I misdiagnosed did end up being the problem!

Of course, I would love for there to be some sort of mandate for manufacturers to document the details of all CAN messages. Because there don't seem to be that many different module manufacturers, they must all be working to some kind of internal standards for their own interchange, and end-user visibility into computing systems is critically necessary for preventing computational disenfranchisement where people see these systems as impenetrable black boxes. But it feels at least in Honda land, much of that capability is practically available to the repair market (at least as of 2015 model years). One just needs to get over the activation energy of setting up the OEM software tool.

I'm working on Right to Repair and we get asked for examples like this from various government agencies all the time. It would be very helpful, thanks!

If you're looking for something a little more formal, I think the factory service manual probably calls out that the R&R on a ton of parts will involve reprogramming. I no longer own any post-Ford Volvos nor do I have any interest in European cars, so unfortunately I don't have any newer FSMs. A way you might be able to get at one on the cheap is to pick a popular model/year later Volvo (maybe like a 2016+ XC60?), and get a subscription to the make/model/year on Alldata (which was something like $20 a year for just a single combination), or hunt for an FSM on eBay, if it's old enough to still have a paper FSM.

Their profit margins will come from somewhere. If not from savings then from higher pricing.

There's no way I would ever recommend someone who wanted to keep their car past the first 50 or so thousand miles ever buy a VW or a VW with slightly shinier wallpaper (Audi). There's a reason the service techs on those and BMWs get paid well, and why they're often hated by mechanics.

they can be expensive, but you can buy them. you may need to visit a dealer to buy them, but you can buy them.

right-to-repair exists for consumer automobiles.

there are no "right to secure CAN buses" laws, unfortunately.

Say I only need to replace a $5 switch as the parent poster suggests. My options then are pay $200 to the dealership to flash and install it (if they'll even flash a third party part) one time, or I can pay thousands of dollars for a tool I'll use once and do it myself.

That isn't a real choice, and the auto makers are adhering to the letter of the law but not the spirit of the law. Which is legal for them to do, but it doesn't make it any less scummy.

There's a reason they're called stealerships - and the service department is where all the profit is. (Well, that and used cars).

Chrysler (and probably Stellantis so Jeep, Dodge, Fiat, RAM, etc) charges $35 per VIN per year. https://kb.fcawitech.com/article/vehicle-reprogramming-subsc...

Ford I believe now requires a subscription for diagnostics but I haven't seen anything about per VIN charges yet. I'm not sure about the British or Japanese brands either. This is AFAIK regardless of dealership or independent shop.

The problem is as I always point, that people want complexity and technology for everyday but as soon as something breaks they want it to be like 1990.

The article complains about CAN bus not being secure but this sort of attack is very rare, you need special tools, skills, physical access to the network and time. Regular car thieves don’t go and make a key to steal a car, that would be the same as a 1980’s one breaking a window and start trying to decode the cylinder and then cutting a key! How does a towing company get your car in 10 seconds? That’s how they’re stolen most of the time.

the automotive parts industry is massive and if you allow third party parts manufacturers to make parts for your car, you are undercutting your own parts replacement business. how do you counter that? you require that replacement parts come from you. the only way to do that is via electronic means, because anything purely mechanical can (and is) reverse engineered quickly.

insurance companies fight against this in court because 3rd party parts are much cheaper than official parts, and usually come with an associated dip in quality as well, which is another reason auto makers fight for first-party parts businesses.

Honda doesn't want Snake Oil Autoparts stuff installed on cars which are still under warranty after a collision, for example, but the insurance company paying for those repairs definitely does.

They lost the right to require things to do with thr car the y sold the car.

Electronic lockouts will be cobsidered theft one day

not if you want a warranty or any manufacturer support on the vehicle at all, and these are things that consumers value a lot.

> Electronic lockouts will be [considered] theft one day

among the most feverish people, they are considered a problem worth fighting, which I agree with, and I don't think it will ever be considered theft. the law just doesn't support electronic lockouts as theft, and precedent on this would be very difficult to undo without changes to laws defining what ownership actually is.

(Genuinely curious; I had no idea such laws existed for cars.)

And only for regular cars, there is no right to repair for commercial vehicles: https://en.wikipedia.org/wiki/Motor_Vehicle_Owners%27_Right_...

There are also long-standing legal requirements for automakers to be separate from car dealers, which also translate into making the repair/diagnostics equipment available.

One huge problem is that they put the smart key on the same bus as other stuff (headlights, body control) to save money/wiring.

These kinds of busses should be buried far inside the dashboard or some other hard-to-reach area.

I know this stuff "pays off" for the manufacturers, but I really wish they'd avoid including unnecessary complexity such as those horrific touch screens, call connections, etc. That sort of thing is why I won't buy newer cars.

Yet car manufacturers don't do this. CAN transceivers are still too expensive to build into every bulb. Instead, a single CAN transceiver and microcontroller will control a whole set of nearby bulbs (eg. brake, indicator, reversing lights). That then makes it vehicle specific, so you don't get the economies of scale of just making a single model of can-bulb which fits lots of places in many cars from many manufacturers.

No, that's not obvious at all.

Separating the control board and the bulb is obvious. You wouldn't want to replace your entire control circuit every time you need to replace a bulb, would you? You don't want to have to reprogram your ECU to know which bulb serial number corresponds to your front headlight because all of your bulbs are the same.

Moreover, this is impossible because there isn't a single bulb model that goes into a car. High beams, low beams, blinkers, and interior lights are all different. They also differ from model to model depending on the requirements.

> That then makes it vehicle specific, so you don't get the economies of scale of just making a single model of can-bulb which fits lots of places in many cars from many manufacturers.

Car companies make millions or tens of millions of cars per year.

When you're making 10s of millions of something every year (or 2X that for parts that come in pairs, like headlights), you already have economies of scale.

Automotive equipment manufacturers will also share components between car companies, and further upstream you have companies that make chips for auto makers who share chips across the companies.

Automotive manufacturing is a great example of economies of scale. It's not correct to say that auto manufacturers aren't leveraging economies of scale while producing 10s of millions of common parts per year.

(I'm not sure though - it might be some headlight controller fails non incandescent bulbs)

In the factory, you fit the bulbs in a certain order every time, and the computer knows that order.

I’m guessing you’ve never worked in customer support. The failure modes of mistakes would be nasty. Even smart people swap bulbs around when diagnosing faults.

Simplicity (good usability) is most always crushingly hard to achieve, doubly so for hardware.

Calling things “simple” is often a sign of shallow thinking in my experience - something a customer or manager might naively say but an engineer cannot (because they have to deal with all of the real requirements).

For example, the engineers that build cars can’t say “you simply push a button to start a car” - as an engineer the complexity behind that simple operation is very very deep.

Just imagining the customer support for this is gonna give me nightmares.

“Sir, you need to make sure your vehicle’s ignition is turned to accessory mode. Then wait for the light to blink twice, that’s the vehicle’s confirmation that it correctly identified the new light. If it blinks three times, it can’t confirm the light’s location, so you should try removing it and re-inserting it. If it blinks four times, that means you didn’t replace the bulbs in the correct order so you need to initiate a manual reset procedure by going to the driver’s seat and…”

It's really not a sustainable approach to try to address nodes on a CAN bus by serial number, though. CAN is content addressed rather than receiver addressed. Due to the way arbitration works on the bus, it's invalid for two nodes to transmit to the same CAN identifier. The arbitration mechanism breaks down and results in error frames, at which point the CAN bus is in a degraded state.

That would preclude a CAN enabled bulb from being able to send telemetry back, at least until the bulb was provisioned an identifier. That could be done by an ECU sending a frame with the bulb's serial number and assigned identifier. You still need a zero-conf discovery protocol, though, and so you're back to transmitting before provisioning. You could work around all that, but it's a lot of work.

Stepping back a bit, running a car's CAN bus over a light bulb socket is going to cause some practical reliability problems. Compared to a wire harness going into an ECU, a user serviceable bulb socket is going to be much more prone to intermittent connections from vibration, as well as oxidation and wear. Intermittent connections on CAN_H/CAN_L tend to cause a ton of frame errors, and significantly degrade the overall bus performance often to the point of system failure. When a node encounters enough error frames, it is compelled by the standard to go into a BUS-OFF state where it isolates itself from the bus. Because it's a bus and all the nodes share the same two wires, it's pretty much impossible to diagnose where an intermittent connection is without trial and error.

Ie, with CAN, each node only needs to do reg reads/writes/datasheet-spelunking for a narrow part; the other nodes just need to know the API that sits on top of the hardware.

There's rules of thumb about never overloading a CAN bus beyond, say, 50% utilization. That's because systems with poor prioritization management tend to start falling over around there. With a well thought out scheme, it's possible to push a CAN bus fairly close to 100% utilization. I built several safety critical systems that pushed 80% utilization on average. At that level, you really need to rely on redundancy rather than simple robustness, though. A CAN bus running at 80% falls over very hard when you have a flaky physical connection somewhere.

See for example https://github.com/commaai/opendbc

Quite old and for Wundows, but a lot of code showing how to use a lot of CAN interface boxes is at https://github.com/rbei-etas/busmaster/tree/master/Sources/B...

That sounds like a good thing to me.

Maybe, but given the explosion of weight and cost of new vehicles, it's unclear where these savings went.

I'm adding a CAN bus to my 3d printer for this exact reason.

Without speaking specifically to Ford’s plans, authenticated CAN communications are absolutely coming. I don’t see many approaches that actually encrypt the data on the bus - instead a MAC is used for each frame with a shared key on both secure ECUs, and some protections against replay attacks and such.

I wouldn’t expect all CAN data to be protected by this kind of security - it’s a pain in the butt, and expensive. Instead, certain specific sensitive information (like whether there’s a key in the ignition!) is protected as needed.

The industry is also moving toward IP-based communications for a lot of vehicle networking, which comes with many of the benefits of the modern infosec world. Automotive has a lot of unique challenges, though - like another poster mentioned, key provisioning and management is a huge pain; latency and hard timing constraints are way more important in the onboard/embedded world; many automotive ICs have limited support for e.g., asymmetric encryption, and of course there’s a lot of pain generated from the way the industry does software development generally. It’s an interesting space.

No they won't. One the law requires them to allow third part diagnostics tool (only for things that are about emissions!). Two, the third party tool maters are paying a good chunk of money to get documentation on how to do diagnostics.

While new car buys won't care, car makers know that nobody can afford to buy a new car except by selling their old car (normally done as a trade in), and the buyers of used cars care that the car can be fixed so if third party tools don't work the car has a lot less value.

Without the key to see what the code is, no injector can spoof the frame.

With the after-market procedure making tons of noise and spectacle, and a nice long wait for the police to arrive, the thieves can't replace the key ECU.

With the system being simple, no key provisioning is needed, no non-public information, just an extra page in the manual and a software update.

I can see how they got there. When you're moving getting rid of miles of cables that link everything and move your car to a CAN bus instead, it makes sense to say that you don't want a central blinker-controller that runs separate wires to every blinker. Instead you just run CAN and power to each blinker and give them their own little controller. Fewer wires, less conceptual complexity, at the cost of putting a little PCB in each blinker.

But because "analog" blinkers had the accidental feature that they blink faster if one blinker is broken, you have to replicate that somehow with your new blinkers. And the easiest way to do that is to have the blinker write that to the CAN bus, since it's already right there.

I do even doubt in length of wires point. You need a full bus plus a thick wire from power source per every lamp instead of just a one thick wire from relay.

Copper wiring is expensive and heavy.

It’s far more efficient to have a simple PCB controlling multiple local functions (headlights, high beams, blinkers, additional sensors) and a single power/ground pair.

Automotive systems are 12V, which results in high currents. High currents require thick wires, especially in automotive environments with high under hood temperatures where you might have to de-rate wires. It absolutely makes sense to reduce high current automotive wiring.

Common power wire will still require one or two extra wires for CAN, so it would make sense only as replacement for bundles of 3 or more wires going to the same place.

much cheaper and much less wiring needed if the bulbs (or bulb holders) can receive commands themselves.

Without a board: you need a big power wire for low beams, a big power wire for high beams, a smaller power wire for turn signal. And that's all you can do.

With a board: you need a big power wire for everything. And a two tiny wires for CAN--so you're already ahead. If your beams can move, or be directed, or have LEDs that can be modulated, or have a washer, you start coming out WAY ahead.

High power systems do exist, particularly in electric vehicles. They have different challenges to do with being incredibly dangerous to work on.

This is trivially observed if you take a moment to compare a modern day wiring harness to something older, while considering the functionality provided by the later.

Toyota subscription services described here: https://www.toyota.com/connected-services/

One of these is "safety connect" that does stuff like SOS button and stolen vehicle locator.

It is not for the built-in safety features like collision detection and lane departure alert.

" eCall is a system used in vehicles across the EU which automatically makes a free 112 emergency call if your vehicle is involved in a serious road accident. You can also activate eCall manually by pushing a button. "

"Compulsory for new car models

If you buy a new model of car, approved for manufacture after 31 March 2018, it must have the 112-based eCall system installed."

https://europa.eu/youreurope/citizens/travel/security-and-em...

First off, almost all vehicles are running CANbuses right to the edge of their available bandwidth. Making the signature data fit is a vehicle-wide refactor unless you've designed for it from the beginning.

Secondly, many automotive MCUs don't have hardware crypto support or enough spare cycles for signing/verification. You have to design for that from the beginning.

Third, key distribution is hard. There are a lot of parties outside the OEM that need to flash firmware for various reasons during production. Do you give them all private keys or do you put up a public image signing service anyone can submit binaries to?

There's lots of other issues I could go on about like what the key rollover looks like, but I hope it's clear that retrofitting cryptography onto complicated systems that weren't designed for it is anything but straightforward.

Anyways I’m not in this industry but work on SPIFFE and see similarities- you could have a centralized CA in the car that does attestation to remote workloads.

With CAN, you're pretty firmly in the land of tradeoffs because the safety-critical stuff you want to auth is also hard realtime and solutions that involve expensive coprocessors like HSMs are usually off the table for a number of reasons like cost, lack of vendors supplying high-integrity solutions, inability to do board spins, etc. Adding authentication also has the nasty problem of sometimes reducing your safety because it makes the channel less noise resistant, as demonstrated by Dariz et al [1]. Navigating these sorts of tradeoffs are why some manufacturers have gone with half-measures like only authenticating a small subset of messages.

[1] https://doi.org/10.1109/MTITS.2017.8005670

Ref: https://github.com/commaai/openpilot/discussions/19932

I worked in this space (auto RE, including keyless entry) for a while, and there's almost no way this would work at scale without a top-down platform redo for automakers.

Is your concern that the key management can leave a mess of key disagreement? But that's like the sensors failing altogether, and that already has to be taken into account.

So yes, I would trust "that the dinky economy-scale micro that GM would pick is always going to hold up that encryption when I'm starting to drift off road" because I have to trust that the computers will handle sensor failure correctly.

That said I'd only trust that if the crypto is sensible. Specifically authenticated encryption is essential. Key exchange, pairing -- those are important too. It needn't be complicated to set up: trust-on-first-use-after-reset (with reset being not trivial to execute) should suffice.

> [...] there's almost no way this would work at scale without a top-down platform redo for automakers.

That's possible, but I doubt it.

It's like in the old days when internet traffic was unencrypted and so was Wifi. You could have a lot of fun just watching what's happening in your home network, and perhaps your neighbors (so I heard..legal grey area). Today? Nope. Everything is locked down. Wireshark shows you only lots of SSL. And that's not even proprietary stuff as the car crypto will be. The bad guys will obtain the keys or workarounds somehow. The good guys will be locked out.

Needless to say, never again

Couldn't the keys for decryption be stored in a trusted module that can only be unlocked with the presence of the actual car key? Yes, this means key cloning attacks still get you access to the CAN, but if you can clone the key you can drive away with the car anyway.

Fuckin' good. Then they can give me the damn encryption key so I can diagnose it myself. I am absolutely not going to subscribe to any sort of narrative like these things are mutually exclusive. I'll keep screaming for the security and the repairability.

Autonomous driving something something, computer controlling human actions something something.