Integrating IoT With SSI-Enabled Technologies For Healthcare

So I, my name is Chris. I am a post-doctoral cybersecurity researcher at the information technologies Institute of the center for research and technology had last, which is Greece's largest research Institute, which is also located in Tai the second largest city at the Northern part of Greece.

So the focus of today's talk is as we set on integration of IOT with such sovereign identity technologies for healthcare use cases, I'm going to showcase a very brief and high level overview of our research and development efforts in the context of the pharma ledger project, which in a few words, leverages distributed ledgers in the domain of healthcare. So a few words about search teams. So first we have our team is led by Dr. Cost's ES who's a great B researcher and the director of the vision analytics lab here at se, and who also serves at the, as the scientific coordinator in pharma ledger.

The remaining members of the core team are Dr. Christina Azia and Mrs, who are responsible for project management, business analysis and use case oversight tasks, respectively, and last but not least, we have a very long list of dedicated developers, which have contributed both in individual use case development efforts, as well as the SSI related technical infrastructure that I will briefly present later on. Okay.

Now, a few words about the project now, the pharma ledger project brings together 28 partners from 10 EU members states, including 11 large pharmaceutical companies. Eight of them are in the top 10. The consortium is further comprised by several SMEs, universities, supply chain partners, patient representatives, and leading healthcare service providers.

The projects efforts are funded by the innovative medicine initiative or IMI insured, which is a joint fund among the European union and the European pharmaceutical industry, which is represented by the European Federation of pharmaceutical industries and associations or FPF in short, the overall value proposition of pharma ledger revolves around research and development of entirely blockchain based framework that will provide for the efficient digitization of the healthcare industry that will benefit the entire ecosystem of actors, meaning from manufacturers all the way to patients, the platforms that we develop in pharma ledger aims to aim, to serve as a single source of truth, especially in the context of identity as a single source of truth, that will enable the agile delivery of innovative healthcare applications, not trusted and privacy preserving fashion.

Since that the latter especially is very important in healthcare now, in terms of use cases, pharma framework will is, is, and will be validated in what they're called three domain reference applications or DS insured, which mainly revolve around supply chain. So that's first clinical trials, that's the second category. And the third one is health data marketplaces. Okay. So in terms of objectives, the project cover the entire spectrum.

So we have on the one hand business and the regulatory related topics, the projects efforts involve the establishment of first of all, an effective governance framework that will proliferate the project's outcomes following its completion by involving key healthcare ecosystems stakeholders in a sustainable and evolving fashion.

Furthermore, the project also has an entire work package that is dedicated in legal and ethical framework in, in the development of a legal and ethical framework, as well as recommendations to the European union to ensure regulatory legal and data privacy compliance, including of course, GDPR, but also in terms of drug development, manufacturing, distribution, and other relevant regulations.

The overall call is to ensure legal validity and regulatory compliance of blockchain policies related to data, sharing security and consent among others from a technical standpoint, far ledger would, is developing a scalable and sustainable reference architecture that ensures privacy and confidentiality of data and transactions while providing a secure, fine grain and patient controlled consent system for healthcare and research purposes, the framework will allow greater and secure access to information across use cases, especially the ones that integrate IOT devices, for instance, various sensors and medical devices.

We are going to look at the minimum moment. So as to leverage the tremendous benefits that they provide. Okay. So in terms of use cases, as I mentioned previously, we have three diverse domain reference applications, which are presented here. So for the supply chain category, we have four different use cases, two for the health data and two for the clinical trials, DS respectively. Now I'm going to focus on the ones that are strictly, strictly involved in with IOT.

Now, in terms of the current status score right now regarding IOT involves, especially in the domain of healthcare closed source devices that are paired with their respective manufacturers platform or cloud infrastructure that researchers or various investigators have to query in retrospect, in order to obtain access to data. So that's the big picture. So what basically happens is that these device manufacturers act also as data brokers.

