Stream: implementers
Topic: Encrypted Binaries
Grahame Grieve (Oct 07 2017 at 20:00):
I'm working with an implementer that has a need to use encrypted binaries. A binary is a binary, so encrypted is fine... but you need some minimal crypto metadata .... we don't really have space for this anywhere.
Grahame Grieve (Oct 07 2017 at 20:00):
has anyone looked at this before?
John Moehrke (Oct 10 2017 at 14:28):
Can you give me some context to the use-case? There are standards based solutions. However the choice of which of these will be dependent on the intended use-case. Specifically the use-case will drive key-management. For example how does the one encrypting know the keys to use so that only the targeted recipient can decrypt.
John Moehrke (Oct 10 2017 at 14:28):
The most re-usable is CMS (Like found in the IHE-Document Encryption (DEN) profile http://wiki.ihe.net/index.php/Document_Encryption This is also the core standard used in S/MIME
Grahame Grieve (Oct 10 2017 at 14:29):
why does that make any difference? let's assume that there's some way to know
John Moehrke (Oct 10 2017 at 14:37):
There are efforts now in HTTP workgroup to add targeted Digital Rights Management methods... Is that what this person is looking for? It is a very different architecture than content encryption to a pre-known targeted identity.
Grahame Grieve (Oct 10 2017 at 14:41):
the context of use here is pre-known targetted identity
John Moehrke (Oct 10 2017 at 14:43):
okay, known identities certificate or Oauth? Would drive use of CMS vs JWE..
Grahame Grieve (Oct 10 2017 at 14:44):
OAuth is not in the picture here.
John Moehrke (Oct 10 2017 at 14:44):
I might ask why transport encryption is not sufficient? That might tease out 'requirements' that are not being said.
Grahame Grieve (Oct 10 2017 at 14:46):
because there are multiple hops - both routing and storage- between source and target, and this breaks transport continuity, but the intermediaries are not authorized to view the content
John Moehrke (Oct 10 2017 at 14:46):
Hence why I wondered about DRM... as many people get excited about DRM and want to use it... DRM is very helpful 'access control' model...
John Moehrke (Oct 10 2017 at 14:46):
Okay, then CMS seems a good choice .. CMS is widely implemented. And if you have either secret key (password), or certificate based identities; it is a good choice for end-to-end encryptjon.
John Moehrke (Oct 10 2017 at 14:47):
Take a look at the IHE profile. I think it would be re-usable here.
Grahame Grieve (Oct 10 2017 at 14:47):
cms as in https://en.wikipedia.org/wiki/Cryptographic_Message_Syntax?
John Moehrke (Oct 10 2017 at 14:48):
Yes
Grahame Grieve (Oct 10 2017 at 14:48):
it does look like the right base. What do we need to do to support it with Binary?
Grahame Grieve (Oct 10 2017 at 14:50):
I will have to look
John Moehrke (Oct 10 2017 at 14:53):
So the idea you have is that a Bundle would contain a set of Resources and an encrypted Binary? Or would the whole Bundle be encrypted? I am trying to figure out why this is unique to Binary.
John Moehrke (Oct 10 2017 at 14:54):
Would we have a need to create a Bundle mechanism for 'any' resource to be encapsulated in a CMS envelope? (We are re-inventing SOAP... you know that, right?)
John Moehrke (Oct 10 2017 at 14:55):
Note that SOAP already has this ability, using XML-Encryption....
Julie Maas (Oct 10 2017 at 20:33):
Considering that there are "untrusted" intermediaries involved, signing the content so the recipient can authenticate the source would make sense, in addition to encrypting it for the ultimate data consumer. CMS/S/MIME supports this. This is essentially Direct Messaging without the SMTP transport, so existing Direct tools (and potentially existing endpoints and trust frameworks) could be adapted for this.
Grahame Grieve (Oct 12 2017 at 10:53):
I don't know whether this applies outside binary or not.
Grahame Grieve (Oct 12 2017 at 10:53):
what makes this different to SOAP/S-MIME is that the question is around persisting, not just sending.
John Moehrke (Oct 12 2017 at 13:05):
That sounds like the CMS (like profiled in IHE-DEN profile) is the best choice. This is the kind of use-case that drove the IHE-DEN profile. Where the content needed to be encrypted/signed in a transport agnostic way. The content can be anything, mime-type described. The transport can be anything, including mixed mode transport (http --> email --> usb-stick --> SOAP...). The CMS survives all those conversions between transports. Key management can be as simple as a shared secret, or as complete as PKI. ((( Note that CMS is the underlying standard of S/MIME too)))
Grahame Grieve (Oct 14 2017 at 20:14):
indeed that sounds like the case - do we need to do anything in FHIR for this? It seems to me that we do, for binary at least.
Grahame Grieve (Oct 14 2017 at 20:14):
another question that arises is whether anyone has used element level encryption as defined in https://www.w3.org/TR/xmlenc-core/, and whether we should think about that
John Moehrke (Oct 18 2017 at 16:20):
I would be glad to add a note on the security pages about encapsulating encryption. I would like to see a few more that indicate that this is a proper guidance.
John Moehrke (Oct 18 2017 at 16:23):
element level encryption is fraught with ways to fail... More so than partial signatures... that is to say when one does element level encryption or signatures you must do it really-really correct. element level encryption can fail to fully encrypt due to lack of well implemented initialization vectors. I would certainly recommend that that this is well beyond any implementation today in anything other than academic prototypes.
Grahame Grieve (Oct 22 2017 at 20:08):
I agree. Was just checking
Last updated: Apr 12 2022 at 19:14 UTC
