The project started with the elaboration of the security baseline, listing, and prioritizing all potential threats and related protection measures that the planned security architecture needs to fend off and implement.

The architecture design work resulted in a service platform comprising a secure IoT router and several loosely coupled configurable components – access management system, attack detector, honeypot, runtime monitoring system, and a common data repository with a dashboard – which provide comprehensive protection against a wide range of the most common attacks. The design principle was to establish a system that is flexible, simple to deploy and operate, and can provide high-level protection without the need for highly skilled security professionals for its management, which is in short supply. The target audience for the platform is SMEs and private operators who have started to realize the need for high-level security but lack the necessary expertise for the operation of complex systems.

The IoTAC platform

Implementation of the modules took over a year and was assisted by a sophisticated DevSecOps environment as well as a security-by-design monitoring tool. The purpose of this environment is to ensure high-level code quality, the early detection of potential vulnerabilities, and a seamless continuous development and deployment process.

The completed platform has been validated in four different IoT domains to demonstrate its versatility and adaptability to the various service requirements. The Prosumer cell operation, the Connected car, and Drone operation pilots represented industrial IoT requirements, and the Smart home operation is a consumer environment. At each of these pilots, a different configuration of the platform was deployed and integrated, demonstrating the versatility of the IoTAC platform. Each of the pilot operators was defining performance and security targets, KPIs, that the IoTAC system needed to meet, or exceed. The objective was to increase the security level of the protected environments without interfering with the operation and degrading the quality of service. After a tedious iterative process, by the end of the project, it can be claimed that the deployed architecture at every pilot location not only met but exceeded the initial expectations.

This was the result we aimed for, but it was not something that could be guaranteed, as much of the technology used was truly novel and the integration of the security functions may have carried unanticipated challenges.

Besides improving the security posture of the pilot operations, the technology developers also greatly benefitted from this exercise. These partners not only developed new tools, but also gained first-hand experience from the deployment, integration, and operation of the platform and their individual modules, could remove previously undetected errors, and could also perform improvements both on the operating capabilities of the modules as well as on the service set up, and provisioning procedures.

The IoTAC project has also actively supported standardisation, by working with ISO and ETSI.
The project was using the ISO/IEC 30141 architecture reference model as its underlying guide for the IoTAC architecture and eventually prepared a security extension for the document. The recommendations are related to WG3 IoT Foundational Standards and have been submitted to the working group. If accepted, it would result in a contribution to the newly planned ISO/IEC 30149 document instead of the ISO/IEC 30141 Ed. 2. The publication of the second edition of ISO/IEC 30141 and ISO/IEC 30149 is expected in 2024 at the earliest.
The IoTAC project has actively participated in the work of the ETSI Technical Committee to contribute to the development of ETSI deliverables. Specifically, the project has been involved in the Working Group TST. As part of the project’s engagement, two work items have been initiated. The first document is a Technical Specification (TS) titled “IoT security module testing,”. The second document is a Technical Report (TR) titled “IoT security architecture conformity,”. A publication of both documents TS 103 942 and TR 103 946 is expected in a few weeks and will be publicly available.

IoTAC has actively communicated and disseminated project results via various channels. Project partners published 10 scientific journal papers, one book, presented 20+ papers at academic conferences, and made presentations at several industry events. We published 55 insight posts on the IoTAC homepage. The project exhibited together with sister projects from the same call at the 2023 Barcelona Cybersecurity Congress where the results of our work have been presented to a broader industry audience.

Barcelona Cybersecurity Congress

The project organized the EuroCyberSec 2021 Workshop, publishing the proceedings in a Springer-published book. The organisation of the annual online IoT Day workshops in April has been the most relevant communication achievement of the IoTAC project. Starting in 2021 with presentations of 3 H2020 IoT projects, by 2023 it grew to a large international event with the participation of multiple standard developing organisations, multinational companies, and also the US NIST, focusing on the impact of the new European Cyber Resilience Act, with over 140 participants.

The project has been completed but the work does not stop here. The IoTAC partners have established the IoTAC Association with the purpose to support and coordinate the forthcoming exploitation activities of the project results. It is expected that in a couple of years, the IoTAC platform will become a sought-after niche technology.

The post Key aspects of the IoTAC project appeared first on IoTAC.