Now, what we want to do in pharma ledger is we want to essentially to remove this middle map from the picture and store the data in neither private storage mediums that are completely patient controlled and deploy distributed ledgers for integrity and verifiability. Now, the main idea here is that we want to empower patients to grant and revoke access to data originating from medical devices that are assigned to them to clinical sites, for instance, and other settings.

Now briefly, I want to mention that the ideas and verifiable credentials serves serve as the main building blocks to provide the secure, trusted, and verifiable data share.

Moving on, on top of the services that allow us to do to develop the previous use case, the personalized medicine use case aims at improving among others, the clinical trial recruitment process through health data marketplace that will additional additionally provide solutions for completely digitized electronic health records and will solve a lot of problems there among others and offering discovery and appropriate reward mechanisms.

To, for instance, patients, this holistic framework is envisioned to accelerate drug development significantly and reducing most importantly, recruitment timelines and costs, which are the biggest, the biggest hindrance right now when it comes to setting up and running actually actually trial. Okay. Now shifting our focus a little bit on the types of IOT devices that are, that exist in the context of healthcare here, we can CRF categorization, which involves devices that are where the medicals and the better devices, examples are insulin pumps and pacemaker, for instance.

And then we have bigger devices, which are not typically thought of as IOT devices, but IOT is an all inclusive term, especially nowadays. So we have also stationary medical devices that are bound to specific sites, for instance, such as chemotherapy dispensing stations. And lastly, we have the more common, I would say, and less intrusive category that is more, more oriented towards monitoring vitals, such as smart watches withs and all of that.

Now, regardless of the type of IOT device that we have at hand, in order to leverage their provided benefits, there is a common and mini minimal set of issues that we need to address. And you can see it in the middle. We have device identification, location, how do we communicate securely sensory data and requisite for which of which is ubiquitous connectivity.

Now, an unfortunate, an unfortunate and sadly inevitable side effect of any rapidly growing and penetrating technology is its simultaneous susceptibility to value security related attacks and threats and empirical fact to which IOT is by far exception. These are cascaded even further due to the large technical discrepancies among vendors and the respective platforms in the context of IOT.

First, we, one of the big challenges is the inherent resource constraints of IOT devices, which pose one of the most significant security related roadblocks. And since pharma ledger, domain of interest necessitates the adoption of advanced cryptography based security solution, while also accounting for hardware related constraints thinks get very messy in terms of power usage, storage volatility, and other factors. Now the next challenge in line relates to those of, as I mentioned, identification authentication, authorization, that specific order.

And while people think that there are several security models in practice that are supposedly successful over the intern for the past 10 years, there is a very large discrepancy of involved requirements regarding security, performance and risk management. And on the other hand, the involved management policies of all these issues. So basically there is no one size fits all, and we can see that even internally in the project.

Now, the set of challenges is expanded even further since modern use cases require, as I said, data, privacy, integrity, and Providence to be insured, which is an integral part of data supply chains. So to provide that data actually should be sticked to very specific entities, be human software processes or IOT devices as dictate by the appropriate authorization policy. Clearly there are additional reflections regarding the life cycle of IOT devices, which arguably are of extreme importance as well. There are several different phases, but these are considered out of context of our work.

So in the interest of concreteness, our efforts, we're focused on tackling and resolving technical issues that provide basically application agnostic, secure, flexible, and interoperable building blocks for digital identities that can be used as black boxes by individual use cases. So that's, so life cycle is outside of our, of our reference.

Now here, we can see a overview of the most prevalent digital identity models that, that have been proposed and deployed throughout the years over the internet to address its lack of solid digital identity layer. And hopefully as we all know, these models bring forth severe baggage, an unex exhaustive list of which is presented here moving a little bit quickly because I assume the audience is knowledgeable. And this matters now inspired by the innovative technological advancement that was initially introduced by Bitcoin.

We all know that there is a hybrid identity model that, that emerged in which connection between entities become completely peer to peer. And this in turn gave birth to new decentralized identification standards, which we will discuss in the moment and the functions.

