nema standards publication ps 3 supplement 41dicom.nema.org/dicom/supps/sup41_02.pdf · working...

WORKING DRAFT

NEMA Standards Publication PS 3 Supplement 41

Digital Imaging and Communications in Medicine (DICOM)Security Enhancements Two – Digital Signatures

This is a draft document. Do not circulate, quote, or reproduce it except with the approval of NEMA

Please send comments to Dave Snavely, NEMA ([email protected])

Status: Working Draft Version 0.2 – 23 February 1999

Editor: Lawrence Tarbox, Ph.D, Siemens Corporate Research

Prepared by

DICOM Standards Committee, Working Group 141300 N. 17th Street, Suite 1847Rosslyn, Virginia 22209 USA

© 1998, 1999 by National Electrical Manufacturers Association

Supplement 41Page i

Security Enhancements Version 0.2 – 23 February 1999

Table of Contents

Foreword...........................................................................................................................................iii2

SCOPE.............................................................................................................................................iv

ASSUMPTIONS................................................................................................................................iv4

Additions to PS 3.2.............................................................................................................................1

Item 1.2 Add the following to the conformance requirements in Section 7.5 ...................................16

Additions To PS 3.3............................................................................................................................1

Item 2.1 Add the following references to Section 2 .......................................................................18

item 2.2 Add to following subsections to Section 3 .......................................................................13.x Reference Model Security Architecture Definitions..........................................................1103.y Security Definitions........................................................................................................2

Item 2.3 Add the following definitions to Section 3.8.....................................................................212

Item 2.4 Add the following abbreviations to Section 4 ...................................................................2

Item 2.5 Add the following sub-sections to Section 5 conventions (or wherever Macros are defined)143

5.X Digital Signatures Macro.................................................................................................316Item 2.6 Add the following rows to Table C.12-1 sop common module attributes and add subsectionC.12.1.x 818

C.12.1.x Revision Date/Time and Revision UID.....................................................................9Additions to PS 3.4.............................................................................................................................920

Item 3.1 Replace the third entry in Table 3.2-1 with the following....................................................9

Item 3.2 Replace the third entry in Table 3.2-2 with the following....................................................922

Item 3.3 Add the following to the end of section B.4.1 ................................................................10

Item 3.4 Add the following after the first bullet item of Section B.4.3.2..........................................1024

Additions to PS 3.6...........................................................................................................................10

Item 4.1 Add the following rows to the table in section 6 ..............................................................1026

Additions to PS 3.15.........................................................................................................................11

Item 7.1 Add the following references to Section 2 .....................................................................1128

Item 7.2 Add the following definition to Section 3.2 (definitions from ISO 7498-2).........................11

Item 7.3 Add the following subsection to Section 3.....................................................................1230

3.5 DICOM SECURITY PROFILES DEFINITIONS..........................................................................12

Item 7.4 Add the following at the beginning of Section 6 .............................................................1232

Item 7.5 Add the following subsection to Section 6.....................................................................12

6.3 DIGITAL SIGNATURE PROFILE.............................................................................................1234

Item 7.6 Add the following sections to Annex A ..........................................................................12

A.X BASIC DIGITAL SIGNATURES SECURE USE PROFILE................................................1236

A.Y BIT-PRESERVING DIGITAL SIGNATURES SECURE USE PROFILE...............................13

Item 7.7 Add the following Annex ..............................................................................................1338

Annex C DIGITAL SIGNATURE PROFILES (Normative)................................................................13

C.1CREATOR RSA DIGITAL SIGNATURE PROFILE....................................................................1340

Supplement 41Page ii


C.2AUTHORIZATION DIGITAL SIGNATURE PROFILE.................................................................14

Supplement 41Page iii


Foreword

Supplement 31 to DICOM added hooks to allow DICOM applications to exchange messages over a2Secure Transport Connection. While this protects the data during transit, it did not provide any lifetimeintegrity checks for DICOM SOP Instances. This supplement adds mechanisms for adding Digital4Signatures to DICOM SOP Instances as a first step toward lifetime integrity checks. Digital Signatures,even when used with secure communications channels, do not provide comprehensive security in6DICOM environments, since comprehensive security requires site guidelines and policies that are beyondthe scope of the DICOM Standard. More comprehensive security might also require other considerations8within DICOM that are not covered by this supplement. However, this supplement adds additionalsmeasures that applications may use in creating a more comprehensive secure environment within which10DICOM could operate. Enhancements to or possibly even replacements for these mechanisms areexpected in future versions as clinical needs are identified, as other related standards evolve, and as12technology advances. In other words, we do expect additional Security Enhancements.

This supplement only addresses the following aspects of security:14

— Authentication – verifying the identity of entities involved in an operation

— Data Integrity – verifying that data within an object has not been altered or removed16

Covering other security aspects requires a more comprehensive security policy.

