DICOM SecurityDICOM Security

Lawrence Tarbox, Ph.D.Lawrence Tarbox, Ph.D.Chair, WG 14Chair, WG 14

Mallinckrodt Institute of RadiologyMallinckrodt Institute of RadiologyWashington University in St. Louis School of Washington University in St. Louis School of MedicineMedicine

3 Supplements3 Supplements

Digital Signatures in Structured Digital Signatures in Structured ReportsReports– In its public comment period (Supp. 86)In its public comment period (Supp. 86)

Audit Trail MessagesAudit Trail Messages– Frozen Trial Use Draft (Supp. 95)Frozen Trial Use Draft (Supp. 95)

Extended Negotiation of User Extended Negotiation of User IdentityIdentity– Out for letter ballot now (Supp. 99)Out for letter ballot now (Supp. 99)

Digital Signatures in Digital Signatures in Structured ReportsStructured Reports

Supplement 86Supplement 86

StatusStatus

Was on hold while WG 14 Was on hold while WG 14 concentrated on other concentrated on other supplementssupplements

Has evolved to meet a new set of Has evolved to meet a new set of use casesuse cases

Now in public comment – please Now in public comment – please give us your input!give us your input!

ContentsContents

Addresses issues brought up in Digital Addresses issues brought up in Digital Signature implementations:Signature implementations:– Digital Signature Purpose field (e.g. author, verifier, Digital Signature Purpose field (e.g. author, verifier,

transcriptionist, device)transcriptionist, device)– Reports with multiple signersReports with multiple signers

Adds methods to securely reference other Adds methods to securely reference other composite objectscomposite objects– Via Digital Signature in the referenced objectVia Digital Signature in the referenced object– Via MAC embedded in the reference itselfVia MAC embedded in the reference itself

Adds profiles for using Digital Signatures in Adds profiles for using Digital Signatures in SRsSRs

Extends Key Object Selection template to Extends Key Object Selection template to address new use casesaddress new use cases

Key Use CaseKey Use Case

How can an application know How can an application know what objects constitute a what objects constitute a complete set?complete set?

Options ConsideredOptions Considered

Why not MPPS?Why not MPPS?– MPPS is not a persistent (composite) MPPS is not a persistent (composite)

objectobject– MPPS could trigger generation of a MPPS could trigger generation of a

signed Key Object Selection documentsigned Key Object Selection document Why not Storage CommitmentWhy not Storage Commitment

– Did not wish to change semantics Did not wish to change semantics some applications currently associate some applications currently associate with Storage Commitmentwith Storage Commitment

Key Object Selection Key Object Selection ExtensionsExtensions New Document Titles:New Document Titles:

– Complete Study/Acquisition ContentComplete Study/Acquisition Content– ManifestManifest– Related ContendRelated Contend

Allow Key Object Selection Allow Key Object Selection Documents to refer to other Key Documents to refer to other Key Object Selection Documents (not Object Selection Documents (not allowed previously)allowed previously)

Give Us FeedbackGive Us Feedback

Public Comment document Public Comment document available on the DICOM web site:available on the DICOM web site:

http://dicom.nema.orghttp://dicom.nema.org

Mail comments to:Mail comments to:

how_clark@nema.orghow_clark@nema.org

Audit MessagesAudit Messages

Supplement 95Supplement 95

StatusStatus

Supplement 95 was frozen last June for Supplement 95 was frozen last June for trial usetrial use

Several trial implementations of the Several trial implementations of the new audit trail message format now new audit trail message format now exist (IHE Connectathon 2005)exist (IHE Connectathon 2005)

No significant changes expected No significant changes expected before letter ballot this springbefore letter ballot this spring

IHE considering deprecating the initial IHE considering deprecating the initial message formatmessage format

Lets Clear the Lets Clear the Confusion!Confusion! Base XML message format specified in Base XML message format specified in

RFC 3881RFC 3881– To be shared by multiple domainsTo be shared by multiple domains– Needs vocabulary definition to be usefulNeeds vocabulary definition to be useful

Supplement 95 profiles, augments, Supplement 95 profiles, augments, and defines DICOM-specific vocabularyand defines DICOM-specific vocabulary– Use the schema in Supplement to create Use the schema in Supplement to create

messages and read DICOM extensionsmessages and read DICOM extensions– Audit repositories can interpret key using Audit repositories can interpret key using

the schema in the RFCthe schema in the RFC

Beware the Ides of Beware the Ides of MarchMarch

Last chance to make suggestions Last chance to make suggestions before it goes to ballot! Send any before it goes to ballot! Send any comments to:comments to:

how_clark@nema.orghow_clark@nema.org

before mid-March!before mid-March!

Extended Negotiation Extended Negotiation of User Identityof User Identity

Supplement 99Supplement 99

Use CasesUse Cases

Facilitates audit loggingFacilitates audit logging Step toward cross-system Step toward cross-system

authorization and access controlsauthorization and access controls– DICOM still leaves access control in DICOM still leaves access control in

the hands of the applicationthe hands of the application Query FilteringQuery Filtering

– For productivity as well as securityFor productivity as well as security

Design GoalsDesign Goals

Independent of other security mechanismsIndependent of other security mechanisms Avoid incompatibility with the installed baseAvoid incompatibility with the installed base No changes to current DICOM security No changes to current DICOM security

mechanismsmechanisms Minimum of changes to existing Minimum of changes to existing

implementation librariesimplementation libraries Extensible for future mechanisms, e.g. Extensible for future mechanisms, e.g.

Security Assertion Markup Language (SAML)Security Assertion Markup Language (SAML) Established during association negotiation Established during association negotiation

before any regular DIMSE transactions take before any regular DIMSE transactions take place, allowing SCU to reject associations place, allowing SCU to reject associations based on IDbased on ID

Several OptionsSeveral Options

User identity alone, with no other User identity alone, with no other security mechanismssecurity mechanisms

User identity plus the current User identity plus the current DICOM TLS mechanismDICOM TLS mechanism

User identity plus future lower User identity plus future lower level transport mechanisms (e.g. level transport mechanisms (e.g. IPv6 with security option)IPv6 with security option)

User identity plus VPNUser identity plus VPN

Extended NegotiationExtended NegotiationResponse ExpectedResponse Expected

A-ASSOCIATE A-ASSOCIATE Request Request

(A B)(A B)

A-ASSOCIATE A-ASSOCIATE Response Response (A B)(A B)

DICOM Application Entity "A"DICOM Application Entity "A"

User ID User ID Sub-item Sub-item (58H)(58H)

ID Type ID Type (3)(3)

User ID User ID

DICOM Application Entity "B"DICOM Application Entity "B"

Server-Server-ResponseResponse

User ID User ID Sub-item Sub-item (58H)(58H)

Extended NegotiationExtended NegotiationNo Response ExpectedNo Response Expected

A-ASSOCIATE A-ASSOCIATE Request Request

(A B)(A B)

A-ASSOCIATE A-ASSOCIATE Response Response (A B)(A B)

DICOM Application Entity "A"DICOM Application Entity "A"

User ID User ID Sub-item Sub-item (58H)(58H)

ID Type ID Type (3)(3)

User ID User ID

DICOM Application Entity "B"DICOM Application Entity "B"

(No Sub-Item)(No Sub-Item)

ID Type ProfilesID Type Profiles

Un-authenticated identity Un-authenticated identity assertionassertion– Systems in a trusted environmentSystems in a trusted environment

Username plus passcodeUsername plus passcode– Systems in a secure networkSystems in a secure network

Kerberos-based authenticationKerberos-based authentication– Strongest securityStrongest security

KerberosKerberos

Kerberos employs a Key Distribution Center Kerberos employs a Key Distribution Center (KDC) that(KDC) that– Authenticates the userAuthenticates the user– May be incorporated into local login processMay be incorporated into local login process– Provides a Ticket Granting Ticket (TGT) to the local Provides a Ticket Granting Ticket (TGT) to the local

systemsystem Local application uses TGT to ask KDC to Local application uses TGT to ask KDC to

generate the Service Ticket, which then is generate the Service Ticket, which then is passed in the Association Negotiation Request passed in the Association Negotiation Request

Remote application uses the Service Ticket to Remote application uses the Service Ticket to securely identify the user, and optionally securely identify the user, and optionally generate a Server Ticket that is returned in generate a Server Ticket that is returned in the Association Negotiation Responsethe Association Negotiation Response

Prepared for the Prepared for the FutureFuture Could support any mechanism Could support any mechanism

that supports uni-directional that supports uni-directional assertion mechanism (e.g. using assertion mechanism (e.g. using PKI and Digital Signatures)PKI and Digital Signatures)

Does not support identity Does not support identity mechanisms that require bi-mechanisms that require bi-directional negotiation (e.g. directional negotiation (e.g. Liberty Alliance proposals)Liberty Alliance proposals)

What’s Next in What’s Next in DICOM Security?DICOM Security?

Suggestions accepted!Suggestions accepted!