Similarly, how identification works in the real world. Here, we can see the funding principles overview of the funding principles of this new and emerging digital identity paradigm that briefly on the one hand address address the pitfalls of centralized and federated paradigms paradigms, but also they addressed fundamental digital trust issues at the infrastructure layer. So informal ledger, since we want completely to be future proof, and we want to provide a pervasive platform, it became quickly evident that ized the proper approach.

Now this can be more clearly illustrated by this figure where we show that when you move towards the SSI model, the shift in focus that occurs is where the individual becomes the center of attention. So imagine that the patient or whichever end user is placed in the middle than the other way around with the other two models. Now a quick overview of the main actors that are involved in an SSI E system. So we have the issuer who is the point of initiation, who issues, credentials.

There are prominent examples of that can fulfill this role, are government agencies, financial institutions, universities, NGOs, and many, many others holders request I will get for issuers. They store them in a digital wallet, which is an application let's say on the phone and present proofs of claims from one or more credentials when requested by the last entity, the last actor, which is called theier and small caveat here, especially to link it with IOT. Although we must commonly think of real world individuals as holders or approvers, this can also be organizations or even IOT devices.

So there's no problem there. Now, these actors are brought together by the security properties of distributed letters or other forms of decentralized network with whatever security properties they have that essentially serve as a root of trust and provide for verifiable and secure sources of identification information.

Now, these are the technical stacks, the technical standards apologies that comprise the SSI stack along with the responding standardization bodies. A large part of our efforts was dedicated to extensively researching and evaluating these standards and providing a very dense source of information regarding their status maturity, as well as various nuance implication of the implications of their practical application. So in the interest of time, I will be presenting our findings that are related to only to decentralized identifiers and verify financial standards, which are the most famous ones.

So in terms of the ID standard, the first issue is that there are a lot of D ID methods, 78 last time Mac, which are completely out of sync with the core specification, which is also matched by the way, as a draft or experimental for more than one and a half year, which essentially means it can be obsoleted. The core specification overall is rid with conflicted statements, even for its core function, function such as key agreement, capability, vocation, the services specification and others.

Surprisingly, we find it very concerning that they want to complicate the standard even more by adding additional parameters, which in our view at least is not very advisable. The most concerning issue is that there is no security expert expert or cryptographer in the author list nor even as a contributing member. And the standard also has not undergone any kind of security review or there are no test cases provided. And also what he mentioned is that there, there are significant compatibilities between the different serialization models that the standard aim to support.

So we have Jason DNC board. So seems that lost less of information is impossible in terms of the verifiable potential standard. This is the only standard that has been improved by the W3C.

However, it's usability and maturity, especially for people who are in the community is questionable when every single layer builds upon is in draft status. The majority of the standard sections, especially the ones regarding security and privacy are targeted as non normative. All the complimentary specifications are in draft mode, experimental phase. And this is extremely important, especially when we look at the linked data proofs specification, which just as the foundation for encoding proofs included in the verifiable intervention and verifiable presentations.

Now, few words about the, the, the, the research description framework, which is a standard model for semantic data models or ontologies. It's not very well known that it ha it does not have a standardized canalization format. So basically what this means, even if we assumed that, that there is such an algorithm, which there isn't, we still have another problem, which is called basically the graph ISO isomorphic isomorphism problem, which is involved in the framing process of Jason LD or the structures in general, which is an MP intermediate problem.

So it's very hard, basically, at least as hard as the integer factorization and the log problems, which are the problems upon which the security of the entire internet is based upon. And lastly, we have an additional issue where the WC proposes the usage of detached signatures. For those of you who don't know, they did the same thing in the context of the XML standard. And there was a large plethora of security issues, which then they attracted.

But I guess maybe there's some kind of disconnect inside the, the WC now, regardless, the, the whole point is that the SSI stack is just a small part of the overall picture. The fact of the matter is that data models are not enough practically deployed systems, need agents that can communicate with the standards with each other, and none of these standard address, any of the critical issues, such how do you design protocols for secure communications?

How do, how do we design protocols that involve zero knowledge, entropy sharing and all of that in order to do appropriate proofs? How do you define the messages? How do you define the state diagrams, the rules?