Verifiable credentials are frequently stored decentralized, sometimes in digital wallets of the users. There are numerous projects underway both in the US (e.g. mobile driving licence – mDL) and globally (e.g. ICAO, EU Digital Identity Wallet) to provide users, citizens with a digital means to securely identify themselves. Related technologies have also been standardized (e.g. ISO, 3WC, OpenID).

Authentication and Authorisation usually go hand-in-hand, authentication is a precondition of authorisation and is still decentralized, digital authorisation is practically non-existent though such a solution could have at least the same, but potentially even more benefits than Verifiable Credentials.

The Front-End Access Management (FEAM) technology of SafePay stores the user credentials, access rights in a secure element at the user side. This secure storage may even be shared with Verifiable Credentials of the User, may be a SIM card or embedded secure element of a smartphone, may be a Trusted Execution Environment (TEE), or even a cloud-based secure storage facility (Card Farm).  FEAM relies on the concept of OAuth and uses the same signed access tokens but provides independence from central authorisation systems. As a result of the decentralized architecture, communication overhead is substantially reduced, single point of access failure is removed and user profiling by external parties is prevented. Additional major benefit of the technology is that it provides identical transaction procedure and the same high-level security for both online and offline transactions.  The fact that FEAM uses the same type of access tokens (JWT) as OAuth supports its introduction to a large, deployed user base. The technology can also be simply integrated into poorly protected legacy environments without any modifications to the business procedures, communication protocols.
The technology is validated in diverse service environments including connected cars, smart home, prosumer cell operation, and drones. The solution has been adapted to various communication protocols and presently supports REST, TCP, UDP, and MQTT channels. FEAM also provides flexibility with respect to its topology as it can be operated both on-premises as well as in the cloud.

FEAM will not stop here, the next step in its evolution will be the introduction of device authorisation. In this concept, a built-in secure enclave (TPM chip, TEE, iSIM) will store those functions which the device may perform. These functions will be defined by the manufacturers – possibly in the form of MUD files – and customized by the operators of the device. The resulting architecture will prevent the overtaking of IoT devices and using them for malicious activities which happened in the past in the case of large-scale DDoS attacks. This internal control of operation will not only become a new security-by-design feature but will also provide a second line of defense against taking over IoT devices. In this scenario it will not be enough any longer to break the usual username and password or similar protection but to misuse the device also its secure element should be compromised otherwise it will not be possible to alter the intended operation.

With its unique architecture, FEAM opens a whole new approach to user and device authorisation, but whenever possible it uses existing industry standards and best practices. In the development process ongoing industry initiatives are actively monitored to ensure that the solution will be future-proof and will be able to satisfy upcoming, novel requirements.

You can watch a short video about the transaction flow here.

The post The roadmap of FEAM, the Front-end Access Management system appeared first on IoTAC.

The post Summary of the Roundtable “Compliance and Beyond: Understanding the Impact of the New EU Cyber Resilience Act” appeared first on IoTAC.

Let’s look at the factors which could enable this development:

Regulatory environment:

There is a significant new development in the regulatory framework, at least in Europe.

“The European Parliament has adopted the Digital Markets Act (DMA) that will obligate Apple, Google, and other “gatekeeper” technology companies to allow app developers and third-party service providers access to device functionalities “such as near-field communication technology, secure elements, and processors, authentication mechanisms and the software used to operate those technologies”.[1]

DMA paves the way for the flexible use of the secure elements. However, to really leverage the potential created by the new regulation an adequate ecosystem needs to be established. This may have the consequence of some further regulatory involvement.

Technology:

Secure elements

There are more types of secure elements – chip cards – in the smartphones than ever before. The removable SIMs (UICC) in various form factors, the eSIM and iSIM, as well as the embedded secure elements without the SIM functionality. All these chip cards could theoretically be used as secure storage devices.

Smart phones

There are almost 7bn smartphone subscriptions worldwide[2], with annual smartphone deliveries of over 1.5bn annually, including the new type of personal devices, the smartwatches.[3] All these phones have at least one secure element inside, which could be utilized by secure applications.

NFC capability

Most of these smartphones are also NFC capable. The secure applications/services could not only be used for securing online transactions but also for communication with various reader devices, POS terminals, gate readers, controllers, etc.

Application interoperability

