Cyphal is a publish/subscribe protocol built to be a highly reliable network for embedded system environments within next-generation intelligent vehicles or non-embedded system environments such as GUI software, prototyping, and other relevant use cases. The protocol is designed without a “master and slave” concept wherein every participating node operates independently and can use various transport mechanisms such as CAN FD, Ethernet, etc. The OpenCyphal organization has open-sourced cyphal implementations for CAN, CAN FD, and Python; however, implementations in other transport layer protocols have yet to be explored.

How does it work?

The publish/subscribe protocol has no master or broker nodes and is built on the idea of a “decentralized network“ where one-to-many or one-to-one transfers between nodes are supported. Furthermore, data exchanged between nodes are serialized and deserialized, respectively.

Data types used in the protocol are pre-defined. A strongly typed data structure description language (DSDL) houses the complete description of the data types that will be used in a specific implementation of the Cyphal protocol. Similar to the programming construct, a data type helps classify the data utilized by any message or service and suggests a maximum size limit that the DSDL designer defines.

Every data type is associated with a namespace. Namespaces can be nested and thereby forming a hierarchy. Therefore, every data type has a unique name identifier comprising the namespace hierarchy, the DSDL version number, and its short name.

A complete list of supported data types can be found in the Cyphal specification.

The current applications of the protocol that have been open sources are focussed on CAN/CAN FD and UDP. However, it is essential to note that the CAN/CAN FD implementation is for deployment in high-reliability environments (e.g., autonomously driven intelligent vehicles), which currently do not support transport on ethernet out-of-the-box.

The two prominent use cases for a Cyphal network are message publication and service invocation. Messages encapsulate data exchanged between nodes which could be one-to-many (two or more nodes). Service invocations are a one-to-one interaction where the client initiates the exchange with the node providing the service. The specification currently only supports broadcast transfers for message publications and unicast transfers for service invocations.

Security Concerns

Depending on how the Cyphal specification is leveraged, several security concerns might be pertinent to the system builder. The list below is non-exhaustive but elaborates on the scope of security issues one might encounter:

• First and foremost, a DSDL file can be used to automatically generate serialization and deserialization code used by the nodes. Unfortunately, this code could contain insecurely configured deserialization functions.
• If uavcan.file.read is used to read a remote file, a possible race condition could be a relevant attack vector as one could modify the file's contents between the time of check and time of use.
• The uavcan.internet data type can be used to implement an API for nodes to exchange data, send telemetry down to remote servers for data collection, and perform firmware or software upgrades without relying on the application layer to facilitate this function. The User Datagram Protocol (UDP) facilitates transport over the Ethernet bus. This could specifically cause security issues affecting the confidentiality, integrity, and availability (also known as the CIA triad) of the Cyphal network. If UDP is utilized, concerns from an eavesdropping perspective (where the attacker can view and modify communication) and a denial of service perspective are relevant.
• Depending on how the embedded devices are manufactured and assembled, an adversary may be able to introduce a “malicious node” to the environment. Although low, the likelihood of this attack has a high impact due to the ability to influence the operations of the embedded system environment due to the plug-and-play nature of the Cyphal protocol.
• Interactions between nodes over the Cyphal network are generally logged for diagnostic and security or audit purposes. Log data is generally stored onboard the device and exfiltrated to a remote data collection server via the application layer or at the protocol level. An attacker with physical proximity or a network attacker may be able to read/modify log information.

How would one fix these security issues?

Now that we know some of the potential issues with a Cyphal-powered environment, let’s dive into how one could potentially fix them.

Autogenerated code for serialization and deserialization must be checked for insecure library configurations.

If uavcan.file.read is being used, verify the file integrity by checking the hash associated with it every time it is being fetched remotely. This verification allows for time of check and time of use issues to be mitigated.

Any embedded system environment that has nodes with access to a modem will need to be verified to ensure that the protocol support for transport over the internet isn’t implemented unless intended to do so.

If implemented, the certificate of authenticity (COA) for every node needs to be enabled so that every message from a node is signed to verify repudiation. COA, if implemented, can support a 222 bytes identifier that can be used to provide a digital signature of strength that is RSA, ECDSA, or higher.

Currently, the specification only supports UDP; however, if used, it is strongly recommended to use DTLS for all communication. On the other hand, if the focus is to secure transient data (data that is not useful after a specific time), depending on the entities involved in exchanging information, one could enforce digital signatures at the very least.

The current options for securing internet communications involve DTLS. However, it does add a bit of overhead to justify it for onboard communications. Nevertheless, it should be enabled when sending sensitive data to a remote server.

Additionally, to protect against UDP attacks, it is recommended to implement and use network-wide time synchronization. The Cyphal specification provides a way for implementors of a Cyphal-compliant system to define a consistent time system across nodes. Time synchronization can be used with a message authentication code (MAC) to verify if a message has been replayed or spoofed.

UDP communications to and from the IoT device must be controlled via a gateway or edge computing device that filters traffic before forwarding it to the system that operates on Cyphal/UDP. As a result, many cloud providers have solutions focused on IoT, reducing the efficacy of any attack focused on overwhelming the connected IoT device.

Conclusion

As with any piece of technology, you can see, there are numerous points of consideration while leveraging the Cyphal protocol. While the protocol has some security concerns, potential issues can be fixed by checking for insecure code configurations, verifying file integrity, ensuring that the protocol support for transport over the internet is not implemented unless intended, enabling the certificate of authenticity for every node, and using DTLS for all communication. Cyphal can be a reliable and effective network protocol for various use cases.

As future work, it would be interesting to see an upgraded version of the Cyphal specification, which inherently supports authentication and authorization mechanisms within the protocol.

About the Authors

Veer Singh Principal Security Engineer, contributed to this publication.