© Copyright AAMI 2013. Single user license only. Copying, networking, and distribution prohibited.

Features

A Secure Cryptographic Scheme

Protecting Stored and
Transmitted mHealth Patient Data
Dalimar Velez and Michael Shanblatt

About the Authors Recent developments in the field of telemedi-
cine have created new capabilities in
Dalimar Velez is at
the Department
emerging mHealth technologies. These
of Electrical advances can be seen in telecommunications
and Computer technologies, point of care testing (POCT)
Engineering, devices, and the implementation of electronic
Michigan State health records (eHR). The security and
University, East
privacy of the patient could, however, be
Lansing, MI. E-mail: velezdal@msu.edu
compromised if these technologies do not
Michael Shanblatt is work in harmony at all the stages of the
at the Department system. It is therefore crucial for new
of Electrical
mHealth designs to include appropriate
and Computer
Engineering,
security mechanisms to secure patient
Michigan State electronic protected health information
University, East (ePHI) and, at the same time, comply with
Lansing, MI. E-mail: mas@msu.edu governmental regulations and guidelines
such as the Health Insurance Portability and
Accountability Act of 1996 (HIPAA) and the
National Institute of Standards and
Technology (NIST).
The work described in this paper focuses on
protecting all ePHI stored in and transmitted
via smartphones. This includes a crypto-
graphic scheme required to address the
problem. A smartphone with an Android
operating system (OS) is assumed as the
POCT platform to implement and test the
system. The work takes into account crypto-
graphic attacks such as eavesdropping,
interception, data loss, or alteration. The core
of the cryptographic scheme implements
password-based encryption (PBE)1 that uses
the symmetric advanced encryption standard
(AES)2 with a cipher block chaining (CBC)3
mode. This is a similar to the cryptographic
configuration used on sensitive data transac-
tions and data storage in banking and
government operations. The salient difference
is that the encryption/decryption blocks
presented in this work use a key management
design that isolates different parts of ePHI
with separate derived key material. The main
contributions of this design include a frame-
work for protecting ePHI in the context of
mHealth technologies that communicate with
a remote health provider and the algorithms
for security key generation and management.

Cryptosystem
A typical event in a mobile healthcare scenario
(Figure 14) requires the patient to use a
smartphone to connect to one or more
sensors, take a measurement, and then
Figure 1. Mobile Healthcare Scenario Overview4
transfer the data to a remote server. In this

46 Biomedical Instrumentation & Technology January/February 2013

 © Copyright AAMI 2013. Single user license only. Copying, networking, and distribution prohibited.
