Slap me

While I've been at the HL7WGM, I've also been spending time thinking about ABBI and OAuth 2.0 and dynamic client registration.  I still don't have the details and capabilities of dynamic client registration fixed firmly in my head.  Part of the reason I'm working through this so hard is due to a threat to the ABBI Ecosystem that doesn't yet seem to be mitigated.  Let me start with some assumptions:

ABBI PULL will use OAuth 2.0 for authentication.  It will need dynamic client registration to support authentication of client applications.  The reason that authentication of clients is necessary is that we want to establish trust in the ABBI ecosystem.  That means that applications need to be trustable, or not trustable, and that trust once granted could subsequently be revoked.

To identify a client application installed on a user's system, it must be provisioned with credentials so that an authorizer can identify that installation, and grant trust (or not) based on both the user authorization, and the client application identity.  The client application identity could be specific to an installation, or cover all installations of the same client, or an instance's identity could be linked to  an "application class".  Revoking trust on an instance by instance basis is tedious, and means that having seen one threat, you address it, but that doesn't help you with the next one.  In the linked instance to class model, trust could be revoked from a specific instance, or from all instances of the same client, depending on what happened in the ecosystem.

The threat to an application is this:  If an instance of an application can be impersonated, then an attacker can deploy numerous instances of a rogue application that impersonates a real application (e.g., through a bot-net).  These rogue applications behave badly in a way that is detectable by the authorizer.  This results initially in a revocation of trust, first from each badly behaving instance, but eventually to any instance reporting to be that application.

The attacker in this case has successfully denied users of that application from the services it provides in the eco-system. The reputation of the organization supplying the application also suffers.

Denial of service might seem to be a pretty mimimal attack.  No PHI was lost, damaged or stolen.  Service will be restored eventually.  This isn't about not being able to access Twitter though. This is healthcare data.  People have died because they didn't have their medication list readily available when they needed care.  Am I over-responding?  I don't know.

The problem is that in the OAuth threat model, application code isn't secure.  If you've ever used a Java decompiler, you know what I mean.  I've seen C/C++ decompilers that work with x86 architectures that are also pretty good.  So the code isn't safe, nor is the data in your application, so it cannot be safely pre-configured with secrets. Even assuming that an attacker has limited resources, modern tools can reconstruct the application code readily enough to enable serious hacking (been there, done that, all for legal purposes).

Post-configuration of the application with a secret is possible (because the application can store the secret in protected storage), but there is a chicken and egg problem.  Because the application code isn't secure, the protocol by which the installed application obtains its post-configured secret is known, and an attacker can use then that protocol to obtain an installed instance of an application's post-configured secret.  Having that, they can now impersonate the installed instance.  So anyone could masquerade as an application for which they had the code for, and if they can do it once, they can do it a thousand times (or more).

The responsibilities of members of the ABBI ecosystem is not equally shared.  Applications (running on a device) need to protect a single (or perhaps a few) end-user's data and their own secrets in an installation.  Data holders must protect the data of thousands or even millions of patients.  Authorizers enable the trust in the ecosystem, and have one of the highest levels of responsibility, because if they break down, the ecosystem breaks down.

And what I cannot figure out is how to enable an authorizer to protect an application from being impersonated.

This is not my area of expertise.  I know enough about security (which is quite a bit actually) to know how not to get my face slapped, and when I need expert assistance.  This is one of those cases.  Yet, because I understand more of OAuth than many others (there are a few exceptions, including Josh M, whose been really helpful), I'm putting my face right out front.  Slap away.