the design and implementation of a dicom access · pdf filethe design and implementation of a...

The Design and Implementationof a DICOM Access Control Server

Patrik Stenlund

Department of Computing ScienceUmeå Universitet, SE-908 87 UMEÅ, SWEDEN

UMEÅ 2005

Abstract

Picture Archiving and Communications Systems (PACS) is the commonlyused term for the digital archives used by hospitals to store radiographsand other types of medical images. These systems are often required tocommunicate with medical equipment manufacturered by different ven-dors. To be able to do this, the vast majority of systems today uses theDigital Imaging and Communications in Medicine (DICOM) standard. Al-though this standard provides an interface that makes it possible for dif-ferent types of devices to exchange medical image information with eachother, it lacks features for protecting information from unauthorized ac-cess. This thesis therefore presents the design and implementation of anetworked proxy server for controlling access to information sources thatuses the DICOM standard for network communication. The implementedprototype adds moderate security to an existing system by providing pass-word authentication and audit logging.

Acknowledgments

I would like to start by giving special thanks to Erik Wetter, my supervisorat RSA Biomedical for all of your support and encouragement through-out this project. Many thanks also to Per Grundström, Leif Nyström, andGöran Sjöström at RSA Biomedical for your help and good company.

Thanks to Thomas Johansson, my supervisor at Umeå University, andto Nicklas Börlin at Umeå University for pointing out some of the problemsin the design.

I also want to thank Gunnar Jonsson, radiology technician and PACSadministrator at the University Hospital of Northern Sweden for takingtime to answer all of my questions.

Also thanks to everyone who has supported me during the writing ofthis thesis, especially Jonas Karlsson for all the help at the end of the project.

Lastly, I give a hearty thanks to my family and all of my friends.

Patrik StenlundUmeå, Sep 29 2005.

Contents

1 Introduction 11.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 The DICOM Standard 72.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3.1 Information Object Definitions . . . . . . . . . . . . . 92.3.2 Information Object Instances . . . . . . . . . . . . . . 112.3.3 Service Classes . . . . . . . . . . . . . . . . . . . . . . 122.3.4 Application Entities . . . . . . . . . . . . . . . . . . . 142.3.5 Communication Initiation . . . . . . . . . . . . . . . . 142.3.6 Network Exchange . . . . . . . . . . . . . . . . . . . . 162.3.7 Security . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3 System Design 193.1 System Overview . . . . . . . . . . . . . . . . . . . . . . . . . 193.2 Proposed Solution . . . . . . . . . . . . . . . . . . . . . . . . . 203.3 Proposed Designs . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3.1 Forwarding Using a Separate Control Channel . . . . 213.3.2 Forwarding Using Message Encapsulation . . . . . . 233.3.3 Translation Between Protocols . . . . . . . . . . . . . 24

3.4 Adopted Design . . . . . . . . . . . . . . . . . . . . . . . . . . 263.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4 Implementation 274.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.3 Control Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 29

viii Contents

4.4 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.5 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.6 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.6.1 Confidentiality . . . . . . . . . . . . . . . . . . . . . . 334.6.2 Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . 344.6.3 Availability . . . . . . . . . . . . . . . . . . . . . . . . 34

4.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5 Conclusion 355.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

A DICOM Document Reference 37

References 39

Index 41

List of Figures

1.1 The result of a typical mdesk work session . . . . . . . . . . 2

2.1 An example of an IOD . . . . . . . . . . . . . . . . . . . . . . 102.2 A DICOM Data Set . . . . . . . . . . . . . . . . . . . . . . . . 112.3 A DICOM analogy . . . . . . . . . . . . . . . . . . . . . . . . 132.4 Service Class Components . . . . . . . . . . . . . . . . . . . . 142.5 Presentation Context Negotiation . . . . . . . . . . . . . . . . 152.6 The encoding and decoding of SOP Instances . . . . . . . . . 162.7 A DICOM Message . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1 Overview of mdesk network communication . . . . . . . . . 203.2 Overview of a DICOM proxy . . . . . . . . . . . . . . . . . . 203.3 Forwarding using a separate control connection . . . . . . . 223.4 Forwarding using message encapsulation . . . . . . . . . . . 243.5 Translation between protocols . . . . . . . . . . . . . . . . . . 25

4.1 A Control Message . . . . . . . . . . . . . . . . . . . . . . . . 30

List of Tables

4.1 A control protocol request message . . . . . . . . . . . . . . . 314.2 A control protocol response message . . . . . . . . . . . . . . 31

Chapter 1

Introduction

This thesis presents the work of the development of a network server forcontrolling user access to digital picture archives that are commonly usedat hospitals. It was commissioned by RSA Biomedical and the work wasconducted at their office in Umeå during spring 2005.

The thesis is a part of the examination for a master’s degree in comput-ing science.

1.1 Background

RSA Biomedical researches and develops hardware and software for doingmeasurements in digital radiographs. One of their software suites, mdeskTM

is a graphical tool does just that. Its primary use is to help orthopaedicsurgeons do preoperative planning before for example a hip or knee re-placement and is today used by physicians at several large hospitals in theScandinavian region.

When working with mdesk the surgeon first locates the radiographhe or she want to work with by searching in the hospitals digital picturearchives, commonly known as a Picture Archiving and CommunicationsSystems (PACS). The surgeon is able to search for the radiograph by a num-ber of attributes such as the patients name and/or social security number.The radiograph is then transferred over the local network to the surgeonscomputer via TCP/IP, where he or she can plan the best course of actionand select the most suitable prosthesis to use. Thereafter he or she storesthe work back to the PACS so that it is accessible at the time of surgery.Figure 1.1 on page 2 shows the result of a typical work session in mdesk.

To achieve maximum compatibility with the numerous PACS availabletoday, mdesk uses the international standard, Digital Imaging and Com-

TMmdesk is a trademark of RSA Biomedical.

2 Chapter 1. Introduction

Figure 1.1: The result of work session in mdesk where the user has selectedand inserted a template for a hip prosthesis. Note the circular object in themiddle of the image used as reference for automatic scaling.

munications in Medicine (DICOM R©) adopted by most vendors to exchangeinformations with these systems. However the standard, in its presentform, does not specify a way to restrict the accessibility to the resources thata DICOM application such as a PACS provides. The only restriction that ex-ists is that pictures are only sent to one or more predefined IP-addressesand ports. This is not a security measure, but has to do with the wayDICOM transfers information between applications. It is even stated in[NEM05b] that “The DICOM standard does not address issues of securitypolicies”.

Some systems might implement other types of access control but asthese are proprietary solutions, most vendors are not willing to release thisinformation to a third party.

A radiograph is a medical record and should be treated as such. Con-sequently, it is important that one can impose limitations so that only au-thorized personnel has access to this information. Otherwise, the patientspersonal integrity could be violated.

As the mdesk system is designed today anyone that has access to a com-puter with mdesk installed can access any radiograph and associated infor-

R©DICOM is the registered trademark of the National Electrical Manufacturers Associa-tion for its standards publications relating to digital communications of medical informa-tion.

1.2. Objective 3

mation stored within the PACS. As hospitals are typical multi-user environ-ments, with many people having access to the same computers within thehospital site, sensitive personal information could be viewed by unautho-rized personnel.

Thus the network interface of mdesk has to be improved with somekind of user authentication in order to protect sensitive personal informa-tion and fulfill the security requirements found at most Swedish hospitals.

Another problem is that the radiography department is often the ownerof the PACS, while the users of mdesk might be members of other depart-ments. As the PACS has to be manually preconfigured with IP-addressesand ports of the hosts who should be able to communicate with it, it re-quires administration from two different departments within the hospitalto set up a mdesk client. When administrating a large number of user thiscan be a tedious task. Therefore, in addition to user authentication a moreflexible way of setting up the two DICOM applications is needed.

1.2 Objective

