Evaluation of Peer Robot Communications using CryptoROS

—The demand of cloud robotics makes data encryption essential for peer robot communications. Certain types of data such as odometry, action controller and perception data need to be secured to prevent attacks. However, the introduction of data encryption caused increment of overhead for data stream communication. This paper presents an evaluation of CryptoROS architecture on Robot Operating System (ROS) which focused on peer-to-peer conversations between nodes with conﬁdentiality and integrity violation. OpenSSL is used to create a private key and generate a Certiﬁcate Signing Request (CSR) that contains public key and a signature. The CSR is submitted to a Certiﬁcate Authority (CA) to chain the root CA certiﬁcate and encryption of RSA private key with AES-256 and a passphrase. The protected private key are securely backed up, transported, and stored. Experiments were carried out multiple times with and without the proposed protocol intervention to assess the performance impact of the Manager. The results for different number of messages transmitted each time increased from 100, 250 to 500 with performance impact 1.7%, 0.5% and 0.2%, respectively. It is concluded that CryptoROS capable of protecting messages and service requests from unauthorized intentional alteration with authenticity veriﬁcation in all components.


I. INTRODUCTION
In robot applications, robot sensors collect huge amount of data from the environment to characterize the situation. Certain types of data require encryption due to prevent attacks such as odometry, action controller and perception data. There are various types of data such as strings, images and point cloud data [1], [2], [3]. Robotic Operating System (ROS) provides a reliable platform for robot application but is vulnerable to cyber-attacks. It needs to be embedded with security function before obots using ROS platform reach mass market. Despite the clear advantages of robot intergration in ROS, it lacks any security protection, which makes robots insecure and prone to malicious attacks especially in robot communications [4], [5], [6].
With the demand of cloud robotics in connecting multiple robots, the encryption of data communication over the network is essential. At current state, a node in ROS can freely publish messages to a random/chosen topic without prior authorization. It can freely and without prior authorization subscribe to the topic and receive all the messages. A node can freely publish large number of messages, preventing the subscriber of this topic from carrying out meaningful information processing and causing a denial of service [7], [8]. The topic transport channel is not secure. It reveals messages to unauthorized persons, unable to detect unauthorized intentional or unintentional alteration of messages, and also cannot prove that the involved parties [9]. Therefore, there is a need to provide a total solution to overcome these situations.
Previous researches introduced various encryption solutions for robot communication [10], [11], [12], [13]. However, it was reported that the introduction of encryption caused increment of overhead for data stream communication. There were significant increments of CPU utilization and the initialization of the ROST OP IC which shown peak usage, which was the same as during attack [14]. The variety of message types in ROS play important roles as huge data stream such as images and 3D laser data. The increment of packet size causing huge delay which affected overall performance. Measurement of performances were measured based on; i) overhead for the initial handshake, ii) pure transportation overhead and iii) overhead in a normal application [15]. Therefore, this paper aims to evaluate basic performance of CryptoROS architecture as proposed in [16] with a specific data type.
The rest of this paper is organised as follows: Section II addresses related works to data encryption for robot communications. Section III explains the overall structure of CryptoROS. The experimental setup, results and discussion are presented in Section IV. This paper is concluded in Section V.

II. RELATED WORKS
Secure communication channel could be achieved by enabling ROS-nodes to communicate with authenticity and confidentiality. Rodriguez et al. [11] figured out that an increment of overhead caused by the secure channel is only a small fraction of the load application itself generates. Further investigation was conducted on a robot's performance when ciphering the messages interchanged between ROS nodes under the publish/subscribe paradigm. Some other researchers showed that AES produced superior solution in implementation and required less CPU than other encryption algorithms [17], [18]. However, it is not recommended to imply a large data overhead in the network for multi-robot environments which required continuous interaction between each components. Morante et al. [12] discovered that, in humanoid robotics, a 1% overhead while respecting determinism in time can be acceptable if it means the devices can be less vulnerable to cyber attacks.
Some other encryption method were tested in securing robot communications. Amaran et al. [10] implemented a Constrained Application Protocol (CoAP) and MQ Telemetry Transport for Sensor Nodes (MQTT-SN) which were designed for such devices. The outcome shown that MQTT-SN performs 30% faster than CoAP when transmitting the same payload [19], [20]. Rodr et al. [21] used a 3DES cyphering algorithm and performed system, evaluation in both computing and communications aspects. Experimental results showed that symmetric ciphers using private keys imposed significant delays [22], [23]. It is observed that a huge decreased of additional response time when using the secured solution for all tested robots. Mukhandi et al. [13] managed to secure robots' network communications by providing authentication and data encryption, therefore preventing man-in-the-middle and hijacking attacks.

