230 likes | 739 Views
DICOM Security. Lawrence Tarbox, Ph.D. Chair, WG 14 Mallinckrodt Institute of Radiology Washington University in St. Louis School of Medicine. 3 Supplements. Digital Signatures in Structured Reports In its public comment period (Supp. 86) Audit Trail Messages
E N D
DICOM Security Lawrence Tarbox, Ph.D. Chair, WG 14 Mallinckrodt Institute of Radiology Washington University in St. Louis School of Medicine
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)
Digital Signatures in Structured Reports Supplement 86
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!
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
Key Use Case How can an application know what objects constitute a complete set?
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
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)
Give Us Feedback • Public Comment document available on the DICOM web site:http://dicom.nema.org • Mail comments to:how_clark@nema.org
Audit Messages Supplement 95
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
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
Beware the Ides of March Last chance to make suggestions before it goes to ballot! Send any comments to:how_clark@nema.orgbefore mid-March!
Extended Negotiation of User Identity Supplement 99
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
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
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
DICOM Application Entity "A" A-ASSOCIATE User ID Sub-item (58H) Request ID Type (3) User ID (A B) DICOM Application Entity "B" User ID Sub-item (58H) A-ASSOCIATE Server-Response Response (A B) Extended NegotiationResponse Expected
DICOM Application Entity "A" A-ASSOCIATE User ID Sub-item (58H) Request ID Type (3) User ID (A B) A-ASSOCIATE Response (A B) Extended NegotiationNo Response Expected DICOM Application Entity "B" (No Sub-Item)
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
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
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)
What’s Next in DICOM Security? Suggestions accepted!