Electrical Medical Records La Trobe University, Monash University, - - PowerPoint PPT Presentation

▶
electrical medical records
SMART_READER_LITE
LIVE PREVIEW

Electrical Medical Records La Trobe University, Monash University, - - PowerPoint PPT Presentation

Dec 21, 2023 32 likes •473 views

Efficient and Secure Cloud Based Healthcare Systems for the Storage of Electrical Medical Records La Trobe University, Monash University, Victoria University and RMIT What We Will Cover Today Introduction and Motivation Introduction

slide-1
SLIDE 1

Efficient and Secure Cloud‐Based Healthcare Systems for the Storage of Electrical Medical Records

La Trobe University, Monash University, Victoria University and RMIT

slide-2
SLIDE 2

What We Will Cover Today

  • Introduction and Motivation
  • Introduction
  • About Us and the Project
  • Defining the Problem
  • Motivating Example
  • Manual Encryption Approach
  • Manual Encryption Example
  • Attribute Based Encryption
  • Overview
  • ABE example
  • Project Overview and Design
  • Project Overview
  • System Model and Design
  • Implementation Status

2

slide-3
SLIDE 3

Introduction

  • About me
  • Name: Dr. Russell Paulet
  • Role: Research assistant and software engineer

3

slide-4
SLIDE 4

About Us and the Project

  • Project: Efficient and Secure Cloud‐Based Healthcare Systems for the

Storage of Electrical Medical Records

  • Research Team
  • Xun Yi (RMIT)
  • Hua Wang (VU)
  • Joseph Liu (Monash)
  • Naveen Chilamkurti (La Trobe)
  • Hui Cui (previously RMIT)
  • Russell Paulet (RMIT)
  • The target audience for this project is the health-care industry
  • This is the domain from which we draw examples and demonstrate the ABE

implementation

4

slide-5
SLIDE 5

Defining the Problem

  • Storing medical records as physical

(paper-based) documents offers a high degree of security and privacy

  • But using physical medical records

have a number of limitations

  • Easy to repeat medical tests because

some records may be inaccessible or missing

  • Appropriate sharing of medical records

is labour intensive

  • Either via transportation or copying of

records 5

slide-6
SLIDE 6

Defining the Problem

  • The use of e-Health records addresses

the limitations associated with the management of physical health records

  • Records are more readily available when

needed

  • Since e-Health records are more

accessible, they also become more vulnerable to attack

  • So access control is typically restricted

by using software to protect e-Health records

  • Where access to the records is granted
  • nly if some policy or rule is satisfied

6

slide-7
SLIDE 7

Defining the Problem

  • Of course, the management of e-Health

records has associated maintenance costs

  • Computing resources
  • Staffing resources
  • These costs can be significant when

there are a large number of records to manage

  • Also, the number of records grow over

time

  • One way to reduce these costs is to
  • utsource to a cloud provider
  • This concept is known as Economies-of-

Scale

7

slide-8
SLIDE 8

Defining the Problem

  • Thus, we want to store e-Health

records in the cloud to enjoy the benefits of economies-of-scale, but want to enforce secure access control of e-Health records

  • This includes ensuring privacy of the

e-Health records

  • Delegating this responsibility to the

cloud provider would require absolute trust to establish and maintain the privacy of the records

Server Cloud 8

slide-9
SLIDE 9

Defining the Problem

  • Additionally, an adversary may

exploit vulnerabilities to override correct behaviour of the e-Health application running on the cloud

  • Either by breaking the security checks
  • f the application or directly accessing

the data

  • This project aims to use encryption

to address these challenges in a more secure way

  • While reducing record management

complexity

Server Cloud 9

slide-10
SLIDE 10

Motivating Example

  • A common model for access control is Role Based Access Control (RBAC)
  • Which means that the access policy is defined over roles (or attributes) of users
  • For our example we will consider the following users with their attributes
  • Suppose that we want to encrypt a record ℛ under policy 𝒬:

