> And knowing the complexity and lack of quality in encryption libraries(openssl anyone?), adding more complexity would just introduce even more risk.
What you're saying here is fundamentally that because OpenSSL has bugs that everyone should be using HTTP instead. That opinion puts you in the minority of the technical world, to say the least.
> 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
This is a solution that requires perfect implementation from every component. As long as this is actually a specified behavior, written down somewhere that you have to implement to mark your part as "CAN2-compliant", that would be OK, but I doubt that's going to happen.
In general, though, I oppose requiring every node on a network operate perfectly to maintain security.
> The bandwidth of CAN is quite limited so including cryptographic signatures with proper strength in every message is not an option.
So don't include a signature in every message. Nobody does that in the computer world, you authenticate a session. There's still no reason for the head unit to be opening up a session with the brakes, and the brakes should reject such a connection attempt.
I realize that this isn't possible with the architecture of the CAN bus, but the CAN bus is just not suitable for nodes which are connected to the internet and broadcast wifi hotspots. The failure case of a CAN bus attack is just not appropriate - once you're on, that's it, you can do anything. There's going to have to be some changes, and the sooner we accept that fact the sooner we can start working on a solution. If we need a network with a cleaner electrical source and more bandwidth, that can no longer be driven with 8-bit micros on an unfiltered alternator, well, that's the price of having nice things. We'll have to buy the $1 part instead of the $.30 part to get the power windows onto the network. When you're connected to the internet, blind trust is not an option.
Within a year or two we'd see micros with onboard crypto accelerators anyway, and we'd be back to the $0.30 parts.
What you're saying here is fundamentally that because OpenSSL has bugs that everyone should be using HTTP instead. That opinion puts you in the minority of the technical world, to say the least.
> 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
This is a solution that requires perfect implementation from every component. As long as this is actually a specified behavior, written down somewhere that you have to implement to mark your part as "CAN2-compliant", that would be OK, but I doubt that's going to happen.
In general, though, I oppose requiring every node on a network operate perfectly to maintain security.
> The bandwidth of CAN is quite limited so including cryptographic signatures with proper strength in every message is not an option.
So don't include a signature in every message. Nobody does that in the computer world, you authenticate a session. There's still no reason for the head unit to be opening up a session with the brakes, and the brakes should reject such a connection attempt.
I realize that this isn't possible with the architecture of the CAN bus, but the CAN bus is just not suitable for nodes which are connected to the internet and broadcast wifi hotspots. The failure case of a CAN bus attack is just not appropriate - once you're on, that's it, you can do anything. There's going to have to be some changes, and the sooner we accept that fact the sooner we can start working on a solution. If we need a network with a cleaner electrical source and more bandwidth, that can no longer be driven with 8-bit micros on an unfiltered alternator, well, that's the price of having nice things. We'll have to buy the $1 part instead of the $.30 part to get the power windows onto the network. When you're connected to the internet, blind trust is not an option.
Within a year or two we'd see micros with onboard crypto accelerators anyway, and we'd be back to the $0.30 parts.