This project is aimed to develop a network server that enforces user au-thentication and authorization for users of mdesk, and thereby solve theproblems derived from the fact that the DICOM standard does not specifya way to place restrictions on the resources a PACS may provide.

The project also has the ambition to simplify the administration of mdesk.That is, the administration regarding the set-up of the DICOM communi-cation between mdesk and the PACS.

In order to be able to place any restrictions on the resources provided bya PACS, the server should be located logically between the clients and thePACS. Hence it will act as a proxy that communicates with the PACS on thebehalf of the mdesk clients. The idea is that this will also decouple the one-to-one association between the mdesk clients and the PACS, as all clientswill communicate with the server instead of directly with the PACS. ThePACS should therefore only need to be configured to communicate withthe server.

For the actual user authentication, the task is to investigate what possi-ble solutions there exist and then build the best suiting one into the system.This may be done by incorporating third party solutions into the software.

The server is to implement an audit log where selected traffic should belogged to achieve traceability within the system. For example this makes itpossible to check if authorized users access information unrelated to theirwork.

Furthermore, it is also desirable that the solution runs smoothly in anenvironment composed of thin clients.

The target group i.e. the users of the server will be same users that

4 Chapter 1. Introduction

works with mdesk today. These include ordinary users such as orthopaedicsurgeons that will login to the server but will not work with it directly, andadministrators that will manage installations and user accounts. The for-mer category is expected to have varying degree of computer knowledge,while the later is expected to have rather good computer skills.

1.3 Method

In the initial phase of the project the author did introductory readings onnetwork security and on the DICOM standard to get a basic understandingof its use and function. Most of the material used regarding DICOM wasfound on the Internet, while literature was the main source for obtaining in-formation about network security. Network security was initially intendedto be the major subject of the in depth study, but it was soon discoveredthat DICOM had to be prioritized.

After that, a quite extensive specification of requirements was devel-oped in a iterated fashion, where new ideas was presented and discussedin consultation with the supervisor at RSA Biomedical. In parallel with thiswork the author searched into DCMTK, a open source toolkit used for DI-COM communication, and a simple forwarding proxy was written to testthat DICOM packet data units could be forwarded between two DICOMapplications without problems.

The final specification described three main ideas for a system designtogether with the pros and cons for each of the solutions.

When the project entered the design phase there was a deliberation ofwhat solution to continue with. On one hand there was a solution wherethe server had more control over what was sent over the network, and onthe other a solution that would not do any larger impact on existing code.In the middle was a solution that could be seen as a compromise of the two.In the end the second solution, with a separate control channel was chosen.This solution was then evolved to include more details and depicted in aclass hierarchy.

At this time the author met with one of the computer administrators atthe University Hospital of Northern Sweden in Umeå to get feedback ofthe proposed solution.

An implementation was then written in C/C++ for the Microsoft Win-dows 2000/XP platforms, mainly using the Borland C++ Builder IntegratedDevelopment Environment (IDE). During the implementation the DICOMstandard was more deeply explored.

Finally the results were compiled to form this thesis.

1.4. Outline 5

1.4 Outline

The remainder of this thesis is organized in the following way.

Chapter 2 introduces the reader to the DICOM standard. It describes howthe standard is used by hospital equipment to store and exchange dig-ital images and associated information. As it presents a lot of termi-nology, the reader might want to read Chapter 3 in advance to betterplace the information into its context.

Chapter 3 gives an overview of the current system and proposes a solu-tion to the problem with user authentication. It also presents threepossible implementations.

Chapter 4 presents an implementation of the solution described in Chap-ter 3, written in the C++ programming language.

Chapter 5 concludes the work of the project presented in this thesis andalso presents future work.

Appendix A presents a list of the DICOM standard documents.

Chapter 2

The DICOM Standard

This chapter gives a short introduction to the Digital Imaging and Commu-nications in Medicine (DICOM) standard. It is presented here to give thereader a basic understanding of the standard and the systems that uses itto exchange digital images and related information. Note that the standardalso describes media storage, but that topic is not within the scope of thisthesis and will not be discussed here.

The interested reader is encouraged to read [Kon02] as it gives a morecomprehensive description of the standard and serves as a good startingpoint for deeper studies.

Appendix A presents a complete list over the various documents of thestandard.

2.1 Background

In the 1970’s, digital image sources such as computed tomography (CT)made an entry into the medical domain. At this time most devices usedproprietary formats which made it difficult to transfer images and associ-ated information between devices manufactured by different vendors. Asthe use of digital sources increased, so did the need for a standardizedmethod for exchanging digital images. This led the American College ofRadiology (ACR) and the National Electronical Manufacturers Association(NEMA) to form a joint committee in order to develop a standard that couldaccommodate this need [NEM05a, NEM05h]. According to [NEM05a], thepurpose of the contemplated standard was to:

• “promote communication of digital image information, regardless ofdevice manufacturer”

• “facilitate the development and expansion of picture archiving andcommunication systems”

8 Chapter 2. The DICOM Standard

• “allow the creation of diagnostic information databases that can beinterrogated by a wide variety of devices distributed geographically”.

The committee was formed in 1983. Two years later it published ver-sion 1.0 of the standard, namely the ACR-NEMA Standards PublicationNo. 300-1985. Version 2.0 followed in 1988 with the publication of theACR-NEMA Standards Publication No 300-1988 [NEM05a]. These initialstandards stated a standardized terminology, an information structure andan unsanctioned file encoding. However, as with many new things, thestandard had to mature and was not enable to deliver the promise of astandard method for image communication until 1993 [NEM05h].

With the release of version 3.0 the standard included a network pro-tocol for data transport over TCP/IP, a mechanism for uniquely identify-ing information and had support for information types other than images;patients, studies and reports to name a few. It was now renamed DigitalImaging and Communications in Medicine [NEM05h].

In the beginning DICOM based its communication on the Open SystemsInterconnect or OSI communications stack. The inclusion of a method fortransport over TCP/IP — that often was free in contrast to OSI for whichone had to pay a large premium to get — was probably a big step forwardfor the standard to be generally accepted [OG02].

Today, DICOM is acknowledged as an international standard and iswidely used by manufacturers. It has currently 18 parts and is constantlyexpanded to accommodate new image technologies.

2.2 Scope

The scope of the standard is to facilitate interoperability of medical imagingequipment. It does this by specifying:

• “For network communications, a set of protocols to be followed bydevices claiming conformance to the Standard.”

• “The syntax and semantics of Commands and associated informationwhich can be exchanged using these protocols.”

• “For media communication, a set of media storage services to be fol-lowed by devices claiming conformance to the Standard, as well asa File Format and a medical directory structure to facilitate access tothe images and related information stored on interchange media.”

• ”Information that must be supplied with an implementation for whichconformance to the Standard is claimed.”

2.3. Overview 9

2.3 Overview

DICOM is a vast standard and defines a lot of its own terminology fordescribing information related to the real world. Because it lacks a goodoverview, it can be a challenge trying to understand DICOM without anyother reference than the standard documents. This section tries to sort outsome of the definitions and give an overview of the standard in the contextof two applications exchanging information over a network such as Ether-net. It begins by defining general concepts and then moves on to describethe network concepts and security of DICOM.

2.3.1 Information Object Definitions

For two applications to share a common view of the information to be ex-changed, DICOM uses an object-oriented abstract data model to specify in-formation about real-world objects. This model collects information aboutrelated objects into what is called Information Object Definitions (IODs). Anexample of real-world objects that might form an IOD is a patient togetherwith a study of the patient and a CR image of the patient. Each of these real-world objects are represented by an Information Entity within in the IOD. Itconsists of attributes that describes the properties of an object, for examplethe patients name, patient id, sex etc, [Kon02, Rev97]. The structure of animage IOD can be seen in Figure 2.1.

It is important to point out that an IOD does not represent instancesof a real-world objects, but describes a class of objects and how instancesof such classes should be represented and interpreted during informationexchange [Kon02].