𝒬=“(Doctor OR Nurse OR Receptionist) AND (Cardiology)”

User Attributes User Attributes John123 Doctor,Cardiology Jane84 Nurse,Cardiology Jay456 Doctor,Neurology Joe88 Receptionist,Cardiology Bob42 Nurse,Neurology Alice77 Technician,Cardiology

10

slide-11
SLIDE 11

Manual Encryption Approach

Store ℛ User Attributes Key John123 Doctor, Cardiology 𝐿1 Jay456 Doctor, Neurology 𝐿2 Bob42 Nurse, Neurology 𝐿3 Jane84 Nurse, Cardiology 𝐿4 Joe88 Receptionist, Cardiology 𝐿5 Alice77 Technician, Cardiology 𝐿6

𝒬=“(Doctor OR Nurse OR Receptionist) AND (Cardiology)” Server Cloud

11 Encryption ID User Encryption

slide-12
SLIDE 12

Manual Encryption Approach

Store ℛ

Server Cloud

User Attributes Key John123 Doctor, Cardiology 𝐿1 Jay456 Doctor, Neurology 𝐿2 Bob42 Nurse, Neurology 𝐿3 Jane84 Nurse, Cardiology 𝐿4 Joe88 Receptionist, Cardiology 𝐿5 Alice77 Technician, Cardiology 𝐿6

𝒬=“(Doctor OR Nurse OR Receptionist) AND (Cardiology)”

12 Encryption ID User Encryption 1 John123 𝐹𝐿1(ℛ)

slide-13
SLIDE 13

Manual Encryption Approach

Store ℛ

Server Cloud

User Attributes Key John123 Doctor, Cardiology 𝐿1 Jay456 Doctor, Neurology 𝐿2 Bob42 Nurse, Neurology 𝐿3 Jane84 Nurse, Cardiology 𝐿4 Joe88 Receptionist, Cardiology 𝐿5 Alice77 Technician, Cardiology 𝐿6

𝒬=“(Doctor OR Nurse OR Receptionist) AND (Cardiology)”

13 Encryption ID User Encryption 1 John123 𝐹𝐿1(ℛ)

slide-14
SLIDE 14

Manual Encryption Approach

Store ℛ

Server Cloud

User Attributes Key John123 Doctor, Cardiology 𝐿1 Jay456 Doctor, Neurology 𝐿2 Bob42 Nurse, Neurology 𝐿3 Jane84 Nurse, Cardiology 𝐿4 Joe88 Receptionist, Cardiology 𝐿5 Alice77 Technician, Cardiology 𝐿6

𝒬=“(Doctor OR Nurse OR Receptionist) AND (Cardiology)”

14 Encryption ID User Encryption 1 John123 𝐹𝐿1(ℛ)

slide-15
SLIDE 15

Manual Encryption Approach

Store ℛ

Server Cloud

User Attributes Key John123 Doctor, Cardiology 𝐿1 Jay456 Doctor, Neurology 𝐿2 Bob42 Nurse, Neurology 𝐿3 Jane84 Nurse, Cardiology 𝐿4 Joe88 Receptionist, Cardiology 𝐿5 Alice77 Technician, Cardiology 𝐿6

𝒬=“(Doctor OR Nurse OR Receptionist) AND (Cardiology)”

15 Encryption ID User Encryption 1 John123 𝐹𝐿1(ℛ) 2 Jane84 𝐹𝐿4(ℛ)

slide-16
SLIDE 16

Manual Encryption Approach

Encryption ID User Encryption 1 John123 𝐹𝐿1(ℛ) 2 Jane84 𝐹𝐿4(ℛ) 3 Joe88 𝐹𝐿5(ℛ) Store ℛ

Server Cloud

User Attributes Key John123 Doctor, Cardiology 𝐿1 Jay456 Doctor, Neurology 𝐿2 Bob42 Nurse, Neurology 𝐿3 Jane84 Nurse, Cardiology 𝐿4 Joe88 Receptionist, Cardiology 𝐿5 Alice77 Technician, Cardiology 𝐿6

