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 referencesDICOM 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.