Attributes

Attributes are the basic information building block in DICOM and is de-fined in the standard having:

• A unique attribute name in human readable form.

• A unique attribute tag in system readable form.

• An attribute description specifying the semantics of the attribute.

• Value representation that describes the syntax of the attribute.

• Value multiplicity.

• Type classification.


Image IOD

Patient

Study

Series

Equipment

Image

A�ribute

Module

Module

Information Entity

Patient NamePatient IDPatient Birth DatePatient Sex

Series UIDSeries NumberModality Type

ManufacturerInstitution Name

Acquisition A!ributes ...Position A!ributes ...

Study UIDStudy DateStudy TimeStudy IDReferring PhysicianAccession Number

SOP Class UIDSOP Instance UID

Image NumberImage Type

Window WidthWindow Center

Bits Allocated, Bits StoredHigh BitRows, ColumnsSamples per PixelPlanar ConfigurationPixel RepresentationPhotometric InterpretationPixel Data

Figure 2.1: An example of a composite image IOD found in [Rev97].

2.3. Overview 11

Data Set Order of transmission

Tag Value Length Value

Data Element

VR

Data Elem. Data Elem. Data Elem. Data Elem.

Figure 2.2: A schematic over a DICOM Data Set.

The type classification specifies whether an attribute is required to havea value, required to be present with or without a value, or be optional.Some values can also be conditional i.e a value is required to be presentunder certain circumstances [Rev97].

Many attributes are related in some way and are grouped into mod-ules. A module represents a higher level of semantics and can be used inmore than one IOD [NEM05c, Kon02]. How attributes are arranged to formmodules can be seen in Figure 2.1.

Normalized and Composite Information Objects

The standard also talks about Normalized Information Objects and Compos-ite Information Objects. This classification of IODs exists to facilitates futuregrowth of the standard without loss of compatibility. An IOD is a Normal-ized Information Object if it only contains a single Information Entity anda Composite Information Object if contains multiple Information Entities[NEM05c, Kon02]. This is further elaborated in Section 2.3.3.

2.3.2 Information Object Instances

The representation of a specific occurrence of a real-world object is in DI-COM called an Information Object Instance. It is created by giving values tothe attributes of the IOD that is used to describe the real-world object.

In a message or in a file, the actual values for the instance is representedin a Data Set. The Data Set is a sequence of Data Elements that encodes thevalue of each attribute. Figure 2.2 visualizes a DICOM Data Set.

Each Data Element has at least three fields; a tag number field, a valuelength field and a value field. The tag number refers to the tag number ofthe attribute that the Data Element represents. The value length field givesthe number or bytes of the following value field and as one would expectthe value field contains the actual data. The Data Elements in a Data Sethave to be ordered by increasing tag number [Kon02].


Now, if the message is encoded using what is called explicit value repre-sentation each Data Element has a VR field inserted between the tag num-ber and the value length field. This field specifies how the data in the valuefield is actually encoded.

If the message is encoded using implicit value representation the valuerepresentation of each attribute is described in a data dictionary that mustbe shared by two communicating applications.

The former encoding increases the overhead in communication but ismore flexible than the later. This is because it does not require the two datadictionaries to be synchronized [Rev97].

Note that the standard allows Data Elements to be nested to preservethe original structure of the encoded information [Kon02].

2.3.3 Service Classes

In the context of network communication, the relationship between twoDICOM applications is defined by what is called a Service Class. The ServiceClass specify what roles the two applications will play during the exchangeof information.

In DICOM, an application can be either a Service Class User (SCU) or aService Class Provider (SCP), what in network terminology is often referredto as a client and a server respectively [Rev97]. It should be noted however,that this is with respect to which of the two applications that initiated thecommunication. That is, the same application can act both as a client and aserver depending on the operation performed. The application that issuesa request for an operation is normally the SCU, while the application thatperforms the operation is the SCP.

SOP Classes

Operations are called Services or Service Elements, and are performed on In-formation Object Instances. The services that are applicable on a specific IOD,that is applicable on the object classes defined by the IOD, are grouped to-gether to form a Service Group. A Service Group combined with the IOD itsServices operates on, forms a Service Object Pair (SOP) Class. The SOP Classdefines rules and semantics for the usage of services and/or the attributesin an IOD [NEM05d, Rev97]. An analogy between building a sentence andthe described DICOM concepts described so far is shown in Figure 2.3.

SOP classes can be either normalized or composite depending on if ituses normalized or composite IODs. This is reflected by its services. Com-posite services provides only operations while normalized services pro-vides both operations and notifications, and are among other things usedfor management [Kon02, Rev97].

2.3. Overview 13

Verb: Store −→ ServiceNoun: Image −→ IODGeneric sentence: Store a image −→ SOP ClassSpecific sentence: Store this image −→ SOP Instance

Figure 2.3: An analogy between building a sentence and DICOM conceptsfrom [Hor05].

Unique Identifiers

An instance of a SOP Class is naturally called a SOP Instance. How SOPInstances are uniquely identified is quite interesting and is described in[NEM05e]. A Unique Identifier (UID) is composed of two parts, a <org root>and a <suffix>:

<org root>.<suffix>

The <org root> identifies an organization and is supplied by an author-ity which guarantees that it is world-wide unique. It is composed of a num-ber of numeric components as defined in the ISO 8824 standard.

The <suffix> is also composed of numeric components and must beunique within the scope of the <org root>. It is responsibility of the orga-nization identified by the <org root> to guarantee uniqueness of the <suf-fix>. [NEM05e] states that: “Although specific implementation may choosesome particular structure for its generated IUDs, it should never assumethat a UID carries any semantics. Thus, a UID shall not be "parsed" to finda particular value or component.”

Service Class Definition

Having defined what a SOP Class is we are now ready to give the precisedefinition of a Service Class. In [NEM05d] a Service Class is described inthe following way: “A Service Class Specification defines a group of one ormore SOP Classes related to a specific function which is to be accomplishedby communicating Application Entities. A Service Class Specification alsodefines rules which allow implementations to state some predefined levelof conformance to one or more SOP Classes. Applications may conform toSOP Classes as either a Service Class User (SCU) or Service Class Provider(SCP).” Application Entities is described in Section 2.3.4, but it can be saidthat they are the part of a process that deals with the communication inDICOM. The relation of SOP Classes, Service Groups and IODs are shownin Figure 2.4.


IOD “A”

Operation “X”

Operation “Y”

+

Service Group “1”

SO

P C

lass

“1”

Service Group “2”

Operation “Z”

+

IOD “B”

SO

P C

lass

“2”

Service Class

Figure 2.4: The relations of Service Classes, SOP Classes, Service Groupsand IODs.

2.3.4 Application Entities

A DICOM application can essentially be split into two parts; one that dealswith the medical imaging, and one that are responsible for network com-munication, called an Application Entity (AE) [Rev97].

Every AE has a symbolic name called an Application Entity Title or AETitle, that uniquely identifies the application on a specific system in thenetwork. It is a 16 character long string consisting of printable charactersand is often used to identify an application as the source or destination ofinformation [NEM05e, Rev97].

An AE Title is independent of network topology and has to be mappedto a network address before it can be used, in the case of TCP/IP a IP-address and port. However, this mapping have not to be unique, but an AETitle can be associated with different IP-addresses and/or ports. A singlenetwork access point can even support multiple AE Titles [NEM05g].

2.3.5 Communication Initiation

The first thing two DICOM applications do when they need to exchangeinformation is to establish an Association. When an AE requests an associ-ation with another AE it identifies it self with its AE Title and the AE Titleit wants to exchange information with. These are referred to as the Call-ing Application Entity Title and the Called Application Entity Title respectively[NEM05g].

An Association is established by agreeing on an Application Context whichdefines the global functionality for information exchange. The initiating AEproposes what SOP Classes to use, the SCU/SCP role for each SOP Classand how to represent the information i.e. value representation. Dependingon the capabilities of the peer AE it may accept or reject individual SOPClasses. Now, both AEs know of the others capabilities and limitations