Digital Signatures allow authentication, or verification, of the identity entity that created, authorized, or18modified a DICOM Data Set. This supplement adds Attribute sequences to Information Object Definitionsthat allow creators or modifiers of SOP Instances to certify their identity through Digital Signatures. This20authentication is in addition to any authentication done when exchanging messages over a SecureTransport Connection.22

The creator of a Digital Signature identifies the Data Elements of a SOP Instance that are included in thecalculation of the MAC (Message Authentication Code) used in the Digital Signature. After the creator24calculates the MAC, it then encrypts the MAC with a key or the private part of a key pair unique to thecreator of the Digital Signature. The key or public part of a key pair is distributed to those recipients who26need to verify the signature through means outside the scope of this Standard. Any receiver of the SOPInstance that knows the key or public part of the key pair can then recalculate the MAC and compare it with28the MAC recorded in the Digital Signature, taking into account the encryption, in order to verify theintegrity of the subset of Data Elements included in the calculation of the MAC for the Digital Signature. If30any of the identified Data Elements had been altered or removed, it is extremely unlikely that the MACcalculated by the receiver and the MAC within the Digital Signature would agree. Typically the creator of32the Digital Signature would only include Data Elements whose data had been verified in the MACcalculation for the Digital Signature. Note that any Digital Signatures embedded in SOP Instances can be34valid for Media Interchange as well as Network Interchange.

This supplement adds modules and Attribute definitions to PS 3.3, PS 3.4, and PS 3.6 for implementing36the Digital Signature functions. This supplement adds new Security Profiles to Part 15 of this standardthat holds Security Profiles that are used to specify mechanisms and algorithms for providing security. 38Implementations may claim conformance to one or more Security Profiles.

Supplement 41Page iv


SCOPE

The Standard allows receivers of an object to authenticate the source of the various pieces of information2within the object, and to ascertain that the information has not been altered. The use of thesemechanisms is optional.4

The standard does not address issues of security policies, though clearly adherence to appropriatesecurity policies is necessary for any level of security. The standard only provides mechanisms that could6be used to implement security policies with regard to the interchange of DICOM objects betweenApplication Entities.8

Wherever possible this Standard utilizes commonly available mechanisms rather than attempt to defineDICOM specific mechanisms. The primary reason is to allow faster development and implementation of10the Standard. By using existing mechanisms and standards this Standard leverages the knowledge andexpertise of those working intimately in the security field. This Standard primarily selects available12mechanisms and dictates how they may be applied within DICOM.

The initial focus of this Standard is a short-term solution that can be implemented with existing tools. 14Since security mechanisms are still maturing, these short-term solutions may be replaced by moreappropriate solutions in the future.16

ASSUMPTIONS

This Standard assumes that the Application Entities involved in a DICOM interchange are implementing18appropriate security policies, including, but not limited to access control, audit trails, physical protection,maintaining the confidentiality and integrity of data, and mechanisms to identify users and their rights to20access data. Essentially, each Application Entity must insure that their own local environment is securebefore even attempting secure communications with other Application Entities.22

When Application Entities agree to interchange information via DICOM through association negotiation,they are essentially agreeing to some level of trust in the other Application Entities. Primarily Application24Entities trust that their communication partners will maintain the confidentiality and integrity of data undertheir control. Of course that level of trust may be dictated by local security and access control policies.26

This Standard assumes that Application Entities can securely identify local users of the Application Entity,and that user’s roles or licenses. Note that users may be persons, or may be abstract entities, such as28organizations or pieces of equipment. When Application Entities agree to an exchange of information viaDICOM, they may also exchange information about the users of the Application Entity via the Certificates30exchanged with the Digital Signatures.

This Standard also assumes that an Application Entity has secure access to or can securely obtain X.50932key Certificates for the users of the application entity. In addition, this standard assumes that anApplication Entity has the means to validate an X.509 certificate that it receives. The validation mechanism34may use locally administered authorities, publicly available authorities, or some trusted third party.

This Standard cannot assume that all Application Entities preserve bit-for-bit all of the information received36via DICOM, implying that such Application Entities may not pass DICOM SOP Instances along withoutsome minor differences in the data. For example, some implementations may strip or add trailing blanks to38

Supplement 41Page v


text fields. However, this standard does assume that there are some Application Entities that do preserveand can pass along exact copies of DICOM SOP Instances.2

Several sources can contribute to the information content of a DICOM SOP instance. The standardproposes a mechanism for embedding multiple digital signatures within DICOM objects. The digital4signatures could authenticate the sources of various pieces of information within the object, and couldserve as lifetime integrity checks of the information signed. Since not all DICOM implementations are bit6preserving, the standard provides a mechanism for an application entity to verify the incoming digitalsignature, then replace it with one that the application entity generates before sending the object on. 8Further, the standard adds a field to extended negotiation for the storage service class by whichapplication entities can determine if their communication partners are bit preserving (and hence digital10signature preserving) or not.

