Security and DICOM Lawrence Tarbox, Ph.D s Chair, DICOM WG 14 (Security)

Download Report

Transcript Security and DICOM Lawrence Tarbox, Ph.D s Chair, DICOM WG 14 (Security)

Security and DICOM
Lawrence Tarbox, Ph.D
Chair, DICOM WG 14 (Security)
Siemens Corporate Research
s
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
th
1300 North 17 Street, Suite 1847
Rosslyn, VA 22209
(703) 841-3285
Fax (703) 841-3385
Motivation
 Governmental Regulations - for example
– Privacy laws (several countries)
– HIPAA (Health Insurance Portability and
Accountability Act)
–
–
–
–
–
th
1300 North 17 Street, Suite 1847
Rosslyn, VA 22209
(703) 841-3285
Fax (703) 841-3385
EU Directive on Data Protection
MEDIS-DC Online Electronic Storage
Danish Security Regulations
German Digital Signature Laws
More and more every day
Aspects of Security
Policy Issues
Technical Issues
usually set by regulations
or local administrators
usually resolved
through standardization
Training Issues
usually coordinated at
each site individually
th
1300 North 17 Street, Suite 1847
Rosslyn, VA 22209
(703) 841-3285
Fax (703) 841-3385
Policy versus Technical
Policy
Technique
 Level of privacy
 Type of encryption
 Credentials
 X.509 certificates
 When data should be
 Digital signature
signed
 What transactions
should be audited
 Who can access what
mechanisms
 Audit message format
and interchange
 Access control lists
th
1300 North 17 Street, Suite 1847
Rosslyn, VA 22209
(703) 841-3285
Fax (703) 841-3385
Aspects of Security
Policy Issues
Technical Issues
usually set by regulations
or local administrators
usually resolved
through standardization
Training Issues
th
1300 North 17 Street, Suite 1847
Rosslyn, VA 22209
(703) 841-3285
Fax (703) 841-3385
DICOM Security Supplements
 Supplement 31
– Secure Communication Channels
 Supplement 41
– Base Digital Signatures
 Supplement 51
– Media Exchange Security
 Supplement 55
– De-Identification
th
1300 North 17 Street, Suite 1847
Rosslyn, VA 22209
(703) 841-3285
Fax (703) 841-3385
Coming additions
 AES encryption
– CP 338
 Exchange of audit trails
– IETF standard plus a DICOM Supplement
 Digital Signatures in Structured Reports
– DICOM Supplement
th
1300 North 17 Street, Suite 1847
Rosslyn, VA 22209
(703) 841-3285
Fax (703) 841-3385
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
th
1300 North 17 Street, Suite 1847
Rosslyn, VA 22209
(703) 841-3285
Fax (703) 841-3385
Security Communication Profiles
 ISCL Secure Transport
– Based on ISCL
standard (from Japan)
– Symmetric encryption
for authentication
– Specified for Online
Electronic Storage
standard
th
1300 North 17 Street, Suite 1847
Rosslyn, VA 22209
(703) 841-3285
Fax (703) 841-3385
 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
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
th
1300 North 17 Street, Suite 1847
Rosslyn, VA 22209
(703) 841-3285
Fax (703) 841-3385
What about VPN
 No DICOM profile at this time
 But not excluded for private networks
