How DICOM attribute level signatures work

DICOM has an attribute level digital signature capability, similar in some respects to the XML Signature capability. It’s considerably simpler to implement than XML Signatures, and tailored to the DICOM binary encoding structure.

One original motivation for this was the desire to support digital signatures of selected portions of an object, and to support extracting sections complete with their associated signatures. When a CT system creates a SOP Instance of a CT exam some of the attributes are created from measurements and should never change. These are attributes like the image pixels. Other attributes are provided to the CT system and may need to be changed later. For example, the CT image object for a John Doe trauma patient will be modified when the patient is identified and the SOP instance can be updated with their real name. When SOP Instances are imported from another healthcare system some of the administrative fields might also need to be changed.

Creator signatures are of increasing interest as a way to detect malicious modifications of DICOM images.

The creating system, such as a CT, should be able to sign those attributes that it created and that should never change. This signature should remain valid even after the other administrative or changeable attributes are changed. The DICOM digital signature is structured so that SOP instances can be modified to update this other information, such as Patient’s Name, without invalidating the creator’s digital signature.

Another goal was to be able to create overlapping and independent signatures. A creator might sign the portion that it created, and a quality control report might separately sign another portion of that SOP instance. The DICOM digital signature structure enables this kind of subsequent signing of already signed SOP Instances.

The details and precise rules can be found in the DICOM PS3.3 Section C.12.1.1.3 Digital Signatures Macro. The following simplified example gives an overview of how these signatures work.

Let’s start with a tiny DICOM object. It’s got 5 top level attributes, one of which is a sequence that contains two items. All DICOM attributes are identified by a 32-bit tag value that is documented as a pair of 4-digit hexadecimal numbers. (See DICOM PS3.5 for the full details on DICOM object encoding.) Other than Patient’s Name (0010,0010) the attributes chosen for this example either are not assigned or are retired. They are merely examples. The unsigned SOP Instance structure is shown in the diagram below:

Now suppose we add two digital signatures. One, highlighted below in green, signs the attributes (0010,0012), (0020,0014) and (0300,0040). The other, highlighted in red, signs the attribute (0020,0013). Examples of some possible purposes of a digital signature can be found in the FHIR signature type valueset.

The signature process results in addition of a MAC Parameters Sequence (4FFE,0001) attribute at the top level of the signed SOP Instance that has two items. The first item describes a signature of the two attributes (0010,0012) and (0020,0014) which are found at the top level. The second item describes a signature of the one attribute (0020,0013) found at the top level.

It also results in addition of a Digital Signatures Sequence (FFFA,FFFA) sequence at the top level. This sequence also has two items, the digital signature for the two attributes in signature 1, and the digital signature for the one attribute in signature 2. The Digital Signature Purpose Code Sequence (0400,0401) is an optional attribute that might be found in each item in the Digital Signatures Sequence (FFFA,FFFA).

Specifics of normalizing the encoding for the attributes being signed and application of signature algorithms are in DICOM PS3.3 Section C.12.1.1.3 Digital Signatures Macro.

Note that when signing a sequence attribute, (0020,0013) in this example, the entire contents of the (0020,0013) sequence tree is signed. So the digital signature in the second item is the signature for the entire sequence contents.

When an attribute to be signed is found at a lower level, i.e., inside an item that is in a sequence, this pattern is repeated. The attribute (0300,0040) is found only in the second item of the sequence (0020,0013). The attributes MAC Parameters Sequence (4FFE,0001) and Digital Signatures Sequence (FFFA,FFFA) are added to the second item. The digital signature for (0300,0040) in that item is put into these attributes.

The result is a system that allows modification of the SOP Instance, that will detect modifications of the signed attributes and not be disturbed by other changes to the SOP Instance.

This approach does not detect removal of digital signature elements. That might be a problem, but it is a “fail-unsigned” rather than “fail-signed” problem.