Security and DICOM

1
Security and DICOM

• Lawrence Tarbox, Ph.D
• Chair, DICOM WG 14 (Security)
• Siemens Corporate Research

2
Motivation

• Regulations protecting patient privacy
• Primary concern is transmitting confidential data
  over public networks.
• Protection against data tampering
• Liability concerns
• Governmental regulations
• Reimbursement rules in certain countries
• Mandates for access control and audit trails

3
Motivation

• Governmental Regulations - for example
• Privacy laws (several countries)
• HIPAA (Health Insurance Portability and
  Accountability Act)
• EU Directive on Data Protection
• MEDIS-DC Online Electronic Storage
• Danish Security Regulations
• German Digital Signature Laws
• More and more every day

4
Aspects of Security
Policy Issuesusually set by regulations or
local administrators
Technical Issuesusually resolved through
standardization
Training Issues usually coordinated ateach site
individually
5
Policy versus Technical

• Policy
• Level of privacy
• Credentials
• When data should be signed
• What transactions should be audited
• Who can access what

• Technique
• Type of encryption
• X.509 certificates
• Digital signature mechanisms
• Audit message format and interchange
• Access control lists

6
Aspects of Security
Policy Issuesusually set by regulations or
local administrators
Technical Issuesusually resolved through
standardization
Training Issues
7
DICOM Security Supplements

• Supplement 31
• Secure Communication Channels
• Supplement 41
• Base Digital Signatures
• Supplement 51
• Media Exchange Security
• Supplement 55
• De-Identification

8
Coming additions

• AES encryption
• CP 338
• Exchange of audit trails
• IETF standard plus a DICOM Supplement
• Digital Signatures in Structured Reports
• DICOM Supplement

9
Secure Communications (S. 31)

• Entity authentication
• Data integrity during transit
• Confidentiality during transit via encryption
• Secure Transport Connection Profiles
• TLS 1.0 (derived from SSL) with 3DES
• ISCL
• TLS 1.0 with AES (proposed)
• Secure Use Profiles
• Online Electronic Storage

10
Security Communication Profiles

• ISCL Secure Transport
• Based on ISCL standard (from Japan)
• Symmetric encryption for authentication
• Specified for Online Electronic Storage standard

• TLS Secure Transport
• TLS 1.0 framework
• RSA based certificates for peer authentication
• RSA for exchange of master secrets
• SHA-1 hash as an integrity check
• Triple DES EDE, CBC encryption

11
AES Secure Transport (CP 338)

• Backwards compatible with the existing profile
• Request AES encryption, with fallback to Triple
  DES
• Why AES?
• Not proprietary
• Expected to be widely available
• More efficient that 3DES
• 10 to 30 of the computation load
• Possible to encrypt and transmit at 100
  Mbit/second without special hardware

12
What about VPN

• No DICOM profile at this time
• But not excluded for private networks(local
  policy issue)

13
File Level Security (S. 51)

• Protects entire DICOM files
• Includes DICOM directory
• Files are held inside an encrypted envelope
• Utilizes Cryptographic Message Syntax
• An internet standard
• Only selected recipients can open the envelope
• Data integrity check
• Identifies a single file creator
• Several Secure Media Storage Profiles

14
De-Identification (S. 55)

• Why?
• Teaching files, clinical trials, controlled
  access
• How?
• Simply remove Data Elements that contain patient
  identifying information?
• e.g., per HIPAAs safe harbor rules
• But
• Many such Data Elements are required
• So
• Instead of remove, replace with a bogus value

15
Attribute Level Encryption

• Since some use cases require controlled access to
  the original Attribute values
• Original values can be stored in a CMS
  (Cryptographic Message Syntax) envelope
• Embedded in the Data Set
• Only selected recipients can open the envelope
• Different subsets can be held for different
  recipients
• Full restoration of data not a goal
• Attribute Confidentiality Profiles