It seems that we are getting closer to application interoperability as well. “The GSM Association has released a new requirement specification[4] for Secured Applications for Mobile (SAM). This specification describes how cellular connected devices (e.g. smartphones) may use secured applets within an eUICC (embedded universal integrated circuit card).”[5]

Logistics

This is the most difficult part of the concept, requires the most work, because practically nothing has been achieved in this respect so far. Without the right operating model, the DMA cannot achieve its desired effects either.

The concept must be based on an app store-like customer service model, must assure application security through a certification program, and also must achieve technical transparency for the service providers. A seamlessly integrated supply chain must be established.

Business model

In this complex ecosystem, I just consider the key stakeholders, who must transact with each other, in an ad hoc manner, potentially also without long-term agreements and without bilaterally pre-negotiated financial conditions. The key actors are: consumers; service providers; secure element issuers (owners).

The axioms, which seem to be obvious but have been questioned in the past:

• Security has value that must be paid for;
• Service providers must generate revenues for the services they provide;
• Provisioning secure storage capacity costs money which needs to be recovered from revenues.

The point of the story is that customers will need to pay for secure mobile services. This is not an uncommon business model even in the telecom sector as premium/paid apps are widely used. The fees charged to customers must cover the revenues of the other two parties.

Market and demand

Earlier, everyone was searching for the “NFC killer application”. Obviously, no one found it, as such a service does not exist. But today there are already so many potential use cases that we do not even need to search any longer. So, let’s see the most relevant ones:

Mobile payment: Mobile payment became mainstream already today with Google Pay, Apple Pay, Samsung Pay, Ali Pay, PayPal, etc. Emarketer expects 1.31 billion people to use mobile payment this year.

Mobile ticketing: The technology has been implemented in numerous large cities worldwide and the penetration continues. Several million people use it day after day and its expected value is forecasted to exceed US 10Bn this year.

The rising demand for smart ticketing from sports, entertainment, and tourism sector is another opportunity for using secure smart communication devices in the ticketing sector.

Digital ID: Digital ID is a relatively new phenomenon, but with a global reach, great legislative support, and a vast prospective market. The European Commission, ICAO, IATA, the World Bank, and many countries have related initiatives.

Identification and Access Management (IAM): IAM is another domain where chip cards have long been used and which could be revolutionized by introducing the secure mobile application technology.

FIDO (Fast ID Online) creates a new key pair during registration. User retain the private key in a secure device and register the public key with the online service. Authentication is done by proving possession of the private key to the service by signing a challenge. FIDO is supported by all major browsers.

Cold wallets are used in the crypto world to store larger amounts of crypto offline, as a protection of the funds. The secure mobile architecture would be a great alternative providing the secure storage with an always-on capability.

Front-end Access Management (FEAM) combines the best features of FIDO and OAuth. A chip card is used for authenticating the user, authorizing the transactions, and generating the web tokens to be used for accessing the protected resources. The technology can be used for both online and offline access.

Bring Your Own Device (BYOD) received real meaning and importance with widespread remote work practices. The secure elements could well be used for securely authenticating the users’ communication devices thus substantially improving enterprise security.

The above list contains only a handful of potential use cases that could well leverage the potential of secure mobile services.

In summary, we can determine that most conditions, except the integrated supply chain and the associated business model, are ready for the breakthrough change of using the chip cards inside the smartphones and smartwatches for our personal security purposes.

If you want to know more details and potential consequences of the “secure application on the SIM concept” read this Whitepaper.

[1] https://www.nfcw.com/2022/07/07/377870/european-parliament-passes-law-that-requires-apple-to-open-up-its-nfc-chip/

[2] https://www.statista.com/statistics/330695/number-of-smartphone-users-worldwide/

[3]https://www.statista.com/statistics/263437/global-smartphone-sales-to-end-users-since-2007/, https://www.statista.com/statistics/878144/worldwide-smart-wristwear-shipments-forecast/

[4] https://www.gsma.com/newsroom/wp-content/uploads//SAM.01-v1.0.pdf

[5] https://blog.protocolbench.org/2021/06/gsma-published-requirements-for-secured-applications-for-mobile/

The post Could mobile communication devices be used as secure storage of sensitive information? appeared first on IoTAC.

In all the four cases the core security functions, the hosting of the users’ secure elements, chip cards, and their secure applications, will be provided by a card farm.