Figure 2. Cryptographic Scheme
scenario, the cryptographic scheme needs to
protect the main routes of ePHI, which are
the data paths to the sensors, the local storage
units, and the connection/transmission to the
external server via the cellular network. The
cryptosystem presented here focuses on
protecting data that will be accessed and
stored in the phone and also data that will be
transmitted to an external server.
The fulfillment of a secure system that
protects the patient’s ePHI and its integrity
depends on the design of the cryptographic
scheme and the key management. By
definition, encryption involves translating
plain text into ciphertext by using a crypto-
graphic key. The decryption is then the
inverse process by which the ciphertext is
restored to the original plain-text form. If the
key used for encryption/decryption is ever
revealed or discovered, the information is
compromised. Therefore, the element of
randomness in the key generation process is
crucial since it introduces unique material to
seed the process. The more complex the
key-generation algorithm is, and the higher
its degree of randomness, the more secure
the ciphertext becomes.
Consequently, the security of the applica-
tion relies on the strength of the cipher
algorithm, the quality of key material gener-
Features
Figure 3. Basic Flow Chart for the Generation of the Master Key
ated, the key management scheme, and the
implementation of appropriate user policies.
The encryption scheme presented in this
paper is illustrated in Figure 2.
A. Key Generation and Management
When the user enters the application for the
first time, registration will be required to
activate an account through
the user interface (UI). Figure
3 shows the key generation The cryptosystem presented here
block which depends on the focuses on protecting data that
patient password, a “salt” to will be accessed and stored in the
randomize the process, and
phone and also data that will be
the iteration count to produce
the master key (mk). The transmitted to an external server.
password-based key derivation
function (PBKDF2) defined under the
password-based cryptography standard
(PKCS#5)1 is the algorithm used as the key
generation block. The random salt, Rsalt, is a
number that needs to be generated with a
proven level of randomness. This variable is
Biomedical Instrumentation & Technology January/February 2013 47
 © Copyright AAMI 2013. Single user license only. Copying, networking, and distribution prohibited.
Features
Figure 4. Diagram of the Encryption/Decryption Process
generated using the cryptographic pseudo-
random number generator algorithm
SHA1PRNG which complies with the
FIPS140-2.5 The fixed salt, Fsalt, is a hard-
coded number stored at the application level.
The purpose of using a fixed and a random
salt to form the input salt for the key genera-
tion algorithm is to enhance the key strength
against possible rainbow table and dictionary
attacks (see Glossary).6 The iteration count, c,
is the number of times that the key genera-
tion block will iterate to generate a block of
mk.7 Raising this value increases the dif-
ficulty of an exhaustive password search by
an intruder. The last variable is the plain text
password (P) given by the user.
Each DPK is used to protect a particular category of data such
as the patient personal information, account, or sensor data.
In addition to the above measures, this
system relies on deriving data protection keys
(DPKs) from the previously generated mk.
Each DPK is used to protect a particular
category of data such as the patient personal
information, account, or sensor data. Subse-
quently, any attack is more difficult because
the intruder has to find more than one key (if
not all of them) in order to decrypt any data.
Even if all DPKs are obtained from the same
mk, they are cryptographically separated.
This means that if some DPKs are compro-
mised, the event will not degrade the security
48 Biomedical Instrumentation & Technology January/February 2013
strength of the other keys. Figure 2 shows
three DPKs derived from the mk. These keys
are generated using a key derivation function
(KDF). The KDF uses the keyed-hash
message authentication code (HMAC) with
SHA256 in counter mode,8 as defined in
NIST SP800-108.
The mk will be sent to the health provider
only when the patient creates a new account
for backup and emergency situations. After a
successful authentication of the user, the
application generates the DPKs. Therefore,
none of the keys are stored in the smart-
phone after the application is closed.
B. Encryption and Decryption Stage
User data is encrypted using an AES256
algorithm with a CBC mode.3 As shown in
Figure 4, all ePHI data entered by the user is
encrypted/decrypted using DPKj keys which
isolate the data stored in the database. In this
particular case, only three exemplar catego-
ries are used: patient account, personal
information, and POC data. The user must
be authenticated for the application to grant
access and generate the appropriate keys.
These DPKs along with an initialization
vector (IV) are then used to encrypt new
patient information into the database or to
decrypt previous information.
C. Password Storage and Authentication Policies
To avoid the risk of unauthorized access in the
case of a lost or stolen phone, the user pass-
word should never be stored on the device in
plain text. But if the password is not available
in plain text, the main application still needs a
way to authenticate the user’s password entry.
In order to ease this process, it is practical to
use a hash function (e.g., the SHA512 algo-
rithm) over the plain text password and store
the processed value. Then, when the applica-
tion needs to authenticate a user password
entry, the application processes the user entry
using the same hash function and compares it
to the previous processed value. The benefit of
this process is that the device does not need to
store the plain text password for comparison
purposes. The disadvantage is that the hash
function is vulnerable to attacks schemes such
as the rainbow table and dictionary.6
Consequently, the hashed password should
also be encrypted.
 © Copyright AAMI 2013. Single user license only. Copying, networking, and distribution prohibited.
Features

Specifications NIST Security

HIPAA Standards Implemented Strategies
(A=Addressable R=Required) Controls*

AC-3, AC-4
Access Authorization (A)
Information access
Access is granted depending on the user policy such
management
as a registered patient or healthcare provider.
164.308(a)(4) Access Establishment and
AC-3
Modification (A)

Security awareness The patient is required to select a password with at

and training Password Management (A) IA-2, IA-5 least 10 characters that includes case-sensitive letters,
164.308(a)(5) digits, and symbols.
Each user needs a unique ID and authentication code
Unique User Identification (R) AC-3, IA-2, IA-3
for purposes of registration and log-in credentials.
The application allows authorized health
Emergency Access Procedure
AC-3 professionals with credentials to access the patient
Access control (R)
ePHI on such events.
164.312(a)
Application closes after being inactive for certain
Automatic Logoff (A) AC-11, AC-12
amount of time (e.g., 5 min).
Stored ePHI is encrypted using an AES256 cipher on
Encryption and Decryption (A) AC-3, SC-13
a local database.
In the case of a lost/stolen device, a lockdown
Audit controls
AU-6 mechanism and deletion of the ePHI can be initiated
164.312(b)
remotely.
Person or entity The application provides an optional two-factor
authentication IA-2, IA-3 authentication for renewing log-on information
164.312(d) based on security questions.
Transmission security Integrity Controls (A) SC-8, SI-7 The application uses SSL/TLS protocols that enforce
164.312(e) Encryption (A) SC-9 AES256 encryption and data integrity checks.
*AC - Access control, IA - Identification and Authentication, AU - Audit and Accountability, SC - System and Communication protection,
SI - System and Information integrity.10-11
Table 1. Mitigation Strategies

D. Secure Transmission to Health Provider
The data exchanged between the smartphone
and the remote health provider must remain
private and confidential. Secure Sockets
Layer/ Transport Layer Security (SSL/TLS)
protocols were used to protect against
eavesdropping, interception, and alteration.
In this protocol, the client (smartphone) and
the server (health provider) agree on the most
secure cipher suite supported on both ends
during the initial handshake stage. Special
attention should be given to enforce the use
of a strong cipher such as AES128/192/256,
as a weaker cipher could compromise ePHI.
In this particular case the encryption algo-
rithm enforced is AES256. As a result, all
ePHI data sent to a remote health provider is
doubly encrypted because the locally stored
ePHI is first encrypted on the smartphone
and then encrypted a second time when
transmitted over the SSL channel.
Compliance with Standards
And Regulations
An Android application was developed to
implement the cryptographic scheme pre-
sented in this work along with other policies
and strategies.9 This implementation is the
result of a risk analysis for the access, storage,
and transmission of ePHI from the smart-
phone application. The risk analysis includes
the evaluation of threats and vulnerabilities.
The regulations reviewed include the HIPAA
law, the Recommended Security Controls for
Federal Information Systems and
Organization (NIST SP800-53),10 and the
Guidelines for Managing and Securing Mobile
Devices in the Enterprise (NIST

Biomedical Instrumentation & Technology January/February 2013 49

 © Copyright AAMI 2013. Single user license only. Copying, networking, and distribution prohibited.
Features

Max APDU (octets) Draft SP800-124, Rev.1).11 Table 1 shows the

mitigation strategies implemented in the
ISO/IEEE Manager to
Device Specialization Agent to Manager (Ntx) application along with the required HIPAA
11073-104zz Agent (Nrx)
safeguards and the suggested security controls
04 Pulse Oximeter 896 224
for mobile devices from NIST.
64512-persistent metric
Basic electrocardiogram In addition, it is also appropriate to this
06 7168 simple ECG profile 256
(ECG) research to use the information models of
+ 1280 heart rate profile
07 Blood pressure monitor 896 224
medical sensors/devices as described by the
International Organization for Standardiza-
08 Thermometer 896 224
tion/ Institute of Electrical and Electronics
15 Weight scale 896 224
Engineers (ISO/IEEE) 11073 Standard. The
64512-persistent metric ISO/IEEE11073 family of standards specifies
17 Glucose meter 224
5120
models for the interconnection and interop-
International Normalized eration of agents (e.g., medical devices) and
18 896 224
Ratio (INR) monitor
managers (e.g., computers and cellphones).
Body composition IEEE11073-104zz standards12 are the device
20 7730 1230
analyzer
specializations that apply the model to the
21 Peak Flow 2030 224 specific device function and data require-
Cardiovascular fitness ment. For the purposes of this research, the
41 64512 8192
and activity monitor* device’s specializations and their respective
Strength fitness application protocol data unit (APDU) sizes
42 64512 8192
equipment* are used as the main reference for the
71 Activity hub 5120 224 simulated data to be encrypted and/or
72 Medication monitor 1024 64 decrypted. Table 2 shows the maximum size
*No specific device specialization for the APDU: Follow IEEE11073-20601. of APDU by device specialization.
Table 2. Application Protocol Data Unit by Device Specialization
Performance Evaluation
Smartphone CPU Android version In mHealth scenarios, the implementation of
Motorola Photon 4G NVIDIA Tegra 2 (1GHz) 2.3.4 (Gingerbread) the security scheme is restricted by the
limited computational resources available on
Motorola Atrix NVIDIA Tegra 2 (1GHz) 2.3.6 (Gingerbread)
a smartphone. In addition, the performance
HTC EVO 4G LTE Qualcomm MSM8960 4.0 (Ice Cream Sandwich)
of the cryptographic algorithm should not
Snapdragon (1.5GHz)
add a computational cost that significantly
Table 3. Smartphone Hardware Specifications
affects the usability of the application and the
phone in general.

In mHealth scenarios, the

implementation of the security
scheme is restricted by the limited
computational resources available
on a smartphone.

An application was executed on various

smartphone models (shown on Table 3) to
estimate the performance of the cryptosys-
tem with the goal of converging to a
configuration that maximizes the security
strength and maintains an appropriate
measure of usability. This application
measures the execution time in different
Figure 5. Key Generation (256 Bit Key) Total Time for an Iteration Count of 100 to 1000 configurations of the key iteration count and

50 Biomedical Instrumentation & Technology January/February 2013

 © Copyright AAMI 2013. Single user license only. Copying, networking, and distribution prohibited.
Features

the size of the data encrypted. The key length Phone Key generation + Key generation +
of 256 bit was preselected to apply the Encryption (ms) Decryption(ms)
highest security strength possible. The test Motorola Photon 4G 143.69 148.87
application measures the average time taken
Motorola Atrix 142.66 154.30
by the key generation and the encryption/
HTC EVO 4G LTE 92.36 111.50
decryption processes. In addition, this
application takes in account the different Table 4. Cryptosystem Time Response (256 Bits Strength and Iteration Count of 500)

APDU sizes from the ISO/IEEE11073

standard as shown on Table 2. The average
calculations were measured after iterating
1,000 times over each configuration of key
length, iteration count, and APDU size.

A. Test Application and Results

The total time shown on the following
figures as the “key generation time” includes
the time to generate the master key plus the
time to generate three DPKs. Figure 5
presents the total time required for the key
derivation of 256-bit strength using iteration
counts that fluctuate from 100 to 1,000. The
iteration count increases the workload for an
attacker but also increases the computational
work required for the key derivation. The
effects of the iteration count can be seen in
Figure 5, where the performance time for
generating the key increases linearly with
increase in iteration count. Consequently in
order to obtain a performance of ≤ 100 ms in
the key generation stage and to maintain a Figure 6. Encryption Time for Different APDU With Iteration Count of 500 for Tested Smartphones

security (workload) margin, an iteration

count of 500 was chosen.
Figures 6 and 7 shows the mean time of
the encryption/decryption stages for each of
the APDU sizes described in Table 1 using
AES256 with an iteration count of 500. In
the worst-case scenario, when the APDU
has a length of 64,512 bytes, the encryption
time is 47.10 ms and the decryption time is
53.45 ms. The time response of the crypto-
system for an APDU size of 64,512 bytes is
summarized in Table 4.

Conclusion
The cryptographic scheme presented in this
work protects all ePHI in the mHealth
scenario, both stored and transmitted. The
ePHI data is secured at several levels with
different keys, making it as difficult as
possible for an attacker to gain access to any
usable data. In addition, given that the data is
transmitted to a remote health center over a Figure 7. Decryption Time for Different APDU With Iteration Count of 500 for Tested Smartphones
secure channel, the data is doubly encrypted

Biomedical Instrumentation & Technology January/February 2013 51

 © Copyright AAMI 2013. Single user license only. Copying, networking, and distribution prohibited.
Features
Glossary
Advanced Encryption Standard (AES) is a symmetric key
algorithm approved by NIST (2002) to encrypt/decrypt
electronic information with different key lengths.
Cipher Block Chaining (CBC) is a mode of operation used
on the encryption algorithm. In this mode, the plain-text
blocks are combined in a chain with previously encrypted
blocks.
Dictionary attack is an attack used to determine the user’s
password by successively trying words from a list of
passwords/values.
Data Protection Key (DPK) is a key derived from the
master key with the purpose of protecting a section of the
ePHI.
Keyed-Hash Message Authentication Code (HMAC) is a
message-authentication algorithm that is used to verify a
message and its integrity using a cryptographic hash
function and a cryptographic key (FIPS 198-1).
Key Derivation Function (KDF) is an algorithm used to
generate cryptographic key from one or more parameters.
Password-Based Encryption (PBE) is a scheme in which the
encryption/decryption operations rely on a key generated
from a password.
Rainbow table attack involves the use of a pre-computed
lookup table created by building chains of hash and
reduction functions with the purpose of retrieving a
plaintext password.
Secure Hash Algorithm 1 (SHA1) is a cryptographic hash
function that produces a fixed output (160-bit digest).
SHA1PRNG is a pseudo-random number generator
algorithm with cryptography properties.
Secure Sockets Layer/Transport Layer Security (SSL/TLS) is
a secure communication protocol used between two
parties over a network.
Symmetric key algorithm is one that uses the same key for
both encryption and decryption.
52 Biomedical Instrumentation & Technology January/February 2013
from the attacker perspective. The imple-
mentation of the strategies presented fulfills
and exceeds governmental regulations for
ePHI access and storage.
In terms of general usability principles,
the cryptographic scheme presented here
was found to be appropriate, with a time
response of less than 100ms for all major
individual blocks of key generation, encryp-
tion, and/or decryption. In addition,
although the cost of implementing this
cryptosystem adds a significant workload to
the smartphone, encryption/decryption
blocks are still under 55ms. n
References
1. RSA Laboratories. PKCS #5 v2.1: Password-Based
Cryptography Standard. October 5, 2006. Available
at: www.rsa.com/rsalabs/node.asp?id=2127.
Accessed May 15, 2012.
2. National Institute of Standards and Technology
(NIST). FIPS 197. Advanced Encryption Standard
(AES). U.S. Department of Commerce; Nov. 26,
2011.
3. Stallings W. Cryptography and Network Security
Principles and Practice. 4th ed. Upper Saddle River,
NJ: Prentice Hall, 2005.
4. Velez D, Shanblatt M. Taxonomy of Current
Medical Devices for POCT Applications and the
Potential Acceptance of Bluetooth Technology
for Secure Interoperable Applications. IEEE 13th
International Conference on e-Health Networking
Applications and Services (Healthcom). June 13-15,
2011; Columbia, MO: IEEE; 2011.
5. National Institute of Standards and Technology
(NIST) FIPS 140-2. Security Requirements for
Cryptographic Modules. U.S. Department of
Commerce; May 25, 2001.
6. Ciampa M. Security+ Guide to Network Security
Fundamentals. 3rd ed. Boston, MA: Course
Technology, 2009.
7. Sonmez Turan M, Barker E, Burr W, Chen L.
Recommendation for Password Based Key Derivation
Part 1: Storage Applications. National Institute of
Standards and Technology (NIST), 2010; SP 800-132.
 © Copyright AAMI 2013. Single user license only. Copying, networking, and distribution prohibited.
Features

8. Chen L. Recommendation for Key Derivation Using 12. Bogia DP. Supporting Personal Health Devices
Pseudorandom Functions. National Institute of through Standardization and Collaboration.
Standards and Technology (NIST), 2009; SP 800-108. e-Health Networking Applications and Services
(Healthcom), 13th IEEE International Conference.
9. Velez D, Shanblatt M. A Risk Analysis Approach
June 13-15, 2011; Columbia, MO: IEEE; 2011.
for HIPAA Compliance in Mobile Healthcare
Systems [ePoster Abstract]. 17th Annual
International Meeting and Exposition of the
American Telemedicine Association, Telemedicine
and e-Health. 2012; 18: A134; San Jose, CA:
American Telemedicine Association; 2012.

10. National Institute of Standards and Technology

(NIST) SP800-53. Recommended Security Controls
for Federal Information Systems and Organizations.
U.S. Department of Commerce; August 2009.

11. National Institute of Standards and Technology

(NIST) SP800-124 Revision 1. Guidelines for
Managing and Securing Mobile Devices in
the Enterprise (Draft). U.S. Department of
Commerce; July 2012.

AAMI’s Dialysis Collection (2013 Edition)

Just updated – This 10 document collection now includes 60601-
2013 Edition

2-16:2012, Essential performance of hemodialysis, hemodiafiltration

and hemofiltration equipment. AAMI Standards

This collection of every AAMI hemodialysis standard and guidance

Dialysis
Dialysis

document, includes seven published since 2011. Recent updates

include 11663 and 23500 (revise RD52), 13958 (revises RD61),
www.aami.org

26722 (revise RD62), 13959, and TIR43.

Standards on CD
Dialysis

Fully searchable and easy to use, the CD version also includes

important FDA and CMS guidance documents. Association for the Advancement
of Medical Instrumentation
4301 N. Fairfax Dr, Suite 301

2013
Arlington, VA 22203-1633

ISBN 1-57020-467-5 www.aami.org

CD or Book Buy Both and SAVE! For more information or to order additional copies,
call +1-877-249-8226 or +1-240-646-7031

Order Code: DSBKCD or DSBK13 Order Code: DSBK13-S

Any use of materials contained in this product—including reproduction, modification,
distribution, or republication—without the prior written consent of AAMI is strictly prohibited.
Includes Adobe Acrobat® Reader. © 1987-2011 Adobe Systems Incorporated. All rights reserved.
Adobe and Acrobat are trademarks of Adobe Systems Incorporated. 2013

List $430 / AAMI member $260 List $580 / AAMI member $380

To order, call +1-877-249-8226 or visit http://marketplace.aami.org

SOURCE CODE: PB

Biomedical Instrumentation & Technology January/February 2013 53

 © Copyright AAMI 2013. Single user license only. Copying, networking, and distribution prohibited.

Human Factors
Guidance

Standards on CD – Human Factors

NEW
This CD is your single source for Human Factors
standards and guidance documents.

Searchable and easy to use, this CD contains Standards on CD

• ANSI/AAMI HE75: 2009, Human factors Human Factors
engineering - Design of medical devices
• ANSI/AAMI/IEC 62366: 2007, Medical
devices - Application of usability
engineering to Association
medical devices
for the Advancement
• Human Factors of4301 N. Fairfax Dr, Suitearticles
Horizons
Medical Instrumentation
301

• Human Factors articles from BI&T, AAMI’s

Arlington, VA 22203-1633

www.aami.org
peer reviewed journal
• FDA guidance documents, including draft
For more information or to order additional copies,

guidance issued in June of 2011

call 1-877-249-8226 or 1-240-646-7031
Any use of materials contained in this product—including reproduction, modification,
distribution, or republication—without the prior written consent of AAMI is strictly prohibited.

• Additional resources and links

Includes Adobe Acrobat® Reader. © 1987-2011 Adobe Systems Incorporated. All rights reserved.
Adobe and Acrobat are trademarks of Adobe Systems Incorporated.

Order Code: HFCOL-CD

List $375 / AAMI member $195

Order Your Copy Today!

Call +1-877-249-8226 or visit www.aami.org/publications/standards/HF.html

SOURCE CODE: PB