𝒬=“(Doctor OR Nurse OR Receptionist) AND (Cardiology)”

16

slide-17
SLIDE 17

Manual Encryption Approach

Store ℛ

Server Cloud

User Attributes Key John123 Doctor, Cardiology 𝐿1 Jay456 Doctor, Neurology 𝐿2 Bob42 Nurse, Neurology 𝐿3 Jane84 Nurse, Cardiology 𝐿4 Joe88 Receptionist, Cardiology 𝐿5 Alice77 Technician, Cardiology 𝐿6

𝒬=“(Doctor OR Nurse OR Receptionist) AND (Cardiology)”

17 Encryption ID User Encryption 1 John123 𝐹𝐿1(ℛ) 2 Jane84 𝐹𝐿4(ℛ) 3 Joe88 𝐹𝐿5(ℛ)

slide-18
SLIDE 18

Manual Encryption Approach

Store ℛ

Server Cloud

User Attributes Key John123 Doctor, Cardiology 𝐿1 Jay456 Doctor, Neurology 𝐿2 Bob42 Nurse, Neurology 𝐿3 Jane84 Nurse, Cardiology 𝐿4 Joe88 Receptionist, Cardiology 𝐿5 Alice77 Technician, Cardiology 𝐿6

𝒬=“(Doctor OR Nurse OR Receptionist) AND (Cardiology)”

18 Encryption ID User Encryption 1 John123 𝐹𝐿1(ℛ) 2 Jane84 𝐹𝐿4(ℛ) 3 Joe88 𝐹𝐿5(ℛ)

slide-19
SLIDE 19

Manual Encryption Approach

Store ℛ

Server Cloud

User Attributes Key John123 Doctor, Cardiology 𝐿1 Jay456 Doctor, Neurology 𝐿2 Bob42 Nurse, Neurology 𝐿3 Jane84 Nurse, Cardiology 𝐿4 Joe88 Receptionist, Cardiology 𝐿5 Alice77 Technician, Cardiology 𝐿6

𝒬=“(Doctor OR Nurse OR Receptionist) AND (Cardiology)”

19 Encryption ID User Encryption 1 John123 𝐹𝐿1(ℛ) 2 Jane84 𝐹𝐿4(ℛ) 3 Joe88 𝐹𝐿5(ℛ)

slide-20
SLIDE 20

Manual Encryption Approach

  • The main problem with this approach is that there is a ciphertext for each user who

satisfies the policy (which is required for security)

  • Which can result in significant overheads for storage and communication
  • If the record needs to be updated, then all the copies need to be updated too
  • Also observe that this requires us to obtain the key for each user that satisfies the

policy

  • Obviously a user’s key must be current and valid
  • Moreover, the data owner must manually encrypt records according to the policy

before uploading the records to the cloud

  • Selecting the appropriate keys for any given policy is complex and error prone

20

slide-21
SLIDE 21

Attribute Based Encryption Overview

  • We can overcome these problems by utilising Attribute Based Encryption

(ABE)

  • Attribute Based Encryption was introduced by Amit Sahai and Brent Waters in 2005
  • Informally, an Attribute Based Encryption scheme allows us to encode a

policy into the encryption process

  • Where decryption is only possible if a user has the attributes that satisfy the policy
  • The user is assigned attributes according to their roles in the organisation
  • We will now explore how Attribute Based Encryption can be employed for
  • ur example

21

slide-22
SLIDE 22

Attribute Based Encryption

22

𝒬=“(Doctor OR Nurse OR Receptionist) AND (Cardiology)”

Nurse Doctor Receptionist Cardiology OR AND

John123 Attributes={Doctor,Cardiology}

𝒧𝑄𝑝𝑚𝑗𝑑𝑧

slide-23
SLIDE 23

Attribute Based Encryption

23

𝒬=“(Doctor OR Nurse OR Receptionist) AND (Cardiology)”

