Stream: Security and Privacy
Topic: Resource Encryption
Jason Eisenmenger (Oct 29 2020 at 14:42):
I've been doing a lot of research on resource-level encryption without much success, so I'd like to pose a question to this group. The requirements are encryption of individual resources within a FHIR payload for delivery via proxies or distributions that may otherwise inspect unencrypted resources within the payload (e.g. MessageHeader). Encryption is performed with pre-shared keys among FHIR servers, and payloads may contain a single resource from a single server or a bundle of resources from multiple servers (in the case of a distribution), each resource potentially encrypted using different keys and methods.
I've seen mention of using the Binary resource type - however this would require custom functionality by both the sending and receiving server, but may provide a short-term solution. I've also seen talk of using multipart MIME headers, however this seems even further from interoperability standards.
Any guidance would be greatly appreciated.
John Moehrke (Oct 29 2020 at 15:56):
You are in advanced space that the FHIR community has not addressed.
John Moehrke (Oct 29 2020 at 15:57):
I would recommend you look at using transport standards that support this kind of end-to-end + multipart security, S/MIME comes to mind, as does SOAP+XML-Encryption.
John Moehrke (Oct 29 2020 at 15:58):
There is no mechanism, that I know of, where a Bundle is defined as having independently encrypted Resources. This is not beyond where we might go. It is just that the majority of people are working on far more simple point-to-point (aka https/RESTful) interactions.
John Moehrke (Oct 29 2020 at 16:05):
Even if a Bundle was to be enhanced to support this, I would want it to leverage XML-Encryption or JWE containers as the mechanism within the Bundle. Thus your outer Bundle is made up of resources you want the intermediary to see (MessageHeader) and 1..* Binary. Where the Binary.contentType holds the mime-type for XML-Encryption or JWE encryption as appropriate for the Bundle encoding; and the Binary.data holds the encrypted blob conforming to that standard. Inside the encrypted blob , once appropriately decrypted, is the contained Resource. The XML-Encryption standard supports the administrative sugar needed. Not clear that JWE does, im just not that aware of JWE. There would need to be some agreement on the end-to-end key-tryst. Not clear to me what more needs to be done.
Jose Costa Teixeira (Oct 29 2020 at 16:08):
I think the Bundle approach did not really launch. We thought of doing that but we abandoned it.
John Moehrke (Oct 29 2020 at 16:10):
Excellent feedback @Jose Costa Teixeira , so what did you do?
Jose Costa Teixeira (Oct 29 2020 at 16:22):
I will ping the security experts, because I could not understand what they had.
Jose Costa Teixeira (Oct 29 2020 at 16:22):
@Nick Hermans do you know?
John Moehrke (Oct 29 2020 at 16:35):
there is the EC approved AS4 (which is a profile of SOAP+XML-Encryption+XML-Signature+SAML)... no reason why REST actions can be the ONLY actions allowed in the SOAP. Thus you are using RESTful SOAP (can't find a spec, no surprise as this is mixing religions).
Nick Hermans (Oct 29 2020 at 16:39):
@Jose Costa Teixeira are you asking about the details on how the resources would be (besides the transport layer) encrypted or how we exchange public keys between parties?
Josh Mandel (Oct 29 2020 at 16:48):
Depending on your use case, might also look at some of the nascent community efforts like https://github.com/decentralized-identity/didcomm-messaging for general-purpose distribution of encrypted/authenticated messages.
Jeremy Chapman (Oct 29 2020 at 17:03):
Soap encryption and encrypted mime parts could work, but I think they couple encryption to the transport layer more than the application layer (message level). Is that really ideal? Just reading about xml encryption syntax https://www.w3.org/TR/xmlenc-core/ and an RFC for JSON object signing and encryption. https://tools.ietf.org/html/rfc7520. These look like they would allow encryption of xml fragments and json fragments. So you could in theory encrypt the resource element of a bundle entry. As @John Moehrke mentioned JSON Web Encryption, also known as JWE, is another Internet standard of the IETF and is defined in RFC7516 https://tools.ietf.org/html/rfc7516 might work. I'm not sure if the JSON standards allow for fragments to be encrypted like xml encryption does, or if they require the entire object to be encrypted.
Jeremy Chapman (Oct 29 2020 at 17:04):
The only think I didn't like about the message level encryption is the bloat from base64 encoded data
Lloyd McKenzie (Oct 29 2020 at 17:40):
The real issue with doing this in Bundle is bdl-5, which requires that resource be present if you don't have entry.request or entry.response - which means documents, messages, etc. If we didn't have that constraint, we could theoretically have an extension that conveyed an encrypted view of the resource rather than the resource itself. I don't think we could relax that at this point, but we might be able to add new bundle types - e.g. "secured-message" and introduce a new entry.encryptedResource or something like that. The first step in doing something like this would be writing up an approach and finding a group of people who wanted to play with it at connectathon. We could then considering introducing it in a future FHIR release.
Jeremy Chapman (Oct 29 2020 at 18:31):
So are you saying that having something like the following example does not meet the constraints of a bundle? And also, with your idea of secured-message and an entry.encryptedResource would an encrypted resource use an existing standard like xmlenc-core or would it choose something that isn't coupled to the payload content-type (xml vs json, etc).
<Bundle xmlns="http://hl7.org/fhir">
<type value="message"/>
<entry>
<fullUrl value="urn:uuid:e969238e-3044-470f-835c-5646c8d6bf50"/>
<resource>
<MessageHeader>
<destination>
<name value="Acme Message Gateway"/>
<target>
<reference value="Device/example"/>
</target>
</destination>
<sender>
<reference value="urn:uuid:e969238e-3044-470f-835c-5646c8d6bf50/Practitioner/sending"/>
</sender>
<source>
<endpoint value="dgf">
</endpoint>
</source>
<focus>
<reference value="urn:uuid:e969238e-3044-470f-835c-5646c8d6bf50/Patient/example"/>
</focus>
</MessageHeader>
</resource>
</entry>
<entry>
<fullUrl value="urn:uuid:e969238e-3044-470f-835c-5646c8d6bf50/Practitioner/sending"/>
<resource>
<Practitioner>
<EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element"
xmlns="http://www.w3.org/2001/04/xmlenc#">
<CipherData>
<CipherValue>A23B45C56</CipherValue>
</CipherData>
</EncryptedData>
</Practitioner>
</resource>
</entry>
</Bundle>
Lloyd McKenzie (Oct 29 2020 at 18:45):
Yup, that's definitely not conformant. "EncryptedData" is not an allowed data element in Practitioner. In principle, you could put an extension inside Practitioner that conveyed the encrypted content, but you'd still have to satisfy all mandatory elements and invariants on the Practitioner resource (or any other resource)
Lloyd McKenzie (Oct 29 2020 at 18:46):
As for how we'd encrypt the content, that'd be up to the group having the discussion :)
John Moehrke (Oct 29 2020 at 19:26):
hence why I suggested Binary be the container for the encrypted blob, where the encrypted blob is the container of the Resource
Josh Mandel (Oct 29 2020 at 19:57):
Re: bundle requirements, @Lloyd McKenzie does a resource element with an extension (and no actual resource) not count as "present" ?
Josh Mandel (Oct 29 2020 at 19:58):
I'm always confused on this; I know you can satisfy a 1..1 cardinality constraint with just extensions. Is the bdl-5 constraint different in this regard?
Lloyd McKenzie (Oct 29 2020 at 20:10):
A resource with an extension and that satisfies all the resource requirements (mandatory elements present, invariants satisfied) counts as 'present'. So a Patient with just an extension would be fine. However Observation would not - you'd also need Observation.code and Observation.status.
Lloyd McKenzie (Oct 29 2020 at 20:11):
I guess you could send an Observation with an extension and then throw extensions inside Observation.code and Observation.status, but that starts to fall down as you need to start satisfying all of the widely varying requirements of all the resources and is certainly more 'hack' than solution.
Jason Eisenmenger (Oct 29 2020 at 20:17):
@Jeremy Chapman I like the idea of leveraging the built-in functionality of the messaging format (json/xml) to embed encrypted resources. If we assume that the parsing layer transparently encrypts/decrypts these nodes and replaces them with their encrypted/decrypted values upon sending/receiving, and a fully decrypted payload forms a valid FHIR payload, would that allow us to dodge the need for FHIR to adopt any message-level encryption support? Does the cardinality of the messaging format allow us to do that? I'm thinking no but it's worth a shot.
Jason Eisenmenger (Oct 29 2020 at 20:29):
The examples being discussed, with the exception of Binary, are exposing the identity of the resource type (Practitioner, Observation). Going down the new resource type route, the Bundle.entry would need to allow for something like an encryptedResource that hides the resource identity and provides metadata properties similar to EncryptedData from the xml spec. It sounds like Binary could be made to act that way via extensions - but again that's a very custom solution.
Elliot Silver (Oct 29 2020 at 21:01):
Lloyd McKenzie said:
The real issue with doing this in Bundle is bdl-5, which requires that resource be present if you don't have entry.request or entry.response - which means documents, messages, etc. If we didn't have that constraint, we could theoretically have an extension that conveyed an encrypted view of the resource rather than the resource itself. ...
One might be able to argue about where/when this constraint is validated. I could take the position that it isn't FHIR until I've reconstituted the bundle without encryption, and that the JSON or XML I was passing around before that doesn't have to meet any of the FHIR constraints.
Jeremy Chapman (Oct 29 2020 at 21:02):
@Jason Eisenmenger - I originally thought using the built-in functionality of the format to embed encrypted resources was clever, but for some reason I did kind of overlook the obvious fact that the payload is non-conformant because it introduces elements that are not declared within the FHIR schemas. That being said, what you are talking about does make some sense where you effectively decrypt prior to the consumption of the FHIR message so the software that is consuming the message still sees it as a valid message. This is effectively how mtom works, and xml libraries that support it - if you consume xml that contains mtom with compliant librarys the mtom part of the xml is abstracted away. What I don't like is the coupling of the payload format to the encryption implementaiton because xml encoding may have different requirements than json object encryption, which means the decoding and encoding system may need multiple encryption/decryption implementations if they are to support multiple message formats. I don't see that as Ideal although think it's certainly considerably better then going lower down in the stack and using soap or s/mime to handle the encryption/decryption.
What you are talking about could certainly work around the constraint that Lloyd is talking about, at a technical level, but given that FHIR is an interop standard we'd really be not within the spirit of that even though it would still technically function.
Jose Costa Teixeira (Oct 29 2020 at 21:06):
Elliot Silver said:
One might be able to argue about where/when this constraint is validated. I could take the position that it isn't FHIR until I've reconstituted the bundle without encryption, and that the JSON or XML I was passing around before that doesn't have to meet any of the FHIR constraints.
Are you suggesting an outer layer that escapes the FHIR constraints?
Josh Mandel (Oct 29 2020 at 21:11):
A resource with an extension and that satisfies all the resource requirements (mandatory elements present, invariants satisfied) counts as 'present'. So a Patient with just an extension would be fine. However Observation would not - you'd also need Observation.code and Observation.status.
So for example there's no way to provide a "data absent reason" instead of a typed resource in a bundle entry?
Elliot Silver (Oct 29 2020 at 21:59):
Jose Costa Teixeira said:
Are you suggesting an outer layer that escapes the FHIR constraints?
I'm suggesting using something that looks like a Bundle, and contains resources, just like a bundle would, but that the content of the resources in encrypted, which is what I thought Jeremy was proposing until Lloyd shot it down with the fact that it doesn't meet constraints. My point was question at what point the constraints need to be met? Doing something like mtom, you would end up with non-compliant content at lower levels of the interface, but by the time it reaches higher levels, it has been turned into something compliant. (Yes, even if it does, and I'm doubtful of that, meet the letter of the spec, there is a big question of whether it would meet the interoperable spirit of the spec.)
Jeremy Chapman (Oct 29 2020 at 23:05):
Elliot Silver said:
I'm suggesting using something that looks like a Bundle, and contains resources, just like a bundle would, but that the content of the resources in encrypted, which is what I thought Jeremy was proposing until Lloyd shot it down with the fact that it doesn't meet constraints. My point was question at what point the constraints need to be met? Doing something like mtom, you would end up with non-compliant content at lower levels of the interface, but by the time it reaches higher levels, it has been turned into something compliant. (Yes, even if it does, and I'm doubtful of that, meet the letter of the spec, there is a big question of whether it would meet the interoperable spirit of the spec.)
I would think you could successful remain compliant, at a higher level (as you said), but non-compliant at the lower level. I'm sure the interoperable standards checkbox remains empty.
Lloyd McKenzie (Oct 30 2020 at 03:11):
You could do that, but you couldn't use $process-message and you couldn't claim a FHIR mime type
Jason Eisenmenger (Oct 30 2020 at 17:14):
Jeremy Chapman said:
What you are talking about could certainly work around the constraint that Lloyd is talking about, at a technical level, but given that FHIR is an interop standard we'd really be not within the spirit of that even though it would still technically function.
I see where you're coming from, but to look at it from another angle Binary may pass the spirit argument but fail on the technical level since it doesn't provide guidance or standards around how encryption/decryption should be implemented. I see two technically viable solutions discussed so far; 1) leveraging the built-in encryption features of the message format or 2) creating a new encrypted resource type and making encryption a first class citizen. The former provides standards and guidance that have already been adopted (in the case of xml) but leaves open the question of whether decryption happens pre-validation and would potentially require a change in the FHIR schema to support it. A new resource type, however, would require FHIR to shoulder re-implementing concepts similar to the xml standard / json rfc but would give FHIR the ability to conform them to its specific use case.
Jeremy Chapman (Oct 30 2020 at 17:19):
Jason Eisenmenger said:
I see where you're coming from, but to look at it from another angle
Binarymay pass the spirit argument but fail on the technical level since it doesn't provide guidance or standards around how encryption/decryption should be implemented. I see two technically viable solutions discussed so far; 1) leveraging the built-in encryption features of the message format or 2) creating a new encrypted resource type and making encryption a first class citizen. The former provides standards and guidance that have already been adopted (in the case of xml) but leaves open the question of whether decryption happens pre-validation and would potentially require a change in the FHIR schema to support it. A new resource type, however, would require FHIR to shoulder re-implementing concepts similar to the xml standard / json rfc but would give FHIR the ability to conform them to its specific use case.
I think that making encryption a first class citizen is ideal. That requires inclusion into the FHIR specification, which sounds like an arduous process, and a process that is pretty unclear to me. How long does that process even take, and how does it get initiated and shepherded through to fruition?
Jason Eisenmenger (Oct 30 2020 at 17:28):
Jeremy Chapman said:
How long does that process even take
Well... the xml encryption syntax was proposed 12/2000 and adopted as a recommendation by the W3C on 01/2013, but maybe we can get @Lloyd McKenzie to crank it out with us in a connectathon?
Gino Canessa (Oct 30 2020 at 18:51):
Worth every penny, but here's my two cents =)
Adding encryption by adding a wrapping resource does not make encryption easy. E.g., consider a Bundle and some content:
- Does the
Bundleneed to be encrypted? If so, we need to allow returning the encrypted resource instead ofBundleeverywhere (which is not likely to happen). - If the
Bundleisn't encrypted, what do we do about potentially sensitive data there (e.g., I don't want to exposeBundle.entry.fullUrl, but I'm not including full resources)? - Needing to check each entry and determine if it needs to be decrypted will add runtime checking/logic to figure out what's present.
Similar issues would exist for contains, etc. - any place a resource could be used, a developer will need to add handling for encryption. The core specs would need also to be expanded to include it, since a Reference(Patient) could now be a Reference(Binary/EncryptedBinary/whatever) at runtime.
That said, if you want to selectively encrypt parts of a message and remain FHIR-compliant at each step, I don't know that there is another option.
But if you want to move forward with wrapping, I would suggest looking at Binary and seeing what can be done with extensions today (if an encrypted binary is added for R5 and useful, people will likely want a way to use it in R4 anyway). My intuition is that there are only a couple of fields that would need to be added to Binary to get what you need. As the details are fleshed out, it will be easier to figure out if the fields can be added to Binary (it is normative, but non-breaking changes can still be proposed) or if a new resource makes more sense (e.g., EncryptedBinary).
However, if the goal is just to allow secure messages to be forwarded around, I would consider a new serialization format instead. There are a few approaches here that feel like 'low hanging fruit':
application/fhir+xmlenccould be used for encrypted XML (not sure what would be best practice for JSON given all the issues around JWE/JOSE).- Define an a new encrypted container format (e.g.,
application/fhir+secure+xmlandapplication/fhir+secure+json) - this allows for adding metadata outside the encrypted contents, but would be more work. - Use an existing container structure (e.g., Josh's example of DIDComm Messaging, CMS, etc.) to wrap the existing formats.
Going this route loses the ability to have a 'FHIR' object without decoding it, but I think it would be simpler to work with (e.g., servers already handle MIME negotiation, encryption/decryption can only be in one place, etc.).
I will also note (without any relevant experience in the FHIR community) that standards bodies often shy away from proscribing specific forms of encryption because they don't want to be accountable for it (e.g., algorithm 'xyz' has been found insecure and there is now a lawsuit over a data leak because of it). In that context, the more that can be pointed to externally, the easier the sell will be.
Lloyd McKenzie (Oct 30 2020 at 19:12):
Encrypting on a per resource basis would mean that you're comfortable with exposing the full URL (and request and response if appropriate). If you need all of that hidden, then you need to encrypt the whole thing and intermediaries wouldn't be able to see beans. The notion of having entry.encryptedResource would be a bit better than Binary not just in that we could convey some encryption metadata (which we could probably do in Bundle.metadata or in additional extensions if necessary), but because references within the Bundle would actually work. If one of the resources is pointing to Patient/3, then you wouldn't want the Bundle.entry to be a Binary - because if it was, the reference wouldn't work.
My perspective is that you can't encrypt contained resources - they're inseparable from the containing resource. However, we could potentially have a situation where there's a stripped/anonymized/'safe' version of the resource that hides a bunch of stuff and is fully viewable (at least by whoever has permission to see the Bundle) and a 'full' (but encrypted) version of the resource that would be readable only to those with the key. That could potentially let you strip certain contained content and/or other elements from a resource from what the intermediary has access to (to allow appropriate routing/logging/whatever) while still conveying the whole thing to the target recipient
Lloyd McKenzie (Oct 30 2020 at 19:13):
As for Lloyd cranking this out for connectathon, my knowledge of what might be appropriate here is pretty limited. I'd probably toss the actual write-up to @John Moehrke or someone else from the Security WG. I'm just proposing a possible path forward that could theoretically work within the constraints we currently have.
John Moehrke (Oct 30 2020 at 20:02):
I am still standing on the use of Binary as an encapsulating FHIR compliant Resource. Where Binary.contentType is the mime-type for XML-Encryption, and the Binary.data is the encrypted blob. This means that there is NO metadata for the sensitive content that is exposed at the Bundle.entry, as the Bundle.entry is to the Binary, not to the sensitive Resource... Care must be taken when there is a non-encrypted Resource in the Bundle, as any of the elements in there that have a Reference datatype might leak that somewhere else in the Bundle is a sensitive Resource of that type.... but what I am proposing sure seems to me to not need any extensions and does not break FHIR R4 rules. (JSON is another kettle of fish, but one problem at a time, and it is mostly caused by the JSON community failure to have a standard as complete as XML-Encryption... note, XML-Encryption could be used with JSON FHR encoding too, but not as smooth)
Jason Eisenmenger (Oct 30 2020 at 20:21):
@John Moehrke How would one go about referencing a resource in an encrypted binary?
Gino Canessa (Oct 30 2020 at 20:56):
Lloyd McKenzie said:
Encrypting on a per resource basis would mean that you're comfortable with exposing the full URL (and request and response if appropriate). If you need all of that hidden, then you need to encrypt the whole thing and intermediaries wouldn't be able to see beans. The notion of having entry.encryptedResource would be a bit better than Binary not just in that we could convey some encryption metadata (which we could probably do in Bundle.metadata or in additional extensions if necessary), but because references within the Bundle would actually work. If one of the resources is pointing to Patient/3, then you wouldn't want the Bundle.entry to be a Binary - because if it was, the reference wouldn't work.
My perspective is that you can't encrypt contained resources - they're inseparable from the containing resource. However, we could potentially have a situation where there's a stripped/anonymized/'safe' version of the resource that hides a bunch of stuff and is fully viewable (at least by whoever has permission to see the Bundle) and a 'full' (but encrypted) version of the resource that would be readable only to those with the key. That could potentially let you strip certain contained content and/or other elements from a resource from what the intermediary has access to (to allow appropriate routing/logging/whatever) while still conveying the whole thing to the target recipient
Yes. My concern is that the model is (or perhaps, can be) leaky. E.g., a response Bundle for a query of a specific condition, etc.. Bundle can contain quite a bit of meta-information (and presumably things like MessageHeader would be plain-text as well). We can't stop people from shooting themselves in their feet, but we shouldn't give them shoes with targets on them either.
I agree that references with a wrapped resource would be quite problematic. But on the other hand, this means we are developing an encryption mechanism that only works with Bundles. Maybe that's not terrible, but it feels like promoting Bundle into 'the' way of operating.
John Moehrke (Oct 30 2020 at 21:08):
@Gino, there is plenty of encryption that can encrypt the whole thing. TLS being one. That is not what is being asked for. What is being asked for is to allow some quasi-trusted intermediaries to see the MessageHeader and maybe some content, but hide other content from that quasi-trusted intermediary. That quasi-trusted intermediary does not need to walk the whole bundle, just the MessageHeader....
John Moehrke (Oct 30 2020 at 21:09):
@Esteban Fuentealba any Reference values inside the Bundle would need to be to the actual Resource id. Not the Binary. Hence why these references are potentially problematic.
John Moehrke (Oct 30 2020 at 21:10):
Thus only a fully trusted recipient that could decrypt everything could fully walk everything in the Bundle.
John Moehrke (Oct 30 2020 at 21:11):
this would fit the use-case of a qusi-trusted intermediary that needs only to route, and a fully trusted endpoint... the gap would be if there was a use-case where there was a quasi-trusted intermediary that needed to manipulate things beyond just looking at some content (e.g. MessageHeader).
Lloyd McKenzie (Oct 30 2020 at 21:36):
Binary won't work for links. For example, if you have a query where you're seeking MedicationRequest and _include Patient, if you turn both into Binaries, your links aren't going to work - because either all of your fullURLs will have to be to Binary, and when you unencrypt, you won't have a way to recover your 'propery' fullURLs to recover the content. I guess one option is for your Binary to actually include the encrypted version of the whole entry, not just the resource. That could theoretically work. - so the fullUrl for the Binary would get replaced with the fullURL in the encrypted content.
Jason Eisenmenger (Oct 30 2020 at 22:32):
It is a valid use case for all metadata about a resource be encrypted, which breaks FHIR conformance w.r.t. references. From a schema perspective it sounds like a difficult path around that, wrapper classes or not.
I'm really liking the elegance of application/fhir+xenc+xml. An additional step could be a bool:encrypt property on all resource types that requires encryption of the resource and references to it when serialized.
Vassil Peytchev (Oct 30 2020 at 22:35):
What is the actual use case, and what are the risks being mitigated? Before we start designing solutions, we should be clear on these two points.
Jeremy Chapman (Oct 30 2020 at 22:48):
Vassil Peytchev said:
What is the actual use case, and what are the risks being mitigated? Before we start designing solutions, we should be clear on these two points.
I my case, we have EMR software that sends various messages into an exchange, which routes them to other EMR endpoints based on recipient information. Similar to an email scenario I suppose. Only the sender (person) and the receiver person should see the sensitive parts of the message. The idea is that the sender is going to use the receivers public key to encrypt the sensitive parts of the message, but the exchange, and the emr need to see some of the parts so the exchange can route to the appropriate emr endpoint and the emr can route to the appropriate person.
Jason Eisenmenger (Oct 30 2020 at 22:52):
My use case is very similar. The key here is that this proxy / exchange needs to be transparent to the sender/receiver and provide a FHIR-compliant interface.
Lloyd McKenzie (Oct 30 2020 at 23:21):
I would probably handle that use-case by using messaging (which is FHIR's primary mechanism for routing data) and propagating key routing data into the MSH segment as extensions (encrypted if necessary if certain routing nodes should see and not others) and have the focus of the message being an encrypted Bundle (which might be a REST transaction or another message). That way you expose exactly what's needed for routing (and nothing more) and you don't mess up the semantics of a 'regular' Bundle, nor do you have to invent anything custom.
Vassil Peytchev (Oct 30 2020 at 23:21):
Sender and receiver are relative terms. Since in my opinion one of the main strengths of FHIR is the RESTful API, I would rather find a solution where there is a notification from the data producer, going through the proxy/exchange to the data consumer, that there is information for them to consume, and then the consumer obtains the data directly from the producer, maintaining the confidentiality of the information.
Jason Eisenmenger (Oct 31 2020 at 00:09):
Those are both approaches to providing a similar end result, however what is needed is a proxy/exchange interfaced transparently via a FHIR REST API. Messaging is an entirely different pattern, and with consumer/producer it may be the case that the value-add of the proxy/exchange is providing a route for parties to communicate that otherwise cannot.
Jason Eisenmenger (Nov 02 2020 at 17:09):
A few key points from the xmlenc spec:
4. Processing Rules
https://www.w3.org/TR/xmlenc-core/#sec-Processing
This section describes the operations to be performed as part of encryption and decryption processing by implementations of this specification. The conformance requirements are specified over the following roles:
Encryptor
- An XML Encryption implementation with the role of encrypting data.
Decryptor
- An XML Encryption implementation with the role of decrypting data.
Encryptor and Decryptor are invoked by the Application. This specification does not include normative definitions for application behavior. However, this specification does include conformance requirements on encrypted data that may only be achievable through appropriate behavior by all three parties. It is up to specific deployment contexts how this is achieved.
4.1 Intended Application Model
https://www.w3.org/TR/xmlenc-core/#sec-Intended-Processing:
The processing rules for XML Encryption are designed around an intended application model that this version of the specification does not cover normatively.
...
Note that the intended Encryptor behavior will often cause the document with encrypted parts to become invalid with respect to its schema for the hosting XML format, unless that format is specifically prepared to be used with XML Encryption. An Encryptor or Decryptor that implements the intended processing model is
NOT REQUIREDto ensure that the resulting XML is schema-valid for the hosting XML format.
4.5 XML Encryption
https://www.w3.org/TR/xmlenc-core/#sec-Processing-XML
Encryption and decryption operations are operations on octets. The application is responsible for the marshalling XML such that it can be serialized into an octet sequence, encrypted, decrypted, and be of use to the recipient.
For example, if the application wishes to canonicalize its data or encode/compress the data in an XML packaging format, the application needs to marshal the XML accordingly and identify the resulting type via the
EncryptedData Typeattribute. The likelihood of successful decryption and subsequent processing will be dependent on the recipient's support for the given type. Also, if the data is intended to be processed both before encryption and after decryption (e.g., XML Signature [XMLDSIG-CORE1] validation or an XSLT transform) the encrypting application must be careful to preserve information necessary for that process's success.
Vassil Peytchev (Nov 02 2020 at 20:40):
what is needed is a proxy/exchange interfaced transparently via a FHIR REST API.
Is it possible to expand on that? What are the assumptions about the purpose of the proxy/intermediary? What is the problem that needs to be solved?
Jason Eisenmenger (Nov 03 2020 at 13:17):
Vassil Peytchev said:
what is needed is a proxy/exchange interfaced transparently via a FHIR REST API.
Is it possible to expand on that? What are the assumptions about the purpose of the proxy/intermediary? What is the problem that needs to be solved?
Consider a hospital group/system where a central exchange is used to forward queries to all EMRs in the network and aggregate responses back into a single payload. EMR access is configured at the exchange, however asymmetric keys shared between EMRs protect the messages from inspection by the proxy with the exception of allowed metadata.
John Moehrke (Nov 03 2020 at 13:53):
is the return expected to be collated by the intermediary? If so, then it needs to see the results.. If not, then the set of results bundles (search sets) is just carried as encrypted blobs. Those encrypted blobs could be Binary resources as I have explained above.
Jason Eisenmenger (Nov 03 2020 at 14:26):
John Moehrke said:
is the return expected to be collated by the intermediary? If so, then it needs to see the results.. If not, then the set of results bundles (search sets) is just carried as encrypted blobs. Those encrypted blobs could be Binary resources as I have explained above.
It could be collated in the sense that it would be a bundle of bundles.
If we continue down the Binary path:
- Senders would need to go through the validation/serialization pipeline twice, once for the encrypted payload and again for the wrapper.
- Receivers would need to go through the parsing/validating pipeline twice, once for the wrapper and again after decrypting the payload.
- Most off-the-shelf FHIR solutions have validation/(de)serialization as a built-in cross-cutting concern, so practically speaking this may be difficult to implement in application space. If custom validation/serialization is used in application space it may be error prone due to differences/drift from built-in functionality in the outer layers.
- For this specific use case we may get FHIR conformant payloads on the wire, but that may not be true for use cases with references.
I'm not seeing how FHIR conformance buys a lot here when you essentially have to re-implement a good portion of the stack within application space.
Vassil Peytchev (Nov 03 2020 at 14:57):
If you expect a FHIR client to do a RESTful search, and as a result it gets a Bundle of Bundles, the client will be quite surprised. Something, somewhere, must do the transformation from encrypted content to FHIR conformant payload. Might as well be the "central exchange", otherwise it seems like you are punting the issue elsewhere.
Jason Eisenmenger (Nov 03 2020 at 15:15):
Vassil Peytchev said:
If you expect a FHIR client to do a RESTful search, and as a result it gets a Bundle of Bundles, the client will be quite surprised. Something, somewhere, must do the transformation from encrypted content to FHIR conformant payload. Might as well be the "central exchange", otherwise it seems like you are punting the issue elsewhere.
Sorry, that was an implementation detail miss I was just throwing out there. Given that an EMR response would contain an unencrypted FHIR response with an encrypted Binary resource or resources, those encrypted resources would be collated into the main bundle in the aggregate response - so no bundle nesting.
Jason Eisenmenger (Nov 03 2020 at 15:23):
In this case, the constraint is that the central exchange cannot do the transformation from encrypted content to FHIR conformant payload. Encryption needs to be part of the FHIR specification either in the format, schema, or application layer so that resources can pass through securely.
Vassil Peytchev (Nov 03 2020 at 15:40):
Maybe I am misunderstanding, but I don't think you have established the need for a passthrough central exchange. Why can't the central exchange provide a service that will allow a FHIR client to get all the endpoints it needs to reach for a particular search, and let the client use FHIR search to get all the results it needs? Is this somehow considered more difficult than getting an encryption layer added to the specification?
Jason Eisenmenger (Nov 03 2020 at 15:55):
Vassil Peytchev said:
Maybe I am misunderstanding, but I don't think you have established the need for a passthrough central exchange. Why can't the central exchange provide a service that will allow a FHIR client to get all the endpoints it needs to reach for a particular search, and let the client use FHIR search to get all the results it needs? Is this somehow considered more difficult than getting an encryption layer added to the specification?
The central exchange is needed to centrally configure access as well as provide audit (of metadata) and metrics of communications between EMRs.
Vassil Peytchev (Nov 03 2020 at 17:50):
The central exchange is needed to centrally configure access as well as provide audit (of metadata) and metrics of communications between EMRs.
If there are sufficient risk mitigations to allow for storing the access configuration and metadata, isn't it a relatively small step to have the appropriate risk mitigations to pass-through the requests and collate the responses without needing encryption of the data?
John Moehrke (Nov 03 2020 at 19:15):
the trust framework can be managed parellel to the technical communications. Do not conflate a trust framework with the communications path
Jason Eisenmenger (Nov 03 2020 at 19:24):
Vassil Peytchev said:
The central exchange is needed to centrally configure access as well as provide audit (of metadata) and metrics of communications between EMRs.
If there are sufficient risk mitigations to allow for storing the access configuration and metadata, isn't it a relatively small step to have the appropriate risk mitigations to pass-through the requests and collate the responses without needing encryption of the data?
It is not a small step - it would be a nonstarter. Configuration/metadata is not (in this case) PHI. Perhaps the concept of a hospital "group" or "system" gives the impression of unified governance and security posture without jurisdictional data boundaries. Instead imagine that each hospital has their own distinct data and security policies, and to enable this communication they require an exchange that can be trusted to send and receive messages but not inspect them, while encryption ensures that only the intended receiver can read them. The exchange provides audit and metrics of which systems are communicating with which others for compliance, etc.
Vassil Peytchev (Nov 03 2020 at 19:38):
That is why agreements like TEFCA exist...
Josh Mandel (Nov 03 2020 at 19:52):
(In draft form, at any rate ;-))
Jason Eisenmenger (Nov 03 2020 at 20:06):
Vassil Peytchev said:
That is why agreements like TEFCA exist...
I'd not heard of this, thanks! I will give it a read.
Vassil Peytchev (Nov 03 2020 at 20:16):
Take a look at the Carequality agreement as well. There are others, too...
John Moehrke (Nov 03 2020 at 20:18):
as to audit... you can always have all endpoints (clients and servers) report to a centerl audit repository all actions with success/failure. These audits would be about the event, not the data. so they would be limited sensitivity (not completely non-sensitive). These would be enough to track usage, patterns, abuse, problems, etc.... this is the idea behind the IHE - ATNA implementation guide. with the FHIR AuditEvent for FHIR use.
John Moehrke (Nov 03 2020 at 20:20):
audit messages only coming from servers, shows that there is a client out-of-compliance. clients and servers reporting different things shows that there is something worth investigating. etc.
Jason Eisenmenger (Nov 10 2020 at 18:03):
Vassil Peytchev said:
That is why agreements like TEFCA exist...
I've just finished digging through the latest QHIN Technical Framework draft. Although this is a similar infrastructure, because the use case is different it does not address the case where a QHIN should forward queries or messages without being able to inspect them. In fact it even has requirements to log such requests for auditing.
Jason Eisenmenger (Nov 10 2020 at 20:04):
Vassil Peytchev said:
Take a look at the Carequality agreement as well. There are others, too...
Carequality does not appear to have the concept of an exchange. There is an optional Record Locator Service that returns systems that may contain a given patient for the requesting system to communicate with directly. The string "encrypt" does not have any matches in the implementation guide.
Jason Eisenmenger (Nov 10 2020 at 20:15):
John Moehrke said:
as to audit... you can always have all endpoints (clients and servers) report to a centerl audit repository all actions with success/failure. These audits would be about the event, not the data. so they would be limited sensitivity (not completely non-sensitive). These would be enough to track usage, patterns, abuse, problems, etc.... this is the idea behind the IHE - ATNA implementation guide. with the FHIR AuditEvent for FHIR use.
Again, this would be one way to solution it if there wasn't the requirement that the exchange must transport all communication between clients. I understand the desire to challenge requirements and assumptions, but this one is not going anywhere :smile:
Jason Eisenmenger (Nov 19 2020 at 16:48):
Lloyd McKenzie said:
The real issue with doing this in Bundle is bdl-5, which requires that resource be present if you don't have entry.request or entry.response - which means documents, messages, etc. If we didn't have that constraint, we could theoretically have an extension that conveyed an encrypted view of the resource rather than the resource itself. I don't think we could relax that at this point, but we might be able to add new bundle types - e.g. "secured-message" and introduce a new entry.encryptedResource or something like that. The first step in doing something like this would be writing up an approach and finding a group of people who wanted to play with it at connectathon. We could then considering introducing it in a future FHIR release.
Lloyd I'm not following this. Binaryderives from Resource, giving it an id property, etc. How does that not meet bdl-5?
Lloyd McKenzie (Nov 19 2020 at 16:57):
If you have a Patient that's pointing to a Practitioner and want to 'encrypt' the Practitioner, the Patient has to point to an entry of type Practitioner - and you can't stick a Binary into the resource. The issue is that you don't actually want to send the resource, you want to send a new element (probably an extension) called 'encryptedResource' or something like that. And bdl-5 wouldn't allow that to happen.
Jason Eisenmenger (Nov 19 2020 at 16:59):
I see, so it breaks down when there are references. What about if it is simply a Bundle with a single Binary resource?
Jason Eisenmenger (Nov 19 2020 at 17:06):
Although I'm still not understanding how bdl-5 applies in the case you described either.
Jason Eisenmenger (Nov 19 2020 at 17:07):
I can see how it would break referential requirements, but not bdl-5 specifically.
Lloyd McKenzie (Nov 19 2020 at 17:13):
bdl-5 forces 'resource' to be present - when you don't actually want to convey the resource - you want to convey an encrypted view of the resource. If you send a Transaction or a Batch with just binaries, that says "store these Binary" instances, not "unencrypt these and store to the appropriate resource endpoints". And if you're using messages or documents, you have no choice but to follow references - and use the 'correct' resource types. For example, the root resource for a document must be Composition - it can't be binary. And other entries must be of the appropriate referenced resource type (Patient, Practitioner, Condition, etc.)
The 'appropriate' solution therefore is to allow sending something other than the Bundle.entry.resource element. But the bdl-5 constraint essentially prohibits us from doing that.
Jason Eisenmenger (Nov 20 2020 at 14:27):
I see, so it's not only requiring a resource in the technical sense, but in the logical sense as well?
Lloyd McKenzie (Nov 20 2020 at 14:29):
Within a Bundle, there are expectations about how resources resolve and what the actual content is. If the resource path is for Patient, the resource can't be a Binary.
Jason Eisenmenger (Nov 20 2020 at 14:40):
I see, thank you for the clarification
John Moehrke (Nov 20 2020 at 15:18):
I am not disagreeing... but I don't think it is that dire. There are three classes of recipients. There are -A- those that have the keys to everything encrypted, and -B- those that have keys to some, and -C- those that have no keys at all. If we look at the use-cases that drive resource level encryption (aka partial, vs just encrypt everything like is done with TLS), it is because there is something in that resource that is more sensitive (in some way) from the stuff that is not encrypted (or encrypted to a wider audience -B- types AND those resources available to -C- or -B- have a specific need for them. If we look at realistic use-cases, and if FHIR is well designed RESTfully, these three classes of encryption will generally (surely there are exceptions) fall to be unlikely that the resources available do -C- have references to resources not available to -C- (same with -B-). That is to say that sensitive content tends to be at the leaf, not at branch; provided RESTful references tend to point from the leaf resources to the branch resources.
Where this tendency fails, and I know it will fail a non-trivial number of times, those -B- and -C- class recipients should know that they are not -A- class, and thus when they get a relative reference that they can't access then they must assume it is because of their lesser privileges'. THIS is why I want use-cases to be looked at, rather than designing a solution based purely on generic theory.
Yes, this is a break from bdl-5; but it is a break with a describable purpose.
Lloyd McKenzie (Nov 21 2020 at 17:02):
I agree it's a desirable purpose. But bdl-5 exists and is normative. I think it's going to be really hard to get around it, though maybe if we introduce a new bundle type we could pull it off. We could then make bdl-5 contingent on the bundle type not being the new type (or one of the new types if we need more than one)
John Moehrke (Nov 23 2020 at 15:12):
possibly. Seems some experimentation should be done first. These partial encryptions are more often just theory, not ever seen in reality.
Last updated: Apr 12 2022 at 19:14 UTC
