How DCMSIGN Verification Works?

Questions regarding other OFFIS DICOM tools

Moderator: Moderator Team

Post Reply
Message
Author
sleepycloud
Posts: 1
Joined: Thu, 2018-10-18, 07:59

How DCMSIGN Verification Works?

#1 Post by sleepycloud » Thu, 2018-12-20, 06:05

Hello there,

I currently make a research regarding information security in telemedicine system.
One of our subject is document signing for dicom-jpeg and waveform format. Anybody here already using dcmsign for their projects? May I know how dcmsign really works with signing implementation and verification?

I search the documentation and dont get a clue at all

Thanks for your appreciation

Marco Eichelberg
OFFIS DICOM Team
OFFIS DICOM Team
Posts: 1228
Joined: Tue, 2004-11-02, 17:22
Location: Oldenburg, Germany
Contact:

Re: How DCMSIGN Verification Works?

#2 Post by Marco Eichelberg » Tue, 2019-04-09, 15:37

I suppose the answer will come too late to be useful, but it's actually rather simple: The DICOM standard offers a specification on how a digital signature can be created for a certain DICOM object (e.g. image or report) and stored inside the same object/file. A reader that supports digital signatures will check for the presence of a signature whenever an object is loaded from file or received over the network, and will then validate the signature.

What is required for the signature process is a key pair, consisting of a private RSA key and a X.509 certificate containing the public key. As usual with digital signatures, the object to be signed is fed as a byte stream into a cryptographic hash algorithm and the hash is then encrypted with the private key and then stored in the object as a digital signature. The only special thing is that DICOM has very detailed rules on how to convert a DICOM object to a bytestream such that certain encoding options in DICOM (like explicit/undefined length for sequences) do not make the signature invalid when changed. The verification is a two-phase process: The received first validates that the encrypted hash key really matches a newly computed hash key (which establishes that the object is unmodified and that the signature was created by the owner of the private key related to the certificate), and a second phase in which the trustworthiness of the certificate itself is established (i.e. not expired, issued by a trustworthy CA).

How this gets embedded into a clinical workflow is not specified by the DICOM standard, and the lack of responses in the forum probably indicates that this feature is only very rarely used in practice.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest