Материал: part03

associated parameters with which that public key is to be used. Algorithms​ allowed are specified in Digital Signature Security Profiles (see PS3.15).​

Note​

1.​Astechnologyadvances,additionalencryptionalgorithmsmay​ beallowedinfutureversions.Implementationsshouldtakethis​ possibility into account.​

C.12.1.1.3.1 Digital Signature Attribute Descriptions​

C.12.1.1.3.1.1 Data Elements Signed​

The Data Elements Signed Attribute shall list the Tags of the Data Elements that are included in the MAC calculation. The Tags listed​ shall reference Data Elements at the same level as the Mac Parameters Sequence (4FFE,0001) Data Element in which the Data​ Elements Signed Attribute appears. Tags included in Data Elements Signed shall be listed in the order in which they appear within​ the Data Set.​

- Standard -​

The following Data Elementsshall not be included eitherimplicitly orexplicitly in thelist of Tags in Data Elements Signed, norincluded​ as part of the MAC calculation:​

•​The Length to End (0008,0001) or any Tag with an element number of 0000 (i.e., no Data Set or group lengths may be included in​ MAC calculations)​

•​Tags with a group number less than 0008​

•​Tags associated with Data Elements whose VR is UN​

•​Tags of Data Elements whose VR is SQ, where any Data Element within that Sequence of Items has a VR of UN recursively​

•​Tags with a group number of FFFA (e.g., the Digital Signatures Sequence)​

•​MAC Parameters Sequence (4FFE,0001)​

•​Data Set Trailing Padding (FFFC,FFFC)​

•​Item Delimitation Item (FFFE,E00D)​

Note​

1.​TheLengthtoEndandgrouplengthscanchangeifnon-signedDataElementschange,soitisnotappropriatetoinclude​ them in the MAC calculation.​

2.​Since the Data Element Tags that identify a Sequence and the start of each Item are included in the MAC calculation,​ there is no need to include the Item Delimitation Item Tags.​

If any of the Data Element Tags in the list refer to a Sequence of Items, then the Tags of all Data Elements within all Items of that​ Sequence shall be implicitly included in the list of Data Elements Signed, except those disallowed above. This implicit list shall also​ includetheItemTag(FFFE,E000)DataElementsthatseparatetheSequenceItemsandtheSequenceDelimitationItem(FFFE,E0DD).​

Note​

It is possible to sign individual Items within a Sequence by including the Digital Signatures Macro in that Sequence Item. In​ fact, this is a highly desirable feature, particular when used in the context of reports. The Digital Signatures Macro is applied​ at the Data Set level, and Sequences of Items are merely Data Sets embedded within a larger Data Set. Essentially, the​ Digital Signature Macro may be applied recursively.​

An example of nesting Digital Signatures within Data Elements is illustrated in Figure C.12-1.​

- Standard -​

Other Header Data

Sequence of Items

Item 1 Attributes

MAC Parameters Sequence

Digital Signatures Sequence

Item 2 Attributes

MAC Parameters Sequence

Digital Signatures Sequence

Other Header Data

MAC Parameters Sequence

Pixel Data

Digital Signatures Sequence

Figure C.12-1. Example of Nesting Digital Signatures (Informative)​

In this example, there is main signature covering the pixel data and a few other Data Elements, plus two individually signed​ Items within a Sequence.​

ForDataElementswithaVROB(e.g.pixeldata)thathaveanundefinedlength(i.e.,thedataisencapsulatedasdescribedinPS3.5),​ the Item Data Element Tags that separate the fragments shall implicitly be included in the list of Data Elements Signed (i.e., a Data​ Element with a VR of OB is encoded in the same fashion as a Sequence of Items).​

C.12.1.1.3.1.2 Signature​

To generate the MAC, Data Elements referenced either explicitly or implicitly by the Tags in the Data Elements Signed list shall be​ encoded using the Transfer Syntax identified by the MAC Calculation Transfer Syntax UID (0400,0010) of the MAC Parameters Se-​ quence Item where the Data Elements Signed Attribute appears. Data shall be formed into a byte stream and presented to the MAC​ Algorithm for computation of the MAC according to the following rules:​

For all Data Elements except those with a VR of SQ or with a VR of OB with an undefined length, all Data Element fields, including​ the Tag, the VR, the reserved field (if any), the Value Length, and the Value, shall be placed into the byte stream in the order en-​ countered.​

For Data Elements with a VR of SQ or with a VR of OB with an undefined length, the Tag, the VR, and the reserved field are placed​ into the byte stream. The Value Length shall not be included. This is followed by each Item Tag in the order encountered, without in-​ cluding the Value Length, followed by the contents of the Value for that Item. In the case of an Item within a Data Element whose VR​ is SQ, these rules are applied recursively to all of the Data Elements within the Value of that Item. After all the Items have been incor-​ porate into the byte stream, a Sequence Delimitation Item Tag (FFFE,E0DD) shall be added to the byte stream presented to the MAC​ Algorithm, regardless of whether or not it was originally present.​

Note​

Since the Value Length of Data Elements with a VR of SQ can be either explicit or undefined, the Value Lengths of such​ Data Elements are left out of the MAC calculation. Similarly, the Value Length of Data Elements with a VR of OB with an​ undefined length are also left out so that they are handled consistently. If such Data Elements do come with undefined​ lengths, including the Item Tags that separate the Items or fragments insures that Data Elements cannot be moved between​ Items or Fragments without compromising the Digital Signature. For those Data Elements with explicit lengths, if the length​ of an Item changes, the added or removed portions would also impact the MAC calculation, so it is not necessary to include​ explicit lengths in the MAC calculation. It is possible that including the Value Lengths could make cryptanalysis easier.​

