riebl / vanetza

Open-source implementation of the ETSI C-ITS protocol stack
Other
201 stars 158 forks source link

Simulating the security features of Vanetza via Artery #153

Closed eyaget closed 1 year ago

eyaget commented 2 years ago

Hello,

I have seen that you have already integrated Vanetza with Artery. However, there is no clear information on how to simulate the security features of Vatenza, e.g., signing and verifying messages, on Artery. I noticed that the "inet_security" configuration is already listed under the "example" target. However, there is no actual certificate attached to the nodes nor message signature/verification performed when it is simulated. Could you please help to provide a brief information on how to enable and simulate those security features?

Thank you in advance for your help.

riebl commented 2 years ago

Have a look at the paper Improved Security Performance for VANET Simulations which outlines the primary security features implemented in Artery. Of course, you can extend Artery to configure more security aspects of Vanetza; this has just not been a top priority so far. For the sake of simplicity, Artery generates a self-signed certificate that is shared and accepted by all stations.

eyaget commented 2 years ago

Hi Raphael,

Thank you very much for your response.

I guess setting the "itsGnSecurity" flag to "true" in MIB will enable Artery with "full" (as mentioned in the paper) security configuration. Please correct me otherwise. However, after setting "itsGnSecurity", the packet information in the simulation is the same as when it is not set. Meaning, there is no any certificate, message signature and message verification information displayed on the Artery simulation platform. Is there any way to check the signature (on the sender side) and the verification (on the receiver side)? It is just to verify whether the security feature is correctly enabled or not.

From the paper, it looks that the basic security features, i.e., signing and verifying messages using self-signed certificates, are implemented in Artery. Could you please mention the extended security features implemented by Vanetza and how it can be enabled to be used in Artery?

On a side note, Artery does not seem to support incremental building. For example, if I change some configurations on Vanetza (e.g., in CMakeLists.txt), the change will not take effect when rebuilding Artery on top of the existing "build" folder. To take effect, it requires to do a fresh build by deleting the existing one. This is quite cumbersome as a fresh build takes a significant amount of time. Please let me know if there is a fix for this.

Thank you very much for your time and kind assistance.

riebl commented 2 years ago

The MIB option itsGnSecurity is always set to true for any configuration mentioned in the paper except the one named off. Which policies are employed when signing and verifying secured packets is configured in Artery's SecurityEntity module.

What do you mean by "packet information"? Are you referring to the visualisation of packets in the GUI? Security attributes of GeoNetworking packets are not visualised.

Most code related to certificate handling and signing/verifying secured packets employs interface classes, i.e. you can easily modify their behaviour by providing custom implementations of them. I have some code related to PKI communication in a development branch, which deals with station enrolment and authorisation ticket retrieval. However, this code is not yet ready to be published.

Incremental builds are possible and work flawlessly on my system, i.e. if I change a file in the extern/vanetza directory, only those changes and their dependants are rebuilt by Artery.

eyaget commented 2 years ago

Hi Raphael,

Thank you very much for your clarification! It is really helpful to better understand the simulation framework.

As for the incremental build, it does not work for some configurations for me. For example, if I set "ON" for the "BUILD_SOCKTAP" option in "/artery/extern/vanetza/CMakeLists.txt", the incremental rebuilding will not build socktap, i.e., no binary or libraries of socktap will be created. Likewise, socktap will not be cleared when we change its CMake option from "ON" to "OFF" and rebuild it. You may check it on your system.