Supplement 41Page 1


Additions to PS 3.2

Item 1.2 Add the following to the conformance requirements in Section 7.52

An implementation shall declare in its Conformance Statement which level of security features it supports,including such things as:4

a. The conditions under which the implementation preserves the integrity of Digital Signatures (e.g.is the implementation bit-preserving).6

b. The conditions under which the implementation verifies incoming Digital Signatures.

c. The conditions under which the implementation replaces Digital Signatures.8

Additions To PS 3.310

Item 2.1 Add the following references to Section 2

ITU-T Recommendation X.509 The Directory – Authentication Framework”12Note: ITU-T Recommendation X.509 is similar to ISO/IEC 9594-8 1990. However, the ITU-T recommendation

is the more familiar form, and was revised in 1993. ITU-T was formerly known as CCITT.14

ISO/IEC DIS 10118-3 Information technology – Security techniques – Hash-functions – Part 3:16Dedicated hash-functions (RIPEMD-160 reference)

Note: The RIPEMD-160 specification and sample code are also available at18ftp://ftp.esat.kuleuven.ac.be/pub/bosselae/ripemd

PKCS#1 RSA Encryption Standard, RSA Laboratories20Note: The RSA Encryption Standard is also defined in informative annex A of ISO/IEC 9796, and in Normative

Annex A of the CEN/TC251 European Prestandard prENV 12388:1996.22

ISO 7498-2Information processing systems – Open Systems Interconnection – Basic reference24Model – Part 2: Security Architecture

ECMA 235 The ECMA GSS-API Mechanism26

FIPS PUB 46 Data Encryption Standard

FIPS PUB 81 DES Modes of Operation28

item 2.2 Add to following subsections to Section 330

3.x Reference Model Security Architecture Definitions

This Part of the Standard makes use of the following terms defined in ISO 7498-2:32

Supplement 41Page 2


a. Digital Signature2

Note: The definition is “Data appended to, or a cryptographic transformation of, a data unit that allows arecipient of the data unit to prove the source and integrity of that unit and protect against forgery e.g.4by the recipient.”

6

b. Data Confidentiality8

Note: The definition is “the property that information is not made available or disclosed to unauthorizedindividuals, entities or processes.”10

c. Data Origin Authentication12

Note: The definition is “the corroboration that the source of data received is as claimed.”14

d. Data Integrity16

Note: The definition is “the property that data has not been altered or destroyed in an unauthorized manner.”18

e. Key Management20

Note: The definition is “the generation, storage, distribution, deletion, archiving and application of keys in22accordance with a security policy.”

24

3.y Security Definitions

This Part of the Standard makes use of the following terms defined in ECMA 235:26

a. Security Context28

Note: The definition is “security information that represents, or will represent a Security Association to aninitiator or acceptor that has formed, or is attempting to form such an association.”30

Item 2.3 Add the following definitions to Section 3.832

Message Authentication Code: A digest or hash code derived from a subset of Data Elements.

Certificate: An electronic document which identifies a party and that party’s public encryption algorithm,34parameters, and key. The Certificate also includes, among other things, the identity and a digital signaturefrom the entity which created the certificate. The content and format of a Certificate are defined by ITU-T36Recommendation X.509.

Item 2.4 Add the following abbreviations to Section 438

MAC Message Authentication Code

ITU-T International Telephone Union40

Supplement 41Page 3


Item 2.5 Add the following sub-sections to Section 5 conventions (or wherever Macros aredefined)2

5.X Digital Signatures Macro

This macro allows Digital Signatures to be included in a DICOM Data Set for the purpose of insuring the4integrity of the Data Set, and to authenticate the sources of the Data Set. Table 5-x defines the Attributesneeded to embed a Digital Signature in a Data Set. This macro may appear in individual sequence items as6well as in the main Data Set of the SOP Instance.

Note: Each item of a Sequence of Items is a Data Set. Thus, individual Sequence items may incorporate their8own Digital Signatures in addition to any Digital Signatures added to the Data Set in which the Sequenceappears.10

Table 5-XDIGITAL SIGNATURES MACRO ATTRIBUTES12

Attribute Name Tag Type Attribute Description

MAC ParametersSequence

(4FFE,0001) 3 A sequence of one or more items thatdescribe the parameters used to calculate aMAC for use in Digital Signatures.

>MAC ID Number (gggg,ee12) 1C A number used to identify this MACParameters Sequence item. Required if thesequence item is present.

>MAC Calculation TransferSyntax UID

(gggg,eee1) 1C The transfer syntax UID used to encode thevalues of the Data Elements included in theMAC calculation. Only the Explicit VR LittleEndian and Explicit VR Big Endian TransferSyntaxes shall be used. Required if thesequence item is present.

Enumerated Values:

1.2.840.10008.1.2.11.2.840.10008.1.2.2