After the fields of all the Data Elements in the Data Elements Signed list have been placed into the byte stream presented to the MAC​ Algorithm according to the above rules, all of the Data Elements within the Digital Signatures Sequence Item except the Certificate​

- Standard -​

of Signer (0400,0115), Signature (0400,0120), Certified Timestamp Type (0400,0305), and Certified Timestamp (0400,0310) shall​ alsobeencodedaccordingtotheaboverules,andpresentedtotheMACalgorithm(i.e.,theAttributesoftheDigitalSignatureSequence​ Item for this particular Digital Signature are also implicitly included in the list of Data Elements Signed, except as noted above).​

The resulting MAC code after processing this byte stream by the MAC Algorithm is then encrypted as specified in the Certificate of​ Signer and placed in the Value of the Signature Data Element.​

Note​

1.​The Transfer Syntax used in the MAC calculation may differ from the Transfer Syntax used to exchange the Data Set.​

2.​Digital Signatures require explicit VR in order to calculate the MAC. An Application Entity that receives a Data Set with​ an implicit VR Transfer Syntax may not be able to verify Digital Signatures that include Private Data Elements or Data​ Elements unknown to that Application Entity. This also true of any Data Elements whose VR is UN. Without knowledge​ of the Value Representation, the receiving Application Entity would be unable to perform proper byte swapping or be​ able to properly parse Sequences in order to generate a MAC.​

3.​If more than one entity signs, each Digital Signature would appear in its own Digital Signatures Sequence Item. The​ Digital Signatures 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 Digital Signatures is partially filled​ by the authority that issued the Certificate of Signer.​

C.12.1.1.3.1.3 Certified Timestamp​

To generate a certified timestamp, the Value of the Signature (0400,0120) Attribute is transmitted to a third party, as specified by the​ protocol referred to by the Certified Timestamp Type (0400,0305) Attribute. The third party then generates and returns a certified​ timestamp in the form specified by that protocol. The certified timestamp returned by the third party is encoded as a stream of bytes​ in the Certified Timestamp Attribute.​

Note​

The timestamp protocol may be specified by a Profile in PS3.15.​

C.12.1.1.4 Encrypted Attribute Descriptions​

C.12.1.1.4.1 Encrypted Attributes Sequence​

Each Item of the Encrypted Attributes Sequence (0400,0500) contains an encrypted DICOM Data Set containing a single instance​ of the Encrypted Attributes Data Set (Table C.12-7). 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 Data Set by decrypting one of the encrypted content-encryption keys, de-​ crypting the encrypted Data Set with the recovered content-encryption key, and then decoding the DICOM Data Set using the​ Transfer Syntax specified in Encrypted Content Transfer Syntax UID (0400,0510).​

Multiple Items may be present in the Encrypted Attributes Sequence. The different Items may contain Encrypted Attributes Data Sets​ with the same or different sets of Attributes and may contain encrypted content-encryption keys for the same or different sets of recip-​ ients.However,ifthesameAttributeiscontainedinmorethanoneembeddedEncryptedAttributesDataSet,thevalueoftheAttribute​ must be identical in all embedded Encrypted Attributes Data Sets in which the Attribute is contained.​

- Standard -​

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 its own discretion. Since the​ same Attribute is required to have the same value in all embedded Encrypted Attributes Data Sets, it is safe to "overlay"​ multiple embedded Encrypted Attributes Data Sets in an arbitrary order upon decoding.​

C.12.1.1.4.2 Encrypted Content​

Encrypted Content (0400,0520) contains an Enveloped-data content type of the cryptographic message syntax defined in RFC 2630.​ TheencryptedcontentoftheEnveloped-datacontenttypeisaninstanceoftheEncryptedAttributesDataSetasshowninTableC.12-​ 7 (i.e., it is a Sequence with a single Item), encoded with the Transfer Syntax specified by the Encrypted Content Transfer Syntax​ UID (0400,0510) Attribute. Figure C.12-2 shows an example of how the Encrypted Content is encoded. The exact use of this Data​ Set is defined in the Attribute Confidentiality Profiles in PS3.15.​

Since the de-identified SOP Instance is a significantly altered version of the original Data Set, it is a new SOP Instance, with a SOP​ Instance UID that differs from the original Data Set.​

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.​AnyStandardorPrivateTransferSyntaxmaybespecifiedinEncryptedContentTransferSyntaxUID(0400,0510)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 Encrypted Content Transfer Syntax UID (0400,0510).​

3.​For certain applications it might be necessary to "blacken" (remove)identifying information that isburned in tothe image​ pixel data. The Encrypted Attributes Data Set does not specify a means of restoring the original image information​ without the complete image pixel data being encoded inside the Modified Attributes Sequence (0400,0550). If access​ totheoriginal,unmodifiedpixeldataisrequiredandtheimagepixeldatacannotbereplicatedinsidetheModifiedAttributes​ Sequence (0400,0550) due to resource considerations, the SOP Instance UID may be used to locate the original SOP​ Instance from which the de-identified version was derived.​

4.​ThereisnoguaranteethattheoriginalSOPInstancecanbereconstructedfromthedatainEncryptedContent.Ifaccess​ to the original data is required, the (de-encrypted) UIDs may be used to locate the original SOP Instance from which​ the de-identified version was derived.​

Table C.12-7. Encrypted Attributes Data Set Attributes​

- Standard -​