2.3. Overview 15

Pres. Cont. ID “1”

Abs. Syn. Namefor Storage-MRSOP

Trans. Syn. Name forLi�le Endian

Trans. Syn. Name forBig Endian


Abs. Syn. Namefor Storage-CTSOP


Trans. Syn. Name forCompress.


Abs. Syn. Namefor Basic PrintMeta SOP


Pres. Cont. ID “1” Accept


Pres. Cont. ID “2” Accept

Trans. Syn. Name forCompress.

Pres. Cont. ID “3” Reject

Application Entity “A”

Application Entity “B”

Association Request

Association Response

Figure 2.5: An example of Presentation Context negotiation.

[Rev97].Associations can be seen as a special type of connections for which the

two applications has negotiated what data is to be exchanged and how it isrepresented. When communication is over the association is released.

Abstract Syntax and Transfer Syntax

Two communicating AEs use one or more Abstract Syntaxes to identify whichSOP Classes and related that are supported on the Association. The Ab-stract Syntax is independent of the encoding technique used for networkexchange. The encoding rules are instead given by a Transfer Syntax thatspecifies how to unambiguously represent one or more Abstract Syntaxes,that is how to encode each SOP Class into a byte stream for network ex-change. It is important to note that Transfer Syntaxes deals with issues asbyte ordering for multi-byte numbers and compression for image data. Itdoes not involve of the value representation of SOP Classes as the Applica-tion Context [Kon02].

Looking at Figure 2.5 we can see an example of how Transfers Syn-taxes are selected. For each of its SOP Classes the initiating AE proposes all


Information

Process “1”

SOP Instance

Presentation

Information

Process “2”

SOP Instance

Presentation

Data Setencoded inByte Stream

EncodingInformationinSOP Instance

EncodingSOP Instancein Data Set

EncodingData SetinByte Stream

DecodingInformationfromSOP Instance

DecodingSOP Instancefrom Data Set

DecodingData SetfromByte Stream

Transfer Syntax

IOD

Semantics

ValueRepresentation

Byte Ordering

Figure 2.6: An overview of the encoding and decoding of SOP Instances.

Transfer Syntaxes it can handle. If the peer AE can handle any of them, itselects one Transfer Syntax and thereby establishes the Presentation Contextfor each specific SOP Class. In other words, for each SOP Class the peer AEselects one of the encodings proposed by the initiating AE. This encodingis then identified as a Presentation Context. Figure 2.6 gives an overviewof the encoding and decoding of SOP Instances [Rev97].

Association Management

DICOM specifies a special protocol for Association management. It is calledAssociation Control Service Element (ACSE) and is an OSI application layerprotocol. As OSI is not that common today, DICOM defines another proto-col, namely the DICOM Upper Layer (DUL) Protocol. This protocol providesthe DICOM Upper Layer DUL Service and is a full equivalent of ACSE forTCP/IP [NEM05g]. These protocols do not only handle the negotiation foran Association but also provides a data transport service utilized by DI-COM for network exchange.

2.3.6 Network Exchange

When an Association has been established the two AEs are ready to ex-change or update SOP Instances. This is done using the DICOM MessageService Element (DIMSE) Protocol. Using DIMSE, an AE can request oper-

2.3. Overview 17

DICOM Message

Command Set Data Set

Tag Length Value

Command Element

Figure 2.7: The structure of a DICOM message.

ation to be performed upon a SOP Instance residing on the peer AE. Forexample it can query the peer AE for an image using the C-FIND serviceand then request the image to be transferred to it using the C-MOVE ser-vice, or it can store an image on the peer AE using the C-STORE service.An AE can also request to be notified when the state of an SOP Instance ischanged. This is done via the N-EVENT-REPORT service. The C/N prefixtells us whether the command is used for composite or normalized IODs[Kon02].

Figure 2.7 shows the structure of the messages used by the DIMSE pro-tocol. A message is composed by Command Set and can conditionally befollowed by a Data Set. The Command Set indicates a operation to be per-formed on or a notification for the Data Set. The Command Set has a similarstructure to a Data Set. It is composed of a sequence of Command Elements,which constitutes the parameters for a command. For example the affectedSOP instance and which AE that issued the command [NEM05f].

Each Command Element has a tag number, a length field and a valuefield. The tag number uniquely identifies the Command Element and aswith Data Elements the length field gives the length in bytes of the valuefield. The value representation of the value is obtained by looking up thetag number in a dictionary. A specific Command Element can only occuronce in the Command Set and all Command Elements must be ordered byincreasing tag number [NEM05f].

The Command Set is always transmitted using little endian byte order[NEM05g].

This concludes the overview about DICOM network communication.The next section describes DICOM security policies.


2.3.7 Security

[NEM05b] describes the security and system management profiles of DI-COM to which an implementation may claim to conform. It begins by sta-ting that “The DICOM standard does not address issues of security poli-cies”. Instead it places the responsibility for access control to the applica-tion or more specific the AE by saying that “This Standard assumes thatthe Application Entities involved in a DICOM interchange are implement-ing appropriate security policies” and that “each Application Entity mustinsure that their own local environment is secure before even attemptingsecure communications with other Application Entities”. This means thatwhen two AE exchanges information they trust each other to maintain con-fidentiality and integrity of the information exchanged.

The standard also assumes that AEs can determine if a user is autho-rized to access certain information. It does not however consider how suchauthorization might be communicated between AEs, but leaves that as aconsideration for the future.

However, the standard does provide mechanisms that could be used toimplement security policies. For example it describes how Transport LayerSecurity (TLS) protocol and X.509 key certificates can be used to protect confi-dentiality of messages and detect tampering of messages.

2.4 Summary

The DICOM standard is a large international standard that is used to man-age medical digital images in a distributed fashion. It defines its own ter-minology, which results in a somewhat steep learning curve. But whenyou have been climbing that hill for a while, the standard specifies a flexi-ble frame that allows equipment manufactured by many different vendorsto exchange information about digital images. This flexibility allows inclu-sion of new image formats and operations for handling them.

Flexibility might be a good thing for a large standard like DICOM, butbecause DICOM is developed by vendors as well as end user organiza-tions it contains a lot of compromises. This is obvious by the many waysinformation can be represented. Instead of deciding on what the preferredway to represent a certain type of information is, the standard allows formultiple representations, making it a major undertaking to write an imple-mentation.

The standard does not specify any kind of access control. Instead itleaves such an important security issue to the implementers of an AE. Thistakes away some of the interoperability between devices it is supposed tofacilitate, as every vendor has to come up with their own solutions to en-sure the security and integrity of information. Why not incorporate access

2.4. Summary 19

control objects by defining new SOP classes. The specifics about these couldthen be negotiated during association creation. If a peer should not supportthese classes then the association is rejected.

Chapter 3

System Design

This chapter presents the current system in the context of mdesk as a DI-COM application and the proposed solution for incorporating access con-trol into the system. It also presents three designs for the proposed solution.The advantages and the drawbacks of each design will be discussed as wellas the impact on the current system. Finally the motives for the choice ofthe adopted design will be given.

3.1 System Overview

As described in Chapter 1 a user of mdesk can search, retrieve and storedigital images from or to a PACS. For mdesk to be able to do this, mdeskuses the services provided by the DICOM standard. This functionality iscollected into a custom Application Programmers Interface (API), RSADCMthat RSA Biomedical has built upon an open source toolkit for DICOMcalled DCMTK.

For the communication between mdesk and the PACS to work as de-scribed in Chapter 2, mdesk needs to know the AE Title, IP-address or hostname, and port of the PACS. When mdesk sends a request to the PACS itconnects to the PACS as any ordinary TCP/IP client. Depending on therequest, the service performed by the PACS may require one or more suboperations. The sub operations might require additional connections initi-ated by the PACS. This means that the PACS need to be configured with thesame information for each mdesk client. That is an AE-title, the IP-addressor name of host where the mdesk client runs, as well as the port that mdesklistens to for answers from the PACS. In this case mdesk acts as a server.This can make administration tedious, and system will not scale for a largeset of users, as every host with mdesk installed has to be configured in thePACS as a receiver.