And so all of that, which are what makes a system practical and usable, none of these standards do anything about that now, based on our assessment, the only real world system that can meet all of our requirements was Hyperledge, which is currently considered the most mature size system implementation that has demonstrated its ability to provide acceptable level of performance in a variety of production grade use cases. It is an open source project, and then the umbrella of the Linux foundation, which is very important for us since we are also committed in opensource.

And it has a very large diverse community of contributors that are energetic and collectively collaborate in the pushing the, the paradigm of SSI into the mainstream. Now, this is a very high level of review of the architecture of our TSSI infrastructure based on Hyperledge. The developed infrastructure covers both the enterprise and the user domains, and is composed of a diverse set of services, tools, and components.

First, we have the IOT secondary blockchain network, or I P insured, which is a globally connected, transparent, and provides an interoperable blockchain for shared sovereign identity. It has a, it, it consists of a validator pool, which are basically the notes that run the consensus and provides verifiable data. It provides and implementation of that data registry for the participating and entities note that the ledger is entitled as secondary because in pharma ledger, we employ multiple blockchain networks. As part of our flexible architecture.

Here, you can see a glimpse of the web platform, that platform that we have developed for verifiable issuers that allow the establishment of private peer-to-peer connections. Now, these can be automatically established or by having users scanning QR codes, the platform provides visualization of credentials, scanners that are posted on the ledger. And also it allows, so here you can add a new credential on the ledger, and also it provides full management of the actual credentials credential definitions, which been on top of theses that we presented previously.

And here one can issue a new credential over a private connection. And here we can also manage the credentials that have been issued. We have an example of a degree certificate driving driver's license, which you can click on and see additional additional information now. So that's about the potential issue.

Now, there are communication issues that stem from the intermittent connectivity of edge agents. We talked about you because you be disconnectivity in IOT devices. So what we did is we developed horizontal, scalable mediator infrastructure, which can be simply thought of as glorified message buffers for encrypted messages. We are currently exploring mechanisms of building on top of mediators to deliver a completely anonymized network for encrypted message delivery. Our service is very extensible and can handle multiple complex deployments scenarios, such as cross domain communication.

Additionally, as part of our efforts, we develop across platform self-contained edge agent for both Android and iOS, and it can also run on Linux with minor modifications. The term self contained entails that the agent is equipped with a locally stored, secure digital wallet for keys, DS did documents UHCs and all of that. The agent also capable of communicated directly with the ledger, without relying on example, API gateways or anything shady like that.

Here, we have a couple of screens from the initialization of the edge agent, a list of its private connections and how I can create one, some additional functionalities of the UI like filters and all of that credentials. Also various types of displaying them. And also the ability to directly share between mobile agents credentials via verifiable proofs. And this is how our sample proof request looks like lastly, to bridge the gap between the world of verifiable credentials and data of typical web security.

We developed what we call the verifiable credentials, verification service, or VC vs in short, which provides, provides for VC based authentication and authorization by adopting the open ID connect standard. This service essentially acts as an external identity provider, similar to how Google or Twitter rather federated systems to currently on the web web.

However, contrary to these other providers, user authentication via this service inherits all the properties of SSI, such as data portability minimization, and also can be seamlessly integrated. It has a very flexible and scale level and accessible architecture can support multiple instances of agents controllers and all of that and all types of relationships.

Now, here, we can see a very simple example of the webpage that is displayed when a user wants to authenticate selves to what, to a website and clicks on the VCs login button. Essentially this displays a secure code that the, the end users count with her mobile agents, which will probably see slow at the background. What happens is that our connection connection list present proof flow is initiated. And assuming that the end users could ions are valid, an open ID connect compliant token will be issued, and the user will be directed to the services respective main webpage for typical security.

These two codes are shortly as you can, as you can see on the right side of the screen. And of course, if the credentials of the user are invalid, as the service is able to detect it by communicating with the ledger and visualizes an appropriate message to the end user and obviously denies access to the respective service. So that's all I had to cover. Thank you very much for your, for your happy.