Data Security in a Distributed Services Medical Imaging

Network

Zhihong Yang

University of Connecticut

Problem Setting

• Constrained, by-subscription union of users

• Wide-area setting

• Conventional Protocol Base– tcp/ip, http, java/corba, atp

• Multi-use environment

• Multi-role environment

Distributed Services Medical Imaging Network

• Wide-area grouping of image producers, consumers and service providers

• Primary data structure is radiological record, including– images, video and associated text documents

• Imaging services are provided at the most appropriate point of service

Points of Service

• not just a typical client-server model

• imaging services may be provided– by a remote server (service owner)– locally at the client (e.g., java)– statically distributed, on a cluster (e.g., mpi)– dynamically distributed, on a cluster (e.g.,

agent-mediated dynamic parallelism)s

Service Locales

• may be chosen to protect sensitive data– server offers processed image/text data but not

raw data; may be based on access rights

• may be chosen to relative to an optimization criterion e.g., optimize throughput– server and client agree to seek a distributed

solution to processing data

Autonomous Dynamic Scheduling

• hosts within the cloud agree to permit autonomous agents to schedule time on the host

• agents, the code they carry and the data they carry need to be protected from hostile hosts

• hosts and the data they hold need to be protected from hostile (masquerading) agents

Security in a DSMIN

• encompasses baseline security of data while in transit and user authority (access)– conventional public/private encryption

• in addition, we require to– monitor who reads/updates records even if they

possess (general) authority– report data updates to data originators

Weak vs. Strong Security

• Textual data in the DSMIN (Patient names, records etc.) usually requires strong (conventional) encryption and authority monitoring

• Image data (radiographic images), provided it carries no patient information, is usually not encrypted

Weak Image Encryption

• Images can be encrypted in a weak sense by– compressing them to diagnostic quality using a

multi-bases (or best-basis) wavelet decomposition– encrypting (strong) the coefficients of the

decomposition– conveying these keys along with the image (and

perhaps the codec, see later) to the destination

Basic Premise

• Data, as an independent entity, does not exist visibly anywhere in the DSMIN

• No raw data can be communicated between any source and destination

• All data in transit in the DSMIN is wrapped in an agent ferry

• Destinations (clients) see only the wrapping agent

Transfer Protocol1: Client sees data advertisedby (data) server via java-basedforms java applet java servlet

ClientServer

3: Data record is transferred to client wrappedin agent ferry; ferry will also transport remotemethods (including compression/encryption)to client if required

4: Client applet hands ferryover to client’s ferryinterface for access todata

Client Server

2: Client’s request is fielded by server servlet

5: Interaction between clientand data contained in ferry is viaclient’s ferry interface

Dual Authentication

• Traditionally, mobile code is signed and certified to guarantee its authenticity to recipient

• Equivalently, ferries require hosts (users) to be authenticated

• Weak user authentication involves user passwords (could be more sophisticated)

Authentication-based name space interposition

• Authentication slots are transaction limited (to the dataset ferried)

• Authentication establishes access privileges commensurate with user’s role

• Ferries implement access control by name-space interposition

User-role name-space interposition

Client ferry interface

interface stubs (e.g.):

data_read(par list)data_write(par list)

Ferry (ferry context)L1Users

data_read(par list){ ..} data_write(par list){ ..}

L2Users data_read(par list){ ..} data_write(par list){ ..}

L3Users data_read(par list){ ..} data_write(par list){ ..}

Dynamic class loading

Authentication

L2 authentication

L2 instances of classes passed to class loaders

Host-restricted dataEven although a ferry may carry all of the (encrypted) data requested by a host, theowning entity (home server -- possibly different from the server contacted bythe client) may require that all or certain users access or update data only on itshome server

Client ferry interface

interface stubs (e.g.):

data_read(par list)data_write(par list)

Ferry (ferry context)L1Users

data_read(par list){ ..} data_write(par list){ ..}

L2Users data_read(par list){ ..} data_write(par list){ ..}

L3Usersdata_read(par list){ ..} data_write(par list){ ..}

Dynamic class loading

Authentication

L2 authentication

L2 instances of classes passed to class loaders

rmi invocation toowning host

Overall ferry architecture

Encrypted data/security

Visible Interface

ValidationEngineWriter

InterfaceHistorian

Encryption/Compression

Engine

ReaderInterface

visible component of ferry

Basic Structure

• data is ferried in a private (non-visible) data cache, in encrypted (soft/hard) form

• only the top-level interface is visible; calls cannot be made directly to invisible components

• components are gated (enabled) via the validation engine

Authentication Flow

• Validator gates– accessors (reader/writer/read-update)– host Virtual Machine (computational

environment)

• Validator certifies itself to– host Virtual Machine

Authentication Flow

Visible Interface

ValidationEngineWriter

InterfaceHistorian

Encryption/Compression

Engine

ReaderInterface

visible component of ferry

Encrypted data/security

Data gating

Visible Interface

ValidationEngineWriter

InterfaceHistorian

Encryption/Compression

Engine

ReaderInterface

visible component of ferry

Encrypted data/security

Key Security

• Data traveling from a server to a validated user is ferried in encrypted form using the user’s public key suite

• Data travelling from a client back to the home server is encrypted using the server’s public key suite

Conclusions

• Data is secured (for transit) via usual public/private encryption

• Images are secured in a weaker sense

• No data transits the system alone

• All data is wrapped in a ferry which restricts user’s access to data based on user hierarchy