By Joana Gracia and Leonardo Gonzalez, Tecnalia, Dimitrios Tsoukalas, Information Technologies Institute (ITI) of the Centre for Research and Technology-Hellas (CERTH) and György Rácz, Budapest University of Technology and Economics (BME)
Connected Car
The Connected Car demonstration will involve a control station and multiple vehicles, both real ones and simulated platforms. The operations will be performed in a controlled environment at the Tecnalia premises.
The demo will focus on the control station which is the centrepiece of the operation. This unit may issue commands to the vehicles which influence their individual behaviour as well as the interaction of a larger fleet and may also overrule the autonomous actions of the cars. With such an operating power it is of utmost importance to guarantee the cybersecurity of the control station architecture, its highest possible level protection.
The focal point of the autonomous driving pilot centres on an automated parking manoeuvre. This manoeuvre holds significant relevance in various applications, including general logistics within depot areas and the efficient distribution of vehicles that require charging along a designated route. Through this pilot, we aim to demonstrate the practical implementation and benefits of connected and automated parking solutions in real-world scenarios.
The demonstration will model and validate the control station. We will prepare the DSP profile for the key devices and will use these components to “redesign” the architecture. The virtual model of the control station, including some deliberate design errors, will be prepared, and fed into the cybersecurity twin. The security exposure of the operation will be simulated in the cybersecurity twin. Known attack types will be launched and we expect to also generate new ones using the deployed AI capability. The twin shall correct the design and will also elaborate adequate protection measures to avert malicious activities. The resulting design model will be validated against selected standard requirements in the architecture validator.
Pilot architecture
Figure 1 Architecture for Connected Car Use case
The pilot comprises the vehicles and the control station.
- Vehicle:
- Industrial Computer(s):
- Vehicle Intelligence (Control, Decision making, perception, etc…)
- Network Switch.
- 4G/5G Modem.
- Lidar Sensor.
- IMU and GPS.
- CAN Controller and Motor (Braking & Steering).
- Throttle by wire (ECU).
- Industrial Computer(s):
- Control Station Monitoring
- Control Station server:
- Monitoring system
- Logger
- MQTT communication broker
- Autoparking system
- Parking selection.
- Reception of camera information and visualization.
- Control Station server:
The pilot will be performed in Tecnalia’s premises, a designated area will be used to emulate a service to match the automated parking scenario proposed. Within this controlled environment several parking spot will be positioned offering multiple selections for the demonstration. The vehicle platforms will navigate the designated area at a maximum speed of 20Km/h, aligning with standards for parking areas. This setup allows for a realistic and controlled demonstration of automated parking manoeuvre.
Smart Home
The Smart Home site is located at CERTH premises and is Greece’s first house that combines advanced construction materials with intelligent ICT solutions, therefore acting as a test-bed in various European and national research projects. It offers various smart IoT-based technologies related to Energy and is equipped with a large variety of sensors, actuators, and smart home devices. Although the domain is absolutely security sensitive, the used devices have been deployed without any validation, and their security and reliability were taken for granted.
During the demonstration, we are going to prepare Device Security Passports (DSPs) for a set of devices that will be included in the demonstration and will apply diverse testing methodologies on the components used. We will virtualize a subset of the smart home architecture and redesign it from a security perspective in the Digital Cybersecurity Twin using the verified components. The foreseen secure-by-design exercise will be modelling the security status of the overall architecture and thus shall discover the hidden design bugs as well as so far unknown threats and vulnerabilities and recommend additional protective measures. In a further step, new devices will be added to the architecture using the DOSS Secure Onboarding Platform.
Pilot architecture
The Smart Home is equipped with a wide set of heterogeneous sensors and actuators (e.g., smart meters, dimming and on/off actuators, environmental sensors, occupancy sensors, smart plugs, smart appliances, photovoltaics, batteries, etc.) that monitor the consumption, production and the conditions of the entire building, while automated algorithms can implement automation and/or efficiency scenarios while respecting occupant preferences.
Figure 2 High-level overview of the Smart Home architecture (including IoTAC and DOSS modules)
Figure 2 illustrates a high-level overview of the architecture of the Smart Home infrastructure. The Smart Home infrastructure contains a wide set of heterogeneous sensors and actuators (green box) providing information for several operations taking place within the Smart Home (e.g., smart lights, temperature sensors, etc.). All these sensors produce measurements for different variables and send these measurements to the Smart Home Backend Server via several different communication protocols. An appropriate gateway (i.e., the Smart Home Gateway) is deployed on the Smart Home Backend Server, which is responsible for establishing and managing the communication with the Smart Home Assets (i.e., devices).
When measurements from the Smart Home Assets arrive to the Smart Home Backend Server through the Smart Home Gateway, they are persistently stored in a dedicated internal database, i.e., the Smart Home Internal DB. Subsequently, the resources (data) of this database are exposed and distributed to external systems through the Smart Home RESTful API. The endpoints of this API are consumed by both auxiliary systems, deployed in application servers inside Smart Home, as well as the end users of the Smart Home System via the Smart Home Dashboard, which is implemented as a web application.
While the Smart Home RESTful API enables users and services to retrieve data from the Smart Home sensors and actuators using HTTP requests, controlling these devices is only allowed through the MQTT protocol (exclusively from within the protected Smart Home network). To this end, each system or service that needs to control Smart Home assets can do so by implementing an MQTT client, which resides within the protected Smart Home network (e.g., on an application server) and communicates directly with the Smart Home MQTT Broker. Currently, the Smart Home Dashboard relies on such an MQTT client, acting as an intermediary that translates HTTP requests from the front-end into MQTT commands directed to the Smart Home MQTT Broker.
In Figure 2, the security modules that were added by the H2020 IoTAC project are shown in blue while the new modules to be added within the context of the DOSS project are shown in red. As the project progresses, there is a high level of confidence that incorporating the novel DOSS hardware and software security solutions will significantly enhance the overall security of the Smart Home environment. More details on the results will follow in the upcoming blogposts and pilot-related public deliverables. Stay tuned!
Prosumer Cell
The security of individual prosumer cells is gaining increased attention. As their combined contribution grows to the overall energy production so does the exposure of energy security of the overall network to the stability of these operations.
The Prosumer cell, to be used for the pilot, is a live operation, connected to the commercial network, located in Balatonfüred (Hungary). It is an already in use experimental and testing facility primarily used for development of predictive maintenance technologies as well as for modelling and optimizing the operation of commercial deployments. It is assumed that the architecture already had the necessary level of security protection when launched. However, there is no mechanism in place that would guarantee that subsequent changes and modifications do not open new attack surfaces, and do not deteriorate the initial security level.
In this demonstration, we will use the system to demonstrate how software updates and patches can be automatically tested and validated, by modelling in the digital twin, and how new components can be securely integrated into the operating environment following their security assessment. New devices and components will be added to the system using the secure onboarding technology of the project. We will also secure the operating architecture comprising a set of runtime security modules – access control, attack detection, malware detection– and should any threats or attacks be discovered (we will simulate various attack scenarios) security related information will be shared with the other actors of the Supply Trust Chain and if necessary, related DSPs will also be updated.
Pilot architecture
The BME energy testing site comprises a relatively small, 3.5kW peak capacity solar powered prosumer cell (DER – distributed energy resource) and also has an energy storage capacity of 5kWh and is connected to the local power grid.
The whole system is designed to be remotely managed through the public internet, therefore both external and internal protection must be considered. The environment already has an established security monitoring and protection architecture (it has been established by the H2020 IoTAC project). Using the newly developed technologies as well as the existing monitoring system, the pilot will assure that no modifications and additions to the architecture will compromise the security of the operation, and this comprehensive protection environment will be integrated into the overall DOSS IoT supply chain.
The pilot architecture can be seen in the figure below. The security modules that were added by the H2020 IoTAC project are shown in blue while the core modules in green. The place of new modules to be added with the help of the secure onboarding technology of the project are shown in red. These will be further elaborated during the project.
Figure 3 Prosumer cell infrastructure
