Digital Imaging and Communications in Medicine (DICOM)
Supplement 55: Attribute Level Confidentiality (including De-identification)
DICOM Standards Committee, Working Group 14 Security
1300 N. 17th Street
Rosslyn, Virginia 22209 USA
VERSION: Working Draft 06
26 March 2001
This is a draft document. Do not circulate, quote, or reproduce it except with the approval of NEMA
Please send comments to Howard E. Clark, NEMA ()
Security Supplement - Attribute Level Confidentiality
Page iii
Document History
Document Version / Date / Content0.1 / 9 September 1999 / Initial draft
0.2 / 19 January 2000 / Reworked Encrypted Attributes SQ based on CMS envelope.
0.3 / 28 February 2000 / Corrected supplement number.
0.4 / 3 May 2000 / Reworked Encrypted Attribute SQ as agreed at WG14 meeting.
Added document history and list of open issues.
0.5 / 27 Sept. 2000 / Modifications after WG 14 meetings on 2000-05-31 and 2000-09-22.
0.6 / 26 March 2001 / Included WG6 suggestions, added Encrypted Attributes Module.
Open Issues
In the current draft, the Basic Application Level Confidentiality Profile can be implemented with two alternative sets of cryptographic functions (the profiles defined in the PS 3.15 additions X.2 and X.3 defined in this document). X.2 uses ESDH/3DES, X.3 uses RSA/3DES. Is this set of cryptographic functions appropriate? Do we need both; do we need more?
Contents
Foreword iv
SCOPE AND FIELD OF APPLICATION v
2 Additions to PS 3.3 7
3.1 Reference Model Definitions 7
C.12.1.1.x Encrypted Attribute Descriptions 8
C.12.1.1.x.1 Encrypted Attributes Sequence 8
C.12.1.1.x.2 Encrypted Content 9
C.X SECURITY SPECIFIC Modules 9
C.X.1 Encrypted Attributes Module 9
C.X.1.1 Encrypted Attributes Module Attribute Descriptions 11
C.X.1.1.1 Modified Attributes Sequence 11
C.X.1.1.2 Inserted Attributes 11
C.X.1.1.3 Modified Pixel Data Sequence 11
C.X.1.1.4 Modified Image Area Sequence 11
C.X.1.1.5 Modified Image Area Row Origin 11
C.X.1.1.5 Modified Image Area Column Origin 11
3 Additions to PS 3.6 12
4 Additions to PS 3.15 13
ANNEX X - ATTRIBUTE CONFIDENTIALITY PROFILES 13
X.1 Basic Application Level Confidentiality Profile 13
X.1.1 Service Class User 13
X.1.2 Service Class Provider 16
X.1.3 Conformance Requirements 16
X.2 Application Level ESDH/3DES Confidentiality Scheme 17
X.3 Application Level RSA/3DES Confidentiality Scheme 17
5 Index of Attribute Tags 18
Foreword
The American College of Radiology (ACR) and the National Electrical Manufacturers Association (NEMA) formed a joint committee to develop a standard for Digital Imaging and Communications in Medicine (DICOM). This DICOM Standard and the corresponding Supplements to the DICOM Standard were developed according to the NEMA procedures.
This Supplement to the Standard is developed in liaison with other standardization organizations including CEN TC251 in Europe and JIRA in Japan, with review also by other organizations including IEEE, HL7 and ANSI in the USA. This Supplement has been prepared by the DICOM Working Group 14 (Security).
The DICOM Standard is structured as a multi-part document using the guidelines established in the following document:
- ISO/IEC Directives, 1989 Part 3 : Drafting and Presentation of International Standards.
This document is a Supplement to the DICOM Standard. It is an extension to PS 3.3, 3.6 and 3.15 of the published DICOM Standard which consists of the following parts:
PS 3.1 - Introduction and Overview
PS 3.2 - Conformance
PS 3.3 - Information Object Definitions
PS 3.4 - Service Class Specifications
PS 3.5 - Data Structures and Encoding
PS 3.6 - Data Dictionary
PS 3.7 - Message Exchange
PS 3.8 - Network Communication Support for Message Exchange
PS 3.9 - Point-to-Point Communication Support for Message Exchange
PS 3.10 - Media Storage and File Format for Data Interchange
PS 3.11 - Media Storage Application Profiles
PS 3.12 - Media Formats and Physical Media for Data Interchange
PS 3.13 - Print Management Point-to-Point Communication Support
PS 3.14 - Grayscale Standard Display Function
PS 3.15 - Security Profiles
PS 3.16 - Content Mapping Resource
These parts are related but independent documents.
SCOPE AND FIELD OF APPLICATION
The DICOM security extensions proposed in Supplement 31 and 51 enable data confidentiality during DICOM network communication and DICOM media storage interchange, respectively. In both cases, confidentiality (e.g. encryption) always affects complete DICOM SOP instances or network associations – it is not possible to selectively protect only parts of a DICOM SOP instance. In addition, neither of the two extensions can be used if interoperability with existing “non security aware” legacy applications is required.
This supplements adds a mechanism for a selective protection of individual attributes within arbitrary DICOM SOP Instances. It may be used to achieve protection of identifying information, e.g. a reversible anonymization or pseudonymization of DICOM SOP instances, by implementing modest software changes at the application level only, while continuing to use unmodified lower level message and protocol services for network transfer, storage, and media exchange of composite image information objects.
In particular, protected SOP instances can still be communicated and processed (e.g. displayed) with existing DICOM implementations, security aware or not. Implementations not aware of the security extensions proposed in this supplement will only "see” the anonymized version of the SOP instance, whereas implementations of this supplement may offer functions to reverse/remove the protection if the user has access to the appropriate keys. Use cases in which a selective protection of individual attributes within DICOM SOP instances may be desirable include:
· Image databases for case based reasoning, teaching cases or epidemiologic registry.
· Image transmission over high speed networks where the performance penalty for the encryption/decryption of image pixel data may not be acceptable.
· Image interchange scenarios in which the protected images must be processed (transmitted, viewed) with legacy applications and where a selective protection of SOP Instances is considered appropriate, e.g. Teleradiology second opinion requests for modalities where the identification of the patient from the image data itself is highly unlikely.
The underlying principle of the security extension proposed in this supplement is that all DICOM attribute values to be protected are removed from the SOP instance and, if the attribute is required for the IOD, replaced by a pseudonym (“dummy value”). The original attribute values are encrypted and stored in a separate “container” (the Encrypted Attributes Sequence) which is added to the SOP instance. Decryption of the encrypted information requires access to the private “recipient key” which, as with all applications of public key cryptography, is never transmitted.
This supplement addresses the issue of data confidentiality (as defined in ISO 7498-2) at the application level by defining:
— a framework for the protection of attributes within a Data Set,
— a means of communicating the encryption keys to the intended recipients by means of key transport, key agreement or symmetric key-encryption key schemes,
— an industry standard symmetric encryption algorithm for protection of encrypted attributes (Triple-DES);
— a baseline profile of standard Attributes that if present, need to be encrypted to provide confidentiality.
Other aspects of security are not addressed by this supplement. In particular, the issues of security policy, guidelines, and the public key infrastructure that is a prerequisite to the use of this security extensions are considered to be beyond the scope of the DICOM standard.
Since this document proposes changes to existing Parts of DICOM the reader should have a working understanding of the Standard. This proposed Supplement includes a number of Addenda to existing Parts of DICOM :
- PS 3.3 Addendum : Attribute Level Confidentiality Extensions to SOP Common Module
- PS 3.6 Addendum : Attribute Level Confidentiality Data Dictionary
- PS 3.15 Addendum : Attribute Level Confidentiality Security Profiles
Security Supplement - Attribute Level Confidentiality
Page iii
2 Additions to PS 3.3
Item 2.1 Add the following references to Section 2
ISO 7498-2 Information processing systems - Open Systems Interconnection - Basic reference Model - Part 2: Security Architecture
ISO 8825-1 Information technology – ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).
RFC-2313 PKCS #1: RSA Encryption, Version 1.5, March 1998.
RFC-2630 Cryptographic Message Syntax, June 1999
ANSI X9.52 American National Standards Institute. ANSI X9.52-1998, Triple Data Encryption Algorithm Modes of Operation. 1998.
Item 2.2 Add to following subsection to Section 3
3.1 Reference Model Definitions
This Part of the Standard makes use of the following terms defined in ISO 7498-2:
a. Data Confidentiality
Note: The definition is “the property that information is not made available or disclosed to unauthorized individuals, entities or processes.”
b. Data Origin Authentication
Note: The definition is “the corroboration that the source of data received is as claimed.”
c. Data Integrity
Note: The definition is “the property that data has not been altered or destroyed in an unauthorized manner.”
d. Key Management
Note: The definition is “the generation, storage, distribution, deletion, archiving and application of keys in accordance with a security policy.”
Item 2.3 Add the following rows to Table C.12-1 SOP Common Module Attributes
Encrypted Attributes Sequence / (gggg,eee1) / 1C / Sequence of Items containing encrypted DICOM data. One or more Items shall be present. Required if Conformance to the Basic Application Level Confidentiality Profile is claimed. See C.12.1.1.x.1
>Encrypted Content Transfer Syntax UID / (gggg,eee2) / 1C / Transfer Syntax used to encode the encrypted content. Required if sequence item is present.
>Encrypted Content / (gggg,eee3) / 1C / Encrypted data. Required if the sequence item is present. See C.12.1.1.x.2
Item 2.4 Add the following new section C.12.1.1.x
C.12.1.1.x Encrypted Attribute Descriptions
C.12.1.1.x.1 Encrypted Attributes Sequence
Each Item of the Encrypted Attributes Sequence (gggg,eee1) contains an encrypted DICOM dataset containing a single instance of the Encrypted Attributes Module (C.X.1). It also contains encrypted content-encryption keys for one or more recipients. The encoding is based on the Enveloped-data Content Type of the Cryptographic Message Syntax defined in RFC 2630. It allows to encrypt the embedded Data Set for an arbitrary number of recipients using any of the three key management techniques supported by RFC 2630:
· Key Transport: the content-encryption key is encrypted in the recipient's public key;
· Key Agreement: the recipient's public key and the sender's private key are used to generate a pairwise symmetric key, then the content-encryption key is encrypted in the pairwise symmetric key; and
· Symmetric key-encryption Keys: the content-encryption key is encrypted in a previously distributed symmetric key-encryption key.
A recipient decodes the embedded Encrypted Attributes Module by decrypting one of the encrypted content-encryption keys, decrypting the encrypted dataset with the recovered content-encryption key, and then decoding the DICOM dataset using the Transfer Syntax specified in Encrypted Content Transfer Syntax UID (gggg,eee2).
Multiple Items may be present in the Encrypted Attributes Sequence. The different Items may contain Encrypted Attributes Modules with the same or different sets of Attributes and may contain encrypted content-encryption keys for the same or different sets of recipients. However, if the same Attribute is contained in more than one embedded Encrypted Attributes Module, the value of the Attribute must be identical in all embedded Encrypted Attributes Modules in which the Attribute is contained.
Note: If the Encrypted Attributes Sequence contains more than one Item, and a recipient holds the key for more than one of the items, the recipient may either decode any single one or more of the embedded Data Sets at it’s own discretion. Since the same Attribute is required to have the same value in all embedded Encrypted Attributes Modules, it is safe to “overlay” multiple embedded Encrypted Attributes Modules in an arbitrary order upon decoding.
C.12.1.1.x.2 Encrypted Content
The Encrypted Content (gggg,eee6) attribute contains an Enveloped-data content type of the cryptographic message syntax defined in RFC2630. The encrypted content of the Enveloped-data content type is a DICOM Data Set encoded with the Transfer Syntax specified by the Encrypted Content Transfer Syntax UID (gggg,eee2) attribute.
Note: 1. Content encryption may require that the content (the DICOM Data Set) be padded to a multiple of some block size. This shall be performed according to the Content-encryption Process defined in RFC-2630.
2. Any standard or private Transfer Syntax may be specified in Encrypted Content Transfer Syntax UID (gggg,eee2) unless encoding is performed in accordance with an Attribute Confidentiality Profile that specifies additional restrictions. In general, an application entity decoding the Encrypted Attributes Sequence may not assume any particular Transfer Syntax or set of Transfer Syntaxes to be used with Content Transfer Syntax UID (gggg,eee2).
Item 2.5 Add the following new Annex C.X
C.X SECURITY SPECIFIC Modules
C.X.1 Encrypted Attributes Module
Table C.X-1 contains the Attributes that describe how the process of de-identification of a DICOM SOP instance can be reversed. The Encrypted Attributes Sequence (gggg,eee1) of the SOP Common Module (see section C.12.1.1.x.1) contains one or more instances of this Module in encrypted form. The exact use of this Module is defined in the Attribute Confidentiality Profiles in PS 3.15.
Table C.X-1
ENCRYPTED ATTRIBUTES MODULE ATTRIBUTES
Modified Attributes Sequence / (gggg,eee4) / 1 / Sequence of Items containing the original values of protected Attributes. Only a single Item shall be present. See C.X.1.1.1.
> Any Attribute from the main dataset that was modified or removed during the de-identification process. / 3
Inserted Attributes / (gggg,eee5) / 1c / Identifies attributes in the main dataset that were inserted during de-identification Required if attributes were added to the main dataset during de-identification. See C.X.1.1.2.
Modified Pixel Data Sequence / (gggg,eee6) / 1c / Required if any modification to the Pixel Data (7fe0,0010) Attribute of the main dataset that was performed during de-identification. Only a single Item shall be present. See C.X.1.1.3
>Photometric Interpretation / (0028,0004) / 1c / Required if Sequence Item is present.
>Rows / (0028,0010) / 1c / Required if Sequence Item is present.
>Columns / (0028,0011) / 1c / Required if Sequence Item is present.
>Bits Allocated / (0028,0100) / 1c / Required if Sequence Item is present.
>Bits Stored / (0028,0101) / 1c / Required if Sequence Item is present.
>High Bit / (0028,0102) / 1c / Required if Sequence Item is present.
>Pixel Representation / (0028,0103)) / 1c / Required if Sequence Item is present.
> Any other Attribute from the Image Pixel Module of the main dataset / 3
>Modified Image Area Sequence / (gggg,eee7) / 1c / Sequence of Items containing Attributes that describe modifications to the Pixel Data (7fe0,0010) Attribute of the main dataset that were performed during de-identification. One ore more Items shall be present. Required if Sequence Item is present. See C.X.1.1.6.
>Rows / (0028,0010) / 1c / Required if Sequence Item is present.
>Columns / (0028,0011) / 1c / Required if Sequence Item is present.
>Modified Image Area Row Origin / (gggg,eee8) / 1c / Required if Sequence Item is present. See C.X.1.1.5
>Modified Image Area Column Origin / (gggg,eee9) / 1c / Required if Sequence Item is present. See C.X.1.1.6
>Pixel Data / (7FE0,0010) / 1c / Required if Sequence Item is present.
C.X.1.1 Encrypted Attributes Module Attribute Descriptions
C.X.1.1.1 Modified Attributes Sequence
The Modified Attributes Sequence contains a single Item with all attributes that were removed or replaced by “dummy values” in the main dataset by an SCU of the Basic Application Level Confidentiality Profile during de-identification of the SOP instance. Upon reversal of the de-identification process, the attributes are copied back into the main dataset, replacing any dummy values that might have been created by the SCU of the the Basic Application Level Confidentiality Profile.