Notes: 1. Although only these two TransferSyntaxes are allowed, futurerevisions of the standard may allowadditional Transfer Syntaxes. Implementations should be preparedfor such additions.

2. MAC codes for pixel data intendedto be encoded with a losslesscompression scheme (e.g. JPEG orRLE) are calculated on the unecodeddata (i.e. before encoding or afterdecoding). This restriction is neededsince the encoded byte stream of thesame pixel data may differ betweenimplementations even though thedecoded byte stream is identical.

3. Since lossy compresstion (e.g.JPEG) encoding is not reversible andmay not be consistent betweenimplementations, it currently is not

Supplement 41Page 4


possible to include pixel data encodedwith lossy JPEG in a MAC calculationfor Digital Signatures.

>MAC Algorithm (gggg,eee2) 1C The algorithm used in generating the MAC tobe encrypted to form the Digital Signature.Required if the sequence item is present.

Defined Term: RIPEMD160.Note: Although this is a Defined Term,

Digital Signature Security Profilesmay require the use of specific termsrepresenting specific algorithms.

>Data Elements Signed (gggg,eee3) 3 A list of Data Element Tags in the order theyappear in the Data Set which identify the DataElements used in creating the MAC for theDigital Signature. Required if the sequenceitem is present. See Section 5.X.1.1 for moreinformation on how this is used.

Digital SignaturesSequence

(FFFA,FFFA) 3 Sequence holding one or more DigitalSignatures which certify the identity of theentity which created, modified, or verified thisData Set, and provide a means to verify theintegrity of data originally placed in the DataSet or verified by that entity.

>MAC ID Number (gggg,ee12) 1C A number used to identify which MACParameters Sequence item was used in thecalculation of this Digital Signature. Required ifthe sequence item is present.

>Digital SignatureDateTime

(gggg,ee11) 1C The date and time the Digital Signature wascreated. Required if the sequence item ispresent. The time shall include an offset (i.e.,time zone indication) from CoordinatedUniversal Time.

Note: This is not a certified timestamp, andhence is not completely verifiable. Anapplication can compare this date andtime with those of other signaturesand the validity date of the certificateto gain confidence in the veracity ofthis date and time.

>Digital Signature UID (gggg,ee13) 1C A UID that can be used to uniquely referencethis signature. Required if the sequence itemis present.

>Certificate Type (gggg,ee14) 1C The type of certificate used in (gggg,eee4). Required if the sequence item is present.

Defined Term: X509-1993-SIGNote: Although this is a Defined Term,

Digital Signature Security Profilesmay require the use of specific terms

Supplement 41Page 5


representing specific certificatetypes.

>Certificate of Signer (gggg,eee4) 1C A certificate that holds the identity of the entityproducing this Digital Signature, that entity’spublic key or key identifier, and the algorithmand associated parameters with which thatpublic key is to be used. Algorithms allowedare specified in Digital Signature SecurityProfiles. Required if the sequence item ispresent.

Notes: 1. As technology advances,additional encryption algorithms maybe allowed in future versions. Implementations should take thispossibility into account.

2. When symmetric encryption isused, the certificate merely identifieswhich key was used by which entity,but not the actual key itself. Someother means (e.g., a trusted thirdparty) must be used to obtain the key.

>Signature (gggg,eee5) 1C The MAC generated as described in Section12.2.1.1 and encrypted using the algorithm,parameters, and private key associated withthe Certificate of the Signer (gggg,eee4). Required if the sequence item is present.

>Timestamp Type (gggg,eee9) 2C The type of certified timestamp used in theTimestamp (gggg.ee10) Attribute. Required ifTimestamp is present

Defined Terms: ???Note: Although this is a Defined Term,

Digital Signature Security Profilesmay require the use of specific termsrepresenting specific certifiedtimestamp types.

>Timestamp (gggg,ee10) 3 A certified timestamp of the Digital Signature(gggg,eee5) Attribute Value, which isobtained when the Digital Signature is created.

[Editor’s note —Note that this method of signing is similar to both PGP and PEM. In addition, the use of2RSA in creating a Digital Signature is proposed in a draft European Prestandard from CEN/TC251, prENV12388.]4

[Editor’s note — At one time the specification of the MAC calculation parameters (i.e. Mac Algorithm, DataElements Signed) was separated from the Digital Signatures Sequence, the theory being that having that6information at the beginning of the Data Set might allow for calculation of signatures “on the fly”. Whiletechnically feasible, it did make the specification more confusing. In a subsequent revision we combined8them to simplify the specification based on the realization that the creator of the object (and in general the

Supplement 41Page 6


original Digital Signatures) already knows up front what algorithm and Data Elements will be used in thecalculation, and does not benefit from the separation. Having the MAC calculations at the end also2allowed one to easily add Digital Signatures to complete objects after the fact.

However, later someone objected to lack of separation saying that they wanted to create the signature on4the fly in order to avoid having to cache large amounts of pixel data just to be able to verify signatures. Acounter-objection was raised that one might want to create the list of Data Elements Signed on the fly. 6The compromise was to split the MAC calculation parameters from the Digital Signature Sequence andplace it just before the pixel data. Thus, the creator of the object could add to the list of Data Elements8Signed on the fly, and just add the final tag for Pixel Data if needed. The reader of the object would onlyneed to cache the header information before the pixel data (usually small), and could still calculate the10MAC codes ‘on the fly’ while reading in the bulky pixel data. There is still a question about whether or notcurve data should come before or after the MAC Parameters Sequence, particularly in light of the12proposed physiological data object.]

