0

We have a requirement to transfer documents (HL7/FHIR and others) over HTTP (REST), but where the network architecture involves multiple hops through proxies that unpack and repack the TLS. So the TLS-encryption doesn't help us much, since we break the law if the proxies in-between can see the data. (This is all within a secure semi-private network, but that doesn't help us because different organizations own the different boxes and we're required to have end-to-end encryption).

So we need payload encryption of the documents transfered with HTTP/REST. The common way to do it here is to use SOAP and encrypt the envelope.

What is the best mechanism for content/payload-encrypting REST-transported data? Is there a standard or open specification for it? In health or some other industry?

I guess one feasible way could be to add a special content type that requests encrypted content (S/MIME-based?) to the HTTP request header. A FHIR/REST-server should then be able to understand from the Accept-header of the HTTP-request that the content must be encrypted before responding. As long as the URL itself isn't sensitive, I guess this should work?

I guess also that maybe even the public key for encrypting the content could be passed in a special HTTP request header, and the server could use this for encryption? Or the keys could be shared in setting up the system?

Is this feasible and an ok approach? Has payload-encryption been discussed in the HL7-FHIR work?

Larsie
  • 309
  • 1
  • 9

1 Answers1

1

It hasn't been discussed significantly. One mechanism would be to use the Binary resource. Simply zip and encrypt the Bundle/resource you want to transfer and then base-64 encode it as a Binary resource. (I suggest zipping because that makes it easy to set the mime type for the Binary.) That resource would then be the focus of a MessageHeader that would expose the necessary metadata to ensure the content is appropriately delivered across the multiple hops.

This might be a good discussion to start up on the HL7 security list server as they will likely have some additional thoughts and recommendations. (And can also ensure that wherever things land in terms of final recommendation, that that gets documented as part of the spec :>)

Lloyd McKenzie
  • 6,345
  • 1
  • 13
  • 10
  • Does this require base64 encoding the content? Is there another mechanism such as putting the encrypted content in a multipart mime message? – Jeremy Apr 15 '19 at 18:34
  • Actually, no. Binaries only have to be base64 encoded if you're passing them in a Bundle with other content. If you're POSTing or GETing them directly, you can pass around the raw binary. – Lloyd McKenzie Apr 16 '19 at 04:45
  • Hi. Some colleagues have been looking at a similar option here, and I wonder if this is a recommended approach. I've seen https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Encryption which could be also a solution. We can ask in the FHIR Security community about this vs mutual auth TLS, but I was looking at the time of this reply and wanted to see if this is a recommended way of addressing content encryption. – costateixeira Jul 02 '20 at 16:10
  • 1
    You won't find wide support for encryption other than TLS - so if you can make that work, that's certainly the preferred option. Encrypting 'part' of the information is going to require custom system behavior. As well, it doesn't fit terribly well with the RESTful paradigm of direct posts and direct query, which is where systems should generally be trying to migrate to (because those approaches require less negotiation and tend to scale better). – Lloyd McKenzie Jul 02 '20 at 17:31