Vehicle enrollment and active revocation implementation

[jordydehaes]

Hello @riebl,

I am currently working on implementing an enrollment process for vehicles to obtain pseudonym certificates from a central authority and simulate an active revocation scheme in the Artery framework in different scenarios. I understand from previous discussions that Artery does not natively support PKI communication, and all vehicles are expected to be fully enrolled at the start of the simulation. But I'm aiming to manually simulate the PKI processes within the Artery framework.

My approach:

• Creating custom message types for enrollment requests, responses, and Certificate Revocation List distribution.
• Implementing a central authority module that handles these messages, generates certificates, and maintains a Certificate Revocation List (CRL).
• Implementing vehicle modules that request enrollment and handle the responses of enrollment and incoming CRL.

Here are some specific questions I have:

Is this approach feasible within the current capabilities of the Artery framework?
What would be the best way to simulate the enrollment process of all vehicles?
Are there any existing examples or best practices for handling such custom message passing in Artery or similar projects as mine?

Any guidance or suggestions on how to proceed would be greatly appreciated.

Thank you in advance for your help!

Best regards,
Jordy

[riebl]

Hi Jordy,

though Artery does not yet cover PKI communication, it should be a good starting point for your work. For enrollment and AT updates usually a "classic" Internet connection is used. In Artery, you could equip all stations with LTE radios (modelled by SimuLTE) for such a purpose and add a PKI client application to them.
Another question is the intended level of detail: Do you need just logical equivalent messages or precise byte-wise identical messages? The former can be quite easily modelled using OMNeT++'s cPacket and optionally its message compiler. The latter requires an implementation of the "real" messages exchanged with a "real" authority.

Our "lte-blackice" scenario and more specifically its BlackIceCentral module should give you an idea how to add Internet-based applications to Artery vehicles. This scenario also introduces a custom message BlackIceWarning using OMNeT++'s message compiler.

In the end, it depends a lot on what you want to investigate or demonstrate with your simulation. In some cases, it is sufficient to have rather abstract messages which just highlight that some messages are exchanged in some sequence. In other cases, it may be necessary to model the precise length of these messages too.

Best regards,
Raphael

[jordydehaes]

Hi @riebl,

Thanks first of all for the quick response. The main goal of my project is to compare different revocation schemes within V2X communication. For this purpose, the messages need to be somewhat equivalent but definitely not in detail. I am already using custom cPacket classes for enrollment requests/answers, distribution of the Certificate Revocation List to the vehicles, and regular V2V messages.
I have taken a look at the BlackIce scenario as you suggested.

Initially, I was using the method of distribution used in ExampleService, particularly how the trigger method is implemented, for distributing CRL and other messages such as regular V2V. However, I'm not sure if this is the right approach for my use case. For example for regular V2V messages, which are used to test the impact of revocation schemes, is the ExampleService approach appropriate? Would the approach taken in BlackIce be better in my case? Essentially the goal here is to simulate the enrolment/revocation using the ETSI protocol stack and investigating certain metrics such as network overhead, revocation time and others.

The method I'm talking about:

void ExampleService::trigger()
{
	Enter_Method("trigger");

	// use an ITS-AID reserved for testing purposes
	static const vanetza::ItsAid example_its_aid = 16480;

	auto& mco = getFacilities().get_const<MultiChannelPolicy>();
	auto& networks = getFacilities().get_const<NetworkInterfaceTable>();

	for (auto channel : mco.allChannels(example_its_aid)) {
		auto network = networks.select(channel);
		if (network) {
			btp::DataRequestB req;
			// use same port number as configured for listening on this channel
			req.destination_port = host_cast(getPortNumber(channel));
			req.gn.transport_type = geonet::TransportType::SHB;
			req.gn.traffic_class.tc_id(static_cast<unsigned>(dcc::Profile::DP3));
			req.gn.communication_profile = geonet::CommunicationProfile::ITS_G5;
			req.gn.its_aid = example_its_aid;

			cPacket* packet = new cPacket("Example Service Packet");
			packet->setByteLength(42);

			// send packet on specific network interface
			request(req, packet, network.get());
		} else {
			EV_ERROR << "No network interface available for channel " << channel << "\n";
		}
	}
}

Any insights you can provide on these aspects would be greatly appreciated. Thank you again for your help!

Best regards,
Jordy

[riebl]

The ExampleService is quite eager to transmit on any applicable channel. In many cases, you can simply pass your request via request(req, packet), i.e. without a network interface argument. The middleware will send the messages then on all applicable channels for you. After all, this is only of concern if your simulation model uses more than one ITS-G5 channel. For example, the CaService and GbcMockService do not iterate any network interfaces.

Also note that you don't have to use the trigger method for transmission. You can also schedule arbitrary OMNeT++ events and call request(req, packet) from an arbitrary event or signal handler.

I have mentioned BlackIce because I assumed you want use the IP stack for the PKI communication. BlackIce is a nice example how to integrate IP/LTE into Artery. You can ignore it if all your traffic shall use the ETSI ITS stack.