5.X.1 Digital Signature Attribute Descriptions14

5.X.1 .1 Data Elements Signed

The absence of a Data Elements Signed (gggg,eee3) Attribute or an empty value field in a Data Elements16Signed Attribute shall be interpreted as if tags for all Data Elements at the same level as the MacParameters Sequence, except those disallowed below, were explicitly listed (i.e., a missing or empty list of18tags implies ‘include all possible attributes’).

When the Data Elements Signed Attribute is present with a value, the first tag listed shall reference a Data20Element at the same level as the Mac Parameters Sequence (4FFE,0001) Data Element in which the DataElements Signed Attribute appears. Tags included in Data Elements Signed shall be listed in the order in22which they appear within the Data Set.

The Length to End (0008,0001) tag or tags with an element number of 0000 shall not be included either24implicitly or explicitly in the list of tags in Data Elements Signed (i.e., no data set or group lengths may beincluded in MAC calculations). No tag listed either implicitly or explicitly in the list of Data Elements Signed26shall have a group number less than 0008 or a group number of FFFA (e.g. the Digital SignaturesSequence). The list of tags in the Data Element Signed Attribute shall not include the MAC Parameters28Sequence (4FFE,0001).

If any of the Data Element tags in the list refer to a Sequence of Items, then the tags of all Data Elements30within all items of that sequence shall be implicitly included in the list of Data Elements Signed, exceptthose disallowed above.32

Notes: 1. If an implementation changes the order of items within a sequence, it will invalidated any DigitalSignatures which include Data Elements from that sequence.34

Supplement 41Page 7


2. It is possible to sign individual items within a sequence by including the Digital Signatures Module inthat sequence item. In fact, this is a highly desirable feature, particular when used in the context of2reports. The Digital Signatures Module is applied at the Data Set level, and Sequences of Items aremerely Data Sets embedded within a larger Data Set. Essentially, the Digital Signature Module may be4applied recursively.

An example of nesting Digital Signatures within Data Elements is illustrated in the following figure:6

Digital Signatures Sequence

MAC Parameters Sequence



Item 1 Attributes



Item 2 Attributes

Pixel Data

Sequence of Items

Other Header Data

Other Header Data

In this example, there is main signature covering the pixel data and a few other Data Elements, plus two8individually signed items within a sequence.

10

To generate the MAC, the tag (group and element) and the value of each Data Element referenced eitherexplicitly or implicitly by the tags in the Data Elements Signed list shall be encoded using the Transfer12Syntax identified by the MAC Calculation Transfer Syntax UID (gggg,eee1) of the MAC ParametersSequence item where the Data Elements Signed Attribute appears. The tags and values only of those14encoded Data Elements form a stream of bytes which shall be presented to MAC Algorithm forcomputation of the MAC. For Data Elements with a VR of UN, OB, or OW (e.g. pixel data) which have an16

Supplement 41Page 8


undefined length (i.e. the data is divided into fragments), only the value fields of each fragment shall bepart of the byte stream (i.e. a Data Element with a VR of OB or OW is encoded as if the value had an explicit2length). Any Data Set Trailing Padding (FFFC,FFFC) shall be ignored and shall not be part of the bytestream. Sequence Delimitation Item (FFFE,E0DD) and Item Delimitation Item (FFFE,E00D) Data Elements4shall not be included in the MAC calculation.

After the tags and values of all the Data Elements in the Data Elements Signed list have been placed into6the byte stream presented to the MAC Algorithm, all of the Data Elements within the Digital SignaturesSequence item except the Certificate of Signer (gggg,eee4), Signature (gggg,eee5), Timestamp Type8(gggg,eee9), and Timestamp (gggg,ee10) shall also be encoded, their tags and values extracted, andpresented to the MAC algorithm (i.e., the Attributes of the Digital Signature Sequence Item for this10particular Digital Signature are also implicitly included in the list of Data Elements Signed, except as notedabove). 12

The resulting MAC code after processing this byte stream by the MAC Algorithm is then encrypted asspecified in the Certificate of Signer and placed in the value of the Signature Data Element.14

Notes: 1. The Transfer Syntax used in the MAC calculation may not match the Transfer Syntax used toexchange the Data Set.162. An Application Entity which receives a Data Set with an implicit VR Transfer Syntax may not be ableto verify Digital Signatures which include Private Data Elements or Data Elements unknown to that18Application Entity. Without knowledge of the Value Representation, the receiving Application Entitywould be unable to perform proper byte swapping or be able to properly parse sequences in order to 20generate a MAC.

