DICOM Security

1
DICOM Security

• Lawrence Tarbox, Ph.D.
• Chair, WG 14
• Mallinckrodt Institute of Radiology
• Washington University in St. Louis School of
  Medicine

2
3 Supplements

• Digital Signatures in Structured Reports
• In its public comment period (Supp. 86)
• Audit Trail Messages
• Frozen Trial Use Draft (Supp. 95)
• Extended Negotiation of User Identity
• Out for letter ballot now (Supp. 99)

3
Digital Signatures in Structured Reports

• Supplement 86

4
Status

• Was on hold while WG 14 concentrated on other
  supplements
• Has evolved to meet a new set of use cases
• Now in public comment please give us your input!

5
Contents

• Addresses issues brought up in Digital Signature
  implementations
• Digital Signature Purpose field (e.g. author,
  verifier, transcriptionist, device)
• Reports with multiple signers
• Adds methods to securely reference other
  composite objects
• Via Digital Signature in the referenced object
• Via MAC embedded in the reference itself
• Adds profiles for using Digital Signatures in SRs
• Extends Key Object Selection template to address
  new use cases

6
Key Use Case

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

7
Options Considered

• Why not MPPS?
• MPPS is not a persistent (composite) object
• MPPS could trigger generation of a signed Key
  Object Selection document
• Why not Storage Commitment
• Did not wish to change semantics some
  applications currently associate with Storage
  Commitment

8
Key Object Selection Extensions

• New Document Titles
• Complete Study/Acquisition Content
• Manifest
• Related Contend
• Allow Key Object Selection Documents to refer to
  other Key Object Selection Documents (not allowed
  previously)

9
Give Us Feedback

• Public Comment document available on the DICOM
  web sitehttp//dicom.nema.org
• Mail comments tohow_clark_at_nema.org

10
Audit Messages

• Supplement 95

11
Status

• Supplement 95 was frozen last June for trial use
• Several trial implementations of the new audit
  trail message format now exist (IHE Connectathon
  2005)
• No significant changes expected before letter
  ballot this spring
• IHE considering deprecating the initial message
  format

12
Lets Clear the Confusion!

• Base XML message format specified in RFC 3881
• To be shared by multiple domains
• Needs vocabulary definition to be useful
• Supplement 95 profiles, augments, and defines
  DICOM-specific vocabulary
• Use the schema in Supplement to create messages
  and read DICOM extensions
• Audit repositories can interpret key using the
  schema in the RFC

13
Beware the Ides of March

• Last chance to make suggestions before it goes
  to ballot! Send any comments to how_clark_at_nema
  .orgbefore mid-March!

14
Extended Negotiation of User Identity

• Supplement 99

15
Use Cases

• Facilitates audit logging
• Step toward cross-system authorization and access
  controls
• DICOM still leaves access control in the hands of
  the application
• Query Filtering
• For productivity as well as security

16
Design Goals

• Independent of other security mechanisms
• Avoid incompatibility with the installed base
• No changes to current DICOM security mechanisms
• Minimum of changes to existing implementation
  libraries
• Extensible for future mechanisms, e.g. Security
  Assertion Markup Language (SAML)
• Established during association negotiation before
  any regular DIMSE transactions take place,
  allowing SCU to reject associations based on ID

17
Several Options

• User identity alone, with no other security
  mechanisms
• User identity plus the current DICOM TLS
  mechanism
• User identity plus future lower level transport
  mechanisms (e.g. IPv6 with security option)
• User identity plus VPN

18
Extended NegotiationResponse Expected
19
Extended NegotiationNo Response Expected
DICOM Application Entity "B"
(No Sub-Item)
20
ID Type Profiles

• Un-authenticated identity assertion
• Systems in a trusted environment
• Username plus passcode
• Systems in a secure network
• Kerberos-based authentication
• Strongest security

21
Kerberos

• Kerberos employs a Key Distribution Center (KDC)
  that
• Authenticates the user
• May be incorporated into local login process
• Provides a Ticket Granting Ticket (TGT) to the
  local system
• Local application uses TGT to ask KDC to generate
  the Service Ticket, which then is passed in the
  Association Negotiation Request
• Remote application uses the Service Ticket to
  securely identify the user, and optionally
  generate a Server Ticket that is returned in the
  Association Negotiation Response

22
Prepared for the Future

• Could support any mechanism that supports
  uni-directional assertion mechanism (e.g. using
  PKI and Digital Signatures)
• Does not support identity mechanisms that require
  bi-directional negotiation (e.g. Liberty Alliance
  proposals)

23
Whats Next in DICOM Security?

• Suggestions accepted!