Periodic Reporting for period 1 - CERTIFY (aCtive sEcurity foR connecTed devIces liFecYcles)
Reporting period: 2022-10-01 to 2024-03-31
CERTIFY defines a methodological, technological, and organizational approach towards IoT security lifecycle management based on (i) security by design support, (ii) continuous security assessment and monitoring (iii) timely detection, mitigation, and reconfiguration, (iv) secure IoT Over-The-Air (OTA) updating, and (v) continuous security information sharing.
Main objectives are:
Cybersecurity awareness for IoT-enabled environments through a multi-stakeholder sharing of threats and mitigation
Secure reconfiguration and maintenance of customizable embedded devices by means of open hardware primitives and services
Perform security operational management based on bootstrapping and monitoring of attacks and malicious behaviours
Runtime security compliance and continuous certification methodology via objective metrics
Foster knowledge delivery via wide dissemination, capacity building and supporting standardization activities. Build a robust exploitation plan to boost ROI by optimizing current and future EU cybersecurity capabilities
Industrial validation of the CERTIFY framework in IoT ecosystems
Main objectives are:
Cybersecurity awareness for IoT-enabled environments through a multi-stakeholder sharing of threats and mitigation
Secure reconfiguration and maintenance of customizable embedded devices by means of open hardware primitives and services
Perform security operational management based on bootstrapping and monitoring of attacks and malicious behaviours
Runtime security compliance and continuous certification methodology via objective metrics
Foster knowledge delivery via wide dissemination, capacity building and supporting standardization activities. Build a robust exploitation plan to boost ROI by optimizing current and future EU cybersecurity capabilities
Industrial validation of the CERTIFY framework in IoT ecosystems
Results of the pilots’ analysis (requirements, attacks, threats) and preliminary description of the CERTIFY methodology have been reported in the D1.1 “Security requirements, threats models and initial CERTIFY lifecycle management”. The document has been shared and then presented during a virtual meeting with the expert of the security advisory board (SAB), that have also provided insightful feedback. After the approval of the SAB (indeed the D1.1 was marked as sensitive, SEN), the document has been submitted on time at M10. The preparation of D1.1 that included use case requirements and the modelling of relevant threats, allowed to timely achieve the MS1 “Initial requirement elicitation and threats modelling”.
This first reporting period is focused on the design and initial implementation of the CERTIFY Software Platform, including (i) a secure bootstrapping mechanism using flexible/lightweight protocols (T5.1) (ii) continuous monitoring of devices' trustability and integrity, (iii) detection capability to identify intrusions and potentials threats or misbehaviours and (iv) correlation of threat data and an automatic incidence response.
In the CERTIFY methodology, proof of compliance to the latest device certification and runtime configuration is achieved through an extended version of the MUD/threat MUD file. We extended the MUD and threat MUD (KPI 4.2) with a description of the behavioural profile of a device during the network bootstrapping stage, as well as a recommended response for a threat identified at runtime.
CERTIFY is also leveraging a Secure Element based on the ST33G1M2M hardware with a Global Platform-based operating system. In this phase, a Javacard applet was implemented (first release) that supports AES key provisioning, secure data storage, and cryptographic operations such as signature calculation (HMAC) and key derivation.
This first reporting period is focused on the design and initial implementation of the CERTIFY Software Platform, including (i) a secure bootstrapping mechanism using flexible/lightweight protocols (T5.1) (ii) continuous monitoring of devices' trustability and integrity, (iii) detection capability to identify intrusions and potentials threats or misbehaviours and (iv) correlation of threat data and an automatic incidence response.
In the CERTIFY methodology, proof of compliance to the latest device certification and runtime configuration is achieved through an extended version of the MUD/threat MUD file. We extended the MUD and threat MUD (KPI 4.2) with a description of the behavioural profile of a device during the network bootstrapping stage, as well as a recommended response for a threat identified at runtime.
CERTIFY is also leveraging a Secure Element based on the ST33G1M2M hardware with a Global Platform-based operating system. In this phase, a Javacard applet was implemented (first release) that supports AES key provisioning, secure data storage, and cryptographic operations such as signature calculation (HMAC) and key derivation.
CERTIFY will develop a service to support security information sharing between the different stakeholders to support the continuous security assessment throughout the device lifecycle. For this, CERTIFY will consider DLTs technology as a promising approach to enable a trustworthy and transparent platform for sharing cybersecurity information among stakeholders that do not share a common trusted third party
CERTIFY aims to extend the usage of behavioural files to express configuration policies that the deployment domain could apply during the bootstrapping to configure securely the device, reducing the device’s attack surface. A more expressive behavioural profile will be designed to provide a higher expressiveness, allowing to specify different types of policies at different layers beyond the network one. This profile will also include useful information related to the device, for example, vulnerabilities associated. On the one hand, CERTIFY will use MUD files to deliver policy requirements for a device joining the network and then translate them to network access specific policies. These policies, together with the device's information previously mentioned, will be used to decide if the device is secure enough to join the network and to configure it securely according to the defined policies. Finally, CERTIFY will exploit the information of the MUD files during the bootstrapping process to obtain the security policies before the device has access to the network and therefore, configure it before any attack could be performed.
CERTIFY will build security solutions for embedded devices based on the reprogrammable generic node platform and customized with the introduction of a SE designed in alignment with the Global Platform's open ecosystem for secure-by-design digital services and devices. Such SE, in charge of hosting and providing confidential cryptographic data and keys will be built exploiting chips devoted to mobile connectivity (i.e. the SIM card) or software-based solutions to avoid the higher cost and complexity associated with devoted TPM hardware. On the other hand, such a scenario makes the security attestation harder (including integrity and confidentiality) as the devices can be physically accessible to an attacker or the device may need to operate in harsh environments. Fitting the philosophy of the CERTIFY lifecycle management framework, the customizable TEE will support trustworthy monitoring of continuous compliance with given cybersecurity requirements as well as NIST-specified bootstrapping mechanisms along with enhancements proposed by CERTIFY. Ultimately, the customizable TEE will allow designers to i) rely on open HW development, enabling full transparency of IoT design flows and verifiable implementations of security-sensitive components, ii) exploit the flexibility of the SW trusted environment to develop custom self-monitoring and self-intrusion detection systems, auditing support, decommissioning mechanisms, etc., iii) enhance the credential security level, guaranteeing that the set of credentials stored on IoT will not leave the device even when malicious software is installed, iv) enhance the HW security allowing for certified software components executed on the device, in which the trust is spanned from the HW security module, and v) perform effective maintenance mechanisms, e.g. trustworthy channels for OTA security patches, which will fully match the vision of CSA towards comprehensive IoT lifecycle management.
CERTIFY aims to extend the usage of behavioural files to express configuration policies that the deployment domain could apply during the bootstrapping to configure securely the device, reducing the device’s attack surface. A more expressive behavioural profile will be designed to provide a higher expressiveness, allowing to specify different types of policies at different layers beyond the network one. This profile will also include useful information related to the device, for example, vulnerabilities associated. On the one hand, CERTIFY will use MUD files to deliver policy requirements for a device joining the network and then translate them to network access specific policies. These policies, together with the device's information previously mentioned, will be used to decide if the device is secure enough to join the network and to configure it securely according to the defined policies. Finally, CERTIFY will exploit the information of the MUD files during the bootstrapping process to obtain the security policies before the device has access to the network and therefore, configure it before any attack could be performed.
CERTIFY will build security solutions for embedded devices based on the reprogrammable generic node platform and customized with the introduction of a SE designed in alignment with the Global Platform's open ecosystem for secure-by-design digital services and devices. Such SE, in charge of hosting and providing confidential cryptographic data and keys will be built exploiting chips devoted to mobile connectivity (i.e. the SIM card) or software-based solutions to avoid the higher cost and complexity associated with devoted TPM hardware. On the other hand, such a scenario makes the security attestation harder (including integrity and confidentiality) as the devices can be physically accessible to an attacker or the device may need to operate in harsh environments. Fitting the philosophy of the CERTIFY lifecycle management framework, the customizable TEE will support trustworthy monitoring of continuous compliance with given cybersecurity requirements as well as NIST-specified bootstrapping mechanisms along with enhancements proposed by CERTIFY. Ultimately, the customizable TEE will allow designers to i) rely on open HW development, enabling full transparency of IoT design flows and verifiable implementations of security-sensitive components, ii) exploit the flexibility of the SW trusted environment to develop custom self-monitoring and self-intrusion detection systems, auditing support, decommissioning mechanisms, etc., iii) enhance the credential security level, guaranteeing that the set of credentials stored on IoT will not leave the device even when malicious software is installed, iv) enhance the HW security allowing for certified software components executed on the device, in which the trust is spanned from the HW security module, and v) perform effective maintenance mechanisms, e.g. trustworthy channels for OTA security patches, which will fully match the vision of CSA towards comprehensive IoT lifecycle management.