Hello
I have no experience with Cyphal, but have read the specifications, guide and the code and I have vast experience with protocols implementation and design.
I have a question which I think is important in today’s technology and also important for me to adopt the Cyphal to my company products
The question is:
How Cyphal treats the security aspects, mainly over CAN transport, like keys management, authentication of images, authentication of nodes etc.
As reference I can give an example like the UDS (ISO 14229) service 0x27 or 0x29
Cyphal is not security-aware at the moment. If you have access to the network, you have full access to everything.
The topic of authentication keeps resurfacing every now and then. We may work on the security extensions at some point in the future. Would you like to collaborate on this?
Cyphal/CAN doesn’t offer anything new nor make anything worse for CANbus. It’s a known weakness of this medium that security is difficult given it’s tiny MTU, even for CAN-FD. That said, message authentication is something we’ve put a bit of thought into and something we might tackle in the future. Any new contributors interested in this problem would be welcome.
For Cyphal/UDP (which is my focus these days) we actually make a couple things better in providing a transport protocol that avoids the known issues with Ethernet fragmentation. Besides that, Ethernet itself gives you various options like MACsec or secure protocol tunneling. This is an area we will be addressing with more rigor in the future so expect to see some updates to the specification for UDP authentication and security.
I should add, for CAN you can mitigate a class of issues using parts like the NXP TJA115x. This doesn’t provide authentication but it does protect against some attacks and failure modes and is fully compatible with Cyphal/CAN
uint8[<=222] certificate_of_authenticity
# The certificate of authenticity (COA) of the node, 222 bytes max, optional. This field can be used for
# reporting digital signatures (e.g., RSA-1776, or ECDSA if a higher degree of cryptographic strength is desired).
# Leave empty if not used. Not to be changed while the node is running.
which allows you to at least check COA. Given getInfo()-server is implemented on all your nodes and keys are stored in non-volatile memory on your low-level CAN-hardware.