I want to make an authentication system between 2 buses. In order to achieve that I use counter to avoid replay and hash to avoid spoof. The message must be sent in two phases. Is there any proper way to receive back to back messages like A-B without someone adds other, or similar message like A-B'-B ?
\$\begingroup\$
\$\endgroup\$
2
-
\$\begingroup\$ How are the two buses managed? \$\endgroup\$– Andy akaCommented May 14, 2020 at 14:39
-
\$\begingroup\$ Raspberry w/ Canberry managed with CAN Utils. \$\endgroup\$– Kylee HolcombCommented May 14, 2020 at 14:43
Add a comment
|
1 Answer
\$\begingroup\$
\$\endgroup\$
8
You can use multipacket PGN's to send entire encrypted messages if you wish, with whichever counting method you like. For multipart messages using the built in methods there is no distinction. And expects you to have an expected size.
Using your own methods you would want something similar to a rolling code to encrypt the message fragments + a party or crc. Then if other packets get inserted the crc fails. If they are replaid. The rolling code doesnt match and the crc is "likely" to be wrong.
All of this is documented in J1939.21 Data Link Layer, you should be able to find the 2014 version for free online
-
\$\begingroup\$ What do you mean with "escape data" is there such thing on CAN bus ? \$\endgroup\$ Commented May 14, 2020 at 14:58
-
\$\begingroup\$ Escape data is a message type that is used to say to other systems on the bus. "Hey this is weird OEM stuff. Don't bother trying to decode it" its used for things like firmware updates and other things that dont quite line up with the usual pgns and spns. This is coming from a background in automotive CAN. Its possible other feilds might not have left allowances for this type of thing. \$\endgroup\$– RerouteCommented May 14, 2020 at 15:01
-
\$\begingroup\$ Using CRC as a means of "encryption" is fairly trivial to hack using brute force to discover the polynomial. But security on CAN is more about "why is there a fishy node connected to the bus" than the data itself. If a burglar installs custom hardware on your bus, then prevent that with traditional anti-burglar means. If a supposedly valid node on the bus gets hijacked remotely, then prevent that by not connecting Idiotic Things to your high integrity CAN bus. In either case, it's not a software problem. \$\endgroup\$– LundinCommented May 18, 2020 at 11:32
-
\$\begingroup\$ The CRC was not intended as the encryption, I was saying in combination to the encrypted message, In reality if you have physical access and enough time, your done, but that CRC appended to the encrypted message makes it that bit more painful to reverse. There is no real way to know that a can node is fishy, its extremely easy to pretend to be another device, and some devices pretend to be multiple ones currently for backwards compatibility reasons. \$\endgroup\$– RerouteCommented May 18, 2020 at 11:40
-
\$\begingroup\$ Can you provide more details about this ? Also because it is kind of complicated matter we could discuss privately and then share the solution here. \$\endgroup\$ Commented May 21, 2020 at 22:42