Nurse Doctor Receptionist Cardiology OR AND

John123 Attributes={Doctor,Cardiology}

𝒧𝑄𝑝𝑚𝑗𝑑𝑧

slide-24
SLIDE 24

Attribute Based Encryption

24

𝒬=“(Doctor OR Nurse OR Receptionist) AND (Cardiology)”

Nurse Doctor Receptionist Cardiology OR AND

John123 Attributes={Doctor,Cardiology}

𝒧𝑄𝑝𝑚𝑗𝑑𝑧

slide-25
SLIDE 25

Attribute Based Encryption

25

𝒬=“(Doctor OR Nurse OR Receptionist) AND (Cardiology)”

Nurse Doctor Receptionist Cardiology OR AND

Jay456 Attributes={Doctor,Neurology}

𝒧𝑄𝑝𝑚𝑗𝑑𝑧

slide-26
SLIDE 26

Attribute Based Encryption

26

𝒬=“(Doctor OR Nurse OR Receptionist) AND (Cardiology)”

Nurse Doctor Receptionist Cardiology OR AND

Jay456 Attributes={Doctor,Neurology}

𝒧𝑄𝑝𝑚𝑗𝑑𝑧

slide-27
SLIDE 27

Attribute Based Encryption

27

𝒬=“(Doctor OR Nurse OR Receptionist) AND (Cardiology)”

Nurse Doctor Receptionist Cardiology OR AND

Jay456 Attributes={Doctor,Neurology}

𝒧𝑄𝑝𝑚𝑗𝑑𝑧

slide-28
SLIDE 28

Attribute Based Encryption

Encryption ID Policy Encryption Store ℛ

Server Cloud 𝒬=“(Doctor OR Nurse OR Receptionist) AND (Cardiology)”

User Attributes John123 Doctor, Cardiology Jay456 Doctor, Neurology Bob42 Nurse, Neurology Jane84 Nurse, Cardiology Joe88 Receptionist, Cardiology Alice77 Technician, Cardiology 28

slide-29
SLIDE 29

Attribute Based Encryption

Encryption ID Policy Encryption 1 𝒬 𝐹𝒬(ℛ) Store ℛ

Server Cloud 𝒬=“(Doctor OR Nurse OR Receptionist) AND (Cardiology)”

User Attributes John123 Doctor, Cardiology Jay456 Doctor, Neurology Bob42 Nurse, Neurology Jane84 Nurse, Cardiology Joe88 Receptionist, Cardiology Alice77 Technician, Cardiology 29

slide-30
SLIDE 30

Attribute Based Encryption

Encryption ID Policy Encryption 1 𝒬 𝐹𝒬(ℛ) Store ℛ

Server Cloud 𝒬=“(Doctor OR Nurse OR Receptionist) AND (Cardiology)”

User Attributes John123 Doctor, Cardiology Jay456 Doctor, Neurology Bob42 Nurse, Neurology Jane84 Nurse, Cardiology Joe88 Receptionist, Cardiology Alice77 Technician, Cardiology 30

slide-31
SLIDE 31

Attribute Based Encryption

Encryption ID Policy Encryption 1 𝒬 𝐹𝒬(ℛ) Store ℛ

Server Cloud 𝒬=“(Doctor OR Nurse OR Receptionist) AND (Cardiology)”

User Attributes John123 Doctor, Cardiology Jay456 Doctor, Neurology Bob42 Nurse, Neurology Jane84 Nurse, Cardiology Joe88 Receptionist, Cardiology Alice77 Technician, Cardiology 31

slide-32
SLIDE 32

Attribute Based Encryption

  • Thus, using Attribute Based Encryption allows the users that satisfy the

policy to share the one encrypted record

  • Instead of copies of a record that has been independently encrypted (using different

keys)

  • This enables easier updating of records because the one encrypted record can now be

