Cloud-based Secure Smartcard Healthcare
Monitoring and Tracking System
Kartik Moudgil, Ria Maheshwari, Harshal Bharatkumar Parekh, Kailas Devadkar
harshalparekh@outlook.com, kartik@kartik.one, riamaheshwari2507@gmail.com, kailas_devadkar@spit.ac.in
Sardar Patel Institute of Technology,
Andheri, Mumbai
Abstract— As technological advances make strides into many
fields, including that of healthcare, the onus is on us to take
advantage of these. Technology has been adopted by the
healthcare industry since long; however, it retains a secondary
role as far as patient data management and connectivity is
concerned. The aim of this paper is to devise a novel architecture
and framework to make available the patient data in a concise,
secure and accurate manner. Our architecture is based on a
secure cloud system as backend, using smartcard as
authenticators. Our proposed architecture consists of: i) A secure
hybrid cloud system, based on the open-source Eucalyptus
software ii) A secure smartcard called MediCard to securely
authenticate users iii) An Android application that serves as a
user-friendly interface to the patient data, from the perspective of
the healthcare provider as well the patient. iii) A website that
allows easy management of the patient data such as medical
reports, prescriptions etc. by the healthcare provider. These
three components allow a wide variety of applications that can be
undertaken by this healthcare system, which are detailed ahead.
This model seeks to help the healthcare providers such as
hospitals, physicians, diagnostic labs, and chemists by
electronically managing all the patient data they need access to in
a secure, and efficient manner.
Keywords—healthcare, cloud, hybrid, NFC, data, smartcard
I. INTRODUCTION
The healthcare industry is one of the few sectors that has a
substantial economic as well as social impact on a society. The
true benefits of health cannot be gauged in pure economic
terms. For this industry to grow at its current rate, the
challenges it is beginning to face must be addressed. As our
population increases and more people require access to higher
standards of healthcare, the huge volumes of patient data that is
inevitably generated must be managed with high levels of
integrity, security and availability. So, an efficient system and
framework is needed to manage the global health care system.
The healthcare providers are now realizing the importance
of their data as a way to keep up with these drastic changes.
For example, the highest level of practices are maintained by
the hospitals which are looking for insight into patients, care
teams, and services to gain opportunities for improving the
quality. As technology permeates the healthcare sector further,
the masses too are taking advantage of it, trying to make smart
and informed decisions on physicians, as well as other
healthcare providers. Crowd-sourced information is being
utilized on a real-time basis for these kinds of decisions
already. Naturally, the availability of their own medical
records, stored in a secure location, backed by secure methods
to track and access the same is the next logical step.
The data about patients, physicians, services, and locations
is currently fragmented across multiple systems; it is quite
difficult to build data-management relationships among all
these entities, without the presence of an external, centralized
entity. The challenge for healthcare providers is existence of
incomplete, inconsistent master data. This is an informationbased challenge. In a country like India, patient records are still
maintained primarily on paper, and only by larger hospitals it is
stored digitally. Hard copy records are extremely unreliable at
times, being slow and cumbersome to access, as well as less
accurate and generally unreliable. Adoption of our architecture
data management system for healthcare will solve this problem
by maintaining a centralized, secure bank of all patient records.
Using this data, healthcare organizations achieve a better
understanding of patients, and may efficiently decide
procedures and facilities best for them. The centralized
information obtained about doctors/hospitals/labs relationships,
making it easier to compare their performances, identify and
replicate optimum practices from in-network physicians.
Irrespective of the location of the patient or the healthcare
provider, availability of the data is paramount for both, patient
satisfaction as well as improved clinical outcomes. Cloud
technologies facilitate this data trend. Clinics, hospitals,
diagnostic labs, etc. all benefit from quick access to computing
and large storage facilities in a digital setting. Electronic
medical records, data analysis and health information exchange
are some of the features that the model aims to implement,
backed by this hybrid cloud-based data management model.
Compared to other verticals of cyber-crime victims,
healthcare had the highest percentage of incidents from data
theft/loss. [1] With online cloud-based record system personal
health, payment information, also intellectual property i.e.
prescription and report details need to be made private. Hence,
the security measures taken for the Smartcard users are very
important, to prevent the occurrence of any untoward incidents
involving very private user data.
978-1-5090-3239-6/17/$31.00 © 2017 IEEE
The paper is divided into nine sections. Section II pertains
to the details of the existing work done in this area, both
theoretical and practical schemes. Section III comprises of the
details of the underlying NFC technology behind the smartcard
this model uses, including specific information about our
implementation model. Section IV is composed of the
specialized NFC card model/family proposed to be used and all
the details that are associated with its capabilities, including the
very important anti-cloning measure. Section V details the
application scenarios for our model; the functionality it
provides and the systems it is supported by. Section VI pertains
to the specific hybrid cloud system proposed in this paper.
Section VII brings to the forefront the security concerns that
are related to the choice of the software and hardware base
used in our model; it addresses those issues as well as their
resolution. Section VIII details the implementation of our
model architecture practically, at the various user stratum. The
final section, Section IX, deals with the goals this model seeks
to achieve, and the various refinements that are proposed for
implementation in the future.
III. NEAR FIELD COMMUNICATION
Two electronic devices can communicate using Near-field
communication (NFC) which defines a set of communication
protocols, to establish communication between two devices out
of which one is a portable device like smartphone by bringing
them in a proximity of 4 cm i.e. 1.57 inches of each other.
NFC is a subset of the RFID family where radio waves are
used to uniquely identify items operating at 13.56 MHz
frequency. NFC is designed to be a secure and convenient form
mechanism to exchange data; NFC-capable devices include the
functionality of an NFC reader and an NFC tag.
Contactless payment systems which are similar to credit
cards and electronic ticket smartcards is a common application
of NFC allowing mobile payment to replace/supplement these
systems. NFC-enabled devices can act as electronic identity
documents and key cards. It also offers a minimum setup
method to establish a connection that can be used configure
more capable wireless connections in turn.
Each full NFC device can work in three modes:
II. RELATED WORK
The European Health Insurance Card [2] (2004) was
designed to cover the cost of healthcare, state-provided, for
British travellers in certain other European countries. To
obtain a card online, the applicant provided a personal NHS
number, allocated upon registration at a General Practitioner’s
office. Migrants were able to charge the full cost of medical
treatment in their home countries to the UK. The card, valid
for 5 years, was being replicated to be used for more than this
term. The government incurred a heavy loss for two years
before they acted on this.
This model will tackle this kind of fraud, by ensuring that
one citizen gets just one Smart card, which is issued on that
person’s Aadhaar Card number (or equivalent). Even if
misplaced or damaged, another Smart Card with the previous
one’s credentials and records can be issued. This will ensure
that a new card is not issued for the same person twice. Also,
use of anti-cloning technology in the smartcard itself will
prevent such any cloning fraud with our model.
In 2009, in Karachi, Pakistan- a mobile phone and NFCbased patient presence alert system was bought up by
Interactive Research and Development (IRD) is a non-profit
organization for the detection of early pneumonia. Patients
enrolled in the study would wear an NFC bracelet/anklet or
carry an NFC card, which the physician scanned with a cell
phone (Nokia 6131) on a medical encounter. [3]
It worked very well in the city area for a long time. The
issues it eventually faced were: keeping the data secure on
each device, as NFC cards can be read by a lot of devices.
Also, they were not successful in securing the GPRS
communication and central database. It got expensive to scale.
The entire success of this project was based on the physician’s
phone. A lot of security measures have been taken in the
proposed model to rectify these issues. Our hybrid cloud
architecture takes care of all issues above and more that may
arise in the future, by using a scalable and flexible base. [4]
NFC card emulation: Exposes device functionality
emulating a passive NFC smartcard, allowing users to
perform transactions such as payment or ticketing using
the device in lieu of the smartcard.
NFC reader/writer: The reader/writer is the smartphone
serving as the active device and the card is the NFC tag
serving as the passive device.
NFC peer-to-peer: Information can be exchanged when two
NFC enabled devices communicate in ad-hoc fashion.
Fig. 1: NFC Tag architecture [5]
NFC tag type definitions:
There are four basic tag types are given designations 1 to 4
and each having different format and capacity. These NFC tag
type formats are based on ISO 14443 Types A and B
(international standard for contact-less smartcards) and Sony
FeliCa which conforms to ISO 18092.
The different NFC tag type definitions are as follows:
1.
Tag 1 Type: These NFC tags are RW capable; users may
configure the tag to be read-only. Memory availability is
96 bytes expandable up to 2 Kbyte. The communication
speed of this NFC tag is 106 Kbit/s.
2.
Tag 2 Type: Type 2 is similar to Type 1 except the
memory size of this tag type is only 48 bytes although this
can be expanded to 2 Kbyte.
3.
Tag 3 Type: The NFC Tag 3 Type is based on the Sony
FeliCa system. It has 2 Kbyte memory and
communications speed is 212 Kbit/s.
4.
Tag 4 Type: Pre-configuration of these tags at manufacture
is possible to either read / re-writable, or read-only. The
tag memory can be up to 32 Kbytes and communication
speed between 106 Kbit/s and 424 Kbit/s. [6]
Passive NFC tags do not possess their own power. A small
amount of power is drawn by the NFC tag from the
reader/writer to power the tag. The tag is then enabled for data
transfer.
ISO /IEC 7816-4 commands. The most important
characteristics of the device is DESFire where DES stands for
Data Encryption Standard i.e. it indicates high level security
using 3DES or AES; FIRE stand for Fast, Innovative, Reliable
and Secure IC for contactless proximity transactions. [7]
The data transfer rates supported by the device are: 106
Kbit/s, 212 Kbit/s, 424 Kbit/s, 848 Kbit/s with an input
frequency of 13.56 MHz
The MIFARE DESFire EV2 features non-volatile
memory with the capacities: 2 kB, 4 kB or 8 kB, EEPROM
(Electrically Erasable Programmable Read Only Memory)
with up to 25 years of data retention. The read and write
operations are very quick typically 1ms for each transfer.
Each device has a unique 7-digit serial number having a
facility of “RANDOM” ID (optional) to enhance the level of
security along with 3 pass mutual authentication according to
ISO/IEC 7816-4.
The key management for the device supports up to 15
different keys: 1 master key and up to 14 application keys.
The hardware DES uses using 56/112/168 bit keys and AES
uses a 128-bit key encrypting key on RF-channel.
MIsmartApp is available for the application programmers
as a delegated application management. Several checks are
performed by the device such as i) Proximity check for
protection against Relay attacks.
Fig. 2: NFC Reader architecture [5]
Read speed: Within range, it is necessary for the NFC tag to
pass all its data over. Block transfer is allowed by NFC tag
type 1 maintaining read performance.
Die size: Lower cost is possible with a smaller die and also
the NFC tag being less obtrusive.
Unit price: The NFC tags are aimed to have a low unit
price.
The NFC tags can be made read-only makeReadOnly() API
function, making the tag irreversibly read-only.
IV. MIFARE DESFIRE EV2
The model proposes to use MIFARE DESFire EV2 or
equivalent, a part of the MIFARE DESFire family. Smartcard
anti-cloning should be one of the characteristics of the tag card
used in the model. The MIFARE DESFire EV2 possesses a
similar security certification as the banking cards or electronic
passports i.e. Common Criteria EAL5+. The device is based
on air interface and cryptographic methods and is complaint to
ISO/IEC 14443A specifications supporting an optional
Fig. 3: MIFARE DESFire EV2 architecture [7]
V. APPLICATIONS
A. Prescriptions
A prescription is information or a set of instructions given
by the doctor to the patient regarding purpose of the visit,
symptoms, and it also serves as the document which allows
the patient to purchase medication whose availability to the
general public is restricted (Schedule H drugs as per Indian
Penal Code). The proposed model serves the feature of writing
a prescription which is non-volatile i.e. replacing the
traditional paperwork and digitalizing the prescriptions. The
doctor can write the prescription using the application on his
mobile device or through the web services of the system. The
patients can easily change the doctor whilst ongoing treatment
and the changed doctor can quickly and easily understand the
situation by reading all the older prescriptions and reports of
the patient and start the medication.
The prescription consists of the date of the appointment,
time of the prescription, identification of the doctor and the
patient, the symptoms, detected disease and the medication.
The system authorizes the doctor or patient by the MediCard.
Current date and time are tagged in the prescriptions and it is
used to sort the prescriptions in order, to keep track of
duration of treatment. The prescriptions are stored on the
hybrid cloud storage. The prescriptions once stored, cannot be
altered. The patients can view the prescriptions and are thus
authorized to buy the medicines.
The application also provides an interface to order the
medication directly, using third-party medicine stores
available online.
The stores can be filtered based on location, availability,
discounts offered.
The model is also extended to the secondary healthcare
providers, such as chemists. Integrated into this framework,
they are given limited credentials to be able to verify the
validity of the prescription shown by the patient. This feature
is discretionary and may be utilized in a limited manner; for
the certain medications, which are liable to be misused, so that
their use is heavily monitored and can be easily tracked.
B. Reports
The process of determining a condition which explains the
symptoms of a patient or determining a disease is diagnosis.
The outcome of this process (text reports, codes, images,
atomic results) are amalgamated together to form a report. The
diagnostic laboratories add the reports to the hybrid cloud for
each patient. The reports added by the diagnostic centre may
have deletion or modification restricted. The reports are
uploaded in the standard PDF format for compatibility. All the
types of laboratory, pathology, radiology reports such as Xrays, ECG, blood test, etc. are stored in the cloud as PDF files.
Thus, it is possible for the patients as well as the doctors to
view the reports at their convenience. Thus, the overhead of
maintaining reports of a long term chronic disease for a patient
is diminished drastically in a systematic manner.
C. Personalised Treatment Programs
This proposed model also allows doctors to start a program
for a particular patient bearing a particular problem. Example:
a physiotherapist can start a program for a patient having
tennis elbow (a condition causing pain in the elbow due to
overuse of arm muscles), or chronic back pain. Such a patient
needs to visit the physiotherapist daily. The doctor can set the
duration of the program and add prescriptions to it. The
program allows to order the medication altogether and book
the appointments for the tenure. This application is
advantageous as the linked appointments and prescriptions are
grouped together in a program in an intelligent manner. After
the successful completion of the program, an analysis report
will be created using all the prescriptions given during the
program course. The report will include the graph and
statistics indicating the improvement or deterioration in the
patient’s health. In case the patient switches doctors in the
meantime, this analysis helps the new doctor to understand the
case quickly rather than going through all the prescriptions of
the program. Personalized programming is a methodical and
meticulous approach in system designing.
D. Payments
NFC-based e-wallets are being adopted by the masses,
along with merchants and vendors for the purpose of quick,
cashless transactions. They have proven to be largely secure
and fast. The mobile e-wallet of the individual is used to
execute the payment. They are secured using the most modern
methodologies, and as the underlying hardware is up to date,
the security of this method is almost guaranteed. Various
technology giants around the world have rolled out their own
versions of this payment model, such as Apple Pay and
Android Pay.
Within our proposed model, multifarious payment options
are available such as linking with the mobile wallet, credit
cards, debit cards, and third party applications, all with the
help of such payment avenues. The first step of the payment
procedure is to authorize the doctor’s account. The doctors
need to have their account registered and approved as a trusted
entity. The availability of the third-party applications for
payments depends upon the doctor’s registered accounts, or
the preferred modes of transactions. To make a secured
payment, the doctor has to bill the amount and tap the
patient’s card again to the mobile device. The patient’s
account is then validated and the preferred payment mode is
chosen. The verification is completed after the patient
authorizes the transaction by means of a secure code, OTP or
biometric authentication, depending on the mode of payment
selected, and the third-party provider’s implementation. The
application also keeps the track using the log event register
and patients can track the payments sorted according to time,
location and doctor. This application is advantageous as the
usage of mobile payments increases.
E. Live patient monitoring
The records for the patients admitted into the hospital are
critical and has to be kept secured and accurate. Rewritable
NFC tag cards can be used in these cases where a card can be
used for a patient to store all the data in the database and after
the discharge, the ID in the card can be re-written to provide it
to another patient thus reusing the resources. The data of the
patient is not deleted from the database and a relation is
established between that data and the patient's’ application ID.
All the hospital admissions can also be tracked in this way.
The scope of this application is not limited to storing the data
in the database but the doctors can also access the card and
know the updates about the patient immediately and speedily.
This application is advantageous in organizing the data in nonvolatile manner and linking it as a whole to the patient's’
application ID. The updates that can be stored may include the
blood pressure of the patient, heart rate, temperature, saline
levels, electrolyte levels, IV medication, as well as other
relevant physiological parameters.
F. Patient Medical Data Tracking & Analysis
The hybrid cloud system provides an interesting set of
opportunities regarding data analysis. Usually, the patient data
is scattered across inaccessible, closed data storage modes
such as physical records. Having it in a centralized manner
allows easy access to the data for various purposes, such as
data analysis. As this data, may be obtained in an aggregated
format easily, it is easy to run statistical models on these
datasets. Using only the non-personally identifiable patient
information, the privacy of the patient can be respected, as
well as run simulation and analytical processing models on the
datasets.
This raises the prospect of real-time, live medical
monitoring. The progression of any virulent diseases can be
tracked much faster, as patient records get updated in realtime. Other secondary health factors such as propensity to a
chronic health condition, grouped by a patient factor, locationwise or any other factor, can be easily tracked. Such
observations can lead to quicker response time from the
concerned authorities, as well as targeted actions to ensure the
quick dispersion of such threats. This information, however
must be very carefully managed; it can be very personal if the
identity of the person involved is revealed somehow. Hence,
the data processing models must be run within the hybrid
cloud itself, and care must be taken to ensure that only
statistical, aggregated queries are run on the data, with
personally identifying information such as an UID being
inaccessible to such statistical programs.
turning digital. Loss of such data is way too frequent and can
lead to bigger problems as this concerns our health. The
aggregation of data, loss or invalidated records, lack of
centralized structure calls for a better solution.
Cloud computing lets healthcare organizations focus on
health care rather than worrying about data centers, digital real
estate to house them, and skilled professionals to maintain and
operate them. Hybrid Cloud-based applications can easily scale
up or down as demand changes; from a development
perspective, they’re flexible and accessible. A Hybrid Cloud
based architecture extends flexibilities to collaborate which is
the key to this application.
Eucalyptus by Amazon Web Services (AWS) is a private,
compatible and hybrid cloud computing environment. Our
proposed data storage architecture is backed by this platform. It
features pooling compute, storage, and network resources that
can be scaled up dynamically as workloads grow. So as the
amount of data increases, corresponding to the number of
patients and their records, the database itself must grow and
configure itself to the data load it is being subject to.
VI. HYBRID CLOUD MODEL
The healthcare industry has already begun to transition
towards full digitalization, with all its benefits being apparent
in the ease of access to healthcare data and its management.
Currently, a limited local network backed by a local database
server is commonly used to store and manage the patient data.
This effectively limits the accessibility of the data, to both the
patient as well as the other healthcare providers who might
need access to that data.
Compounding this problem, overall digitization and
improvement in the healthcare standards has effectively
increased the magnitude of data collected exponentially. Thus,
the problem of data management in healthcare is with the
unofficial term “huge data” is acceptable as to be a big data
problem. And the only way to deal with big data lies in the
modern, non-traditional methodologies. The costs and issues
associated with obtaining equivalent functionality and security
as a hybrid cloud architecture, from legacy systems is too
prohibitive and may not well be possible. In such a scenario,
the scalability of cloud systems needs to be able to keep up
with the data trends. Thus, the migration into cloud systems is
inevitable.
The traditional architecture of medical records on local
computers of hospitals, labs, clinics and hard copies with
individual patients is rendering obsolete as everything else is
Fig. 4: Eucalyptus architecture overview [8]
Our architecture consists of a set of instances which are
fixed collections of software modules when put to use at
runtime. Cloud instances are virtual servers running off a
hybrid cloud network, which are provisioned by using specific
machine images, that include all the necessary software
modules and information needed for the node to be handle the
cloud functionality. Using instances makes cloud computing
dynamic; it allows adding of resources (processing
nodes/servers) to be done on demand, enabling maximum
throughput to be maintained across the hybrid cloud. As
demand reaches beyond the limits of the current servers,
instances allow a new server to be configured and added to the
hybrid cloud in real time. This abstraction allows seamless
transitioning of data and resources across the hybrid cloud,
which is the reason behind its scalability and flexibility.
Eucalyptus provides a mechanism to firewall off an
instance using just an IP address and functionality port block or
allow. Instances are isolated at TCP/IP layer 2. In the absence
of this, any user could manipulate the networking of records
and access nearby data violating the basic archetype of instance
isolation and separation. Another feature of Eucalyptus is that
identities can be grouped together for common access control.
Common Hybrid cloud security concerns tackled:
1.
Data breach - A data breach is when sensitive, protected or
confidential information is released, viewed, stolen or used
by an individual who is not authorized to do so.
Passwords, sensitive medical reports and appointment
details and prescriptions are a patient’s intellectual
property that needs securing. The standard way to combat
this is by format-preserving encryption (FPE) to encrypt
structured data and Tokenization - the process of replacing
sensitive data, such as the patient ID, with a no sensitive
equivalent(token).
2.
Insufficient Identity, Credential and Access ManagementPatient, doctor or lab credentials and cryptographic keys
won’t be embedded in source code. A well-secured public
key infrastructure (PKI) is utilized here, as the
cryptographic base. Multifactor authentication systems –
smartcard, OTP (planned), and phone authentication helps
address password theft, and enable access to resources
without user consent. The cryptographic keys are
periodically rotated, including TLS certificates, keys used
to protect access and encrypt data.
3.
Advanced Persistent Threats (APTs) are cyberattacks that
infiltrate systems to establish a foothold in the computing
infrastructure. Direct hacking systems, USB devices
delivering attack code, penetration through partner
networks, use of third-party unsecured networks that act as
common points of entry for APTs. APTs customize tools,
to stop these attacks blocking ways for them to
communicate out of the program and unusual SQL
activities are handled. [9]
4.
Denial-of-service (DoS) attacks prevent users of a service
from being able to access their data. They cause a system
slowdown, asymmetric DoS (application level) attacks can
take advantage of vulnerabilities in a web server, databases
of cloud resources to take out an application with a single
extremely small attack payload. To prevent this,
techniques used can be: firewall implementation, flow
level filter used to detect the low rate DoS attack,
application of attack surface reduction and false positives
reduction. [10]
TLS (Transport Layer Security) [11] is an updated, more
secure, version of SSL - Secure Sockets Layer which has been
the standard technology for keeping an internet connection and
sensitive data that is being sent between two systems secure. It
works by making data transferred between users and sites, user
two systems impossible to read using encryption algorithms to
scramble data in transit. This framework is proposed to be
administered into the data storage.
The tenets of TLS 1.3 are utilized, a working draft that has
added features like: i) Requiring digital signatures even when
a previous configuration is used; ii) Removing support for
weak and lesser-used elliptic curve encryptions, MD5 and
SHA-224 cryptographic hash function and more
VII. SECURITY
Many organizations, and hence software systems, seek to
utilize the benefits of cloud; however, data security remains a
prime concern. Maintaining effective data security using
encryption in the cloud is the objective, which is addressed
through a number of techniques.
For data security expansion at an asymmetrical rate, there
arise a number of issues to be addressed. While encryption is
the fundamental technology that drives security, encryption in
the cloud is a relatively newer, and as yet complex issue. One
of the factors making this decision hard is the availability of so
many encryption techniques and algorithms; thus, any
decision to select the particular ones to use can be quite hard.
In legacy systems, encrypted data was stored on the local
servers. As applications move to the cloud, software as a
service (SaaS) systems can be used that will manage the
encryption and decryption keys as well as any encryption
metadata. The latter approach is used in our hybrid cloud
architecture.
It uses Transport Layer Security (TLS) [12] encryption to
create a secure link between the cryptography management
server and the cloud storage application. Once the data reaches
the cloud application' servers, it can encrypt/decrypt the data
securely.
Managing encryption keys is the most important objective
in this model. For this to be achieved, separating the
encryption key from the encrypted data is paramount to keep
the data secure. The Cloud Storage Application might store
the keys in memory while they are being used. This must be
managed securely on fulfilment of the operation, using secure
wipe techniques to make any possible unauthorized retrieval
of the keys impossible.
Encryption keys will also be kept on a separate server or
storage block. A backup of all the keys is also envisioned to be
kept in an offsite location in case of disaster. This backup
must be audited every couple of months. It is very important
to carry out these tasks regularly and efficiently, as any
encrypted data is almost useless without the encryption keys.
There are three basic states of the data across the hybrid
cloud network: in transit, in use and at rest.
Protecting data at rest is essential. Sensitive data will be
protected at any layer, from the local layer to the data
centre/cloud layer. As data is added to the database, security is
an integral part of process, so that security moves with the
data.
Secure Socket Layer (SSL) approach, standard for years,
has fallen out of favour since the discovery in 2014 of the
POODLE (Padding Oracle On Downgraded Legacy
Encryption) attack, a man-in-the-middle exploit that
effectively was designed into the SSL code. The model has
implemented the TLS 1.3 draft where handshake and record
protocols provide authentication and security. PSK (pre-shared
key) system resumption has been replaced with cipher suites.
Digital signatures are checked even though a configuration is
previously used. Changes in Ed448 digital signature
algorithms (Ed25519) and message authentication codes
(Poly1305) are made.
Cloud Security Alliance recommends:
Use of approved algorithms and long, random keys
Encryption before transmission from the lower layers to
the cloud provider
Encrypted state is maintained in transit, at rest, and in use
The cloud data storage must never have access to the
decryption keys
In our model, processing of sensitive data takes place in
the cloud, and users take advantage of the cloud's economy of
scale and elasticity. The data remains encrypted up to the
moment of use and that both the decryption keys and the
decrypted versions of the data are available in the clear only
within a protected transient memory space.
It is paramount that the keys and any cleartext data is
securely wiped, without insecure disk copies being created by
processes such as logs or any other persistent records.
B. Android security
The android application used in our model has access to
the highly-secured information belonging to the patient, as it is
one of the possible endpoints of the data communication flow.
This means that the data must be unencrypted at the device,
for it to be viewed and used by the patient. Also, any new data
records may be added as a result of the functionality provided
in our application, such as when the patient seeks to pay thru
the e-wallet functionality. Here, the patient’s actions lead to a
record being written to the patient’s medical records, with the
date, time, purpose and case details being logged. Here, some
data originates from the device, and hence it must be securely
transmitted to avoid eavesdropping, malformation or loss of
integrity of the data.
Hence, our proposed model features TLS connections,
using public-key encryption scheme: ECC for session key
agreement, while using RSA 2048-bit private key for
authentication. The objective is to implement the following
cipher suite:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
1) ECDHE: ephemeral Elliptic Curve Diffie-Hellman key
agreement
2) RSA based authentication
The application does not store any of the data
unencrypted; the cache level data is stored encrypted, and
whether it is data fetched from the server or from the cache,
decryption is performed on-the-fly. The use of root
permissions will not be effective in breaking the data security
in any way; without the card, the key cannot be obtained, as it
is stored nowhere on the device itself. Thus, the only exploit
avenues left are memory dumping while the decrypted data
and the key is held in the memory, and the use of malicious
snooping applications acquiring global hooks on events. To be
immune from this issue, our application utilized the new
Android API SafetyNet.
SafetyNet is an API allowing the evaluation of the
hardware and software of the device to verify if it’s
characteristics match those with which the application was
developed. Put simply, it will block out the rooted/modified
devices, where it is not possible to be entirely sure about the
chain of trust. The value contained in ctsProfileMatch
variable, from the response received from Play Services,
indicated if the device has passed the Android compatibility
testing, and hence can be allowed to execute further.
VIII.IMPLEMENTATION
To deploy this model architecture, an application for
Android devices using Android APIs (SDK 21 and above) and
an interface to it thru a normal web server using PHP and
MySQL as backend was made.
The android application authenticates the user via the
NFC MediCard or manual login using the unique MediCard
ID and password, which keeps record of all test reports also
downloadable offline, appointments, prescriptions-authorized
by physician and a doctor search engine. It has a pop-up
notification functionality for reminder of appointments. This
application has been tested on Google Nexus 5 device. The
android.nfc.tech package provided by Android has all required
methods and classes to enable interaction with NFC tags. The
card can be accessed from an authorized Android application
installed using custom platform APDUs (application protocol
data unit) for communication between card and card reader.
The physician can send new and view old prescriptions and
reports. A payment gateway is also integrated into the
application.
The web server has been implemented using advanced
PHP and MySQL for the hybrid cloud based database set-up
Eucalyptus (Version 3.3.2). The cloud was set up on two
machines. One hosted the cloud controller - Walrus, the
cluster and the storage controller and the other acted as the
node controller that ran on a KVM hypervisor. Two simple
desktops were used, each equipped with a 500GB hard drive, a
4 GB RAM, and a Virtualization Technology enabled
processor on-board. [13]
Fig. 5: Proposed Eucalyptus Architecture [14]
Fig. 6: A demo set-up [14]
The website developed has a dedicated patient, diagnostic,
hospital and pharmacist profile. The patient logs using his
MediCard ID and password and can keep track of his medical
information, prescriptions, reports, appointments, personalized
programs and a doctor search engine. Diagnostics and hospitals
can add and authorize prescriptions and reports in a PDF format.
A database of all medicines is maintained and they can add to this
list.
The card used for this implementation is the MIFARE
DESFire EV2 [7]. It is a Common Criteria EAL5+ security
certified card with backup management system and mutual three
pass authentication system on-chip. DES indicates the high level
of security and hardware cryptographic engine-DES using
56/112/168 bit keys. A 7 bytes long serial number acts as a
unique identifier that generates an ID required. It has flexible,
non-volatile memory. There is the mutual authentication protocol
according to ISO/IEC 7816-4 on application level. These new
features make this the ideal technology to use for secure
communication and data storage such as our applications.
IX. CONCLUSION AND FUTURE WORK
This paper has proposed applications on an NFC based
smartcard for improving healthcare, to secure medical object
data and to implement a system of patient Smartcard or mobile
device itself. The applications to this technology are
significant, namely prescription management, conveyance and
storage of reports, personalized doctor-patient routines, easy
payment integration and live patient monitoring.
Implementation of this system will decrease the load on
hospitals. The model will benefit the patients and medical
professionals equally.
security. Periodic data access could get validated using the
patient’s finger print to minimize leakage of data. Prescription
and reports authentication by doctors and labs too.
To facilitate the usage of this MediCard in developing
countries and all sectors of society including those who do not
have access to mobile internet at all times, offline saving of
prescriptions, reports, programs, charts and basic emergency
medical information about a patient; and uploading of data can
be implemented with periodic (monthly) updating of the
online cloud database.
Another application to this is the NFC Smartcard
integrated with Bluetooth that can unlock channels and send
large quantities of data such as a timed electrocardiogram
strip. This is a way in which live patient monitoring speed will
be enhanced.
REFERENCES
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
Another application of this technology could be embedding
NFCs into patients’ medical charts at hospitals/labs. Doctors
and nurses could quickly see procedures due and completed
along with the patient’s prescriptions and medical history, to
administer the best possible care.
At the patient front, NFC in healthcare can be extended to
a centralized (offline) mobile phone controlled interface. This
will provide the added layer of security namely biometric
[13]
[14]
Verizon Enterprise, source: http://www.verizonenterprise.com/verizoninsights-lab/dbir/, December 2016.
Hugh Pym “NHS vulnerable to health card fraud”, source:
http://www.bbc.com/news/health-33843758, December 2016.
Aam Marcus, Guido Davidzon, Denise Law, Namrata Verma, Rich
Fletcher, Aamir Khan, Luis Sarmenta, “Using NFC-enabled phones for
public health in Developing Countries”, First international workshop on
Near Field Communication, 2009, IEEE.
Divyashikha Sethia, Daya Gupta, Huzur Saran, “NFC based Secure
Mobile Healthcare System”, IEEE, 2014.
RFwireless World, source: http://www.rfwirelessworld.com/Terminology/NFC-tag-vs-NFC-reader.html, December
2016.
Radio Electronics, Ian Poole, source: RFwireless World, source:
http://www.rfwireless-world.com/Terminology/NFC-tag-vs-NFCreader.html, December 2016.
MF3D(H)x2; MIFARE DESFire EV2 contactless multi-application IC
Data sheet, source:
http://www.nxp.com/documents/short_data_sheet/MF3DX2_MF3DHX2
_SDS.pdf, December 2016.
Eucalyptus Architecture Overview, source:
https://en.wikipedia.org/wiki/Eucalyptus_(software), December 2016.
2016 Cloud Security Alliance “The Treacherous 12 Cloud Computing
Top Threats in 2016”, source:
https://downloads.cloudsecurityalliance.org/assets/research/topthreats/Treacherous-12_Cloud-Computing_Top-Threats.pdf
Subramaniam. T. K, Deepa. B, “Preventing Distributed Denail of
Service Attacks in Cloud Environments”, International Journal of
Information Technology, Control and Automation, Vol. 6, No. 2, April
2016.
Transport Layer Security, source:
https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_1.3_.28dr
aft.29, December 2016.
Transport Layer Security Protocol, E. Rescorla, source:
https://tlswg.github.io/tls13-spec/, December 2016.
Arunkumar Goge, Magesh S., “Implementation of Database as a Service
in
a
Private
Cloud
using
EUCALYPTUS”,
source:
https://www.researchgate.net/publication/262375919_Implementation_o
f_Database_as_a_Service_in_a_Private_Cloud_using_EUCALYPTUS,
April 2013.
Yohan Wadia, “Build Your Own Private Cloud with Eucalyptus”,
source:http://opensourceforu.com/2014/03/build-private-cloudeucalyptus/, March 2014.