III. CRYPTOROS STRUCTURE
The proposed architecture of CryptoROS has been described in Amini et al. [16]. It focused on providing peer-topeer conversations between nodes, which capable of ensuring confidentiality and performing integrity violation check. A computation graph was set up for DoS attacks. The entities must also be scrutinized to ensure true identity. Nodes should not be allowed to publish/subscribe a topic or advertise a service without prior authorization. For evaluation of CryptoROS, three more components were added which consist of JSON Web Token, TLS and MySQL. Two machines were configured, running only the processes needed to carry out the experiments. A rudimentary attempt was also made to assess the overhead caused by CryptoROS.

A. JSON Web Token
The JSON Web Token (JWT) structure for CryptoROS is illustrated in Fig. 1. The header and payload in the form of UTF-8 byte array was encrypted using a Base64 encoding algorithm. The resulting strings were put together and fed into a hash function (SHA-256) to produce a message digest. This message was further encrypted using the private key (RSA) to create a signature. Then, the signature was encoded with a Base64 encoding algorithm and used to form the Access Token. Receiving entities that hold the associated public key (Managers) were able to reverse the procedure in order to ensure the Access Token has been issued by a trusted party (Authorization Server).
Nodes exchange a ROS connection header when establishing new connections. The ROS connection header holds crucial information regarding the connection that was established and used to route the connection. It was connected to ROS Publisher if the ROS connection header carries the topic field, or connected to ROS Service when ROS connection header carries the service field [24], [25]. The subscriber sends together with other data, its name (callerid), topic name to subscribe/connect (topic), and data type for the messages published to this topic (type). On a successful connection, the publisher replied with the fields shown in Fig. 2.
The Interceptor intercepts ROS connection header sent by its peer, extracted certain fields from it, and then compares with the values contained within the Access Token that had been sent by its peer. Then, it decided if the connection should be aborted or not. When issuing Access Tokens, users must decide how long the Access Token should last. Short-lived Access Tokens that expire after several hours or a couple of weeks are recommended. An Access Token cannot be revoked, so if it was issued with a short expiry time, the Manager is forced to refresh it frequently. However, users must select the best configuration which suit their needs.

