RSA once again secures the open web
In 1994 the World Wide Web was at a crossroads. The technology that today we simply call “the web,” invented five years earlier by Tim Berners-Lee, was poised to become the de facto interface to the internet. Its document-based, human-centric, point-and-click model was wildly popular among the technologists of the day, and was beginning to see rapid uptake among the broader population of desktop software users.
But something was missing: trust. Because the web was inherently open, any use case requiring trust between parties was impossible. All web traffic at that point traveled in clear text where it could be intercepted, and potentially modified in transit.
At Netscape, engineers were working furiously to address this requirement. It was widely understood that encryption could deliver the necessary security. But deploying encryption on a global scale, with such a critical use case, proved difficult to deliver.
By 1994, Netscape had developed Secure Sockets Layer (SSL) 1.0 for encrypted communication between a web server and a browser, but testing revealed security issues that kept it from being released. Taher Elgamal, Netscape’s Chief Scientist, known as the “Father of SSL,” had previously been Director of Engineering at RSA. He knew that RSA had developed leading-edge cryptography libraries in a product called BSAFE. Netscape built its security solution around RSA cryptography and released it in early 1995 as SSL 2.0.
This solution proved quite durable and has improved continuously; today, SSL is known as Transport Layer Security (TLS). The SSL/TLS approach has secured the Web for over 30 years. With technologies like quantum cryptography on the horizon, we can expect the same level of security to extend into the future.
So why the little history lesson? What does all that matter in 2021?
Well, we’re at it again. The next version of the web is coming, and RSA is delivering the cryptography needed to make web data trustworthy. As Mark Twain said, “History doesn’t repeat itself, but it does rhyme.”
The next version of the web will be based on decentralized principles. A widespread recognition that the web has evolved to favor large, highly centralized corporations instead of the interests of individual end users – you and me – has given rise to a powerful alternative approach. On a decentralized web, users gain control of their own data and identities; with this simple change, apps and services become interchangeable. In a decentralized world, you can easily switch vendors because you own and control the data. You can even share your data among multiple vendors and switch between them seamlessly.
So it’s no surprise that Tim Berners-Lee has designed a major update to his original invention, this time based on decentralized principles. His newest design, Solid, implements a few relatively small changes to completely transform the web. Solid empowers the people who use the web, instead of favoring the companies that dominate it today.
Trust on the decentralized web has several forms, including authentication and access protocols. Similarly, for data provenance and integrity decentralization relies upon a new standards-based model called Verifiable Credentials. With RSA partner Janeiro Digital, we’ve launched the first enterprise solution for the decentralized web at the UK National Health Service (NHS). Let’s take a quick look at decentralization in general, and Solid in particular, and then describe the NHS use case. This shows both the tremendous power of Solid and the role RSA plays in delivering the trust layer for the NHS application.
Decentralization and Solid
Over the past several years, many technologists have endorsed the “re-decentralization” of the web. By putting data and identity under the ownership and control of individual users, it becomes much harder to sustain the big “walled gardens” that result from centralized data apps and services – and which are the cause of so much concern today that efforts to regulate and legislate solutions are front-page news. Berners-Lee himself has lamented the state of the web and how it’s steadily diverged from his original vision of a digital space with freedom and equality.
In this context, Solid is best viewed as the next release of the World Wide Web. Like the original, Berners-Lee designed Solid as a collection of open standards and protocols. As with the original, this model promotes radical innovation; any app or service that supports these standards, using any underlying technology, can deliver all the benefits of the platform.
Solid addresses the root cause of today’s web pains: we all give our data away for free. Specifically, we assume that the apps and services we use online will get to keep the data we create when using them. That’s actually a terrible design for many reasons. First, it chops your personal data up into silos so you can’t create apps that combine your stuff. It also creates multiple identities, which drives security issues and password hassles. But most importantly, the more data we give to an app or service, the harder we get locked in.
Solid differs from the original web in three critical ways:
- Decentralized Data — Solid provides users with a personal online datastore (pod) to store their data, with the ability to control who can access it and what they can do with it.
- Decentralized Identity — Solid uses decentralized Identity, a consolidated, permanent instance that each user owns and controls, and which cryptographically authenticates with any Solid app (or legacy app that supports the open APIs).
- Extreme Programmability — Solid exploits semantic web principles, an approach that essentially turns the entire web into a single, radically programmable application space.
A user may elect to share pod data, fully or in restricted form, with any other party. A pod can store any type of data, including files. But to the user (and to the apps that they choose to use) the pod is all one data store. This approach separates data from apps, making it possible to choose any app that supports the standards and even switch back and forth between them seamlessly.
The Collaboration with NHS
In partnership with Janeiro Digital, RSA Labs is providing Verifiable Credentials in a collaboration with the UK National Health Service. On June 22, NHS posted a new Policy Paper: Data saves lives: reshaping health and social care with data that formalizes the plan to separate applications from data for the benefit of NHS patients, and decentralized data is a core component of its IT strategy. This use case shows the fundamentally different – and better – nature of the decentralized approach.
With the current collaboration pilot, NHS is transforming the way electronic health records (EHRs) work. Existing systems combine patient EHRs into centralized databases using traditional methods and access controls. Essentially, each user’s view into that data set is an SQL query based on their identity as managed by the NHS.
The problem with that model is that, even within a single system like the NHS, there are many different EHR products and versions in place, making it difficult to view all of a patient’s records. This leads to the “first visit” problem where each new doctor or facility seen by a patient essentially is treated as a first visit, and the patient’s history must be provided – usually by the patient themselves, for evaluation.
Janeiro Digital has created a solution to this problem with its XForm Health product, which pulls and normalizes data from multiple systems. XForm Health provides out-of-the-box support for HL7’s Fast Healthcare Interoperability Resources (FHIR) Specification, which is a standard for exchanging healthcare information electronically.
But instead of combining the data into yet another centralized database, Janeiro – a specialist in Solid and decentralized web principles – is recording the complete patient records into individual pods, which the patients now own and control. A patient can simply grant access to a provider, who will have the full view of the EHR. And those permissions can be tightly managed or revoked when no longer needed.
This delivers unprecedented benefits for both patients and the NHS. Because the pod is owned by the user, additional data – such as health tracker output or retail vaccination records – can be stored in a pod. Third-party apps can also connect, for example, a life insurance company offering lower rates for good health or a pharmaceutical manufacturer seeking patients for clinical trials.
For NHS, using a decentralized data standard like Solid greatly enhances compliance with privacy laws such as the GDPR. Since the patient owns and controls all the data in the pod, requirements around data access, review, and portability are inherent to the design. And of course, the completeness of the data enables care providers to have a full view of the patient even on a first visit.
If you’re a security person though, you may have picked up on a design flaw. If the patient owns and controls the data, what’s to prevent them from modifying or even adding false data? For example, changing a diagnosis on a disease or adding a prescription for an unauthorized drug.
That’s where Verifiable Credentials come in.
Get ready for the future of trust
Verifiable Credentials is an open W3C standard that creates a layer of trust on the web. It extends and automates the credentials we use in the physical world, and can add new ones that aren’t possible today, to create the confidence needed to exchange important information online.
We’re all familiar with credentials in the physical world, where some trusted entity issues us a physical assertion about something abstract, such as a:
- Passport — a credential from your nation asserting your citizenship and authorization to travel internationally
- Driver’s license — a credential from your state or regional government asserting you are qualified to operate a motor vehicle
- Diploma — a credential from a school or college asserting completion of an educational curriculum
In the digital world, however, it’s still not easy to prove such things. Typically the process defaults to manual steps such as photos or scans of various physical credentials. But those credentials (especially their digital versions) are themselves subject to counterfeiting or modification, or even may have been revoked by the issuer. This leads to messy and inconvenient proof of trust in the digital world. Verifiable Credentials address that problem.
In the NHS example, data placed into a pod by the NHS is cryptographically signed. In the interface, all cryptographically signed data has a checkmark icon, which – much like the lock in a browser’s address field – gives assurance that the data can be trusted. Hovering over the checkmark shows that it’s “Verified by RSA”. As with TLS on the web, a whole lot of sophisticated cryptography is taking place behind the scenes, but all of that is hidden from the user.
The following diagram illustrates how it works. In the NHS case, NHS (Issuer) provides records in the form of Verifiable Credentials, which are stored in the patient’s (Holder) EHR pod. When the patient or authorized third party user or app (Relying Party) views the data, RSA (Credential Assurance) makes a check against the credential store (Verifiable Data Registry) to validate that the data was signed by the party that claims to have signed it, and that the data hasn’t been modified or revoked. This assurance is returned to the Relying Party to complete the process.
RSA Verifiable Claims Service
RSA Labs Project Mercury is a cloud service that provides the verification of these claims in the NHS Pilot, and potentially any other Solid (or non-Solid) app that has a verified claims requirement. This capability is accessed via open APIs. Importantly, the service can be set up by the issuer so that the actual data cannot be viewed in the process – a security and privacy show-stopper in a health record use case and many others – because it simply validates the cryptographic signature.
Again, the technology behind Verifiable Claims is sophisticated, but it’s core infrastructure that must perform its function perfectly every time. This is an RSA strength and has been for nearly 40 years. Just as we helped secure the original web, we’re on the job and ready to deliver trust for the next version.
###
Learn more about RSA and its support for Verifiable Credentials.