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 Digital Signatures in Structured Reports –In its public comment period (Supp. 86) Audit Trail Messages Audit Trail Messages –Frozen Trial Use Draft (Supp. 95) Extended Negotiation of User Identity 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 Was on hold while WG 14 concentrated on other supplements Has evolved to meet a new set of use cases Has evolved to meet a new set of use cases Now in public comment – please give us your input! Now in public comment – please give us your input!

5. Contents Addresses issues brought up in Digital Signature implementations: 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 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 Adds profiles for using Digital Signatures in SRs Extends Key Object Selection template to address new use cases 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? 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 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: 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) 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 site: http://dicom.nema.org Public Comment document available on the DICOM web site: http://dicom.nema.org http://dicom.nema.org Mail comments to: how_clark@nema.org Mail comments to: how_clark@nema.org

10. Audit Messages Supplement 95

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

12. Lets Clear the Confusion! Base XML message format specified in RFC 3881 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 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@nema.org before mid-March! how_clark@nema.org

14. Extended Negotiation of User Identity Supplement 99

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

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

17. Several Options Several Options User identity alone, with no other security mechanisms User identity alone, with no other security mechanisms User identity plus the current DICOM TLS mechanism 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 future lower level transport mechanisms (e.g. IPv6 with security option) User identity plus VPN User identity plus VPN

18. Extended Negotiation Response Expected A-ASSOCIATERequest (A B) A-ASSOCIATEResponse DICOM Application Entity "A" User ID Sub-item (58H) ID Type (3) User ID DICOM Application Entity "B" Server- Response User ID Sub-item (58H)

19. Extended Negotiation No Response Expected A-ASSOCIATERequest (A B) A-ASSOCIATEResponse DICOM Application Entity "A" User ID Sub-item (58H) ID Type (3) User ID DICOM Application Entity "B" (No Sub-Item)

20. ID Type Profiles Un-authenticated identity assertion Un-authenticated identity assertion –Systems in a trusted environment Username plus passcode Username plus passcode –Systems in a secure network Kerberos-based authentication Kerberos-based authentication –Strongest security

21. Kerberos Kerberos employs a Key Distribution Center (KDC) that 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 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 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) 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) Does not support identity mechanisms that require bi-directional negotiation (e.g. Liberty Alliance proposals)

23. What’s Next in DICOM Security? Suggestions accepted!