In the current system, depicted in Figure 3.1, neither mdesk nor thePACS makes any checks to ensure that a user is authorized to access the

22 Chapter 3. System Design

PACS

DICOMmdesk

DCMTK

RSADCM

DICOM

DICOM

mdesk

DCMTK

RSADCM

mdesk

DCMTK

RSADCM

Non Public Location

(Sensitive Info.)

Figure 3.1: A schematic over how the system works today, where themdesk clients communicate directly with the PACS using the DICOM pro-tocol.

mdesk

DCMTK

RSADCM

DICOM

DICOM

mdesk

DCMTK

RSADCM

mdesk

DCMTK

RSADCM

Pro

xy

Non Public Location

PACS

Proxy

Controled

(Sensitive Info.)

Figure 3.2: A solution where a proxy server acts as a gatekeeper for DICOMcommunication between mdesk and the PACS.

resources the PACS provides. The only security barrier is that the user hasaccess to the computer where mdesk is installed. At a hospital this can be alot of people, not only the surgeon but all kind of hospital staff. The PACSmay implement an audit trail, but from this it can only show from whichcomputer and which application a request was made. Not who made therequest. Also all information that is exchanged by mdesk and the PACS issent in clear text.

As the PACS is not developed by RSA Biomedical, but by third parties,a solution where the access control is built into the PACS is not possible.

3.2 Proposed Solution

One way to solve the problems described in Section 3.1, both with userauthentication and administration would be to build a proxy server thatworks as a gatekeeper between mdesk and the PACS as shown in Figure

3.3. Proposed Designs 23

3.2. We have chosen to call such a proxy server for a Access Control Server(ACS).

If the PACS and the ACS are installed on a system or systems that re-sides in a secure location i.e. a location without non-public access, the sys-tem can be configured once for all installations of mdesk. This is done inthe following way. The PACS is first configured with the ACS as the onlyreceiver of information. Then all mdesk clients are configured so they knowhow to reach the ACS. When the ACS receives a DICOM request it acts onthe behalf of the client and sends a corresponding request to the PACS. Itsome how keeps track of which client made that request. This to be able tosend the corresponding response from the PACS back to the right client.

Any request done directly to the PACS will not be responded to as thehost of that request is will not fit any description of AEs listed as receiversin the PACS.

Thus, this system allows for the ACS to control the access to the PACSand should thereby increase the overall security of the system.

Administration of AE titles will be minimized and the person responsi-ble for administrating users do not need access to the PACS but can managethese via the ACS.

The ACS will also be able to manage the licensing of mdesk. For exam-ple one could use it to set a limit on the maximum number of concurrentusers or restricting a license to a limited period of time.

Although a proxy server seems as a simple solution it can be constructedin numerous ways. Section 3.3 describes three possible designs.

3.3 Proposed Designs

This section presents three possible designs of the proxy server. For each ofthe designs the advantages and disadvantages are listed.

3.3.1 Forwarding Using a Separate Control Channel

This design makes use of two separate connections as shown in Figure 3.3.One for sending control information to the ACS and one for sending DI-COM traffic. It requires a separate control protocol for managing controlinformation and that the ACS is configured to have one or more AE Titles.Also the PACS is required to be configured with the ACS as the receiver ofinformation. That is, it has to have the same AE Titles listed as the ACS.

When a user starts mdesk, he or she will be asked to login to the ACSwhere by mdesk opens a control connection and sends the credentials theuser supplied to the ACS. The ACS authenticates the user and if successful,it creates a network session for the user. Otherwise it will deny the useraccess.


PACS

DICOM

DICOM

Proxy

mdesk

DCMTK

RSADCM

mdeskDCMTK

RSADCM

Control

Control

DICOM

DICOM

“mdesk1”

“mdesk2”

“mdesk1”

“mdesk2”

“mdesk1”

ü

ü

“mdesk2”

“mdesk3”

“mdesk1”

“mdesk2”

“mdesk3”

Figure 3.3: Forwarding of DICOM messages using a separate connectionfor sending control information to the ACS.

If the user wants to access a resource residing on the PACS, mdesk sendsa request on the control connection, telling the ACS that it needs to accessthe PACS. The request contains information about what type of informa-tion the user wants to access so that the ACS can compare it to the userspermissions. If the user is permitted to access the resource, the ACS checksif it has a free AE Title and allocates it for the mdesk client to use. It thennotifies the client about which AE Title it should use during DICOM com-munication and on what port it should connect to. The client connects tothe port and supplies the AE Title allocated by the ACS in the Associationrequest. The ACS checks the AE Title and verifies that the connection isdone from the same host as the one that requested it. It then connects to thePACS and forwards the Association request. Any reply from the PACS willthen be forwarded to the client. When the DICOM communication is overthe AE Title is released for future use.

The ACS will from a DICOM point of view be transparent, both to themdesk client and the PACS. However for the ACS to be able to enforce userpermissions it has to filter the incoming DICOM traffic, otherwise it has totrust the mdesk client to supply the correct information about the type ofinformation to be accessed.

The design has the following advantages:

• No changes to how mdesk communicates via DICOM are needed.

• The ACS does need to know about DICOM and thereby reduce itscomplexity.

• Any changes to the DICOM standard will not affect the ACS.


• It is simple to remove the support for the ACS making mdesk a standalone client.

• The design is expected to have minimal system requirements as anyincoming data on the DICOM connection can be forwarded directlywithout any modification.

It has the following known disadvantages:

• It requires a separate protocol for control information.

• The synchronization of the two connections increase the complexityof the system.

• The many connection setups increase the response time.

• A problem exists with delayed responses from the PACS. If the userlogs off before having received a response from the PACS, this mightbe forwarded to a second client if that same AE Title has been reas-signed to the second client. This needs to be addressed by the clientso that the response is declined, or the AE Title has to be marked asunusable.

• It requires a well-behaved client.

3.3.2 Forwarding Using Message Encapsulation

The method proposed here is similar to the one described in Section 3.3.1.The difference is that the control protocol encapsulates any DICOM mes-sages sent from the mdesk client to the ACS. The ACS strips of the controlinformation passed along with the DICOM messages and forwards the re-quests to the client.

The user credentials may have to be supplied with every new Associa-tion made by the mdesk client. This is because the DCMTK API has controlof the connection and can close it at any time. It does however simplifythings by having support for a custom transport layer, what the controlprotocol basically is.

The usage of AE Titles is the same as for the as for the design presentedin Section 3.3.1 and thereby shares the same problem with delayed replies.It also shares the problem with many connections being setup and torndown. An illustration of this particular design is shown in Figure 3.4.

The advantages of the design are listed bellow:

• No changes to how mdesk communicates via DICOM are needed.

• The ACS does need to know about DICOM and thereby reduce itscomplexity.


DICOM

DICOM

Proxy

over control protocol

“mdesk1”

“mdesk2”

“mdesk1”

“mdesk2”

“mdesk1”

ü

ü

“mdesk2”“mdesk3”

mdesk

DCMTK

RSA

DCM

mdeskDCMTK

RSA

DCM

DICOM

over control protocolDICOM PACS

“mdesk1”

“mdesk2”“mdesk3”

Figure 3.4: Forwarding of DICOM messages by encapsulating them in acustom control and transport protocol.

• Any changes to the DICOM standard will not affect the ACS.

• An implementation is expected to have small system requirements.

The design has the following disadvantages:


• The encapsulation of DICOM messages may increase response time,although this is time is probably small in comparison with the timefor connection setup.