16
SOP Instance
Attributes (unencrypted)
Encrypted Attributes Sequence
Item 1 (of n)
Encrypted Content Transfer Syntax Encrypted
Content
Cryptographic Message Syntax envelope
CMS attributes
encrypted Content
Modified Attributes Sequence
Item 1 (of only 1)
Attributes to be encrypted
Item 2 (of n)
Encrypted Content Transfer Syntax Encrypted
Content
CMS envelope
Item n (of n)
Encrypted Content Transfer Syntax Encrypted
Content
CMS envelope
17
Digital Signatures (S. 41)

• Embedded in SOP Instance
• Lifetime integrity check.
• Identifies signer
• Optional secure timestamp
• Multiple signatures
• Overlapping subsets
• Multiple signers
• Signatures on individual items

18
Current Profiles

• Digital Signature Profiles
• Base RSA (referenced by other profiles)
• Creator RSA (typically the equipment)
• Authorization RSA (typically the operator)
• Structured Report RSA (proposed)
• Secure Use Profiles
• Base Digital Signatures
• For legacy systems
• Bit-preserving Digital Signature
• Possible future implementations?

19
Questions Raised about Reports

• What portion of the report should we sign?
• SOP Instance UID management
• How do we deal with amendments?
• How do we deal with multiple signers?
• How does a report refer securely to other SOP
  Instances?
• That are already signed
• That do not have signatures

20
Proposals for SR (Subject to change)

• What is signed?
• SOP Class UID
• Study and Series Instance UID
• All of the SR Document Content Module
• Current and Pertinent Evidence Sequence
• Once VERIFIED
• SOP Instance UID
• Verification Flag
• Amendments are new SOP Instances

21
Purpose of Digital Signature

• Add Purpose field to differentiate between
  signers (from ASTM 1762 standard), e.g.
• Author
• Verifier
• Reviewer
• Witness
• Event
• Identity
• Consent
• Administrative

22
Secure References

• Objects that are already signed
• Include Digital Signature UID and value
• Objects that are not signed
• Include a secure hash of selected Attributes in
  the referenced object
• or
• Reference other signed SRs that include secure
  hashes of the referenced object

23
Audit Trail Exchange (new)

• Transmit audit trail data to a collection site
• Simplifies long term storage
• Simplifies monitoring and analysis
• Need goes beyond DICOM
• Joint work HL7, DICOM, ASTM, IHE, NEMA, COCIR,
  JIRA, others?
• Common base format
• Specializations as needed

24
Participating Groups

• HL7 Security Accountability SIG
• DICOM WG 14
• IHE
• Joint JIRA/NEMA/COCIR Security and Privacy
  Committee
• ASTM E31

25
Current Proposals

• Define a common XML payload
• General organization of content
• XML schema
• To become a draft internet standard (RFC)
• Application-specific Vocabularies
• DICOM
• HL7
• Transport Mechanism Blind
• Reliable Syslog (RFC-3195) most likely candidate

26
(No Transcript)
27
Background on RFC-3195

• Reliable replacement for BSD Syslog
• Provides BEEP message structure, store and
  forward transport, common mandatory fields, and
  an XML payload.
• Options for encryption and signatures.

28
Level of detail

• Surveillance
• Detail on the study level, not individual
  Attributes
• Designed to detect intrusions
• Forensic
• Could be very detailed
• Determine how it happened

29
Status of Audit Trail Work Item

• Derived from, but not the same as IHE Year 4
  work
• Current draft of the common payload on the IETF
  web sitehttp//www.ietf.org/internet-drafts/draft
  -marshall-security-audit-00.txt
• DICOM Supplement being developed
• References the common payload document
• Specifies the transport mechanism
• Identifies DICOM-specific vocabulary

30
Future Plans
This page should not be intentionally left blank!
31
Potential Future Security Topics

• Full user authentication between nodes, key
  management
• More sophisticated access control support
• Role-based access
• Institutional versus personal access
• Patient authorization
• List of intended recipients
• Support for new technology and algorithms

32
We welcome your input!

• Thank you.