3. If more than one entity wishes to sign, each would create their own Digital Signatures Sequence22item. They may or may not share the same MAC Parameters Sequence item.

4. The notion of a notary public (i.e., someone who verifies the identity of the signer) for Digital24Signatures is partially filled by the authority which issued the Certificate of Signer.

26

If any Data Element with a VR of UN is included in the Digital Signature, then the Application Entity whichcreated that Digital Signature shall transmit that Data Element with a VR of UN.28

Item 2.6 Add the following rows to Table C.12-1 sop common module attributes and addsubsection C.12.1.x30

Attribute Name Tag Type Attribute Description

RevisionDate/Time

(gggg,eee6) 3? The date and time of this version of the SOP Instance.See C.12.1.x for a description of its use. The timeshall include an offset (i.e., time zone indication) fromCoordinated Universal Time

Revision UID (gggg,eee7) 3? The unique identifier of this version of the SOPInstance. See C.12.1.x for a description of its use.

Include ‘Digital Signatures Macro’ Table 5-X As a minimum, the SOP Class UID (0008,0016) andSOP Instance UID (0008,0018) shall be included inthe list of Data Element Tags being signed.

The Digital Signatures are added by the creators ofthe SOP Instance as a lifetime data integrity check. Multiple Digital Signature items can be used to allowdifferent parties to sign different parts of the Data Set.

Supplement 41Page 9


C.12.1 .x Revision Date/Time and Revision UID

DICOM allows Application Entities to Attribute values (e.g. to correct a patient’s name). When such a2change occurs, the Application Entity may record the date and time of the revision in the RevisionDate/Time (gggg,eee6) Attribute. The application may also uniquely identify this particular revision of a4SOP Instance in the Revision UID (gggg,eee7) Attribute.

Note: These Attributes may be used in some implementations as part of a change tracking mechanism. For6example, a site’s security policy may require such a mechanism, particularly for tracking the validity ofDigital Signatures and the identities of those entities making the changes.8

Additions to PS 3.410

Item 3.1 Replace the third entry in Table 3.2-1 with the following

ItemBytes

Field Name Description of Field

3 Level of DigitalSignature support

A Level 2 SCP may further define its behavior in this byte field.

0 – The signature level is unspecified, the AE is an SCU only, orthe AE is not a level 2 SCP

1 – signature level 1



If extended negotiation is not supported, the default shall have avalue of 0.

12

Item 3.2 Replace the third entry in Table 3.2-2 with the following

ItemBytes

Field Name Description of Field

3 Level of DigitalSignature support

A Level 2 SCP may further define its behavior in this byte field.

0 – The signature level is unspecified, the AE is an SCU only, orthe AE is not a level 2 SCP




If extended negotiation is not supported, no assumptions shallbe made by the Association-requester about the capabilities ofthe Association-acceptor based upon this extended negotiation.

14

Supplement 41Page 1 0


[Editor’s Note: This use of Extended Negotiation is fully backward compatible with existing use; it doesnot change the enumerated values of existing negotiation parameters, and uses formerly reserved byte2fields. A zero value in these new fields will simply indicate the particular behavior is undefined.]

4

Item 3.3 Add the following to the end of section B.4.1

Three levels of Digital Signature support are defined for an SCP which claims conformance to Level 26(Full) storage support:

0 Signature Level 1. SCP may not preserve Digital Signatures and does not replace them.8

1 Signature Level 2. SCP does not preserve the integrity of incoming Digital Signatures, butdoes validate the signatures of SOP Instances being stored, takes implementation-specific10measures for insuring the integrity of data stored, and will add replacement Digital Signaturesbefore sending SOP Instances elsewhere.12

2 Signature Level 3. SCP does preserve the integrity of Digital incoming Signatures (i.e. is bit-preserving, does not change the order of sequence items, and stores and retrieves all Attributes14regardless of whether they are defined in the IOD).

16

[Editor’s note: Signature level 2 only requires the SCP to retain attributes needed for storage level 2conformance. Other attributes may be discarded, and would not be included in replacement Digital18Signatures. Do we need a signature level which is not bit-preserving, but does retain all attributes? Orshould we issue a change request to alter the definition of storage level 2 to say it preserves all attributes?]20

Item 3.4 Add the following after the first bullet item of Section B.4.3.2

0 The level of Digital Signature support, as defined by Section B.4.1, shall be stated.22


Item 4.1 Add the following rows to the table in section 6

26

Tag Name VR VM

(gggg,eee1) MAC Calculation Transfer Syntax UID UI 1

(gggg,eee2) MAC Algorithm CS 1

(gggg,eee3) Data Elements Signed AT 1-n