The card farm will have a multireader – this device is also a development of the IoTAC project – which will host 16 JAVA chip cards each storing seven IoTAC user secure applications. All in all, this architecture will be able to serve more than 100 users and if necessary, the number of deployed multireaders can be increased, the operation is flexibly scalable.

Although the four pilots will be located at four different geographic locations and will have completely independent architectures, one single card farm, which is a multi-tenant cloud-based operation, will provide security services for all of them. This operation will be maintained and supported by ATOS Hungary.

The Management modules of the four FEAM services will initially be run remotely from the architecture of SafePay. Four independent modules, one for each operation, will be installed and configured. Initially these modules will not be integrated with the legacy architecture of the pilot services. Their databases, in terms of available functions, operations, the list of users and their privileges will be populated manually. In the second pilot cycle some deeper level of integration may be possible, but it is not a major target of the exercise.

Figure 1: FEAM Architecture

The Management module is the FEAM component which establishes the link between the local pilot operations and the card farm. The four Management modules will be registered with the card farm, each of them will have a number of secure elements allocated, and these dedicated chip cards will be assigned to their respective users.

It is the Resources server, or Gateway module of FEAM which must be deployed locally at each of the pilot locations. It is also possible to have more than one Gateways for any of the pilot operations should the architecture require more than one access points. The Management module will remotely configure and manage the Gateway(s) which belong(s) to its specific operation. Configuration comprises key exchanges and the generation of certificates, while the operation covers the synchronisation of operating constrains and the collection of service logs.

In the first pilot cycle each FEAM Gateway module will be running on local servers connected through an API to the secure internet gateway of the pilot operation, while in the second phase of the operation, a tighter integration is foreseen, and the modules will be hosted by the gateway device itself.

As FEAM will become an integral part of the pilot architectures and operations some level of integration will be inevitable.

On the front-end, user side, the legacy service application (we call it Host application) must be integrated with the FEAM Library and they jointly become the FEAM Client. The FEAM Client may be a mobile or desktop application and both will be demonstrated in one or the other pilot operation. The FEAM library has the task to perform all the FEAM specific functions on the user side. It should receive the original command from the Host application, which without FEAM would be directly sent by the Host app. to the pilot architecture. The FEAM library then communicates with the Card farm, have the command approved by the user secure application, establishes secure communication with the Gateway module and transmits the command to the Gateway. The FEAM Library also receives a response from the Gateway about the result of the operation, or a content, which it passes on to the Host application. There is an API specification available which describes how the Host application should communicate with the FEAM Library.

At this point we expect that at the back-end the Gateway module just needs to be configured to communicate with the protected system, the pilot architecture. The Gateway will transmit the same message/command to the legacy environment which without FEAM, would have come directly from the Host application. The legacy operation should not be changed at all, should not even realize that a robust security mechanism has been integrated into the overall operation.

The post Integration of the Front-end Access Management system into the pilot architectures appeared first on IoTAC.

The post Roundtable „The need for IoT security standards and certifications” appeared first on IoTAC.

The post EuroCybersec2021 Workshop appeared first on IoTAC.

The post White Paper: Front-end Access Control (FEAC) appeared first on IoTAC.

Some basic features of the Front-end Access Control System, the attack detection and prevention model, the honeypot, the secure IoT gateway, as well as the Software Security Design Platform have been presented to the project partners.

Though the implementation phase of the IoTAC project has just started recently, the initial results show that the project is on the right track and its ambitious targets can realistically be achieved.

The post Demonstrations of First Results appeared first on IoTAC.

In the introductory presentation, Mr. Andreas Mitrakas, Head of Unit “Market Certification & Standardization” at the European Union Agency for Cybersecurity (ENISA), gave a summary about the roadmap of the ENISA certification schemes and their relevance for IoT security, looking into the Cybersecurity Act, the candidate EU Common Criteria certification scheme, the draft candidate EU cloud services certification scheme, and other relevant existing certification schemes.

Other presentations by the European Commission, ISO, and multiple industry representatives were describing multiple aspects of IoT certification, including the EU IoT cybersecurity certification framework, the EU standard of connected device security, as well as the cybersecurity evaluation methodology and security labeling for ICT products.

This event provided important input for IoTAC as it gave us orientation in respect of our future standardization-related activities, how we can best align our work with broader EU initiatives.

The post IoT Security Certification @ ETSI Security Week 2021 appeared first on IoTAC.