• It requires support by DCMTK, that is it requires that DCMTK canbe used with other transport protocols other than TCP/IP. This is re-quirement is fulfilled but it is difficult to reuse an already establishedconnection.

• It requires a well-behaved client.

3.3.3 Translation Between Protocols

This design transfers the DICOM part of mdesk to the ACS, and imple-ments a custom control protocol that implements the functionality of theAPI used for DIOCM today. That is, when mdesk makes a request to theACS it does not use DICOM at all, but the custom protocol instead. TheACS translates the request to DICOM and sends it to the PACS and viceversa for the response. As the ACS itself uses DICOM it can either makeuse of multiple AE Titles that it uses to serve different clients or it can makeuse of its knowledge of which resources i.e. SOP Instances is being accessed


DICOM

DICOM

Proxy

Custom Protocol

“mdesk1”

“mdesk2”mdesk

RSADCM

Custom Protocolmdesk

RSADCM

DCMTK

“mdesk1”

ü

ü

“mdesk2”

“mdesk3”

RSADCM

PACS

“mdesk1”

“mdesk2”

“mdesk3”

Figure 3.5: The translation between a custom protocol and DICOM mes-sages at the ACS.

on the PACS to route incoming replies from the PACS. This is shown in Fig-ure 3.5

Using this implementation the ACS can enforce restrictions at almostany level in DICOM. However, it requires that the DICOM API on the clientis totally rewritten. It may also require some adjustments to the same APIfor the server to be able to utilize it. Also all responses from the PACShas to be cached on the ACS before it can be sent to the client i.e. duringtranslation. This is a possible resource issue as the images used by mdeskcan be as large as 40 megabytes.

The following advantages has been identified:

• The proprietary API for DICOM can still be used to a certain extent.

• The custom protocol can be implemented designed to fit the needs ofmdesk specifically.

• The ACS can enforce restrictions to the communication at a deep levelof DICOM.

• Only one connection is required between the client and the ACS. Thisincreases the response time as the time for connection setup is re-moved.

• Delayed responses from the PACS can be handled safely.

• It does not require a well-behaved client.

Disadvantages:



• Changes in DICOM might require that the ACS needs to be updatedas it translates between the custom protocol and DICOM.

• An implementation is expected have large memory requirements.

• The translation between DICOM and the custom protocol, might re-sult in high CPU requirements.

• Increased delays due to the translation between protocols.

3.4 Adopted Design

As we have seen, the three designs presented in Section3.3 all have theirpros and cons. After some deliberation about which design to go forwardwith the design where the ACS forwards DICOM messages using a sepa-rate control connection was chosen. The primary reason for this was thesmall system requirements along with the prospect of being able to in-corperate the the solution to the current system with only a small amountof changes, and no changes what so ever to the DICOM communicationsmodule. This also increased the chances for a prototype to be implementedon the appointed time. The implementation is presented in Chapter 4.

In the author’s opinion, the design where the ACS translates between acustom protocol and DICOM is more clean-cut than the other designs froma security point of view, but he also recognizes the problem with the systemrequirements and the larger impact on the existing code.

3.5 Summary

This chapter proposed three designs for a proxy server for controlling ac-cess to a PACS using user authentication. The first presented user authen-tication managed via a separate control channel. In the second, the au-thentication was managed by piggy-backing control information on to theDICOM messages. In the third and last design, the communication withthe client was conducted using a custom protocol, which was then trans-lated into DICOM messages by the proxy. In the end the first design waschosen because it required the least amount of changes to the original code.

Chapter 4

Implementation

This chapter presents an implementation of an Access Control Server orACS for controlling user access to a PACS as described in Section 3.3.1. Theimplementation was written in the C++ programming language for the Mi-crosoft Windows 2000/XP platforms using Borland C++ Builder. Supportfor the ACS was also written into the existing code of mdesk.

4.1 Requirements

The requirements of the implementation of the ACS where the following:

• The ACS must be able to forward any request to the PACS that aresent from the mdesk client using DICOM, and must be able to for-ward responses from the PACS back to the client that made the re-quest.

• It must be able to identify itself using multiple AE Titles and copewith multiple mdesk processes residing on the same host.

• The ACS must be able to handle two or more concurrent users, withthe exception when all AE Titles are being used.

• Usernames and passwords should be either encrypted or hashed whenstored or transmitted over the network.

• The ACS is required to implement an audit trail where all transactionsto the PACS are logged. The information that is to be logged are:

– The time of access.

– The IP-address for the host from which the access originated.

– The AE Title allocated for the client.

– The name of the user that makes the access.

30 Chapter 4. Implementation

This information is required for one to be able make a useful com-parison with the access log of the PACS. If possible the log shouldalso contain other important information about a transaction, such aspatient ID’s.

• An error log must bee implemented, to which selected errors are writ-ten.

• The ACS should implement a method for verifying a functional com-munication between an mdesk client and the PACS. That is that themdesk client can reach the PACS and vice versa.

• It should allow for an mdesk client to act as a passive receiver of im-ages.

• The ACS should be implemented as a service under Microsoft Win-dows, enabling it to execute without user interaction.

• It should be possible to administrate the user database of the ACSremotely, when logged into the ACS with special administrator priv-ileges.

• It would be good for the ACS to be able to support multiple PACS,this is not a requirement though.

4.2 Overview

The ACS is implemented as a multithreaded process where the main threadlistens for incoming TCP/IP connection requests. The ACS listens on twoports; one for incoming control connections and one for incoming DICOMtraffic.

When the ACS receives a connection request on the control port it cre-ates a new thread that starts a new network session. The main thread thengoes back to handle new connections. The session thread then continues toask the mdesk client for user credentials. If the credentials can be verifiedi.e. the user can be authenticated the user is logged in to the system andcan continue to do further requests. If not the session is closed and and allresources for it are released.

If the user needs access to the PACS, for example to retrieve an imagefrom the PACS, the mdesk client sends a DICOM open request on the con-trol channel for the ACS to allocate an AE Title for it. The ACS checks if ithas a AE Title available. If that is the case it sends this back to the clientalong with the port that it listens to for DICOM traffic. The client will thenpass the AE Title and port provided by the ACS to the DICOM API. TheAPI uses it to make an association request to the PACS via the ACS. The

4.3. Control Protocol 31

association request is in the end realized by sending an A-ASSOCIATE-RQPacket Data Unit (PDU) defined in the DUL protocol [NEM05g] to the ACS.

Upon the reception of an incoming connection request on the DICOMport, the main thread of the ACS will read the first byte to check the typeof the DUL PDU. If the PDU is an A-ASSOCIATE-RQ PDU it continuesto read the first 42 bytes of the packet. This is enough to get the CallingAE Title and the Called AE Title, that is the source and destination of therequest [NEM05g]. If the two AE Titles are known and the IP-address of theCalling AE Title matches with the session that corresponds to this AE Title,it will hand over the connection to the thread of that session. Otherwise,the ACS sends a A-ASSOCIATE-RJ PDU back to the source of the request,telling it that the association was rejected, and then closes the connection[NEM05g].

After the session thread takes over the connection it looks up the IP-address of the Called AE Title and then connects to the correspondingPACS. It then starts to forward data between the two AEs.

When the mdesk client has received all data including error notifica-tions from the PACS it issues a DICOM close request on the control chan-nel. The ACS will then close all open DICOM connections if any, belongingto that particular session and deallocates the AE Title for the session so thatit may be reused.

A session is automatically closed when the user exists mdesk or theACS looses the connection to the client. The user is then logged out andany AE Title allocated to it will be deallocated.

The AE Titles in the ACS are rotated to avoid that delayed responsesfrom the PACS are sent to the wrong client, and relies on the client to dis-card any wrongly received images.

4.3 Control Protocol

This section briefly describes the architecture of the protocol used in theimplementation to send messages over the control channel.

