5 ms·

Regardless of the firmware question with the V850 module, I'm surprised that other modules on the CAN bus would accept commands from an entity that 'should' onl

• mzs 11y ago
  CAN is a bus over a wire with no concept of source (or destination).
• kevin_thibedeau 11y ago
  CAN isn't really designed for security. The nodes don't even have addresses. They communicate using message IDs without regard to who the sender or responder is. The error detection requires a party line so that any node can flag a corrupt message and the data rate is too slow to make tunneling a secure stream practical.
  • dsuth 11y ago
    Thanks for this description (and others below). In that case it's not reasonable to use this for safety critical applications, IMO. Any element on the bus becomes a potential point of entry, and there's no defence in depth once on the bus. Kinda scary from an architectural point of view.
    • billforsternz 11y ago
      Unfortunately you are casually proposing to trash untold billions, probably trillions of dollars worth of existing automotive engineering infrastructure with that comment. As any system is decomposed into components you can and must reach a level where inter-component communication is dumb, unquestioning, immediate. Obviously by the time you reach transistors (or pistons) that's how it works. CAN is not as fundamental to cars as pistons (or wheels if you prefer electric cars I suppose) but it's not that far removed. It was developed decades ago, at a time when this kind of hacking was strictly science fiction. I don't think it's necessary to throw away everything (as near as makes no difference) to address this problem. Real air gaps, real read-only circuitry etc. (as described in other comments) could do the job.
      • dsuth 11y ago
        I disagree; it's not necessary to throw everything away, but an improvement should, and must be made. Existing protocols can be extended to include security (and have, see Safety CIP for an example). Any form of engineered design is unlikely to go backwards in terms of the functionality and flexibility that things like bus communications bring, but awareness of these new attack vectors needs to be included in the base design. This is the path that industrial control systems are taking in light of attacks such as Stuxnet, I expect that the automotive guys (who are usually ahead of the game in terms of systems engineering) will follow suit. Edit: The problem I have with people proposing air gaps and read-only circuitry, is that they just don't work in real applications. If there is a business case against it, such as the service these jeeps were offering, then air gaps and hardwired circuitry solutions will be overridden by that business case. Further than that, as can be seen with things like the Lenovo hardware fiasco, manufacturers cannot be trusted to abide by the rules (such as: air gaps are now mandatory), when there is a benefit for them to act otherwise. As Chrysler now has the ability to remote into their cars, they are very unlikely to remove this ability 'merely' due to safety concerns. It's far safer on the whole to offer secure methods of achieving the existing or proposed functionality, than to try and walk backwards and make things harder and more costly to implement, for lesser functionality.
        • Too 11y ago
          The nature of a bus-network makes it very hard to do verification that the sender is in fact who he claims to be. Only solution i can see that really works is if the true sender "breaks the bus" when it detects a malicious sender is using it's source address, as is done when you get ID-collisions, CAN itself does not have a concept of source but many protocols implemented on top of CAN does. In practice this could be very complicated though because often devices deliberately pretend to be other devices due to compatibility with legacy devices. The bandwidth of CAN is quite limited so including cryptographic signatures with proper strength in every message is not an option. Establishing encrypted connections also comes with a safety risk if they fail, current architectures are designed to allow glitches in the physical connections and recover instantly once the connection is back. Really, many ECUs are designed to fail in every possible way, you can even pull the power of an ECU and plug it back in while driving and your car will keep going without you even noticing it(dont try this at home). You don't want to waste a second with encryption handshaking on a 100hz signal just because you lost a sequence number somewhere. And knowing the complexity and lack of quality in encryption libraries(openssl anyone?), adding more complexity would just introduce even more risk.
    • mzs 11y ago
      Whoa there, no it's totally fine. It has great error and collision detection, is very tolerant of noise, has priority for realtime baked in, all the controllers do rudimentary and effective protections against failed controller, and the entire notion of some controller sending something a few are interested in and a controller interested in the same message that a number of different controllers may send is central tenant to the operation. The mistake is making it accessible over a cellular network. This was not careful air gapping. The OEMs will learn a lot from this. They had protections but they were not strong enough. There will be protections that are harder in the future thanks to this. CAN is really quite good and in fact is used at times in industrial automation as well as automotive where it shines.
  • willyt 11y ago
    Just to add. It can be implemented on an 8bit micro controller. It's pretty similar to I2C or SPI but with a bit of error checking thrown in.
• jfim 11y ago
  CAN bus isn't designed for security, it's designed to transmit bits in electrically noisy environments (such as a car) between embedded devices. It sends frames of up to 8 bytes, which is not even large enough to fit a TCP packet header.