S Security and DICOM Lawrence Tarbox, Ph.D Chair, DICOM WG 14 (Security) Siemens Corporate Research.
-
Upload
oscar-horn -
Category
Documents
-
view
227 -
download
3
Transcript of S Security and DICOM Lawrence Tarbox, Ph.D Chair, DICOM WG 14 (Security) Siemens Corporate Research.
s
Security and DICOM
Lawrence Tarbox, Ph.DChair, 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– Governmental regulations– Reimbursement rules in certain countries
Mandates for access control and audit trails
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
Aspects of Security
Policy Issuesusually set by regulations
or local administrators
Technical Issuesusually resolved
through standardization
Training Issuesusually coordinated ateach site individually
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
Aspects of Security
Policy Issuesusually set by regulations
or local administrators
Technical Issuesusually resolved
through standardization
Training Issues
DICOM Security Supplements
Supplement 31– Secure Communication Channels
Supplement 41– Base Digital Signatures
Supplement 51– Media Exchange Security
Supplement 55– De-Identification
Coming additions
AES encryption – CP 338
Exchange of audit trails– IETF standard plus a DICOM Supplement
Digital Signatures in Structured Reports– DICOM Supplement
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
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
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
What about VPN
No DICOM profile at this time But not excluded for private networks
(local policy issue)
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
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
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
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
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
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?
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
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
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
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
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
Participating Groups
HL7 Security & Accountability SIG DICOM WG 14 IHE Joint JIRA/NEMA/COCIR Security and
Privacy Committee ASTM E31 …
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
Audit Trail Standards in HealthcareA Proposed Model
Application Specific Trigger/Content
Security Admin Audit Trail Mgt
User Generated Events
HL7 Security SIG Driven – DICOM references
DICOM WG14 Security Driven – HL7 References
Audit Trail Records TransferSession and Transport : Reliable SYSLOG or ebXML ?
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.
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
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
Future Plans
This page should not be intentionally left blank!
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
s
We welcome your input!
Thank you.