(gggg,ee14) Certificate Type CS 1

(gggg,eee4) Certificate of Signer OB 1

(gggg,eee5) Signature OB 1

(gggg,eee6) Revision Date/Time DT 1



(gggg,eee7) Revision UID UI 1

(gggg,eee9) Timestame Type CS 1

(gggg,ee10) Timestamp OB 1

(gggg,ee11) Digital Signature DateTime DT 1

(gggg,ee12) MAC ID number US 1

(gggg,ee13) Digital Signature UID UI 1

(4FFE,0001) MAC Parameters Sequence SQ 0-n

(FFFA,FFFA) Digital Signatures Sequence SQ 0-n


Item 7.1 Add the following references to Section 2

ITU-T Recommendation X.509 The Directory – Authentication Framework”4Note: ITU-T Recommendation X.509 is similar to ISO/IEC 9594-8 1990. However, the ITU-T recommendation

is the more familiar form, and was revised in 1993. ITU-T was formerly known as CCITT.6

ISO/IEC DIS 10118-3 Information technology – Security techniques – Hash-functions – Part 3:Dedicated hash-functions (RIPEMD-160 reference)8

Note: The RIPEMD-160 specification and sample code are also available atftp://ftp.esat.kuleuven.ac.be/pub/bosselae/ripemd10

PKCS#1 RSA Encryption Standard, RSA Laboratories12Note: The RSA Encryption Standard is also defined in informative annex A of ISO/IEC 9796, and in Normative

Annex A of the CEN/TC251 European Prestandard prENV 12388:1996.14

FIPS PUB 46 Data Encryption Standard

FIPS PUB 81 DES Modes of Operation16

Item 7.2 Add the following definition to Section 3.2 (definitions from ISO 7498-2)18

a. Digital Signature20

Note: The definition is “Data appended to, or a cryptographic transformation of, a data unit that allows arecipient of the data unit to prove the source and integrity of that unit and protect against forgery e.g.22by the recipient.”

24



Item 7.3 Add the following subsection to Section 3

3 .5 DICOM SECURITY PROFILES DEFINITIONS2

Message Authentication Code: A digest or hash code derived from a subset of Data Elements.

Certificate: An electronic document which identifies a party and that party’s public encryption algorithm,4parameters, and key. The Certificate also includes, among other things, the identity and a digital signaturefrom the entity which created the certificate. The content and format of a Certificate are defined by ITU-T6Recommendation X.509.

Item 7.4 Add the following at the beginning of Section 68

An implementation may claim conformance to any of the Security Profiles individually. It may also claimconformance to more than one Security Profile. It shall indicate in its Conformance Statement how it10chooses which profiles to use for any given transaction.

Item 7.5 Add the following subsection to Section 612

6 .3 DIGITAL SIGNATURE PROFILE

An implementation may claim conformance to one or more Digital Signature Profiles.14

A Digital Signature profile consists of the following information:

a. The role that the Digital Signature plays, including:16

1. Who or what entity the Digital Signature represents.

2. A description of the purpose of the Digital Signature.18

3. The condidtions under which the Digital Signature is included in the Data Set.

a. A list of Attributes that shall be included in the Digital Signature.20

b. The mechanisms that shall be used to generate or verify the Digital Signature, including:

1. The algorithm and relevant parameters that shall be used to create the MAC or hash code,22including the value to be used for the MAC Algorithm (gggg,eee2) Attribute.

2. The encryption algorithm and relevant parameters that shall be used to encrypt the MAC or24hash code in forming the Digital Signature.

3. The certificate type or key distribution mechanism that shall be used, including the value to be26used for the Certificate Type (gggg,ee14) Attribute.

a. Any special requirements for identifying the signator.28

b. The relationship with other Digital Signatures, if any.

c. Any other factors needed to create, verify, or interpret the Digital Signature30

Digital Signature Profiles are specified in Annex C.32

Item 7.6 Add the following sections to Annex A

A.X BASIC DIGITAL SIGNATURES SECURE USE PROFILE34

An implementation that validates and generates Digital Signatures may claim conformance to the BasicDigital Signatures Secure Use Profile. Any implementation that claims conformance to this Security Profile36shall obey the following rules in handling Digital Signatures:



a. The implementation shall store any SOP Instances that it receives in such a way that it guardsagainst any unauthorized tampering of the SOP Instance.2

b. Wherever possible, the implementation shall validate the Digital Signatures within any SOPInstance that it receives.4

c. If the implementation modifies the values of any Attributes (for example, to correct a patient’sname), it shall record a Revision Date/Time (gggg,eee6) and Revision UID (gggg,eee7) in the6SOP Instance.

d. If the implementation sends the SOP Instance to another Application Entity, it shall do the8following:

1. remove any Digital Signatures that may have become invalid due to any allowed variations to10the format of Attribute values (e.g. trimming of padding, alternate representations ofnumbers),12