The purpose of the control protocol is to send user credentials and othersession related information between a mdesk client and the ACS, and alsoto setup DICOM communication between a mdesk client and a PACS. Mes-sages are sent synchronously using a request-response paradigm, wherethe mdesk client sends a request to the ACS and then waits for the re-sponse. For some requests there exists no response. In these cases, theclient just sends a message — that triggers a change of state in the ACS —and then continues with its execution. As one can see, it is always the clientwho initiates the communication.

When the ACS cannot fulfill a request from the client it sends a messagenotifying the client about the failure, together with a code indicating the


Length Type Payload

Control Message

Checksum

4 bytes 1 byte 2 bytesLength bytes

Figure 4.1: The structure of a control message.

reason. It is then up to the client to deal with this error, either by notifyingthe user or by resending the request to the ACS.

The protocol makes use of five basic data types:

char represents an arbitrary 8-bit value i.e. a byte.

bool represents boolean values. Values are stored as a single char, wherethe value 0 represents false and the value 1 represents true.

short represents a 16-bit unsigned integer and is stored as two bytes innetwork byte order.

int represents a 32-bit unsigned integer and is stored as four bytes in net-work byte order.

string represents a text string of arbitrary length. It is stored as a int con-taining its length, followed by zero or more chars giving the value ofthe string.

The data types described above are then used to build a control mes-sage. As seen in Figure 4.1 a control message always contains four fields.They have the following meaning:

Length of the message payload in bytes, given by an int.

Type identifying the type of the message, given by a single byte. This fieldtells the receiver of the message how to interpret the payload.

Payload represented by zero or more bytes.

Checksum calculated on the above fields. It is given by a short containinga checksum based on the ordinary Internet checksum described in[RBP88]. The difference is that the messages described here can belarger than the maximum of 65535 of an Internet packet and must betaken to account when calculating the checksum.

The different message types are shared between the ACS and the client,which means that there can exist 256 types of messages.

What can be said about the payload is that depending on the messagetype it is composed by zero or more fields represented by the five basic

4.4. Testing 33

Type Field Field descriptionint Length Message lengthchar Type Message type = 0x29short PACS ID ID of the PACS to exchange information withshort Client Port Client port for information retrievalstring Client Address Client IP-address for information retrievalshort Checksum Message checksum

Table 4.1: The components of a DICOM request message. When the clientrequests to exchange information with a PACS, it tells the ACS which PACSto connect to and where a reply from the PACS should be sent.

Type Field Field descriptionint Length Message lengthchar Type Message type = 0x2Astring Client AE Title Title for the client to identify it self withstring PACS QR AE Title Title of the PACS used for query/retrievestring PACS Store AE Title Title of the PACS used for storageshort Server Port ACS port for DICOM communicationshort Checksum Message checksum

Table 4.2: The fields of a response to a successful DICOM request. TheACS tells the client what AE Title it should use in order to identify it self tothe PACS, as well as the AE Title of the PACS and the port on the ACS toconnect to.

data types. Examples of different payloads can be seen in Table 4.1 thatshows a DICOM request message and Table 4.2 that shows a correspondingresponse message for a successful setup.

The length field and the checksum field is used to detect invalid mes-sages. That is, invalid due to network errors or by implementation errors.When the ACS receives a invalid message it clears the channel by readingall remaining data and then sends the client a notification about the error.

The structure of the control protocol makes it quite simple to interpretmessages as opposed to a text based protocol, however it requires that thelength of an entire message can be calculated before the message is beingsent. The checksum on the other hand, can be calculated in an accumulativefashion and does not need to be known when one starts to send a message.

4.4 Testing

Some pilot testing has been made during the implementation of the ACS.The tests has been done on a small scale with only a few concurrent users.


They have been conducted using mdesk augmented with the prototypecode for the control protocol and the PACS locally installed at RSA Biomed-ical’s office. This PACS contains sample radiographs and dummy patientinformation.

Telling from these tests, the ACS seems to perform the tasks it is given.It successfully allocates AE Titles and forwards DICOM traffic in both di-rections, making it possible to both search for and retrieve images from thePACS. The ACS also automatically notifies the client about the port whichto connect to and the AE Title of the PACS, simplifying the administrationas intended.

The password login works as planned and users are required to login before they are granted access to DICOM communication. Any otherattempts tried are successfully denied.

When it comes to performance, the response times does not change no-ticeable when adding the ACS to the system, but we have seen an increaseof up to 15% in total transfer time when retrieving a large set of images.This is probably due to the many connection setups and tear-downs.

How stable the prototype is is yet to be seen as the tests made so far hasonly been made on a short term basis, as of a couple of hours or so. But agood sign is that when it comes to invalid messages, the prototype discardsboth erroneous control messages and erroneous DUL PDUs. It also handlesbroken connections well.

4.5 Limitations

Due to the limited amount of time, some of the features listed in Section4.1 had to be left out. At the time of writing the following features are notimplemented:

• The remote administration of users.

• Encryption of usernames and passwords.

Also, the current implementation suffers from the synchronization problemdescribed in Section 3.3.1. This is somewhat intentional since if one wouldmark AE Titles in the problem zone as unusable it would eventually renderthe ACS unusable. Instead the ACS relies on the client to do the right thingand discard the erroneous responses.

4.6 Security

Security is often described the tree terms: confidentiality, integrity andavailability. This section will discuss the security of the developed ACSfrom these three aspects.

4.6. Security 35

4.6.1 Confidentiality

Confidentiality or privacy is about keeping unauthorized from reading sen-sitive information [Sch00]. In DICOM, it is the two communicating AEsthat are responsible for ensuring confidentiality. In the current setup ofmdesk it communicates directly with a PACS. Since mdesk does not im-plement any kind of authorization, all users that have access to the samecomputer where mdesk is installed have access to the archive. The imple-mented here tries to solve this by forcing users to identify them self with ausername and password. If a user can present these two credentials for avalid user, he or she is considered to be authorized to access the PACS. Aswith any other systems that base their security on passwords, they are onlysecure as long as the passwords are kept a secret.

The system still sends DICOM information unencrypted though, mak-ing it possible to eaves drop on the network and thereby getting access tothe information sent between the PACS and mdesk.

One should also keep in mind that mdesk is developed to be used onthe hospitals internal network, supposedly behind a firewall and not overthe Internet. Therefore, in our risk assessment we came to the conclusionthat there are far more easier ways of getting image data than to try to hackour system by trying for example a man in the middle attack and then try todecode the DICOM data. This is a bit naive, and should be taken care ofin the future. However, the implemented ACS still improves security byrestricting access to the PACS for a large set of unauthorized users.

4.6.2 Integrity

Integrity is about ensuring that information has not been altered by unau-thorized means [Sch00]. The implemented system also helps protecting theintegrity of the information by not allowing unauthorized to alter any in-formation stored at the PACS. It does not protect against errors introducedwhen the information is exchanged over the network. This is the responsi-ble of the two DICOM implementations, that is mdesk and the PACS.

4.6.3 Availability

Availability has to do with the system being accessible for authorized userswhen they need it [Sch00]. By simplifying administration of mdesk it canbe installed on more computers and there by the availability for the endusers. On the other hand if the ACS should crash it would make the PACSunavailable for all users on the hospital. Much focus has therefore beengiven to get a stable implementation.


4.7 Summary

This chapter described an implementation of the proposed ACS, imple-mented using C++. It works like a relay node for DICOM traffic betweenmdesk clients and the PACS, and keeps users from gaining unauthorizedaccess to a PACS by requiring that the users logs on to the system with ausername and password.

Chapter 5

Conclusion

The result of this thesis is a functional prototype of an ACS. The chosen de-sign using a simple tunnel and a separate control channel makes DICOMadministration easier and adds moderate security to the mdesk system, asystem that previously did not include any kind of access control at all.Moving the DICOM communication from mdesk to the ACS could makethe system more secure, but would probably not have been possible to im-plement during this short amount of time.

