Document Encryption - Discussion

From IHE Wiki
Revision as of 12:20, 21 August 2011 by Pkoster (talk | contribs)
Jump to navigation Jump to search

Introduction

This page captures discussion items related to the development of the IHE Document Encryption (DEN) profile. Specifically it holds the closed issues list which was removed from the DEN supplement when it went to Trial Implementation.

Latest version

The latest version of the DEN supplement can be found here: http://www.ihe.net/Technical_Framework/upload/IHE_ITI_Suppl_DEN_Rev1-1_TI_2011-08-19.pdf

Related topics

Document_Encryption_-_Implementation_Notes_and_Examples

Closed Issues

Closed Issue 1: Multiple encrypted documents in same transaction / submission set / medium / etc.

Status: added recommendation to key management section in case of encryption of multiple documents that are together to 1) apply same algorithms and other parameters, and 2) use same keys/passwords for a recipient in (the unlikely) case there is choice for such recipient.

Closed Issue 2: Policy aspects out of scope

Status: added statement in security considerations section and/or introduction that policy aspects are out of scope. Policy aspects may be general (regulatory, organizational) policies defining when encryption must take place or relate to e.g. consent policies (BPPC). In later stage may consider appendix to discuss profiles combination to obtain certain result, e.g. BPPC and Document Encryption.

Closed Issue 3: Key Management out of scope

Key management is in general out of scope of this profile. However, this profile acknowledges that key management is an important aspect of any encryption solution. For this purpose this profile puts requirements on the minimal key management hooks that the encryption solution should provide for. Also, certain key management solutions like password-based encryption are so straightforward that they are typically integral part of an encryption solution with little keys to manage. On the other side, more advanced or flexible key management solutions typically have to be carefully chosen in relation to the applicable environment, which may already have a particular infrastructure. For this purpose, this profile does not choose a particular technology but limits itself to the hooks / interfaces to key management.

Status: added text to abstract/introduction and key management section

Closed Issue 4: Selective encryption of documents in (XDM/XDR/XDS) submission set

Status: added use case “Partial encrypted submission set”

Closed Issue 5: XDM Media Encryption option

XDM over media lacks a means to protect the XDM media content like for XDS, XDR and XDM Zip-over-E-mail. Document Encryption can encrypt individual XDM payload documents, but not transactional data and transaction structure, submission set metadata, document metadata. Such data is typically used to route the document(s). XDM uses a file system structure to organize the data in files:

<< image >>

Conclusion:

  • Supplement includes “XDM Media Encryption” option that extends the XDM profile to protect XDM media content on physical media (similar to XDM Zip-over-E-mail). Where possible the solution will be technically aligned with the new Document Encryption profile which can protect generic documents.
  • Supplement discusses application of Document Encryption profile in context of XDM (and XDR) to encrypt individual documents within XDM media content. Supports cases where complete XDM media content encryption is too course.
  • Separate (partial) encryption of metadata, etc., is out of scope for this supplement. It integrates too deep with the XDM specification and would enlarge the scope of this work too much. Similar arguments hold for encryption of submission sets within XDM media content. The two options above (XDM Media Encryption and Document Encryption) have sufficient scope to address a broad range of use cases.

Closed Issue 6: Profile type selection

Options:

  • Transaction Profile
    • representative examples: XUA, ATNA (,PDI)
  • Content Profile
    • representative examples: BPPC
  • Change Proposal
    • representative examples: n/a

Actor and dynamic behavior requirements:

  • Algorithm support (e.g. design for future backwards compatibility)
  • Encryption and decryption process and responsibilities (e.g. ensure proper and secure handling)
  • Key management (e.g. like password derivation requirements in PDI)
  • Above aspects are also seen in e.g. PDI, ATNA and XUA

Through the virtual actors (Content Creator actor and Content Consumer actor) and default transaction (Share Content) also content profiles can constrain the behavior of its actors for Document Encryption. Consequently, the required functionality can be described without the introduction of new actors.

Conclusion:

  • This supplement outputs to two profiles
  • The Document Encryption profile takes the form of a content profile
  • The XDM Media Encryption option takes the form of a change to the XDM profile

Closed Issue 7: Base technology selection for Document Encryption

Criteria:

  • Functional soundness
    • Encryption functionality
    • Key management hooks
    • Crypto algorithm support
  • Maturity and availability
  • Standard (openness)
  • Efficiency
  • Architectural fit
    • Consistency with other IHE profiles
    • Embedding with XD*
    • Generic payload (no bias for document type)
  • Well-defined technology package (constrain vs compose)
  • Functional extensibility (e.g. partial document encryption)
Technology CMS XML Encryption Proprietary Methods Open License Open Implementations WS-* on media
example / note Secure ZIP PGP, Secure TAR TrueCrypt-SingleFileMode Implies XDR/XDS (or equivalent) to carry doc on top of SOAP. Inherits encryption functionality from XML Encryption. SOAP binding to media instead of HTTP.
Pro • Encryption

• PDI uses CMS

• XDM email option uses CMS

• Standard (RFC), publically controlled

• Hooks for flexible key management

• Mature & supported

• Intrinsically supports password-based keys

• Efficient handling of binary data

• Well-defined package for desired functionality (few RFCs)

• Encryption

• ATNA WS-Security option uses XML encryption

• DSG uses XML encryption family

• Standard (W3C), publically controlled

• Hooks for flexible key management

• Mature &supported

• Basic encryption

• Password, certificate support

• Basic file encryption support • Basic file encryption support • ATNA for XDS/XDR allows for WS-*

• Inherits pro’s from ‘XML Encryption’

Con • Password-based keys only supported with extension (PKCS#5v2 Amendment1)

• Complexity to overcome size explosion

• Combination of several parts/standards required (instead of well-defined package)

• Not a publically controlled specification (especially for encryption; tight control of PKWare)

• No consensus regarding encryption method (industry partitioned in PKWare and WinZip camp)

• Less flexible key mgt (limited to password, possibly PKI depending on APPNOTE versionno symmetric)

• Limited vendor support for APPNote implementation of strong encryption

• Not a publically controlled specification

• No integrated encryption / no consistent solution package

• Limited key management hooks

• Not a publically controlled specification

(code = spec) • • Limited hooks for key management options

• Non-standard SOAP binding to media

• SOAP and WS-* overhead for individual documents

• Well-defined support for documents requires extra standard such as XDR to embed document on protocol. Creates complexity.

• Inherits con’s from ‘XML Encryption’; especially password-based encryption; exception: binary data attachments are well-defined in the WS-* stack

Neutral • Tooling support seems okay although not all implementations are clear on all features (e.g. password) • Tooling support seems okay although not all implementations are clear on all features; no PKCS#5v2 Amendment1 (password) support

Discussion and technical findings:

  • Two options to avoid 30% overhead with base64 encoding with XML encryption:
    • XOP (XML-binary Optimized Packaging, W3C):
      • “A XOP package is created by placing a serialization of the XML Infoset inside of an extensible packaging format (such a MIME Multipart/Related, see [RFC 2387]). Then, selected portions of its content that are base64-encoded binary data are extracted and re-encoded (i.e., the data is decoded from base64) and placed into the package. The locations of those selected portions are marked in the XML with a special element that links to the packaged data using URIs.” http://www.w3.org/TR/xop10
      • “at the conceptual level, this binary data can be thought of as being base64-encoded in the XML Document”
      • [Background: MTOM is XOP applied in context of SOAP; used in e.g. XDR/XDS]
    • Keep encrypted data separate from XML using <CipherReference> instead of <CipherValue>.
      • Potentially more efficient than XOP as it avoids base64 encoding and decoding altogether
      • Requires container format to combine both, e.g. mime-container (like XOP). Issue: although technically not complex, it is not specified somewhere separate (i.e. functionality covered in sections 3-5 of the XOP specification) and therefore does not come in a well-defined package
    • [In comparison: CMS does not suffer from this]
  • Password key derivation for XML encryption is not integral part of the current XML encryption specification. The relevant base specification in all cases is PKCS#5v2.
    • RSA released PKCS#5v2 Amendment 1 which defines the XML schema for PKCS#5v2 in context of XML encryption. ftp://ftp.rsa.com/pub/pkcs/pkcs-5v2/pkcs-5v2-0a1.pdf
    • The work-in-progress W3C working draft for XML Encryption 1.1 is going to (release date unknown) include PKCS#5v2 based on but also technically slightly different from Amendment 1. http://www.w3.org/TR/xmlenc-core1/
    • [In comparison: CMS uses PKCS#5v2 (which defines the ASN.1 module) as standardized in RFC3211 and RFC2898]
  • Symmetric keys, public/private keys, out-of-band key retrieval are supported by both CMS and XML Encryption through RecipientInfo and <KeyInfo> structures respectively.


Decision: CMS

Closed Issue 8: Base technology selection for XDM Media Encryption

Criteria:

  • technical alignment with similar cases, e.g.
    • S/MIME solution for XDM Zip-over-Email
    • Encryption (CMS/XML Encryption) solution for Document Encryption
  • same criteria for Document Encryption
    • functionality, hooks for key mgt, etc.
Technology “encrypt-zip-on-media” Document encryption over container format S/MIME with multipart PDI encrypting file by file
example / note (apply S/MIME on ZIP-container just like Zip-over-Email) (with container = ZIP-format; and with document encryption = CMS or XML encryption in line with Document Encryption profile for optimal synergy) (encrypt file-by-file and combine in MIME container)
Pro • alignment with XDM Zip-over-Email (S/MIME)

• ZIP is proven container format

• Open standards and specifications

• alignment with Document Encryption for encryption

• ZIP is proven container format

• Open standards and specifications

• Supports key management hooks

• Basic encryption

• Explicit alignment

Con • S/MIME standard puts many constraints on the application of CMS targeted to the context of E-mail (e.g. for key mgt just PKI, no passwords)

• Extending S/MIME with aspects it explicitly left out through constraints is counter intuitive and may lead to ambiguity or specification complexity

• S/MIME standard puts many constraints on the application of CMS targeted to the context of E-mail (e.g. for key mgt just PKI, no passwords)

• Extending S/MIME with aspects it explicitly left out through constraints is counter intuitive and may lead to ambiguity or specification complexity

• no specification to mimic (XDM) file system structure in MIME multipart; high risk of breaking XDM

• The MIME container does not add functionality except for some metadata as the encrypted files could be stored in the existing file system structure

• PDI Privacy Option is focused only on PDI, which is only defined for DICOM structures on media, not XDM media content.

• PDI Privacy Option is limited in functionality.

• Encryption of individual files in XDM media content file tree exposes structure and may lead to ambiguity

Neutral • Strictly speaking ZIP is not an open standard under public control, but it is available, longstanding and used by many formal (ISO) standards

• Many other archive / container formats, but not intrinsically better (and certainly less widely used)

Main aspects are:

  • Serialization of XDM file structure in some kind of container structure (ZIP, MIME multipart, etc.)
  • Encryption of (serialized) XDM media content
  • Serialization/container candidate is ZIP-format

Decision: document encryption over container format Update: see closed issue #17.

Closed Issue 9: XDM Document Encryption option

Is this an option that belongs in the option list?

Decision: it is an option. Preserves backward compatibility.

Closed Issue 10: File extension for files encrypted using Document Encryption

Option: “.p7m”.

This extension is also used for CMS with enveloped-data such as S/MIME. Some parsing of content may be required to determine actual type (under assumption that no other information is available).

DICOM encryption takes other approach by mandating absence of extension. Decision: use “.p7m”

Closed Issue 11: Mime-type for files encrypted using Document Encryption

Option: “application/pkcs7-mime”

Same as mimeType for S/MIME. Profile uses same structure: CMS over MIME over document

Decision: use “application/pkcs7-mime”

Closed Issue 12: Identification of encapsulated content type

It would be convenient for an application to extract the content type of the encrypted content.

A MIME-wrapper has been introduced that may contain the mime-type of the encrypted content. This is available to parties that have access to the decrypted content.

In an XD* environment the formatCode may contain some information regarding the content of the encrypted content. If present, this is available to all parties (with no access to the decrypted content required). NB: protection of XD* metadata is discussed in a separated issue.

Status: sufficiently addressed by MIME-wrapper and (XD*) metadata which may contain information or hints regarding the type of the content

Closed Issue 13: XDS Metadata for files encrypted by Document Encryption

Affected metadata:

XDSDocumentEntry Attribute Document Encryption Requirement Remark
hash No special requirement for Document Encryption Hash is calculated over encrypted document
mimeType Set to “application/pkcs7” Identifies document encrypted according to Document Encryption Profile
size No special requirement for Document Encryption Size of encrypted document

For discussion on formatCode see closed issue #19.

Discussion on mimeType attribute. How to deal with the loss of the ‘original’ (underlying) values for mimeType? Definition of additional attributes is undesired as it introduces complexity. Preserve mimeType inside the encrypted data addresses the potential loss of metadata (to some extent). See closed issue #12.

The main indicator in an XD* environment that Document Encryption is applied is through the mimeType attribute.

Status: resolved through above proposal

Closed Issue 14: File name for XDM encrypted ZIP file

Option 1: “XDMME???.pk7”. Approach comparable with XDM Zip-over-Email option (magic subject line). XDMME = XDM Media Encryption. Extension same as above.

Status: proposal accepted with further constraint that ??? may only be 3 numeric characters to ensure compatibility with all file-systems.

Closed Issue 15: Preservation of filename and mime-type

In a number of cases application of Document Encryption leads to potential loss of the original filename (replacement of extension by .p7m) or mimeType (replaced by application/pkcs7-mime)), which may cause problems.

Solution: apply MIME-wrapper to document before encrypting using CMS. Very similar to S/MIME. This use of MIME can be done efficient and with low complexity (addition of few MIME-headers in front of binary data). See also closed issue #13.

Status: volume 3 for Document Encryption has been adapted according to above solution.

Closed Issue 16: Integrity protection

Arguments:

  • it is good security practice to combine encryption with basic integrity protection.
  • some means to determine that decryption was successful is desired.
  • in some (XD*) cases a logical candidate is available to protect integrity (and more, e.g. IHE DSG), others do not (and cannot practically use e.g. IHE DSG)
  • some standards intrinsically support basic integrity (e.g. keyed message digest)
  • increased complexity in key management is undesired
  • creating options in profile (and multiple solutions, e.g. competing with IHE DSG) is undesired

DICOM Secure DICOM Files mandates:

  • The encrypted content of the Enveloped-data content type shall be of the following choices:
    • Signed-data content type;
    • Digested-data content type.
  • In both cases, SHA-1 [SHA-1] shall be used as the digest algorithm. In case of the Signed-data content type, RSA [RFC 2313] shall be used as the signature algorithm.

Resolution: include integrity protection to verify that the decryption was successful

Closed Issue 17: Encryption approach for XDM Media Encryption option

Should XDM Media Encryption option re-use Document Encryption or just use encryption option identical to Document Encryption?

  • Option 1: reference Document Encryption
    • Advantage : functionality only defined in one place
    • Disadvantage: the broader scope of Document Encryption may confuse implementers, e.g. the handling of XDS metadata which is at a different level.
  • Option 2: copy encryption functionality from Document Encryption profile to XDM transaction
    • Advantage: simpler for implementer who just looks at single profile
    • Disadvantage: maintenance may be more work

Resolution: verbatim copy of DEN profile encryption solution used for XDM Media Encryption option (without MIME wrapper as the extra information from the MIME header is not necessary for XDM Media Encryption option)

Closed Issue 18: Protection of metadata

A tension was discovered that in an XD* environment on one hand it may be desired to not disclose metadata for documents that are encrypted as the metadata may disclose information inconsistent with the objective of encrypting the content, and on the other hand that the metadata is present in an XD* environment with a purpose.

Principle: protection of metadata is a policy issue (similar to the application of Document Encryption)

Options: 1. No metadata 2. Minimal metadata (e.g. just patientID; no clear UC for XDS although ‘purpose of use UC’ may provide applicable UC) 3. Encrypted XDM encapsulation: wrap original metadata and document(s) in XDM with Media Encryption (or E-mail with S/MIME) option and put the resulting file as payload in a XD* transaction with no/minimal metadata. As a result the metadata and documents can be protected and still available to a receiver.

Option 1 and 2 are already covered in the present security considerations (see below). Option 3 could also be included in the security considerations as an option that can be applied. No technical changes are required.

Statements already in this supplement regarding protection of metadata:

  • XDM Media Encryption (closed issue): Separate (partial) encryption of metadata, etc., is out of scope for this supplement. It integrates too deep with the XDM specification and would enlarge the scope of this work too much. Similar arguments hold for encryption of submission sets within XDM media content. The two options above (XDM Media Encryption and Document Encryption) have sufficient scope to address a broad range of use cases.
  • Security considerations (section X.28.4): Security of metadata. This profile presents how it can be combined with IHE XDR and XDM exchange protocols. It should be stressed however that this profile only protects the document and not the other transaction-related data. An example of this is the mandatory XDS metadata, which may contain privacy sensitive data. The impact of this should be assessed separately. Possible action can be to minimize the metadata, but also to use transport security, e.g. IHE ATNA, to protect the transaction including the metadata. This excludes outsiders from access to the metadata while legitimate intermediaries and end-points can use the metadata for basic handling of the encrypted document.

Resolution: add encapsulation alternative to security considerations

Closed Issues 19: Discussion on formatCode attribute

FormatCode potentially can identify that document is encrypted. Document Encryption may but not necessarily must affect formatCode. Potential issue is that some implementations do look to formatCode, but not to mimeType. However, typical implementations have code that handles if data is different than expected and will throw an error, which in this case is acceptable behavior. Prefixing existing formatCodes with a value indicating encryption effectively doubles the number of formatCodes which is terrible to maintain. Proposal therefore that Document Encryption does not affect formatCode.

Regarding the discussion of formatCode in XDS metadata here is the current text from volume 3: "Code globally uniquely specifying the format of the document. Along with the typeCode, it should provide sufficient information to allow any potential XDS Document Consumer to know if it will be able to process the document. The formatCode shall be sufficiently specific to ensure processing/display by identifying a document encoding, structure and template (e.g., for a CDA Document, the fact that it complies with a CDA schema, possibly a template and the choice of a content-specific style sheet)."

As-is, that says to me that an encrypted document must have a different format than its underlying document would have. Considering the detail it describes, it actually seems to mandate that there be a matching "encrypted" format for every other format that might be encrypted. If we're going to have the formatCode represent the format of the underlying document, I feel that we need to spell out that distinction.

Resolution: update vol 3 text on XDS Metadata that if mimeType indicates encryption that formatCode then reflects the underlying document

Retrieved from "http://wiki.ihe.net/index.php?title=Document_Encryption_-_Discussion&oldid=53079"