B. TLS
To setup and run this project, OpenSSL was used to create private key and generate a Certificate Signing Request (CSR) that contains, among other data, a public key and a signature to prove ownership of the associated private key. The CSR was sent to a Certificate Authority (CA). The CA issued a certificate and gives all of the intermediate CA certificates needed to chain to the root CA certificate. The genrsa command was used to create RSA private key as shown below. The −aes256 option protected the private key with AES-256 and a passphrase. Henceforth, the encrypted private key can be securely backed up, transported, and stored. The last option, 2048, stated the size of the private key to create in bits. Fig. 3 and 4 show the implementation of these processes using genrsa and req commands respectively.
Eq. 1, 2, 3 and 4 show the process flow for key generation. In order to generate a CSR, the req command was used. Option −new generated a new CSR by asking the user to provide the Distinguished Name (DN) field values. Value −key provided the file name for OpenSSL tool to read the private key. As mentioned earlier, the CSR carried a public key and signed using the private key associated to the public key it hold. The x509 command was used to sign a CSR, resulting in the creation of certificate. The cipher suite configuration string used in this project is shown in Fig. 5. It selected the cipher suites that will be supported by the TLS server. TLSv1.2 keyword appends TLS 1.2 cipher suites to the list. As in Eq. 5, !LOW keyword permanently deletes all low strength encryption cipher suites from the list (e.g. 56-bit or 64-bit encryption algorithms). !MD5 keyword permanently deleted all cipher suites that used the obsolete and unsecure MD5 digest algorithm from the list. All cipher suites that do not checked for authentication with the involve parties (e.g. ADH and AECDH) were permanently deleted from the list using !aNULL keyword. The use of these cipher suites was strongly discouraged because they were vulnerable to a man-in-the-middle attack. !eNULL keyword permanently deleted all cipher suites that do not offer encryption from the list. !DES, !RC2, and !RC4 keywords  permanently deleted all cipher suites that used the obsolete and unsecure DES, RC2, and RC4 ciphers from the list, respectively. @STRENGTH keyword sorted the cipher suite list according to the cipher strength/key length [26].
At the beginning the cipher suite list was empty, but the cipher suite list changed in some way as new keywords were added to the cipher suite configuration string. The cipher suite configuration string must be chosen carefully to avoid adding unsecure cipher suites to the list. The cipher command was invoked with the cipher suite configuration string as the parameter in order to list the cipher suites that match the requirements. As depicted in Fig. 6 the cipher suite names were very descriptive.   table and the publisher table. The columns named name, topic, and data type stored the name of the node, the (name of the) topic to publish messages to, and the data type of the messages published to this topic, respectively. The same applied to the subscribers, services, and service clients.

A. Experimental Setting
The purpose of this paper is to demonstrate how the proposed solution can alleviate the impact of various strategies used by malicious actors in order to exploit ROS based robots.
The following experiments were carried out to analyze the performance impact of the Manager. All tests were executed on environment configurations consist of hardware, software, and network as listed in Table I. In this experiment, a publisher named talker was adver-   Fig. 8. The time command was used to launch the subscriber. When the program finished, time elapsed since its invocation was written to standard error by the time command [27]. The experiments were carried out 3 times with and without the proposed protocol intervention and the number of messages transmitted each time increased from 100, 250 and 500.
As mentioned previously, an attendee well versed in ROS was capable of controlling the ROS based robot without using the provided web based user interface during the DEF CON 20 conference [28]. These attacks required to a certain extent with little effort to accomplish. In the absence of the proposed protocol, data was transmitted in plain text format as depicted in Fig. 9. A TLS session was negotiated and established in accordance with the proposed protocol in order to secure the conversation as shown in Fig. 10.

B. Performance Impact
The time elapsed values (Fig. 11, 12, 13) were obtained from launching the subscriber using the time command with and without the proposed protocol intervention. The summary of results in Table II concluded that the performance impact was inconsequential. To reduce the performance impact caused by the proposed protocol, the implementations were conducted using rich feature set offered by modern C++ (C++11 and C++14 standards). The finite computing resources used by class objects were also gracefully released (e.g. closing sockets) when appropriate to avoid running out of these resources. However, the size of the transferred data has increased from 2,478 bytes to 14,478 bytes. It happened based on the following factors; 1) many handshake messages required full handshake to negotiate and established a TLS session and 2) JWT was used for secure information transmission between the involved entities (e.g. publisher, subscriber).
The implementation of CryptoROS was capable in preventing unauthorized publishing and subscribing. The TLS handshake for inbound and outbound of peer-to-peer connection will failed and prohibit malicious nodes which were not supposed to be part of a specific conversation from injecting data. The attack surface for denial of service in ROS has also been decreased. The Interceptors could be configured to drop XML-RPC shutdown requests, preventing attackers from shutting down nodes. This approach also made sure the messages, service requests and responses were not be disclosed to unauthorized persons (confidentiality). Any unauthorised intentional or accidental alteration of them was detected (integrity) and the proposed protocol ensured the authentication of involved entities.

V. CONCLUSION
CryptoROS has been designed in such a way that no changes needed to ROS software libraries and tools. Additionally, rebuilding nodes were not required to occupy secure conversation channels. CryptoROS works with all ROS client