shared among many users

  • Attribute Based Encryption has a different encryption model
  • It is no longer required to obtain a user’s key prior to encryption
  • There is reduced complexity required to enforce the policy
  • Deciding which key to use is now simpler because the user key can now be encoded in

the attributes of the user

32

slide-33
SLIDE 33

Project Overview

  • The objective of the project is to develop an application that encrypts e-

Health records before upload to a cloud infrastructure

  • The cloud provides the benefits of economies-of-scale
  • In particular, the application makes use of Attribute Based Encryption to

simplify the encryption process

  • An ABE scheme by Waters (Waters, 2011) will be used in the

implementation to demonstrate ABE as a proof-of-concept

33

slide-34
SLIDE 34

Design

  • System Model

Hospital Data manager Store Encrypted Records Server Cloud

34

Staff Member

(e.g. Doctor or Nurse) Attribute Keys Encrypted Records

slide-35
SLIDE 35

Design

  • Record Structure
  • The implementation uses the following fields for a record

Field Description id Uniquely identifies a row. gender Indicates whether the patient is male or female. given_name The patient’s given name. middle_name The patient’s middle name. family_name The patient’s family name. address1 The patient’s address. city_village The patient’s city. state_province The patient’s state within the country. postal_code The patient’s postal code. country The patient’s country. value_numeric The recorded numerical value for the medical concept. name The clinical name of the medical concept, which is measured by value_numeric. description An expanded description of the medical concept defined by name.

35

slide-36
SLIDE 36

Implementation Status

  • Essential functionality
  • Generates user keys based on simple attributes
  • Encrypts a record under a policy string
  • For example “Doctor or Nurse” and “Doctor and Cardiology”
  • Decrypts records under policy that is satisfied by a user’s attributes
  • General functionality
  • Connects to a database established on the cloud, where encrypted records are stored
  • Uses a local database to store the master secret and user keys
  • Estimated timeframe for commercialisation: 3-6 months
  • Depending on staff resources and system environments of existing solutions
  • Also depending on what data formats are in use
  • For example, Digital Imaging and Communications in Medicine (DICOM)

36

slide-37
SLIDE 37

Summary

  • We began by motivating the use of e-Health Records instead of physical documents
  • We explained that outsourcing the task of storing e-Health records to a cloud provider can

reduce management costs

  • But this would require absolute trust in the cloud provider to ensure privacy
  • Additionally, the software that is used to enforce access control may contain vulnerabilities
  • We explored how these issues could be addressed using encryption
  • Manual encryption provided security and privacy, but is labour intensive and complex
  • Using Attribute Based Encryption resulted in a more efficient and manageable approach
  • Presented an overview about an OCSC project that employs ABE to encrypt e-Health

records in the cloud

37

slide-38
SLIDE 38

Our Value Proposition

  • These are the key messages for this talk
  • We want to store health-care records on a cloud provider to reduce

costs, but unable to absolutely trust the cloud provider

  • We can use encryption to address this scenario
  • But using traditional encryption technology has significant drawbacks
  • Scalability issues: one ciphertext for each user who satisfies the policy is needed to

ensure security

  • Data management issues: it is complex and error prone to manually manage

the encryption process under a policy

  • By using Attribute Based Encryption, we can overcome these scalability

problems that are inherent when using traditional encryption

  • Because ABE embeds the policy into the encryption process

38

slide-39
SLIDE 39

Appendix Proof-of-Concept Implementation (Screenshots)

  • This appendix contains screenshots for the Proof-of-Concept

implementation

39

slide-40
SLIDE 40

Proof-of-Concept Implementation Administrator Interface: Parameters

40

slide-41
SLIDE 41

Proof-of-Concept Implementation Administrator Interface: Private Key

41

slide-42
SLIDE 42

Proof-of-Concept Implementation Administrator Interface: Encryption

42

slide-43
SLIDE 43

Proof-of-Concept Implementation Administrator Interface: Decryption

43

slide-44
SLIDE 44

Proof-of-Concept Implementation User Interface

44