(local policy issue)
th
1300 North 17 Street, Suite 1847
Rosslyn, VA 22209
(703) 841-3285
Fax (703) 841-3385
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
th
1300 North 17 Street, Suite 1847
Rosslyn, VA 22209
(703) 841-3285
Fax (703) 841-3385
De-Identification (S. 55)
Why?
– Teaching files, clinical trials, controlled access
How?
– Simply remove Data Elements that contain patient
identifying information?
• e.g., per HIPAA’s safe harbor rules
But
– Many such Data Elements are required
So
– Instead of remove, replace with a bogus value
th
1300 North 17 Street, Suite 1847
Rosslyn, VA 22209
(703) 841-3285
Fax (703) 841-3385
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
th
1300 North 17 Street, Suite 1847
Rosslyn, VA 22209
(703) 841-3285
Fax (703) 841-3385
SOP Instance
Attributes (unencrypted)
Encrypted Attributes Sequence
Item 1 (of n)
Encrypted Content Transfer Syntax
Encrypted Content
Cryptographic Message
CMS attributes
Syntax envelope
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
th
1300 North 17 Street, Suite 1847
Rosslyn, VA 22209
(703) 841-3285
Fax (703) 841-3385
Digital Signatures (S. 41)
 Embedded in SOP
Other Header Data
Instance
 Lifetime integrity check.
 Identifies signer
 Optional secure timestamp
 Multiple signatures
Sequence of Items
– Overlapping subsets
– Multiple signers
– Signatures on individual
items
Item 1 Attributes
MAC Parameters Sequence
Digital Signatures Sequence
Item 2 Attributes
MAC Parameters Sequence
Digital Signatures Sequence
Other Header Data
MAC Parameters Sequence
Pixel Data
Digital Signatures Sequence
th
1300 North 17 Street, Suite 1847
Rosslyn, VA 22209
(703) 841-3285
Fax (703) 841-3385
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?
th
1300 North 17 Street, Suite 1847
Rosslyn, VA 22209
(703) 841-3285
Fax (703) 841-3385
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
th
1300 North 17 Street, Suite 1847
Rosslyn, VA 22209
(703) 841-3285
Fax (703) 841-3385
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
th
1300 North 17 Street, Suite 1847
Rosslyn, VA 22209
(703) 841-3285
Fax (703) 841-3385
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
th
1300 North 17 Street, Suite 1847
Rosslyn, VA 22209
(703) 841-3285
Fax (703) 841-3385
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
th
1300 North 17 Street, Suite 1847
Rosslyn, VA 22209
(703) 841-3285
Fax (703) 841-3385
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
th
1300 North 17 Street, Suite 1847
Rosslyn, VA 22209
(703) 841-3285
Fax (703) 841-3385
Participating Groups
 HL7 Security & Accountability SIG
 DICOM WG 14
 IHE
 Joint JIRA/NEMA/COCIR Security and
Privacy Committee
 ASTM E31
…
th
1300 North 17 Street, Suite 1847
Rosslyn, VA 22209
(703) 841-3285
Fax (703) 841-3385
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
th
1300 North 17 Street, Suite 1847
Rosslyn, VA 22209
(703) 841-3285
Fax (703) 841-3385
Audit Trail Standards in Healthcare
A Proposed Model
Application Specific Trigger/Content
Security Admin
Audit Trail Mgt
User Generated Events
Audit Trail Records Transfer
Session and Transport : Reliable SYSLOG or ebXML ?
th
1300 North 17 Street, Suite 1847
Rosslyn, VA 22209
(703) 841-3285
Fax (703) 841-3385
HL7 Security SIG Driven – DICOM references
DICOM WG14 Security Driven – HL7 References
Common DICOM/HL7 infrastructure
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.
th
1300 North 17 Street, Suite 1847
Rosslyn, VA 22209
(703) 841-3285
Fax (703) 841-3385
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
th
1300 North 17 Street, Suite 1847
Rosslyn, VA 22209
(703) 841-3285
Fax (703) 841-3385
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 site
http://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
th
1300 North 17 Street, Suite 1847
Rosslyn, VA 22209
(703) 841-3285
Fax (703) 841-3385
Future Plans
This page should not be
intentionally left blank!
th
1300 North 17 Street, Suite 1847
Rosslyn, VA 22209
(703) 841-3285
Fax (703) 841-3385
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
th
1300 North 17 Street, Suite 1847
Rosslyn, VA 22209
(703) 841-3285
Fax (703) 841-3385
We welcome your input!
Thank you.
s