security and dicom
DESCRIPTION
Security and DICOM. Lawrence Tarbox, Ph.D Chair, DICOM WG 14 (Security) Siemens Corporate Research. Motivation. Regulations protecting patient privacy Primary concern is transmitting confidential data over public networks. Protection against data tampering Liability concerns - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: Security and DICOM](https://reader036.vdocuments.us/reader036/viewer/2022070419/56815c33550346895dca17f9/html5/thumbnails/1.jpg)
s
Security and DICOM
Lawrence Tarbox, Ph.DChair, DICOM WG 14 (Security)Siemens Corporate Research
![Page 2: Security and DICOM](https://reader036.vdocuments.us/reader036/viewer/2022070419/56815c33550346895dca17f9/html5/thumbnails/2.jpg)
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
![Page 3: Security and DICOM](https://reader036.vdocuments.us/reader036/viewer/2022070419/56815c33550346895dca17f9/html5/thumbnails/3.jpg)
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
![Page 4: Security and DICOM](https://reader036.vdocuments.us/reader036/viewer/2022070419/56815c33550346895dca17f9/html5/thumbnails/4.jpg)
Aspects of Security
Policy Issuesusually set by regulations
or local administrators
Technical Issuesusually resolved
through standardization
Training Issuesusually coordinated ateach site individually
![Page 5: Security and DICOM](https://reader036.vdocuments.us/reader036/viewer/2022070419/56815c33550346895dca17f9/html5/thumbnails/5.jpg)
Policy versus Technical
PolicyPolicy Level of privacy Credentials When data should be
signed What transactions
should be audited Who can access what
TechniqueTechnique Type of encryption X.509 certificates Digital signature
mechanisms Audit message format
and interchange Access control lists
![Page 6: Security and DICOM](https://reader036.vdocuments.us/reader036/viewer/2022070419/56815c33550346895dca17f9/html5/thumbnails/6.jpg)
Aspects of Security
Policy Issuesusually set by regulations
or local administrators
Technical Issuesusually resolved
through standardization
Training Issues
![Page 7: Security and DICOM](https://reader036.vdocuments.us/reader036/viewer/2022070419/56815c33550346895dca17f9/html5/thumbnails/7.jpg)
DICOM Security Supplements
Supplement 31– Secure Communication Channels
Supplement 41– Base Digital Signatures
Supplement 51– Media Exchange Security
Supplement 55– De-Identification
![Page 8: Security and DICOM](https://reader036.vdocuments.us/reader036/viewer/2022070419/56815c33550346895dca17f9/html5/thumbnails/8.jpg)
Coming additions AES encryption
– CP 338 Exchange of audit trails
– IETF standard plus a DICOM Supplement Digital Signatures in Structured Reports
– DICOM Supplement
![Page 9: Security and DICOM](https://reader036.vdocuments.us/reader036/viewer/2022070419/56815c33550346895dca17f9/html5/thumbnails/9.jpg)
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
![Page 10: Security and DICOM](https://reader036.vdocuments.us/reader036/viewer/2022070419/56815c33550346895dca17f9/html5/thumbnails/10.jpg)
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
![Page 11: Security and DICOM](https://reader036.vdocuments.us/reader036/viewer/2022070419/56815c33550346895dca17f9/html5/thumbnails/11.jpg)
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
![Page 12: Security and DICOM](https://reader036.vdocuments.us/reader036/viewer/2022070419/56815c33550346895dca17f9/html5/thumbnails/12.jpg)
What about VPN No DICOM profile at this time But not excluded for private networks
(local policy issue)
![Page 13: Security and DICOM](https://reader036.vdocuments.us/reader036/viewer/2022070419/56815c33550346895dca17f9/html5/thumbnails/13.jpg)
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
![Page 14: Security and DICOM](https://reader036.vdocuments.us/reader036/viewer/2022070419/56815c33550346895dca17f9/html5/thumbnails/14.jpg)
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
![Page 15: Security and DICOM](https://reader036.vdocuments.us/reader036/viewer/2022070419/56815c33550346895dca17f9/html5/thumbnails/15.jpg)
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
![Page 16: Security and DICOM](https://reader036.vdocuments.us/reader036/viewer/2022070419/56815c33550346895dca17f9/html5/thumbnails/16.jpg)
Attributes to be encrypted
Item 1 (of only 1)Modified Attributes Sequence
Cryptographic MessageSyntax envelopeCMS attributes
Encrypted Content Transfer SyntaxEncrypted Content
encrypted Content
Item 1 (of n)
Encrypted Content Transfer SyntaxEncrypted Content
Item 2 (of n)
CMS envelope
Encrypted Content Transfer SyntaxEncrypted Content
Item n (of n)
CMS envelope
Encrypted Attributes Sequence
Attributes (unencrypted)SOP Instance
![Page 17: Security and DICOM](https://reader036.vdocuments.us/reader036/viewer/2022070419/56815c33550346895dca17f9/html5/thumbnails/17.jpg)
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
Digital Signatures Sequence
MAC Parameters Sequence
MAC Parameters Sequence
Digital Signatures Sequence
Item 1 Attributes
MAC Parameters Sequence
Digital Signatures Sequence
Item 2 Attributes
Pixel Data
Sequence of Items
Other Header Data
Other Header Data
![Page 18: Security and DICOM](https://reader036.vdocuments.us/reader036/viewer/2022070419/56815c33550346895dca17f9/html5/thumbnails/18.jpg)
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?
![Page 19: Security and DICOM](https://reader036.vdocuments.us/reader036/viewer/2022070419/56815c33550346895dca17f9/html5/thumbnails/19.jpg)
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
![Page 20: Security and DICOM](https://reader036.vdocuments.us/reader036/viewer/2022070419/56815c33550346895dca17f9/html5/thumbnails/20.jpg)
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
![Page 21: Security and DICOM](https://reader036.vdocuments.us/reader036/viewer/2022070419/56815c33550346895dca17f9/html5/thumbnails/21.jpg)
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
![Page 22: Security and DICOM](https://reader036.vdocuments.us/reader036/viewer/2022070419/56815c33550346895dca17f9/html5/thumbnails/22.jpg)
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
![Page 23: Security and DICOM](https://reader036.vdocuments.us/reader036/viewer/2022070419/56815c33550346895dca17f9/html5/thumbnails/23.jpg)
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
![Page 24: Security and DICOM](https://reader036.vdocuments.us/reader036/viewer/2022070419/56815c33550346895dca17f9/html5/thumbnails/24.jpg)
Participating Groups HL7 Security & Accountability SIG DICOM WG 14 IHE Joint JIRA/NEMA/COCIR Security and
Privacy Committee ASTM E31 …
![Page 25: Security and DICOM](https://reader036.vdocuments.us/reader036/viewer/2022070419/56815c33550346895dca17f9/html5/thumbnails/25.jpg)
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
![Page 26: Security and DICOM](https://reader036.vdocuments.us/reader036/viewer/2022070419/56815c33550346895dca17f9/html5/thumbnails/26.jpg)
Audit Trail Standards in HealthcareA Proposed Model
Application Specific Trigger/Content
Security Admin Audit Trail Mgt
User Generated Events
HL7 Security SIG Driven – DICOM referencesDICOM WG14 Security Driven – HL7 References
Audit Trail Records TransferSession and Transport : Reliable SYSLOG or ebXML ?
Common DICOM/HL7 infrastructure
![Page 27: Security and DICOM](https://reader036.vdocuments.us/reader036/viewer/2022070419/56815c33550346895dca17f9/html5/thumbnails/27.jpg)
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.
![Page 28: Security and DICOM](https://reader036.vdocuments.us/reader036/viewer/2022070419/56815c33550346895dca17f9/html5/thumbnails/28.jpg)
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
![Page 29: Security and DICOM](https://reader036.vdocuments.us/reader036/viewer/2022070419/56815c33550346895dca17f9/html5/thumbnails/29.jpg)
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
![Page 30: Security and DICOM](https://reader036.vdocuments.us/reader036/viewer/2022070419/56815c33550346895dca17f9/html5/thumbnails/30.jpg)
Future Plans
This page should not be intentionally left blank!
![Page 31: Security and DICOM](https://reader036.vdocuments.us/reader036/viewer/2022070419/56815c33550346895dca17f9/html5/thumbnails/31.jpg)
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
![Page 32: Security and DICOM](https://reader036.vdocuments.us/reader036/viewer/2022070419/56815c33550346895dca17f9/html5/thumbnails/32.jpg)
s
We welcome your input!
Thank you.