REGISTER | LOGIN
Breaking News
News & Analysis

CAN Bus Can Be Encrypted, Says Trillium

10/22/2015 00:01 AM EDT
13 comments
NO RATINGS
1 saves
Page 1 / 3 Next >
More Related Links
View Comments: Newest First | Oldest First | Threaded View
Page 1 / 2   >   >>
dt_hayden
User Rank
Author
Re: CAN Bus Encryption
dt_hayden   11/9/2015 3:12:48 PM
NO RATINGS
"What consumer would choose not to have their vehicle secured against nefarious and potentially life threatening cyberattack?"

What consumer would demand needless connectivity which would mandate security against cyberattacks?  No thanks.

 

"...what government could allow 'hack-able' cars to become weapons of considerable distruction on any street at any time at the whim of hackers halfway around the world."

 

Exactly, I'll keep my car off the net.

zeeglen
User Rank
Author
Re: CAN Bus Encryption
zeeglen   11/8/2015 8:48:22 PM
@dt_hayden Who wants to play the virus/antivirus game on their car?

The next car I purchase MUST have the option to DIS-connect, even if it means pulling the fuse to the RF link.  Have to do this on the test-drive of course; to make sure some dumass did not program the thing to stall when the RF link dies.

David@Trillium
User Rank
Rookie
Re: CAN Bus Encryption
David@Trillium   11/8/2015 2:27:22 PM
NO RATINGS
What consumer would choose not to have their vehicle secured against nefarious and potentially life threatening cyberattack? I foresee cybersecurity updates potentially being included as a component of the manufacturers 5-year warranty package. Could also be included within insurance premiums or a component of car insurance offerings. Cost-wise we anticipate single digit $s per year for unlimited cybersecurity updates to vehicular control system firmware.

Lets face it, this will be a legislated ubiquitous component of future vehicles mandated by the regulatory commisions of nations. Seat belts, air bags, emission standards, etc....multi-layer vehicular cybersecurity will not be an option. After all, what government could allow 'hack-able' cars to become weapons of considerable distruction on any street at any time at the whim of hackers halfway around the world.

Not a matter of sanity, this is a matter of public and personal safety.

dt_hayden
User Rank
Author
Re: CAN Bus Encryption
dt_hayden   10/28/2015 11:11:10 AM
NO RATINGS
What sane consumer wants to get into the software maintenance / patch / security update rat race on their transportation vehicle?   Who wants to play the virus/antivirus game on their car?

What do you foresee as the ongoing fees required by consumers to support this evolving soultion?

David@Trillium
User Rank
Rookie
Re: CAN Bus Encryption
David@Trillium   10/24/2015 7:33:25 PM
NO RATINGS
Dear PhilipK3, As you mentioned, peer review and hardening of algorithm are critical to a comprehensive and lasting solution. We are enhancing our algorithm and key management system daily. Peer review takes time and can be very costly. We are working with government agencies on the peer review. In the meantime, there is a sense of urgency bordering on desperation in the automotive industry to protect connected cars from cyber attack. We are pursuing both static analysis and commercialization paths in parallel. Fortunately, our solution was designed from the outset to be a "living" / evolving aspect of the vehicle. As we enhance the SW to protect against new threats, the improved code is remotely flashed to the vehicle(s) using a yet-to-be-publicly-announced (for USPTO filing reasons) secure delivery methodology. Stay tuned...much more to come from this little upstart venture from Japan. Thanks for your advice. We take it all to heart and embed all good ideas in our code.

PhilipK3
User Rank
Author
Re: CAN Bus Encryption
PhilipK3   10/24/2015 11:39:35 AM
I worked on CAN security with Chris Szilagyi several years ago, and we came up with an approach that would solve many of the same security issues that Trillium seems to be going after.  Chris did his PhD thesis on getting full-strength crypto security for authenticating highly constrained embedded networks using just a few bits of the payload. 

For example:

Note that encryption is often not what you really want.  Much of the time it doesn't matter if messages are secret. What you care about is if they have been sent by an imposter node tapping into the network, or whether a critical message is being faked by a compromised non-critical node.

Key management is always tough for these systems, so I'm glad to see that Trillium is working on that problem.