The prototype fulfils the basic requirements that was set in the begin-ning of the project. Users of mdesk are required to login using a user nameand password before any DICOM resources can be accessed, and all DI-COM transactions initiated from mdesk can be logged. However the sys-tem is still vulnerable eavesdropping and other more sophisticated attacksand thus has quite a bit to go before it can be considered fully secure.

5.1 Future Work

Being at the end of this thesis project it is time to look ahead. What can bedone to make the system more functional and secure? For starters the syn-chronization problem should be addressed. This can be solved by lettingthe ACS become a full scale DICOM Application Entity. When the ACS un-derstands the DICOM language it can also enforce access restrictions at adeeper level of DICOM. The communication channel between the involvedAEs can be encrypted using for example TLS as hinted in the DICOM stan-dard. User authentication can be enhanced to include X.509 key certificates.

Although the methods above could solve system security, the best thingwould be for access control to bee included in the DICOM standard.

Appendix A

DICOM Document Reference

Part 1: Introduction and Overview presents the history and purpose of DI-COM, as well as a description of each of the other parts of the stan-dard.

Part 2: Conformance specifies the requirements which must be met to claimconformance to the standard and the contents of a conformance state-ment.

Part 3: Information Object Definitions specifies the structure and attributesof DICOM information objects including images, patients and stud-ies.

Part 4: Service Class Specifications defines the operations that may be per-formed upon information objects, for example storage and retrieval ofimages.

Part 5: Data Structures and Encoding specifies the structure of informa-tion objects and the data encoding used for disk storage and messageexchange.

Part 6: Data Dictionary defines the data representation and multiplicity ofthe individual attributes used to build information objects.

Part 7: Message Exchange specifies the operations and the message proto-col used by two DICOM applications to exchange information over acomputer network.

Part 8: Network Communication Support for Message Exchange specifiesthe services and protocols necessary to support message exchangeover OSI and TCP/IP based networks.

Part 9: Point-to-Point Communication Support for Message Exchange usedto define the services and protocols used for point-to-point commu-nication, but has been retired.

40 Chapter A. DICOM Document Reference

Part 10: Media Storage and File Format for Media Interchange specifies amodel for storage of information objects to physical media.

Part 11: Media Storage Application Profiles defines a number of applica-tion profiles that are application specific subsets of the standard towhich an implementation may claim conformance.

Part 12: Media Formats and Physical Media for Media Interchange speci-fies a structure for describing the relationship between the storagemodel defined in Part 10 and a specific physical media.

Part 13: Print Management Point-To-Point Communication Support usedto specify the services and protocols for point-to-point communica-tion for print management. It has been retired.

Part 14: Grayscale Standard Display Function specifies a function for pre-senting grayscale images consistently on different display media e.g.monitors and printers.

Part 15: Security and System Management Profiles specifies a set of secu-rity profiles. These are defined on other standard protocols such asDHCP, LDAP and TLS.

Part 16: Content Mapping Resource specifies templates for structuring doc-uments as information objects and a set of coded terms for use inthese objects.

Part 17: Explanatory Information contains informative information of vary-ing kind. As an example it explains how to use patient orientationdata elements.

Part 18: Web Access to DICOM Persistent Objects (WADO) specifies a web-based service for retrieving and presenting information objects overthe HTTP protocol.

References

[Hor05] Steven C. Horii, A nontechnical introduction to dicom, Web-site, 12 May 2005, Available at http://www.rsna.org/practice/dicom/intro/index.html .

[Kon02] Mats Konradsson, A Description and Analysis of the DICOM 3.0Standard, Master’s thesis, Umeå University, 2002.

[NEM05a] National Electrical Manufacturers Association, DICOM Part 1:Introduction and Overview, 9 March 2005, Available at http://medical.nema.org/dicom/2004/04_01PU.PDF .

[NEM05b] National Electrical Manufacturers Association, DICOM Part15: Security and System Management Profiles, 9 March 2005,Available at http://medical.nema.org/dicom/2004/04_15PU.PDF .

[NEM05c] National Electrical Manufacturers Association, DICOM Part 3:Information Object Definitions, 9 March 2005, Available at http://medical.nema.org/dicom/2004/04_03PU.PDF .

[NEM05d] National Electrical Manufacturers Association, DICOM Part 4:Service Class Specifications, 9 March 2005, Available at http://medical.nema.org/dicom/2004/04_04PU.PDF .

[NEM05e] National Electrical Manufacturers Association, DICOM Part 5:Data Structures and Encoding, 9 March 2005, Available at http://medical.nema.org/dicom/2004/04_05PU.PDF .

[NEM05f] National Electrical Manufacturers Association, DICOM Part7: Message Exchange, 9 March 2005, Available at http://medical.nema.org/dicom/2004/04_07PU.PDF .

[NEM05g] National Electrical Manufacturers Association, DICOM Part8: Network Communication Support for Message Exchange,9 March 2005, Available at http://medical.nema.org/dicom/2004/04_08PU.PDF .

http://www.rsna.org/practice/dicom/intro/index.html

http://www.rsna.org/practice/dicom/intro/index.html

http://medical.nema.org/dicom/2004/04_01PU.PDF














42 References

[NEM05h] National Electrical Manufacturers Association, Strategic Doc-ument, Website, 21 February 2005, Available at http://medical.nema.org/dicom/geninfo/strategy.htm .

[OG02] Herman Oosterwijk and Paul T. Gihring, DICOM Basics, 2 ed.,OTech Inc., 2002, ISBN 0-9718867-0-9.

[RBP88] D. Borman R. Braden and C. Partridge, Rfc 1071: Computing theinternet checksum, Network Working Group, 1988, Available atftp://ftp.rfc-editor.org/in-notes/rfc1071.txt .

[Rev97] Bas Revet, DICOM Cook Book for Implementations in Modal-ities, Philips Medical Systems, 1997, Available at ftp://ftp-wjq.philips.com/medical/interoperability/out/DICOM_Information/CookBook.pdf .

[Sch00] Bruce Schneier, Secrets & lies: Digital security in a networkedworld, WILEY, 2000, ISBN 0-471-25311-1.

http://medical.nema.org/dicom/geninfo/strategy.htm

http://medical.nema.org/dicom/geninfo/strategy.htm

ftp://ftp.rfc-editor.org/in-notes/rfc1071.txt

ftp://ftp-wjq.philips.com/medical/interoperability/out/ DICOM_Information/CookBook.pdf



Index

AAbstract Syntaxes, 15ACR, 7ACS, 21ACSE, 16AE, 14AE Title, 14, 19, 28API, 19, 28Application Context, 14Application Entity Title, 14Association, 14, 16attribute, 9audit log, 3authentication, 3authorization, 3availability, 34

Bbool, 30

CC/C++, 4char, 30checksum, 30client, 12Command Element, 17Command Set, 17computed tomography, 7confidentiality, 33control message, 30CR, 9credential, 28CT, 7

DData Elements, 11Data Set, 11

DCMTK, 4, 19DICOM, 2, 7DIMSE, 16DUL, 16

EEthernet, 9

IIDE, 4Information Entity, 9Information Object Instance, 11, 12int, 30integrity, 34IOD, 9, 12, 13IP-address, 14, 19

Mmdesk, 1

NNEMA, 7

OOSI, 8, 16

PPACS, 1payload, 30PDU, 29, 32port, 14, 19, 28Presentation Context, 15proxy, 3proxy server, 20

Rradiograph, 1real-world object, 9

44 Index

RSADCM, 19

SSCP, 12–14SCU, 12–14server, 12Service, 12Service Class, 12, 13Service Element, 12Service Group, 12short, 30SOP Class, 12SOP Instance, 13string, 30

TTCP/IP, 1, 8, 16, 19, 28TLS, 18traceability, 3Transfer Syntax, 15

UUID, 13

Vvalue, 11value multiplicity, 9value representation, 9, 12

XX.509 key certificates, 18

the design and implementation of a dicom access · pdf filethe design and implementation of a...

Documents