Next steps

Future outlook

From prototype to production

The deliverables are focusing on specifications and prototyping. We experimented with small building blocks, using the tools which enabled the simplest development experience. Even if that wasn't the goal of the project, what would it take to put into production?

Going into production would also require a common stack for native embedded systems. C is the most widely used programming language, but doesn't provide modern and safe capabilities. We believe in the future ziglang might be well suited to the task. It is safer than C, but maintains ABI compatibility therefore enabling easy and gradual interoperability with existing systems. With many new concepts, rust proves not that easy to scale within a team, although the quality of tools (such as rust analyzer) and quality materials can really improve the learning curve, as we started to do (and will continue to expand). Rust brings the benefits of a more mature and coherent (except partially for async/await) ecosystem (and a growing community for embedded systems, without the standard library), and so provides the best option for the years to come. For instance, debugging tools such as the probe library, on which it is possible to build further, come a long way compared to traditional tooling. rust also brings much better memory safety. So rust is our choice, and we're now developing the opensource framework with it.

Note: our prototypes use LVVM, which has limitations for 8 and 16 bits architectures, which we considered out of scope.

The next step would be to include our building blocks into a large scale experimentation. We contacted several vendors, but so far, the answers have not been very positive. Healthcare organisations didn't have enough resources during that COVID-19 period, and most vendors seem comfortable with their state of security, despite all the limitations and potential attacks (presumably they don't want to open the pandora box of having to implement much more requirements). Only regulation can significantly change that state of mind.

Focus on IETF GNAP + DIF KERI

Probably also, trying to solve the issue generically is too broad in scope. Most people are focused on keeping their current infrastructure safe, which means that one needs to find how to cope with legacy and unsafe infrastructure first (cf use cases for healthcare IT and BMS). That's the path taken by most competitors, although most of them only provide additional observability, without any guarantees on actionability (especially considering the limited resources of healthcare organizations, for anything that's not directly related to their core value).

As far as we know, only mbed, ockam and medcrypt have taken the alternative path of improving protocols. Sometimes, this felt like an effort to boil the ocean, and is likely to be difficult for European players as the largest medical equipment vendors are US based and aren't threatened by competition. Regulation might provide sufficient incentives for them to work more on cybersecurity, but they tend to consider they're good enough (which seems an over-statement, from what we've observed) and our efforts have been received with little interest by those quasi monopolistic vendors who can still wait, especially if the medical benefits are strong enough.

Through our testing, we realized that we needed to change the scope, while still supporting the business cases put forward by healthcare professionals. Hence our choice of DIF KERI (for identity) + IETF GNAP (for authorizations). The most drastic consequence is our reliance on HTTP, which is not the obvious choice to include IoT devices. Yet, we demonstrated that HTTP/3 provides great prospects as a core layer, especially if it is completed by SCHC header compression.