It seems from the article that they are home-brewing a crypto algorithm.  That is an awfully difficult feat to pull off (I say this as someone who has done such work). I hope that they publish or patent their cryptographic algorithm so it can be reviewed and vetted by independent parties. In the past there have been too many poorly conceived automotive cryptography approaches that hide behind the "secret algorithm" smokescreen, but ultimately turn out to be insecure.  (Keeloq anyone?) It's important that they get it right if they are going to do this. I wish them well.

 

David@Trillium
User Rank
Rookie
Re: CAN Bus Encryption
David@Trillium   10/24/2015 7:38:40 AM
NO RATINGS
Dear Dr. Juliussen & Junko-san;

As Dr. Juliussen, director research & principal analyst at IHS Automotive, pointed out in his recent presentation to the automotive industry, "Hacking research has shown that nearly all access points can be compromised."

 

This is exactly why we at Trillium have developed SecureCAN. To reduce the vulnerability of the automotive CAN bus eliminating one of the most vulnerable access points which could be compromised. SecureCAN, and more specifically the TrilliumCipher, was designed to be resilient against replay attack and other attack strategies. The TrilliumCipher combines transposition, substitution and time multiplex algorithms. The result of the last one is significant - in addition to the key, Time is infused within the cipher text itself... meaning that a simple replay attack will have no effect. Trillium's key management system (DKLP) uses a virtual channelling scheme and msg id hopping technique to defeat surface attacks.

Trillium continues to research new cryptanalytic techniques used to compromise the CAN bus and enhances continuosly the SecureCAN counter measures.

Bert22306
User Rank
Author
Re: CAN Bus Encryption
Bert22306   10/22/2015 5:35:41 PM
I don't think that the CAN bus encrypting the data will solve the hacking problem necessarily. It all depends what gets hacked. This same question came up some time ago on EE Times, on an article that talked about lack of encryption in the telco trunk cables.

In short, if the bus does the encryption and decryption, the bus could very diligently be encrypting and decrypting hacked commands or hacked sensor data. The best way to protect data flows is to do so at the end systems, not in the middle.

Yes, this does get done on networked systems, a lot. For this, I would be looking at some sort of symmetric key stream cipher though. A shared secret between end systems. It's efficient and low latency. I think block ciphers are not always the best choice, even though they've been around longest and have been well scrutinized over the years.

Another point is that yes, authentication may be more important than encryption, to protect against hacking per se (but not against snooping). But the two are not sigificantly different in terms of computational complexity. To authenticate, one would usually encrypt some or all of the message header, and send a plaintext header along with the encrypted "authentication header." At the receive end, if the receiver can successfully decrypt the the authentication header, and this header matches the plaintext header, the message packet would be accepted as good.

So, authentication ends up being encryption of the header only, rather than of all the message payload. (When people say "encryption," they usually mean both encryption and authentication of the packet, although in principle one could encrypt the payload only and not authenticate.)

Doug_S
User Rank
Author
Don't encrypt it, replace it
Doug_S   10/22/2015 4:03:31 PM
CAN bus was developed when home computers were still using 8 bit CPUs.  They should start with a clean sheet of paper, with security built in from the ground up.  Include a way for the replacement to interface with a legacy CAN bus, and as various bits of the vehicle are converted from CAN bus to new bus over the next 5-10 years they can be migrated until the CAN bus is no longer needed.

 

The important thing is insure that anything new technology with external interfaces can only talk to the new secure bus, and it can be careful about what information it will let pass from the legacy CAN bus devices.

 

Otherwise we're going to be stuck with the CAN bus forever, with more and more layers of kludge applied for security, higher speeds, greater functionality, etc.  The more layers of crap you add to an insecure standard, the greater the chance you've missed something and left a hole wide open.

junko.yoshida
User Rank
Author
Re: Authentication is more important, not encryption
junko.yoshida   10/22/2015 3:37:24 PM
@luting, thanks for sharing your detailed thoughts here. Helpful. My next question, then, is how much it would cost for Tier Ones to implement what you described as step 1 to 3. And more importantly, is this something they are already doing?

Page 1 / 2   >   >>
Like Us on Facebook
EE Times on Twitter
EE Times Twitter Feed