2. generate one or more new Digital Signatures covering the Data Elements that theimplementation was able to verify when the SOP Instance was received.14

A.Y BIT-PRESERVING DIGITAL SIGNATURES SECURE USE PROFILE

An implementation that stores and forwards SOP Instances may claim conformance to the Bit-Preserving16Digital Signatures Secure Use Profile. Any implementation that claims conformance to this Security Profileshall obey the following rules in handling Digital Signatures:18

a. The implementation shall store any SOP Instances that it receives in such a way that when theSOP instance is forwarded to another Application Entity, the value fields of all Attributes are bit-20for-bit duplicates of the fields originally received.

b. The implementation shall not remove any Data Element of any SOP Instance that it receives when22sending that SOP Instance on to another Application Entity via DICOM. This includes any DigitalSignatures received.24

c. The implementation shall not change the VR (e.g. changing UN to something else) of any DataElement that it receives when it transmits that object to another Application Entity.26

d. If the implementation modifies the values of any Attributes (for example, to correct a patient’sname), it shall record a Revision Date/Time (gggg,eee6) and Revision UID (gggg,eee7) in the28SOP Instance.

Item 7.7 Add the following Annex30

Annex C DIGITAL SIGNATURE PROFILES(Normative)32

C.1 CREATOR RSA DIGITAL SIGNATURE PROFILE

The creator of a DICOM SOP Instance may generate signatures using the Creator RSA Digital Signature34Profile. The Digital Signature produced serves as a lifetime data integrity check that can be used to verifythat the pixel data in the SOP instance has not been altered since its initial creation. An implementation36which supports the Creator RSA Digital Signature Profile in general includes a Creator RSA DigitalSignature with every SOP Instance; however, the implementation is not required to do so.38

As a minimum, an implementation shall include the following attributes in generating the Creator RSADigital Signature:40



a. the SOP Class and Instance UIDs

b. the SOP Creation Date and Time, if present2

c. the Study and Series Instance UIDs

d. any attributes of the General Equipment module that are present4

e. any overlay data present

f. any image data present6

The implementation shall use the RIPEMD-160 hashing function to generate a MAC, which is then8encrypted using a private RSA key. The value of MAC Algorithm (gggg,eee2) shall be set to"RIPEMD160". The public key associated with the private key as well as the identity of the Application10Entity or equipment manufacturer that owns the RSA key pair shall be transmitted in an X.509 (1993)signature certificate. The value of the Certificate Type (gggg,eeee) Attribute shall be set to "X509-1993-12SIG". A site-specific policy determines how the X.509 certificates are generated, authenticated, anddistributed. A site may issue and distribute X.509 certificates directly, may utilize the services of a14Certificate Authority, or use any reasonable method for certificate generation and verification. Typicallythe certificate and associated private key are configuration parameters of the application entity set by16service or installation engineers.

Creator RSA Digital Signatures bear no direct relationship to other Digital Signatures. However, other18Digital Signatures, such as the Authorization Digital Signature, may be used to collaborate the timestampof a Creator RSA Digital Signature.20

C.2 AUTHORIZATION DIGITAL SIGNATURE PROFILE

The technician or physician who approves a DICOM SOP Instance for use may request the Application22Entity to generate a signature using the Authorization Digital Signature Profile. The Digital Signatureproduced serves as a lifetime data integrity check that can be used to verify that the pixel data in the SOP24instance is the same that the technician or physician saw when they made the approval.

As a minimum, an implementation shall include the following attributes in generating the Authorization26Digital Signature:

a. the SOP Class and Instance UIDs28

b. the Study and Series Instance UIDs

c. any attributes whose values are verifiable by the technician or physician (e.g., their values are30displayed to the technician or physician)

d. any overlay data present32

e. any image data present34

The implementation shall use the RIPEMD-160 hashing function to generate a MAC, which is thenencrypted using a private RSA key. The value of MAC Algorithm (gggg,eee2) shall be set to36"RIPEMD160". The public key associated with the private key as well as the identity of the technician orphysician who owns the RSA key pair and who is authorizing the SOP Instance shall be transmitted in an38X.509 (1993) signature certificate. The value of the Certificate Type (gggg,eeee) Attribute shall be set to"X509-1993-SIG". A site-specific policy determines how the X.509 certificates are generated,40authenticated, and distributed. A site may issue and distribute X.509 certificates directly, may utilize theservices of a Certificate Authority, or use any reasonable method for certificate generation and verification.42

The Application Entity shall determine the identity of the technician or physician and obtain their certificatethrough a site specific procedure such as a login mechanism or a smart card.44



Authorization Digital Signatures bear no direct relationship to other Digital Signatures. However, otherDigital Signatures, such as the Creator RSA Digital Signature, may be used to collaborate the timestamp of2an Authorization Digital Signature.

nema standards publication ps 3 supplement 41dicom.nema.org/dicom/supps/sup41_02.pdf · working...

Documents