Protecting Integrity

The pandemic truly occupied our attention over the last several months. Governments worldwide struggled to keep citizens safe, and daily life changed drastically for many people. Finally, we now have vaccines, and some countries even have COVID-passes for safe international travel.

We are all excited to break the isolation and visit other countries. However, we should also be aware that the COVID-pass contains sensitive health-related information. For example, the European version includes the recipient's name, date of birth, vaccine information, test results, and recovery information. If certain information is wrong, it is classified as a "technical issue" (read more about the EU Digital COVID Certificate). I state this is an integrity issue.

I mean, if you lose money, you may borrow some or get it returned. If you lose your credit card, you can block it, cancel illegitimate transactions, and sign up for a new one. However, if your health records are stolen and sold on the darknet, you are permanently exposed. You have lost part of your integrity. You may even need a new life to start over, which is no trivial task.

The health-related data in the COVID-pass may appear trivial, but what happens if technical issues lead to a massive leak of health-related information and high-worth data? Such was the case in a big leak of phone calls from a medical consultation in Sweden as disclosed by the media in June 2019. I believe it is ethical to have consequences for companies, but honestly, penalty fees do not help the victims. What happens if technical issues result in manipulated health records and incorrect prescriptions for medications? Here, the potential consequences on human life are dire.

Honestly, I don't want to be the engineer with somebody's death on my conscience. As an engineer, security expert, and customer, I believe health care providers and their data consumers should place as much effort into protecting health-related data as they do for maximum security. It is far better to invest in tools that correctly protect data integrity rather than paying penalties when data is exposed. Such tools can be of regulatory or technical nature. I appreciate the convenience of booking a doctor's appointment online or enabling different institutions to share my records — however, this must happen securely.

Secure OAuth 2.0 Profile

Thankfully, the OpenID Foundation has a working group engaged in this matter: HEART, which stands for HEAlth Relationship Trust. Among others, the working group defined a security profile for OAuth 2.0 — the Health Relationship Trust Profile for OAuth 2.0 (Implementer's Draft), which encourages using the authorization code flow and JWT-based client authentication whenever possible. When not possible, such as in the case of a browser-embedded client with user delegation, organizations should consider the Token Handler pattern. With this pattern, the token is never revealed to the client, and the security level raises to that of a full client with user delegation.

Sharing Data

If your systems handle potentially sensitive data, be restrictive in what information resides in tokens to avoid any exposure — that includes even the sub claim. To benefit from using JWTs, use wrapped opaque tokens to avoid placing sensitive data in the tokens. Wrapped opaque tokens use a minimum of metadata required for validation, such as issuer name or expiration time. They fit perfectly into an environment where interoperability between different providers is important — as is the case in the health care sector.

In addition, consider using proof of possession tokens. Such tokens require the client to prove that it possesses the cryptographic key that the token is bound to. There are different techniques for sender-constrained tokens, including DPoP and Certificate Bound Access Tokens.

Accessing Data

The HEART profile requires the resource server, the API, to validate tokens. This is a primary pillar of a Zero-Trust Network wherein the main principle is to trust no one until authenticated. As a consequence, not even the reverse proxy is trusted for authentication. With that said, I still strongly recommend having a reverse proxy for mitigating different kinds of attacks on various layers. However, the API is responsible for ensuring that the token is valid. If this information is available in the token, it must validate that it is the intended receiver of the token ("aud" claim) and that the token includes the rights required to grant access to the protected resource. Doing so should be self-evident as it mitigates the risk of unauthorized access and data leaks significantly.

Conclusion

Personally, I like that the HEART Profile for OAuth 2.0 refers to the Security Considerations section of RFC6749 and the OAuth 2.0 Threat Model for the profile for Authorization Servers. In this way, operators are forced to go through all the threats identified in the documents comprehensively. Sometimes we should pause, take a step back and reflect on what we are doing to ensure it's the safest method possible. Doing so can help keep systems and people safe.