Honours Project Report

Mobile Medical Records An investigation of the secure storage and transmission of medical

records on a mobile phone

Shelley-Ann Petzer

Supervised by: Sonia Berman

Category Min Max Chosen 1 Requirement Analysis and Design 0 20 15 2 Theoretical Analysis 0 25 0 3 Experiment Design and Execution 0 20 0 4 System Development and Implementation 0 15 5 5 Results, Findings and Conclusion 10 20 15 6 Aim Formulation and Background Work 10 15 15 7 Quality of Report Writing and Presentation 10 10 8 Adherence to Project Proposal and Quality of Deliverables 10 10 9 Overall general project evaluation 0 10 10 Total Marks 80 80

Department of Computer Science

University of Cape Town

2011

Abstract

In this report we investigate the concept of mobile medical records. An application that allows for both the storage and Bluetooth transmission of a medical record between a mobile phone and a computer is developed. The security of the medical record both in storage on the mobile phone and for the purposes of transmission is explored. In particular, the performance of both symmetric and asymmetric cryptographic algorithms is analysed according to their execution time, CPU usage and memory usage. We specifically measure and compare the performance of both RSA and ECC when applied to secure the Bluetooth transmission of the medical record. We find that, contrary to claims in the literature, ECC is not more efficient than RSA for the most part in this instance. We also find that the Twofish symmetric block cipher can provide both a high level of security and efficient performance, thus making it suitable for implementation on mobile devices. The results from the performance tests demonstrate that providing security for both storage and transmission of a medical record is feasible within the limitations of a mobile phone. We thus demonstrate that the development of a secure mobile medical record framework can be achieved.

i

Contents

1. INTRODUCTION................................................................................................................ 1

2. BACKGROUND .................................................................................................................. 3

2.1 Mobile devices in healthcare ................................................................................................................... 3

2.2 The use of mobile phones in developing countries ................................................................................ 3

2.3 Electronic medical records ..................................................................................................................... 4

2.4 Mobile device limitations ........................................................................................................................ 4

2.5 Security Attacks and Risks ..................................................................................................................... 5

2.6 Security Mechanisms ............................................................................................................................... 5 2.6.1 Confidentiality ...................................................................................................................................... 5 2.6.2 Authentication ....................................................................................................................................... 6 2.6.3 Integrity ................................................................................................................................................. 7

2.7 Analysis..................................................................................................................................................... 8

2.8 Conclusion ................................................................................................................................................ 8

3. DESIGN .............................................................................................................................. 10

3.1 Introduction ........................................................................................................................................... 10

3.2 System Overview ................................................................................................................................... 10

3.3 Secure Transmission ............................................................................................................................. 11 3.3.1 Transmission medium ......................................................................................................................... 11 3.3.2 Data Format......................................................................................................................................... 12 3.3.3 Security ............................................................................................................................................... 12

3.4 Device security ....................................................................................................................................... 13 3.4.1 Authentication ..................................................................................................................................... 13 3.4.2 Secure storage ..................................................................................................................................... 14

3.5 Medical records ..................................................................................................................................... 15

3.6 Performance testing ............................................................................................................................... 16 3.6.1 Asymmetric cryptography performance .............................................................................................. 16 3.6.2 Symmetric cryptography performance ................................................................................................ 20

3.7 Conclusion .............................................................................................................................................. 21

4. IMPLEMENTATION ....................................................................................................... 22

4.1 Introduction ........................................................................................................................................... 22

ii

4.2 System overview..................................................................................................................................... 22

4.3 Mobile phone specifications .................................................................................................................. 24

4.4 Security overview ................................................................................................................................... 24 4.4.1 Bouncy Castle ..................................................................................................................................... 24 4.4.2 Spongy Castle ..................................................................................................................................... 25

4.5 Login authentication ............................................................................................................................. 25

4.6 Transmission overview .......................................................................................................................... 26 4.6.1 Bluetooth communication ................................................................................................................... 26

4.7 Sending a medical record ...................................................................................................................... 29

4.8 Receiving the medical record ................................................................................................................ 32

4.9 Viewing a medical record...................................................................................................................... 34 4.9.1 Password-based encryption ................................................................................................................. 34 4.9.2 Encryption and decryption .................................................................................................................. 35

4.10 Integration .............................................................................................................................................. 37

5. EVALUATION .................................................................................................................. 38

5.1 Introduction ........................................................................................................................................... 38

5.2 Functionality tests .................................................................................................................................. 38 5.2.1 Sending the medical record from the mobile phone to the computer .................................................. 38 5.2.2 Encryption and decryption of the medical record on the mobile phone .............................................. 38

5.3 Performance tests .................................................................................................................................. 39 5.3.1 Testing tools ........................................................................................................................................ 39 5.3.2 Asymmetric cryptography performance .............................................................................................. 41 5.3.3 Symmetric cryptography performance ................................................................................................ 42

5.4 Results..................................................................................................................................................... 43 5.4.1 Functionality tests ............................................................................................................................... 43 5.4.2 Performance tests ................................................................................................................................ 44

5.5 Discussion ............................................................................................................................................... 55 5.5.1 Asymmetric cryptography performance .............................................................................................. 55 5.5.2 Symmetric cryptography performance ................................................................................................ 56

6. CONCLUSION .................................................................................................................. 58

6.1 Future work................................................................................................................................................... 59

REFERENCES ....................................................................................................................... 61

iii

List of Figures Figure 3.1: Graphical representation of the overall system flow .......................................................... 11

Figure 3.2: The security protocol that is applied when sending the medical record from the mobile phone to the computer. ..................................................................................................... 13

Figure 4.1: The tasks that are involved in the secure storage of the medical record ............................ 22

Figure 4.2: The tasks that are involved with sending the medical record from the mobile phone to the computer. .......................................................................................................................... 23

Figure 4.3: The tasks that are involved with receiving the medical record from the computer. ........... 23

Figure 4.4: Login screen (left) and toast message that appears when the password is invalid (right) .. 25

Figure 4.5: The main menu for the mobile application ......................................................................... 26

Figure 4.6: The main menu for the computer-based application. The mobile version equivalent is shown in Figure 4.5. ......................................................................................................... 29

Figure 4.7: The interface that allows the user to select an algorithm and key length for the computer (left) and the mobile application (right). .......................................................................... 29

Figure 4.8: The interface that allows the user to connect to a device that is discoverable and within range of the mobile application. ....................................................................................... 30

Figure 4.9: The pop-up window that results from the selection of Connect a device and lists the devices that are available for connection via Bluetooth for the mobile application. ........ 31

Figure 4.10: The feedback messages indicating the success of the transmission for both applications 32

Figure 4.11: The interface that allows the user to select the file to send to the mobile phone along with the choice of algorithm and key length that will be used to secure the transmission. ...... 33

Figure 4.12: The screen that appears after selecting View Record in the main menu (left) and the choice of algorithms for encrypting and decrypting the medical record once the drop down list is selected (right)............................................................................................... 34

Figure 4.13: A graphical representation of the way ECB is used to encrypt data ................................ 35

Figure 4.14: A graphical representation of the way in which CBC is used to encrypt data ................. 36

Figure 4.15: A screenshot of the medical record in XML format as it is viewed on the mobile phone. .............................................................................................................................................................. 36

Figure 5.1: Example output from the top command for the mobile application. .................................. 40

Figure 5.2: Graph showing the average execution time with standard deviation for key generation between RSA and ECC. ................................................................................................... 45

Figure 5.3: Box and Whisker plots showing outliers for ECC 256 bit (left), RSA 2048 bit (centre) and RSA 1024 bit (right). ........................................................................................................ 46

Figure 5.4: Graph showing the average execution times with standard deviation for key exchange between RSA and ECC. ................................................................................................... 47

Figure 5.5: Graph showing the average execution times with standard deviation for the digital signature between RSA and ECC. .................................................................................... 48

Figure 5.6: Graph showing the average CPU usage with standard deviation for both RSA and ECC over all the performance tasks. ......................................................................................... 49

Figure 5.7: Graph showing the average CPU usage over time between RSA 1024 bits and ECC 192 bits. ................................................................................................................................... 49

Figure 5.8: Graph showing the CPU usage over time for both RSA 2048 bits and ECC 256 bits. ...... 50

Figure 5.9: Graph showing the average memory usage with standard deviation between RSA and ECC over time for all three performance tasks. ........................................................................ 51

Figure 5.10: Graph showing the average encryption times as the medical record grows in size. ......... 52

iv

Figure 5.11: Graph showing the average decryption times as the medical record grows in size. ......... 52

Figure 5.12: Graph showing the average CPU usage with standard deviation over all of the sample medical records. ................................................................................................................ 53

Figure 5.13: Graph showing the average memory usage with standard deviation taken over all three sample medical records. ................................................................................................... 54

v

List of Tables Table 3.1: Equivalent key lengths for RSA and ECC ........................................................................... 16

Table 4.1: Summary of the chosen symmetric block ciphers. .............................................................. 37

Table 5.1: Results from the functionality test of sending the medical record from the mobile phone to the computer ..................................................................................................................... 43

Table 5.2: Results from the functionality tests for symmetric encryption and decryption ................... 44

Table 5.3: Results from the t-test conducted on the key generation execution times ........................... 45

Table 5.4: Results from the t-test conducted on the key exchange execution times ............................. 46

Table 5.5: Results from the t-test conducted on the digital signature execution times ......................... 47

Table 5.6: Results from the t-test conducted on the average CPU usage (%) measurement over time. 48

Table 5.7: Results from the t-test conducted on the average memory usage in kilobytes over time. ... 50

Table 5.8: Summary of the results of the performance tests conducted on the symmetric block ciphers. .............................................................................................................................................................. 54

1

Chapter 1

Introduction Medical records that consist of a complete patient history are vital for a doctor when it comes to making a diagnosis. This is especially relevant in the treatment and diagnosis of a dreaded disease. However in developing countries specifically, clinics in general do not have an efficient means of managing  their  patient’s  records  such  that  they are always kept up to date. This is therefore a problem when it comes to the sound diagnosis and treatment of diseases such as HIV/AIDS in developing countries. Therefore in order to ensure the correct treatment, patients require a means of managing their own medical records that will allow them to be kept up to date at all times. The use of paper-based medical records however could  lead  to  loss  or  damage  of  a  patient’s medical history.

Mobile phones have become ubiquitous and can therefore be used in this scenario to store the patient’s  medical  history  as  an  Electronic  Medical  Record  (EMR).  This  allows  for  convenient  sharing  and access to the medical record by both the patient and a medical practitioner.

There are however issues with this solution that need to be addressed. Firstly, the privacy concerns of storing a medical record on a mobile phone. Secondly, the growth of the medical record given the limited amount of memory that is available and finally, dealing with these issues given the constraints inherent in using a mobile phone.

In order to deal with these issues the project aims to investigate the use of compression and encryption on a mobile phone, as well as the performance thereof. Furthermore, we aim to investigate the transmission and storage of a medical record on a mobile phone in an attempt to demonstrate the feasibility of such an application.

The focus of this report is to investigate the following:

The transmission of the medical record between the mobile phone and a computer. This is to ensure that the medical record is kept up to date.

The performance comparison of cryptographic algorithms used for the storage of the medical record on the mobile phone as well as the transmission of the medical record. This is to ensure that the security that is implemented caters for the limitations of a mobile phone.

There has been much research done recently in the field of public key cryptography regarding the comparison between Rivest, Shamir and Adleman (RSA) and Elliptic Curve Cryptography (ECC). Although practical comparisons of these two algorithms have been performed [Gura et al. 2004; Haodong et al. 2006], the aim is to test their performance in the context of the mobile medical record framework, and more specifically when applied to secure the Bluetooth transmission.

We aim to establish, through performance testing, whether the following hypotheses are true:

1. For the same strength security, there is a significant difference in execution time between RSA and ECC.

2. For the same strength security, there is a significant difference in CPU usage between RSA and ECC.

2

3. For the same strength security, there is a significant difference in memory usage between RSA and ECC.

Furthermore, the aim is to determine the most efficient and secure algorithm for securely storing the medical record on a mobile phone. This is done by conducting performance tests on different symmetric block ciphers such as AES, Twofish and XTEA when performing encryption and decryption on various sample medical records.

This report outlines the outcome as well as the steps taken to achieve these research aims. Chapter 2 presents the background information provided by the relevant research that was conducted. This is followed by the details of the design of the system and performance tests in chapter 3. The details regarding the implementation of the system is discussed in chapter 4. The results and discussion of the data obtained is presented in chapter 5. Finally in chapter 6, the overall conclusions and findings are discussed as well as possible future extensions.

3

Chapter 2

Background 2.1 Mobile devices in healthcare Information technology and its application to healthcare has recently sparked a vast amount of research due to the opportunities that are present in this field. There have been rapid advances in cellular technologies which have paved the way for new means of managing information, specifically in healthcare. These technologies have the potential to transform aspects of information management; from the way healthcare is documented to the way it is transported and stored [Sood et al. 2008].

Mobile health (mHealth) focuses primarily on the provision of healthcare services to patients through the use of mobile devices. The one disadvantage of this technology however is the potential privacy issues that it creates, particularly with the management of sensitive medical data [Huang et al. 2010].

The current use of mobile phones in healthcare is aimed primarily at interventions based on messaging services that deliver reminders and general health information to patients. These systems have been shown to improve knowledge and health outcomes in a wide range of areas. The interventions are most beneficial in their usage to support chronic diseases, such as diabetes, that require regular management as well as advice and constant support [Krishna et al. 2009]. The use of mobile devices also extends towards applications of remote healthcare and diagnosis in rural areas as well as informative support and treatment of HIV and AIDS in these areas [Boulos et al. 2011]. Mobile devices can also be used for dosage reminders and lab results where the mobile phone is at most times only accessible by the individual to whom they relate [Patrick et al. 2008]. This however is not always the case and in the event that the device is left unattended, the control of the data that is stored on the phone could be compromised [Kaplin 2006]. If the mobile phone is linked to a healthcare service by any means, all related information should be encrypted on the device and the user authenticated using password protection.

2.2 The use of mobile phones in developing countries The use of mobile phones in Africa is far more widespread than the use of fixed line communication. Statistics show that in 2010, for every 100 people living in South Africa there were 100 mobile phone subscriptions. In contrast to this, the number of fixed telephone lines per 100 inhabitants is a mere 8 [International Telecommunications Union 2010]. This provides evidence that the access to mobile phones in resource-poor areas is more abundant than other technologies such as fixed telephones and the Internet. The main reason for this is that it costs less and is faster to implement a wireless network as opposed to a fixed line network.

The ubiquity of mobile phones in developing areas is therefore evident and its meaning and use extends beyond what is conventionally perceived as a means of communication. This diversity can therefore be harnessed, as it has been in other healthcare applications, to improve the lives of patients by allowing the secure storage of their health record on their mobile phone.

The Personal Health Record (PHR) provides a means for the patient to have full control over their medical record. One of the most appealing aspects of a PHR when it is stored on a mobile device, is the ability that it provides patients in terms of sharing their information with family and caregivers at the desired level of granularity [Cushman et al. 2010]. These records can also be stored on encrypted

4

USB devices and medical smartcards that are then carried with the patients at all times [Wright and Sittig 2007].

The storage of PHRs on a mobile device provides ease of information sharing which is particularly useful for doctor-patient communication and decision making when it comes to diagnosis.

The value of mobile PHRs is also realised in emergency situations where the need for critical medical information arises and it is often not available. This advantage is particularly beneficial to a tourist in a foreign country requiring urgent medical attention [Pagliari and Fernando 2007].

2.3 Electronic medical records Electronic Medical Records (EMRs) are becoming both a popular and vital method of tracking and storing   a   patient’s   medical   history,   particularly   in   developing   countries.   The   need   for   EMRs   is  highlighted   by   the   treatment   of   diseases   such   as   HIV/AIDS   and   TB   which   require   the   patient’s  medical history, and therefore an efficient means of storing and retrieving these records for use by medical professionals [Huang et al. 2010].

We are particularly interested in the storage of  these  EMRs  on  a  patient’s  mobile phone in the form of a PHR, thus allowing the patient to take full control of their own medical data. In developing countries, patients are often responsible for the storage and transportation of their own medical records as these do not reside in one centralised location but are often distributed amongst different clinics. This creates a challenge for medical professionals who require the complete medical record in order to make a sound diagnosis and treatment plan. The benefits that are inherent in storing a patient’s  medical  record  on  their  mobile phone are challenged by the security issues that are involved; in particular the privacy and user authentication that must be strictly monitored [Elmufti et al. 2006].

The research in this area highlights a number of interesting techniques that provide the security mechanisms needed for possible attacks on the sensitive data. There is also an attempt to cater for the constraints inherent in a mobile device. The medical record data must also exhibit granularity in order to give the patient more control over which parts of the record they wish to view or reveal to a medical professional at any time.

2.4 Mobile device limitations When developing applications for mobile devices such as mobile phones, it is important to be aware of and deal with the restrictions on the capabilities of these devices [Burgsteiner and Prietl 2008].

In particular we are interested in providing a secure mobile PHR framework that is able to handle the following mobile device restrictions [Artail et al. 2008]:

Processing power: Encryption algorithms must require only a small amount of computational resources for execution.

Storage capacity: The keys needed for encryption must exhibit a balance in terms of their strength (a larger key provides more secure encryption [Hutchison 2011]) and the amount of storage space they require. The amount of memory required by the application as a whole must also be kept to a minimum.

Limited bandwidth: The algorithms that encrypt the data and the cryptographic keys for transmission must consider the limited bandwidth that is available to a mobile phone and therefore weigh up the security services that they provide with the rate of data transfer that is required to transport the necessary keys.

5

2.5 Security Attacks and Risks A security attack is defined as any action that compromises the security of information [Hutchison 2011]. An attack can take place while the data is in transit or at rest in storage. In the case of our research, a security risk encompasses the risks that are involved in the event that the patient misplaces their mobile phone or it is lost due to theft.

Security attacks of particular interest to our research, in terms of securing data in transmission, can take the form of one of the following [Hutchison 2011]:

Interception: This is an attack on the confidentiality of the data in transit. The data is intercepted  and  the  privacy  of  the  patient’s  medical  record  is  compromised.

Modification: This is an attack on the integrity of the data as it has been intercepted and modified  before  retransmission.  The  privacy  of  the  patient’s medical record is compromised along with the risk involved in misdiagnosis given the incorrect medical history.

Fabrication: This is an attack on the authenticity of the data. The data received by the patient is not from the medical database or vice versa. Once again this creates a potential risk of misdiagnosis.

2.6 Security Mechanisms A security mechanism is defined as a mechanism that serves to provide detection and protection from a security attack [Hutchison 2011]. Of particular interest to our research are the security mechanisms presented in the literature that ensure confidentiality, integrity and authentication.

2.6.1 Confidentiality The medical record remains confidential if it is kept private from those who are not authorised to view the data. Encryption allows the record to remain concealed when it is transmitted through the network as  well  as  at  rest  in  storage  on  the  patient’s mobile phone.

Symmetric cryptography involves the use of a shared secret key between the sender and recipient that is used to encrypt and decrypt the data. This method of cryptography is commonly used to encrypt SMS data, particularly the Advanced Encryption Standard (AES) algorithm, as it demands only a small amount of computational power [Lisonek and Drahanský 2008].

The Tiny Encryption Algorithm (TEA) was designed with constrained mobile environments in mind. The implementation of TEA is simple and makes use of addition and subtraction instead of XOR operations, thus giving it a performance advantage. However due to its simplicity, the strength of the security provided by TEA has been questionable.

The key scheduling algorithm in particular is weak as it splits the key into 32 bit blocks and uses them repeatedly in successive rounds of encryption [Wheeler et al. 1995].The Extended TEA (XTEA) algorithm is said to have corrected the weaknesses of TEA but due to the simplistic nature of the algorithm still exhibit a performance advantage [Wheeler et al. 1995].

The Twofish algorithm was one of the contenders in line to be the successor to DES which was in the end awarded to AES. Twofish was designed from the very start with performance in mind, yet it offers a level of security that is comparable to AES [Schneier et al. 1998] and therefore a promising candidate for use on a mobile device.

However, the disadvantage of using symmetric cryptography is the need to exchange the secret key between the sender and receiver in a secure manner [Lisonek and Drahanský 2008].

6

Asymmetric cryptographic algorithms such as RSA make use of public and private key pairs that are used for encryption and decryption. This method of encrypting data provides more security services but requires more computational power to perform manipulations on the data in comparison to symmetric cryptographic techniques [Elbaz 2002; Lisonek and Drahanský 2008].

ECC is emerging as an attractive alternative to the traditional public key cryptosystems. ECC provides the same security strengths as RSA but has been demonstrated to require only a fraction of the computational power [Ren et al. 2010]. The reason for this lies in the smaller key size that is required for ECC in comparison to RSA. The smaller key size therefore results in faster key exchanges across the network as well as improved computational performance and reduced memory usage [Katiyar et al. 2010].

The security of asymmetric cryptosystems is based on challenging mathematical problems such as integer factorisation as well as finite field and elliptical curve logarithms. The security of RSA depends on the computational difficulty of factoring large prime numbers whereas ECC security depends on the computational difficulty of discrete logarithms. The only known method of solving this problem has an exponential run time. The lack of a sub exponential algorithm for ECC means that a small key size can be used to achieve a high level of security. The smaller key sizes result in a faster key generation and encryption time which in turn leads to increased performance of the algorithm in general [Agoyi and Seral 2010]. An example given in [Misic 2008] shows that the same security mechanisms can be achieved by using 163 bit ECC keys as one would achieve using 1024 bit RSA keys.

Another means of ensuring the confidentiality of data in transmission is presented in [Jenkin and Dymond 2002]. The method makes use of a one-time pad to encrypt and decrypt the data. The pad must be the same length as the message and consist of a random string of bits that is unique for every message that is passed. The method is shown to provide strong encryption since each pad is unique and therefore cannot fall victim to a fabrication attack. The method is also conservative in terms of computational power since the encryption is performed by applying only an exclusive or (XOR) operation to the message using the pad. The one disadvantage of this method is the storage space that it requires, given that the pad must be the same length as the message.

Encrypting and decrypting the medical record   stored   on   the   patient’s  mobile phone requires some form of authentication mechanism to ensure that the person accessing the data has permission to do so.

2.6.2 Authentication Mobile devices such as mobile phones make use of encryption in order to protect sensitive data, but the challenge does not lie in the encryption of the data but rather with the authentication of the user [Nicholson et al. 2006].

Authentication can be token-based (typically verified by a password) or biometric-based (some characteristic of the user, for example their fingerprint). Mobile devices generally make use of token-based authentication with a password or PIN which is inherently weak as it is possible to bypass using brute force password generation [Clarke and Furnell 2007]. The idea is to overlay the token-based approach with a biometric-based authentication to enhance the security service.

7

Keystroke analysis is a means of authenticating the user by their typing style. The approach makes use of two variables, namely keystroke latency and hold-time characteristic in an effort to increase the authentication security beyond the biometric-based or password-based approach [Clarke and Furnell 2007].

A possible approach in eliminating the vulnerability of a password-based authentication is to force the user to re-enter the password for decryption after a certain time lapse. This however affects the usability of the system and will result in the user disabling the security mechanism [Corner and Noble 2002].

Zero interaction authentication is a concept presented in [Corner and Noble 2002; Nicholson et al. 2006] whereby the user is only required to provide a password once for authentication. A small token is worn by the user which constantly authenticates the mobile device through a short-range wireless link. The authentication expires if the mobile device is not within range of the token and the only way authentication can take place is through the token. When the token is within range again, it authenticates the device automatically.

Granular encryption provides flexibility in terms of the user being given the authority to reveal only certain portions of their medical record to different groups of people [Gardner et al. 2009]. This requires each subdivision of data to be encrypted individually and then once again encrypted as a whole in order to ensure that users only access those divisions for which they have been granted permission [Gardner et al. 2009].

Attribute-based encryption provides a natural cryptographic tool for implementing a granular access approach. The encrypted data is associated with a set of attributes and an access structure is defined using these attributes. The access structure can be further defined by making use of the Boolean operators to classify users and their attributes [Ostrovsky et al. 2007]. An example of how this may be applied in the context of a medical record is to assign specific access rights to different parts of the record by making use of the Boolean operators. For instance aspects such as medical allergies and current drug regime might be useful to a paramedic in an emergency situation. This can be implemented   using   attributes   such   as   ‘paramedic’   along  with   the   Boolean   operators   to   specify   the  combination of data that is to be stored for that attribute.

In terms of the processing power required for a token-based authentication, mobile phones already provide this functionality with a SIM card which authenticates the user with their PIN when booting up as well as authenticating the mobile device to the mobile base station [Elbaz 2002]. Authentication of data in transmission allows the receiver to verify that the data did in fact originate from the assumed sender and was not an attempt at a fabrication attack [Elbaz 2002]. The data is encrypted by the sender using the public key of the receiver and decrypted by the receiver using their private key. The public keys are known to all in the system and are distributed by means of certificates that are verified and signed for integrity by a Certificate Authority. The receiver assumes that the data is intended for them given that they can decrypt it using their private key [Hutchison 2011].

2.6.3 Integrity The integrity of information can be verified by ensuring that the data received was in fact the data that was sent and that it has not been tampered with during transmission [Elbaz 2002].

A digital signature provides a means of integrity checking. The signature consists of a hash that is computed from the original data and then signed or encrypted using the private key of the sender. This is done to provide assurance for the receiver that the data was in fact sent by the assumed party.

8

This is based on the assumption that nobody else would have access to their private key [Hutchison 2011].  Upon  receipt  of   the  data,   the  receiver  will  decrypt   the  hash  using   the  sender’s  public  key  as  well as compute a hash of the original data and perform a comparison of the two hashed values to ensure that the data was not tampered with [Hutchison 2011].

Ensuring the integrity of the data requires the use of public key cryptography as well as the computation of a hash function. As mentioned before, ECC is an efficient public key cryptography method that requires the use of smaller keys compared to RSA [Ren et al. 2010]. By making use of this method for the digital signature, one could provide the integrity that is required within the limited bandwidth and computational power that is associated with a mobile phone.

2.7 Analysis We are interested in a security framework that will maximise the security and privacy surrounding a patient’s   medical   record   as   well   as  minimise the resources required by the mobile phone and the services that it makes use of. In order for the data that is at rest on the mobile phone to remain private it would need to be encrypted and require an authentication mechanism for protection.

The zero interaction authentication method proposed in [Corner and Noble 2002; Nicholson et al. 2006] provides a convenient and secure approach to authentication which does not require the user to enter their password on every access of the record. However, there are issues with this method in terms of the user misplacing the token or more seriously, misplacing the token along with mobile phone and ultimately compromising the privacy of their record. The user is also burdened with having to carry an additional device, as small as it may be.

Analysing the keystroke techniques of a user does provide a more secure authentication mechanism but it not only requires more computational power but also contains flaws given that a user will not always enter their password in a similar fashion [Clarke and Furnell 2007].

Since we are also interested in providing data granularity, attribute-based encryption proves to be a secure option for providing such a feature. However the storage space required for this approach will be proportional to the number of subdivisions of the data as each division requires an encryption key to be stored on the mobile phone.

The AES algorithm is not only a more secure option than that of its predecessor, DES, but also requires less computational power and is already used to encrypt SMS transmissions. This result makes AES an attractive solution for encrypting the medical record for transmission. Similarly, both Twofish and XTEA are suited for implementation on a mobile device due to their performance driven design.

The ECC public key cryptography algorithm also requires less computational power due to the smaller key size but provides the same security services as the RSA algorithm [Ren et al. 2010]. This is particularly useful for the secure transmission of a secret key when using symmetric cryptography as well as providing a digital signature for integrity purposes.

2.8 Conclusion The literature has provided several techniques that can be used toward a secure mobile medical record framework. Some ideas were more focused on maximising the security mechanisms whilst others were focused on providing mechanisms that were conservative in their use of resources. However, the ideas that were presented, for example in [Clarke and Furnell 2007; Elbaz 2002; Gardner 2009; Nicholson et al. 2006; Weerasinghe et al. 2007] made use of general security mechanisms and

9

enhanced these to cater for the strict privacy that is required for medical records as well as the limitations of a mobile phone.

We examined different techniques of providing confidentiality, authentication and integrity for data both stored on the mobile phone and in transmission. Providing data privacy and granularity was also of particular interest to our research and the literature indicated that this is possible by making use of attribute-based encryption. Encrypting the data in divisions will also be beneficial in terms of bandwidth constraints when it is only necessary to transmit a portion of the data across the network.

Furthermore, the research provided us with the knowledge that by using the ECC algorithm for public key cryptography along with the AES symmetric cryptography algorithm, we are be able to provide a high level of confidentiality, authentication and integrity security services whilst minimising the resources required by the mobile phone. These services apply to data both at rest and in transmission, and therefore provide us with a result that conforms to the initial requirements that were stated. This is further supported by the fact that there exist mobile devices that are making use of the combination of AES and ECC to perform cryptography. The data for wireless transmission is secured using AES and the symmetric key is then secured using ECC [Nie and Hu 2008].

The goal of our research would therefore be to test the hypotheses that have been put forward in the literature with regard to the most efficient cryptographic algorithms for mobile devices. This will be achieved by conducting a performance analysis on a variety of both symmetric and asymmetric cryptography algorithms in the context of their use in a mobile medical record framework. The main aim is to compare the performance of the algorithms relative to the level of security that they provide and present these findings in an attempt to contribute to future research in this field.

10

Chapter 3

Design 3.1 Introduction The purpose of this chapter is to provide details regarding the design of our proposed mobile medical record framework. The design of the overall system is presented before going into detailed descriptions of the security and transmission of the medical record which is the focus of this report. Furthermore, the objectives of the performance analysis are discussed as well as the design of the tests that were conducted.

The original idea for this project was to target low-end mobile devices by creating a system using the Java Micro Edition (J2ME) platform for development. However, recent research has revealed that Android is currently the leading smart phone platform in the world [Canalys 2011]. More specifically, statistics from the fourth quarter of 2010 show that Google were the leaders in the smart phone market with a 32.9% share. In order to create a more sustainable framework and contribution towards future research we have thus opted to develop the framework using the Android platform.

The context within which the idea for a mobile medical record arose required granular access to the medical record in its constituent parts. After discussing the idea with employees from Cell-Life, who are professionals in the field of mobile healthcare, they brought our attention to the fact that when being diagnosed by a doctor they will require the record in its entirety. Therefore, the idea of a granular medical record seemed to only have a purpose in the context of the original idea of giving the patient the control to reveal only certain parts of their medical record. To overcome this we have opted to alter the design in such a way that will allow the medical record to be viewed in separate parts on the phone but it will be transmitted to a doctor as a complete medical record.

The main focus of this section of the project is providing security for the mobile medical record framework as well as a means of securely transmitting the record  to  a  computer  in  a  clinic  or  doctor’s  room. The interface for the purposes of this project are therefore purely for the sake of testing the performance and functionality of the application and will not undergo any prototyping or user testing. A user interface for a patient or medical practitioner is beyond the scope of this project and is regarded as future work.

3.2 System Overview The system that constitutes the mobile medical record framework is separated into two sub-systems:

1. Transmission and security system which includes: The secure transmission of the record between the mobile phone and a computer. The encryption and decryption of the medical record on the mobile phone.

2. Storage and compression system which includes: The storage of the medical record on the mobile phone. The compression of the record on the mobile phone.

11

Figure 3.1: Graphical representation of the overall system flow

The compression is applied to the data before it is encrypted. This is done since the encryption results in random data and therefore the benefit gained from compression would be negligible since there are no patterns or repetition to exploit. Applying the compression first also provides more security since it removes the redundancy in the data and thus the possibility of deciphering the plaintext by recognising patterns [Allaërt 2002].

In order to find the optimum solution to both security and compression, different algorithms were implemented and measured according to their performance. The algorithms were tested in terms of the following performance measurements:

Execution time: This was measured in order to find the most efficient algorithm from the point of view of the user waiting for a response from the application.

Memory usage: This was measured in order to find the algorithm that occupies the least amount of memory for execution in order to satisfy the constraints of a mobile phone.

CPU usage: This measurement allows us to gauge which algorithm demands the most CPU time and in turn slows down the process as a whole. This is limited due to the limited processing power on a mobile phone.

3.3 Secure Transmission The medical record must be transmitted between the mobile device and a computer to allow for sharing of the data with medical practitioners. There are various aspects of the transmission that were taken into consideration. These include the transmission medium, the format of the data and the security of the communication channel.

3.3.1 Transmission medium In order to ensure that the framework is compatible with the majority of mobile phones and that it is able to deal with the possible lack of a wireless network in a clinic, Bluetooth technology was chosen.

12

The low energy consumption and high speed transmission of Bluetooth also make it suitable for the constraints of a mobile device [Bluetooth SIG 2010]. The use case for this particular framework does not require that the medical record be transmitted over large distances but rather in the context of a doctor’s  room.  The  short  range of Bluetooth (1-100m) is therefore not a limiting factor.

3.3.2 Data Format The medical record must be transmitted between the mobile device and the computer and therefore needs to be in a format that is both platform independent and preserves the original structure of the data. Extensible Markup Language (XML) was chosen to fulfil this purpose due to its structural properties that make it suitable for transportation between all types of devices. The tags in the XML document will also allow the file to be parsed and specific data to be extracted for when it is viewed in separate parts. This will also then pave the way for further extensions that can be implemented whereby a patient database is created with tables and columns that map to the XML tags.

3.3.3 Security In order to ensure that the privacy of the medical record is not compromised, the communication channel must be secured. The required security was achieved through the use of both symmetric and asymmetric encryption. The aim was to test the performance of the asymmetric algorithms once the communication channel was implemented. The medical record was encrypted for transmission using a symmetric encryption algorithm, namely AES. The secret key used for the symmetric encryption is then sent to the computer with the use of an asymmetric encryption algorithm such as RSA and the performance of this task was measured.

Once a Bluetooth connection has been established between the two parties, the secret key is distributed securely through the use of public key cryptography. The medical record is then encrypted using the secret key. The use of asymmetric encryption algorithms for large data sets is infeasible due to the large key sizes (1024 bits for RSA) which results in poor performance. This makes it suitable only for the distribution of the small secret symmetric key which can then be used to encrypt the large data sets more efficiently.

In the event that the medical record is sent from the mobile phone to the computer, the following is a list of consecutive events that were implemented:

1. Establish a Bluetooth connection. 2. The computer and mobile phone exchange public keys. 3. The secret key is encrypted  using  the  computer’s  public key and sent to the computer. 4. The computer decrypts the secret key using its private key. 5. The mobile phone uses the secret key to encrypt the medical record for transmission and

sends the encrypted record to the computer. 6. In order for the computer to verify the integrity of the record, a digital signature is sent along

with the encrypted record. The digital signature is made up of a hash of the medical record which is then encrypted using the mobile phone’s  private  key.

7. Upon receiving the data, the computer decrypts the medical record using the secret key. The digital signature is then decrypted using the mobile phone’s  public  key  to  reveal  the  hashed  data.

8. The medical record is then hashed and compared to the outcome of decrypting the digital signature in order to verify that the integrity of the medical record has not been compromised.

9. The computer then sends a Boolean value to the mobile phone providing information as to whether the record was received successfully or not.

13

A more concise graphical version of this protocol is detailed below.

Figure 3.2: The security protocol that is applied when sending the medical record from the mobile phone to the computer.

3.4 Device security A mobile phone is regarded as a personal and individual device yet in some cases it is shared amongst family members and often not in the hands of the owner. The device can also be misplaced or stolen, thus resulting in the loss of private medical data.

In order to ensure that the medical record is not compromised under these circumstances, the data must be encrypted before it is stored. The framework also needs to cater for the fact that the mobile phone is not necessarily an individual device by providing a means of authenticating the user to ensure that only the patient is able to view their medical record.

3.4.1 Authentication A token-based authentication interface was implemented in order to protect the medical record by prompting the user for a password. The research in this area showed that a combination of both token-based and biometric-based authentication would provide the optimum security. The implementation of a biometric-based authentication such as facial or fingerprint recognition is out of the scope of this project and may also affect the usability of the system if it is not accurately designed. Users are also familiar with the process of password-based authentication and therefore it is a more user-friendly option.

The user will be required to enter their password in order to access and view their medical record. When launching the application, the user will be prompted with a login screen where they will be prompted to enter their password.

14

Once the user has selected the login option, their password will be validated against the password that is stored on the phone. The password will be stored as a hash in an attempt to ensure its security and consequently the security of the medical record. A hash is a one way function and therefore it is not possible to derive the password from the hash itself which therefore makes it secure. The verification process therefore requires the input password to be hashed first before it is compared to the stored password.

In the event that the password verification is successful, the user will then be presented with a menu consisting of the following three options:

View their medical record Send their medical record to a Bluetooth enabled computer Receive their medical record from a Bluetooth enabled computer

3.4.2 Secure storage The medical record data must be encrypted after compression and before it is stored on the mobile phone in order to provide confidentiality in the event that the phone is misplaced or the data is copied from the memory card. Symmetric encryption will enable the data to be securely stored and more specifically by making use of a key that is generated from the authenticated password.

Password-based encryption Password-based encryption (PBE) makes use of the password to generate a key that will then serve to encrypt and decrypt the data in storage. The main drawback of PBE is that it is vulnerable to dictionary attacks. This is a brute means of trying to guess the password used for encryption by essentially using a dictionary of all possible passwords. There is however a conflict between the user’s  requirements  and  the  strength  of  the  security  that  is  needed.  When  choosing  a  password, people often select one that is short and easy enough to remember yet by security standards, a key of at least 128 random bits is required.

In order to overcome this conflict and provide a secure enough key without forcing users to remember long passphrases, PBE combines the password with a random sequence of bits called a salt. The password is thus appended with the salt before the key is generated and therefore avoids the possibility of the system succumbing to a dictionary attack.

A secure hash function which randomly maps data to an integer is then applied to the password and appended salt. This process is then repeated whereby the salt is appended to the output which is then hashed again. The number of times that this is repeated is referred to as the iteration count and is only considered secure if it performed at least 1000 times.

Once the key has been generated, the data can be encrypted for storage and decrypted when viewed by the user using a symmetric encryption algorithm. The reason why this method was chosen is that it is more secure to store the hashed password and generate the key each time than store the key itself which would then be accessed and used to decrypt the data. The salt value also provides security in the form of randomness and protects against an attacker possibly generating the correct key from the stored password.

The key that is generated using password-based encryption is only for the purpose of securing the medical record at rest on the cell phone. In the event that the medical record is shared via Bluetooth transmission, a new secret key will be generated for the purposes of securing the record for that communication session alone. Thereafter, the secret session key will be destroyed. The reason for this

15

is that it is not advisable to share a key that is being used to encrypt all the data at rest on the phone as this  could  result  in  a  security  attack  and  ultimately  compromise  the  patient’s  privacy.

3.5 Medical records In order for the system to be tested effectively it needs to be done in the context of a real world situation whereby actual examples of medical records are used. The aim is to also have medical records of varying sizes in order to test the performance of the algorithms as the size of the record increases. However due to patient privacy issues and the general lack of electronic medical records, obtaining actual patient records has not been feasible.

Since this was one of the risks that were identified from the start, there were mitigation plans in place in the event that no real medical data could be obtained.

Two sample PHRs were then sourced from Records for Living [HealthFrame 2011], a website that provides personal health management. The PHRs are in XML format and serve as an example of the service that they provide to patients in need of EMRs.

The two PHRs represent medical data for a middle-aged diabetic man, and a young mother. The minimum aim however was to source three medical records of varying sizes, with the largest record having a size of over one megabyte for performance testing purposes. The third record was then generated by extending various aspects of the record for the young mother using anonymised medical data obtained from research being done at a hospital.

The basic structure of the PHRs is as follows:

Personal Information o Name o Surname o Gender o Hair Colour o Eye Colour o Blood type o Birth information o Location o Contact information o ID number

Emergency Contact Information o Name o Surname o Contact Information o Relationship

Medication o Type o Name o Dosage o Period of administration

16

Tests o Vital signs o Blood o Glucose o Blood Pressure o Weight

Allergies Conditions Treatments Immunisations Medical Aid information Details regarding Doctor visits Names of all physicians consulted in the past

3.6 Performance testing The primary goal behind the performance testing aspect of this project is to analyse the performance of the encryption algorithms that are used relative to the strength of security that they provide. The aim is that the results from the performance testing will provide insight into the best algorithms to use for the medical record framework.

The testing was performed on the algorithms used to secure the medical record stored on the phone as well as the algorithms used to secure the transmission of the record. Before the performance testing could take place, the system was also subjected to a series of functionality tests to ensure that the algorithms are in fact producing the correct output.

3.6.1 Asymmetric cryptography performance The goal behind these tests was to analyse the performance of two public key cryptography algorithms, namely RSA and ECC. The research in this field claims that for much smaller key sizes, ECC is able to provide the same strength security as RSA but at a fraction of the computational power and execution time.

The claim is that a 163 bit ECC key is equivalent to a 1024 bit RSA key in terms of the security that it provides. The performance tests therefore make comparisons according to these claims and attempt to provide more insight into the most suitable public key cryptography algorithm for a mobile framework given its limitations. The tests were conducted with respect to a number of tasks that are performed on the mobile device.

The following table represents the recommended comparative key lengths for RSA and ECC used in software implementations [Katiyar et al. 2010]. Note that the 163 bit key is replaced with a 192 bit key as this is the key length that was recommended by NIST for software implementations of ECC.

Table 3.1: Equivalent key lengths for RSA and ECC

RSA ECC 1024 192 2048 256

17

Performance tasks

Key generation The key generation is an important part of public key cryptography. ECC requires a much smaller key to perform the same task but the complexity lies in the way the key is created and thus could be computationally intensive. The algorithms were tested on their performance when generating keys and compared according to the equivalence claims that are stated in the literature. The following is a description of how both algorithms generate their key pairs.

RSA key generation RSA is a public key cryptographic algorithm that makes use of a public and private key pair, one to encrypt and the other is used to decrypt. RSA is typically used in conjunction with symmetric cryptography as a means of securely distributing the secret key for further communication. The security of RSA relies on the discrete logarithm problem. The algorithm is a block cipher and the keys are generated as follows [Hutchison, 2011]:

1. Two distinct large primes of approximately equal length, p and q, are multiplied together to produce n, the modulus. The key size specified for RSA usually refers to the size of the modulus.

2. A number, e, is then chosen which is less than n and relatively prime to (p-1)(q-1). This means that e and (p-1)(q-1) have no common factors except one.

3. Another number, d, is found such that (ed-1) is divisible by (p-1)(q-1). 4. The value e is known as the public exponent and the value d is known as the private

exponent. 5. The public key pair is then (n, e) and the private key is (n, d)

Obtaining the private key from the public key is currently a difficult task as it relies on integer factorisation which is not feasible with the computational ability of current processors.

ECC key generation The strength of ECC relies on the difficulty of the ECDL problem. Let P and Q be two points on an elliptic curve such that kP = Q for some scalar k. Given P and Q, it is computationally infeasible to obtain k if it is sufficiently large since k is the discrete logarithm of Q to the base P [Hankerson et al. 2004].

The operations performed on the elliptic curve are defined over two finite fields, namely the Prime field (Fp) and the Binary field (F2

m). The Prime field is more suited for use in software implementations such as this due to the fact that integer arithmetic is more optimised on current processors [Neustadter and St. Denis 2008].

Before a secure communication can take place between two parties using ECC, there are domain parameters that must be agreed upon. The domain parameters for a Prime field consist of the following [MS 2004]:

o p is the prime number defined for the finite prime field. o a and b are the parameters used to define the elliptical curve (y2 + xy = x3 + ax + b

mod p). o G is the generator which is a point on the curve that is chosen for cryptographic

operations. o n is the order of the elliptic curve i.e. the number of elements within the group.

18

o h is the cofactor which is equal to (the number of points on the elliptic curve / n)

ECC keys are generated from the elliptic curve as follows [Hankerson et al. 2004]:

1. Let E be the elliptic curve defined over the finite field Fp where p is a prime number and let P be the point on the elliptic curve that has prime order n.

2. Select d randomly from [1, n-1] where d is the private key. 3. Compute public key Q = dG.

Key exchange The purpose of public key cryptography in this project and in most cases is to securely distribute a secret key that can be used to encrypt all further data transmission. The algorithms must therefore be tested on their performance when exchanging this key between the computer and phone, and in particular how long this transfer takes.

RSA makes use of a public and private key pair to perform this task whereas ECC makes use of the Elliptic Curve Diffie Hellman (ECDH) key exchange whereby the secret key itself is not exchanged but rather the ingredients that are needed to create it.

RSA key exchange The key exchange protocol used for the RSA implementation requires that the sender of the medical  record  create  the  secret  key  and  then  encrypt  it  using  the  recipient’s  public  key  before  sending it across the Bluetooth connection. In the event that the cell phone is sending the medical record to the computer, the following steps are taken in order to share the secret key:

1. Both parties exchange their RSA public keys. 2. The mobile phone generates the secret key. 3. The mobile phone  then  encrypts  the  secret  key  using  the  computer’s  public  key  and  

sends the encrypted key to the computer. 4. The computer decrypts the secret key using its private key. Both parties now share a

secret key.

ECC key exchange The Spongy Castle library implements the ECDH key agreement algorithm for the exchange of secret keys. Generating a shared secret between two parties requires that both have already agreed upon the domain parameters. Both parties thus have a key pair consisting of a private key (d) and a public key (Q). Let (dA , QA) be the private and public key pair of A and (dB , QB) be the private and public key pair of B. The secret is then generated as follows [MS 2004]:

1. A computes K = (XK , YK) = dA * QB 2. B computers L = (XL , YL) = dB * QA 3. Since dAQB = dAdBG = dBdBG = dBQA we have K = L and therefore XK = XL 4. The shared secret is therefore XK

19

The security of this protocol depends on the discrete logarithm problem and the fact that it is computationally infeasible to determine the private key from the public key and the products K and L.

Digital signature The purpose of the digital signature is to ensure integrity of the data that is sent across the Bluetooth channel. This was initially not considered to be a necessary part of the performance testing since encrypting a hash is comparable to encrypting the secret key for the key exchange. However since RSA and ECC differ in their implementation and the way in which the digital signature is distributed to the computer, testing this aspect will provide a more thorough evaluation of the algorithms.

The algorithms were thus analysed according to their ability to generate the digital signature on the mobile phone and send it to the computer. Since the output of a hash function has a fixed length it will not be necessary to analyse the performance of this task with the growth of the medical record and therefore this test was only conducted on the largest sample medical record.

RSA digital signature The RSA digital signature makes use of the public and private key pair in order to perform the encryption and decryption for creating and verifying the signature. The digital signature is created as follows:

1. Create H = Hash (medical record) 2. Sign the hashed data (H) using the private key of the sender: D = Encrypt(KRA , H)

The signature is then verified by the recipient as follows:

1. Create  H’  =  Hash (received medical record) 2. Decrypt the  digital  signature  using  the  sender’s  public  key:  Decrypt(KUA , H) 3. Compare  H  to  H’  and  if  they  are  equal  then  the  signature  is  valid.

The hash is created using the Secure Hash Algorithm (SHA) with a size of 256 bits. SHA-256 is a member of the set of SHA-2 cryptographic hash functions. SHA was chosen for the simple reason that is has been proven to be more secure than the Message-digest algorithm (MD5) which is prone to collision attacks whereby two distinct messages are hashed to the same value.

The hash is encrypted using the private key in order to verify that the message is in fact coming  from  the  sender,  given   that   the  hash  can  be  decrypted  with   the  sender’s  public  key.  This is based on the assumption that only the sender has access to their private key. This is also why collision attacks are a threat since the hash is not sent securely it can be accessed by an attacker and replaced with a different message that hashes to the same value.

ECC digital signature The Elliptic Curve Digital Signature Algorithm (ECDSA) is a variant of the Digital Signature Algorithm (DSA) that applies to elliptic curve groups. Before two parties can exchange any information, the elliptic curve domain parameters must first be agreed upon. The protocol for signature generation consists of the following [MS 2004]:

20

1. Calculate e = Hash (medical record) 2. Select a random integer k in the range [1, n-1] 3. Calculate r = x1 (mod n) and if r = 0 then return to step 2 4. Calculate s = k-1(e + dAr) (mod n) and if s = 0 then return to step 2 5. The signature is then the pair (r, s)

In   order   to   verify   the   signature,   the   recipient  must   have   the   sender’s   public   key   (QA)   and  perform the following [MS 2004]:

1. Verify that both r and s are integers in the range [1, n-1] and if this is not the case, the signature is considered invalid.

2. Calculate a hash of the received medical record 3. Calculate w = s-1(mod n) 4. Calculate u1 = ew (mod n) and u2 = rw (mod n) 5. Calculate (x1, y1) = u1G + u2QA 6. The signature is then considered to be valid if x1 = r (mod n)

In the event that both r and a are continuously equal to zero during the creation of the signature, the execution time for this task could take substantially longer than the RSA implementation.

Performance parameters

Key length The only parameter that will be adjusted for these tests is the length of the keys that are generated and used to exchange the secret key.

3.6.2 Symmetric cryptography performance Password-based encryption was used to generate a key for a specific symmetric encryption algorithm to secure the stored medical record. The encryption for these tests was performed on the compressed data, as it would be done in the context of the actual framework. The aim was to perform the tests on the following symmetric encryption algorithms:

AES: AES is the algorithm of choice in terms of the level of security that it provides since it is a standard recommended by NIST. The aim is to determine the computational resources required to provide this level of security.

AESLight: This is a Bouncy Castle specific implementation of an optimised version of AES that is said to weigh up a longer execution time with a more conservative use of memory.

AESFast: This is another Bouncy Castle specific implementation of an optimised version of AES that is said to be the fastest of the three AES variants due to pre-computation that uses more memory but reduces the execution time.

Twofish: This algorithm was designed with performance in mine and provides a level of security that is on par with AES. Twofish therefore in theory exhibits the best of both worlds in this situation and thus it would be interesting to see if this holds in practice.

XTEA: This is the successor to the TEA algorithm that overcomes the weaknesses of TEA in terms of key scheduling without degrading its performance.

21

Performance tasks The aim was to analyse the performance of the above algorithms with regard to their ability to encrypt and decrypt the medical record as it grows in size. For each algorithm that was tested, there are two input parameters that were be adjusted in an attempt to conduct a thorough performance analysis.

Performance parameters

Input size This parameter was adjusted in order to analyse how much the performance of each algorithm degenerates as the medical record grows. The medical records that have been sourced are 517, 817 and 1055 kilobytes in size and decrease to 247, 578 and 782 kilobytes in size respectively. The medical records are compressed only for the purposes of storage on the mobile phone due to the memory limitations on a mobile phone.

Key length Several of the above mentioned algorithms have a fixed key length whilst others have a range of key lengths that can be chosen from. Since the aim is to weigh up the strength of the security in relation to the performance of the algorithm, the largest key length for all algorithms was chosen. This will then ensure that we are testing the performance of the algorithm given the highest level of security that it can achieve.

3.7 Conclusion This chapter served as a means to describe the overall design of the system and give a high level overview of the transmission and security sub-system. This included a description of the design for a secure transmission protocol, secure storage of the medical record, and performance tests. The challenges that were encountered during this phase as well as the ways in which they were overcome were also discussed. The details regarding how this design was executed is outlined in the implementation chapter.

22

Chapter 4

Implementation 4.1 Introduction The main goal of this chapter is to provide details regarding the way in which the system that is specified in the design chapter was executed. The challenges that were encountered during the implementation phase are discussed as well as the ways in which these were overcome.

The software artefact that was implemented merely serves as a basis upon which the necessary functionality and performance tests can be conducted. The core functionality of the system was implemented on the mobile phone; however a computer-based solution was also developed for the purposes of implementing the Bluetooth transmission of the medical record.

4.2 System overview The transmission and security system can be split into two separate parts:

1. The secure storage of the medical record on the mobile phone, which involves the following: Login authentication Encryption of the medical record for storage Decryption of the medical record for viewing on the mobile phone and before it can

be secured for transmission.

Figure 4.1: The tasks that are involved in the secure storage of the medical record

23

2. The transmission of the medical record between the mobile phone and a computer, which involves the following:

Establishing a Bluetooth connection between the computer and the mobile phone. Decrypting the medical record from storage. Encrypting the medical record for transmission. Creating a computer-based and mobile-based application to handle the use cases of

sending and receiving a medical record on both the computer and mobile phone.

Figure 4.2: The tasks that are involved with sending the medical record from the mobile phone to the computer.

Figure 4.3: The tasks that are involved with receiving the medical record from the computer.

24

Although the system is described here as two separate entities, the transmission of the medical record relies on secure storage module to encrypt the record for storage when it is received from the computer as well as decrypt the record that is in storage before it can be secured for transmission to the computer.

For this reason, the implementation will be described in terms of the use cases of the mobile application, namely viewing, sending and receiving the medical record.

4.3 Mobile phone specifications The mobile phone that was chosen for the development of this system is the Huawei Ideos U8150 running Android 2.2. This device is an affordable, entry level Android phone aimed at making smartphones more accessible. Since the original aim of this project was to target low end devices as well as create a more sustainable design for the purposes of future research, the Ideos is the perfect choice that meets both of these requirements.

4.4 Security overview The security that was used for the transmission of the record was provided by a combination of both symmetric and asymmetric cryptography. Since this is the basis upon which the asymmetric encryption performance testing between RSA and ECC took place, the symmetric algorithm which was used to encrypt the medical record therefore remained fixed.

The symmetric encryption of the medical record for transmission was performed by AES due to the fact that it is approved and accepted by the National Institute of Standards and Technology (NIST). AES is also a Federal Information Processing Standards (FIPS) approved cryptographic algorithm that is trusted to secure classified information [NIST 2001]. This evidence provides a sense of confidence in its use for the purposes of securing the record for transmission.

The asymmetric algorithms, namely RSA and ECC, were tested in terms of their performance when creating key pairs, exchanging secret keys, as well as the creation and exchange of digital signatures. These two algorithms have been chosen due to claims that currently exist in the literature regarding the strength of security provided by ECC with key lengths that are a fraction of the size of those used by RSA. Due to the constraints inherent in a mobile device, the aim is to determine whether ECC would be a more suitable option for securing the medical record during transmission. More specifically, how do the algorithms compare in the context of the mobile application and their usage for Bluetooth transmission of data.

The security required for storage of the medical record was tested according to the performance of the encryption and decryption of the medical record. There are five symmetric algorithms that have been chosen for comparison, and once again, a practical comparison of these algorithms will be useful for future research in the field of cryptography on mobile devices.

The Java Cryptographic Extension (JCE) does not unfortunately provide the necessary functionality or choice of algorithms that were required and therefore supplementary cryptographic libraries were sourced.

4.4.1 Bouncy Castle The Legion of Bouncy Castle [Bouncy Castle 2011] is a lightweight cryptographic API that serves as a provider for the JCE. Bouncy Castle is suitable for use in mobile applications due to its lightweight API and provision of more options and algorithms than the JCE. This library provided more choice

25

for both securing the Bluetooth communication channel as well as security for authentication and storage on the mobile phone.

4.4.2 Spongy Castle The Android API comes standard with a more compact version of the Bouncy Castle API due to size constraints of a mobile phone. They have therefore included the more commonly used classes and omitted ones such as those required for the implementation of ECC. The problem with this is that since it is already included, adding a more updated and complete version of Bouncy Castle to the application results in classpath conflicts.

In order to overcome this issue, as it seems many other developers are experiencing this problem, someone has created the Spongy Castle library [Tyley 2011]. This is a full version of the Bouncy Castle library that can be used in Android development without any conflicts.

4.5 Login authentication In order to protect the medical record that is stored on the mobile phone, the user is required to login into the application using their password before they can gain access to or manipulate their medical record. For the purposes of this project, it has been assumed that the user has registered by selecting an appropriately secure password for future use when logging in.

A hash of this chosen password is then computed using an algorithm from the Secure Hashing Algorithm (SHA) series, namely SHA-256  and  stored  on  the  mobile  phone’s  microSD card.

The user enters their registered password and upon selecting the Login button, the system verifies whether or not the password is correct. In order to do so, the entered password is extracted from the text field and hashed before it is compared to the password stored on the mobile phone. In the event that the passwords do not match, the user is presented with an Android toast message notifying them that their login was unsuccessful. The password text field as well as the variable representing the password are set to null thus allowing the user another login attempt.

Figure 4.4: Login screen (left) and toast message that appears when the password is invalid (right)

Verified == false

26

The number of login attempts should be restricted to avoid attackers from guessing the password. Ideally a security question that only the user knows the answer to should be implemented which is then triggered on the third unsuccessful login attempt. However this is beyond the scope of this project and it is therefore assumed that the number of failed login attempts is never more than three.

In the event that the passwords match and the login is successful, the password text field is set to null and the user is presented with a menu.

The menu presents the user with three options:

View their medical record Send their medical record to a computer in a clinic, allowing their doctor to view it before

making a diagnosis. Receive an updated version of their medical record from a computer after a visit to the clinic.

Figure 4.5: The main menu for the mobile application

4.6 Transmission overview The sending and receiving of the medical record that was implemented on the mobile phone both involve secure transmission over a Bluetooth connection and therefore share a few common operations. This section serves to describe the implementation of these operations and then go into detail regarding the specifics between sending and receiving the medical record on the mobile phone.

4.6.1 Bluetooth communication The transmission medium that was chosen, as discussed in the design chapter, is Bluetooth. The secure transmission of the medical record was developed in iterations. The first iteration involved the establishment of a Bluetooth connection between the computer and the mobile phone and the last iteration involved the two way exchange of the record.

The Android SDK provides a Bluetooth class for developing Bluetooth applications as well as an example Bluetooth chat application for use between two Android mobile phones.

27

A library by the name of BlueCove [BlueCove 2011] was used for the implementation of Bluetooth communication on the computer. The first goal of this section was to establish a Bluetooth connection between the mobile phone and the computer by adapting the Android Bluetooth Chat application to connect to a computer and making use of the necessary methods in the BlueCove library to connect to the mobile phone.

Establishing a connection For the sake of simplicity, the computer-based application was programmed to always function as the server for both the sending and receiving of the medical record. This implies that the computer application must always be initialised first in order for the mobile application to recognise it when it is initialised. The computer sets its local Bluetooth device into discoverable mode and listens for any incoming connections from other devices that are within its range.

Both applications share a value known as a Universally Unique Identifier (UUID) which is a unique 128 bit string identification value that is used to uniquely identify the Bluetooth service of a specific application. The two applications therefore share the same UUID which allows them to communicate over a Bluetooth connection.

The mobile application always serves as a client and therefore searches for a list of available devices that are within range. Once all of the devices have been found, the target device can be chosen from the list. In order to connect to the chosen device, the mobile application must initialise a Bluetooth socket through the use of the local Bluetooth device on the mobile phone. In order to access the Bluetooth device on an Android phone, the following permissions must be added to the AndroidManifest.xml file:

android.permission.BLUETOOTH_ADMIN android.permission.BLUETOOTH

The Bluetooth socket that is used to connect to the computer is initialised using the same UUID that is used by the computer. The mobile application first verifies that both UUIDs match before performing the connection and creating the Radio Frequency Communication (RFCOMM) channel that will be used for the transfer of data.

RFCOMM was chosen since it is the simplest communication protocol that is defined as part of the Bluetooth protocol stack. It is also defined to be suited to stream simple binary [Bluetooth SIG 2010] which makes it a suitable choice since the medical record is encrypted to a byte format.

Upon receiving the request for connection from the mobile application, the computer accepts the connection and once the UUIDs are verified, it opens a stream connection which allows communication to take place via the sockets.

Once the connection was established, the goal was to send plaintext messages between the two devices using input and output streams connected to the sockets. The next step was then to secure the communication channel by performing the necessary key exchanges and encryption procedures that were outlined in the design chapter. This implementation was then scaled to cater for the transmission of larger sets of data by testing it with the sample medical records.

28

Data transfer The following section outlines the iterations that were involved from when a Bluetooth connection was established between the two devices up until the transmission of an encrypted medical record.

1. Sending a plaintext message In the event that the mobile phone was sending a string to the computer, the string was input using   the   phone’s   keypad.  The   string  was   then   sent  via   the   output   stream   to   the  Bluetooth  socket connected to the computer  and  then  through  the  computer’s  input  stream.  The  message  was then output to the console in order to verify that the data was received correctly. The next step was then to secure the communication channel to prevent any security attacks on the data.

2. Encrypting the plaintext message As described in the design chapter, the encryption for communication needed to make use of both symmetric and asymmetric cryptography. Given that the plaintext message was sent successfully, this step involved applying the necessary encryption functions in order to secure the transmission of the message. The full details regarding the security protocol between the mobile phone and the computer for both sending and receiving is detailed in section 3.7 and 3.8 respectively. Once this iteration was successfully implemented, the encryption could be applied to the transmission of a medical record.

3. Scaling the implementation Given that the message was sent successfully and securely across the Bluetooth channel, the next goal was then to test this implementation on larger data sets such as the sample medical records. The encryption on the larger data proved to be successful due to the fact that the symmetric algorithm used to secure the record for transmission, AES, is a block cipher and thus encrypts the input data in separate blocks, regardless of its total size. There was a problem however with the amount of data that was sent over the Bluetooth channel, and with the larger medical records only a portion of the data was received. This was however initially understood to be a problem with the decryption since the algorithm could not process the data correctly having not received all of it and thus output a cryptographic error. This actual problem was identified, after a series of checks, by sending a plaintext version of the record to test whether the entire record was received. Upon realisation that this was the problem, it was overcome by sending the record in smaller, more manageable blocks to avoid a backlog from occurring between the sockets on either side. The problem could have been avoided if the transmission of the sample medical records was tested before the communication channel was secured.

The next step involves the explanation of the protocol that was involved in both sending the medical record from the mobile phone and receiving the medical record from the computer.

29

4.7 Sending a medical record This section serves to detail the protocol that was implemented when the mobile phone sends a medical record to the computer. As stated previously, the computer always functions as the server during communication and must therefore be initialised first. The following is the main user interface for the computer-based application:

Figure 4.6: The main menu for the computer-based application. The mobile version equivalent is shown in Figure 4.5.

The interface is simple and the options are clear. The user can either send a medical record to the mobile phone or receive a medical record from the mobile phone. In this case, the computer is receiving the medical record and therefore the Receive record button is selected.

Figure 4.7: The interface that allows the user to select an algorithm and key length for the computer (left) and the mobile application (right).

The user can then select an algorithm between RSA and ECC as well as a key length that will be used to secure the transmission. The choices of key length for RSA are 1024 and 2048 bits, and between either 192 or 256 bits for ECC. The main purpose of this choice was for the convenience of performance testing and also to cater for the possibility that the tests need to be repeated in future.

30

These menu options may however be removed from the application entirely and replaced with the most appropriate choice that results from the evaluation of the performance tests.

Upon selecting the Proceed button (in the case of the mobile phone) and the Receive button (on the computer), the chosen algorithm and key length are extracted from the drop-down menus and stored in variables for further use in the application.

The next step is to establish a Bluetooth connection between the mobile phone and the computer. Since the computer always functions as a server, once the Receive button is selected, Bluetooth is enabled and the computer is set to discoverable mode. There are therefore no interface events required for the computer. However, the mobile application requires input from the user in order to connect to the computer via Bluetooth.

Figure 4.8: The interface that allows the user to connect to a device that is discoverable and within range of the mobile application.

The Make discoverable option places the mobile in discoverable mode, allowing it to be seen by other Bluetooth enabled devices that are within range. Since the mobile phone always acts as a client, the only purpose of this button was for the initial pairing of the computer with the mobile phone.

The process of pairing two Bluetooth devices involves establishing a shared secret link key which enables them to recognise each other without having to scan all the devices that are within range [Bluetooth SIG 2010]. Pairing also increases the security of the Bluetooth communication in the event that an attacker sets their device name to be the same as the computer in a clinic and the medical record is then sent their way. If the devices are paired, they have already been authenticated and will therefore be recognised for selection by the application.

31

The Connect a device button allows the user to connect to a paired device or scan for other devices within range:

Figure 4.9: The pop-up window that results from the selection of Connect a device and lists the devices that are available for connection via Bluetooth for the mobile application.

The list of paired devices shows the names of all paired devices along with their corresponding Bluetooth hardware address. Upon selecting the computer that the user wishes to communicate with (for the purposes of this project it is Shelley-PC), a Bluetooth connection is established if the computer’s  Bluetooth  is  enabled  and  in  discovery  mode  listening  for  incoming  requests.  

In the event that the Bluetooth is disabled, an Android toast message will appear informing the user that they are unable to connect, and then allows them to try again. Once the devices are connected via Bluetooth, the transmission of the medical record between the mobile phone and the computer can take place. The protocol that was implemented for this purpose is as follows:

1. The record is retrieved in encrypted format from memory on the mobile phone. 2. It is then decrypted using PBE and the appropriate symmetric algorithm and corresponding

key  generated  from  the  user’s  password. 3. The record is now ready to be secured and sent to the computer. 4. Both devices generate their own public and private key pairs for either RSA or ECC. 5. The computer and mobile phone exchange public keys. 6. The secret key is then generated and encrypted by the mobile phone using   the   computer’s  

public key and sent to the computer. 7. The computer then decrypts the secret key using its private key. 8. The mobile phone uses the secret key to encrypt the medical record for transmission and

sends the encrypted record to the computer. 9. In order for the computer to verify the integrity of the record, a digital signature is sent along

with the encrypted record. The digital signature is made up of a hash of the medical record which is then encrypted using the  mobile  phone’s  private  key.

32

10. Upon receiving the data, the computer decrypts the medical record using the secret key. The digital  signature  is  then  decrypted  using  the  mobile  phone’s  public  key  to  reveal  the  hashed  data.

11. The medical record is then hashed and compared to the outcome of decrypting the digital signature in order to verify that the integrity of the medical record has not been compromised.

12. The computer then sends a Boolean value to the mobile phone providing information as to whether the record was received successfully or not.

Once the medical record is received on the computer, it is written to a file for storage. Both the computer and mobile applications then update their user interface regarding the success of the transmission.

Figure 4.10: The feedback messages indicating the success of the transmission for both applications

Alternatively if the transmission is not successful then error messages are displayed informing the user to try again.

4.8 Receiving the medical record This section serves to describe the protocol that takes place in the event that the mobile phone receives a medical record from the computer.

In terms of the user interface for both applications, the mobile application remains the same. The interface for the computer when selecting the Send record button is shown in Figure 4.11.

Medical record sent successfully!

33

Figure 4.11: The interface that allows the user to select the file to send to the mobile phone along with the choice of algorithm and key length that will be used to secure the transmission.

The Browse button allows the user to select a file for sending by invoking a pop-up window containing a file manager listing all the directories and files present on the computer. The algorithm selection is the same as it was for the receive event and thus selecting the Send button will merely update the interface to tell the user that the record is in the process of sending.

The following protocol was implemented for the secure transmission of the medical record from the computer to the mobile phone:

1. The application reads in the data from the chosen medical record file. 2. Both devices generate their own public and private key pairs for either RSA or ECC. 3. The computer and mobile phone exchange public keys. 4. The secret key is then generate and encrypted on the computer using   the   mobile   phone’s  

public key and sent to the mobile phone. 5. The mobile phone then decrypts the secret key using its private key. 6. The computer uses the secret key to encrypt the medical record for transmission and sends the

encrypted record to the mobile phone. 7. In order for the mobile phone to verify the integrity of the record, a digital signature is sent

along with the encrypted record. The digital signature is made up of a hash of the medical record  which  is  then  encrypted  using  the  computer’s  private  key.

8. Upon receiving the data, the mobile phone decrypts the medical record using the secret key. The digital signature is then decrypted  using  the  computer’s  public  key  to  reveal  the  hashed  data.

9. The medical record is then hashed and compared to the outcome of decrypting the digital signature in order to verify that the integrity of the medical record has not been compromised.

10. The mobile phone then sends a Boolean value to the computer providing information as to whether the record was received successfully or not.

11. The medical record must now be prepared for secure storage on the mobile phone so it is encrypted using a symmetric encryption algorithm and corresponding key generated from the user’s  password.

12. The   encrypted   record   is   then   stored   in   a   file   on   the   mobile   phone’s  microSD card called MedicalRecord.txt.

34

Similarly with sending the medical record from the mobile phone to the computer, both user interfaces are updated appropriately regarding the success of the transmission.

4.9 Viewing a medical record This event forms the basis for the performance testing of the symmetric encryption algorithms. For the purposes of testing, another copy of the medical record in plaintext format is stored on the mobile phone for when this option is selected.

When View record is selected from the menu that appears after a successful login, the user is presented with a drop down list of symmetric encryption algorithms to choose from as shown in the figure below.

Figure 4.12: The screen that appears after selecting View Record in the main menu (left) and the choice of algorithms for encrypting and decrypting the medical record once the drop down list is selected (right).

Upon selecting the View button, the application stores the selected algorithm as a variable and inserts it as a parameter to initialise the symmetric encryption and decryption objects. The plaintext copy of the medical record is then encrypted before it is decrypted for the purposes of performance testing both operations. The encryption and decryption are based on password-based cryptography.

4.9.1 Password-based encryption The encryption and decryption of the medical record that is stored on the mobile phone is implemented using password-based cryptography as specified by the Bouncy Castle library.

The implementation is based on the public-key cryptography standard (PKCS) published by RSA Security for password-based encryption, namely PKCS#5.

Due to the fact that passwords are often chosen from a small search space, they are prone to dictionary attacks. The password therefore requires extra processing before it can be considered for use as a key for symmetric cryptography .The password is generally combined with a random byte array called a salt to produce the key. Furthermore, the key derivation technique can employ an iteration count which increases the cost of exhaustive search. The iteration count is the number of times that the underlying functions used to generate the key from the password and the salt are iterated over [RSA

35

Laboratories 1999]. Both of these techniques have been implemented in order to increase the level of security used for creating the key that is used for symmetric encryption and decryption.

4.9.2 Encryption and decryption These operations only differ in terms of a flag that is specified in the implementation to specify whether encryption or decryption must be performed on the incoming byte array. Since all of the symmetric algorithms that have been chosen for performance testing are block ciphers, the implementation makes used of the PaddedBufferedBlockCipher as specified in the Bouncy Castle library. This cipher allows the data to be processed in a piecemeal fashion and padded with the specified padding scheme.

Padding is required for block ciphers due to the fact that the data is split into blocks of equal bit size, and the size of the data may not be a multiple of the block size. The data is therefore padded and there are various ways in which this can be done. The implementation makes use of PKCS7 padding scheme whereby the padding is done using whole bytes and the value of the bytes that are added is equal to the total number of bytes that must be added to the last block.

There are a number of modes available that specify the way in which each block of data is processed during both encryption and decryption. Electronic Code Book (ECB) is the simplest of these modes and therefore requires the least amount of computational power and consequently provides the lowest level of security.

ECB processes each block of data individually and therefore equal plaintext blocks are encrypted into equal ciphertext blocks. The main advantage of this operation mode is that it can be performed in parallel and will therefore have a performance advantage over other modes. However, ECB is insecure as it allows for the detection of patterns in the data and could lead to an attacker deciphering the plaintext from the ciphertext [Hutchison 2011]. For this reason, it was not used in the implementation of securing the medical record for storage.

Figure 4.13: A graphical representation of the way ECB is used to encrypt data

The most commonly used mode of operation is Cipher Block Chaining (CBC). Although this requires more computational power, memory, and each block of data cannot be processed in parallel, it is a more secure and widely used option and thus used in the implementation. In CBC mode, before each block of data is encrypted, it is XORed with the previous ciphertext block. An initialisation vector is used for the first block of data since there are no previous ciphertext blocks at that point [Hutchison 2011].

36

Figure 4.14: A graphical representation of the way in which CBC is used to encrypt data

Once the key has been generated from the password for the chosen algorithm, and the operation mode and padding scheme have been initialised, the medical record can be encrypted.

The plaintext record is read from a file on the microSD card and encrypted before it is written back to a separate file on the microSD card. The encrypted record is then read from this file, decrypted and sent to a text area on the interface for the user to view.

The original goal was to allow the user to have granular access when viewing their medical record on the mobile phone. However this involves the process of using an XML parser to extract the data within the specified tags which was in the end beyond the scope of the project and therefore not implemented. The medical record is therefore displayed to the user in raw XML format for the purposes of functionality testing to ensure that the decryption is in fact producing the correct output.

Figure 4.15: A screenshot of the medical record in XML format as it is viewed on the mobile phone.

37

The symmetric block cipher algorithms that have been chosen along with their respective key lengths and block sizes are detailed in the table below:

Table 4.1: Summary of the chosen symmetric block ciphers.

The key length for each algorithm is set to the largest possible since the larger the key, the greater the security that the algorithm provides [Hutchison 2011]. Similarly, the larger block size, the stronger the security however is specified for each algorithm by the Bouncy Castle library and cannot be adjusted.

4.10 Integration After completing the implementation of the security and transmission system, it was necessary to integrate it with the storage and compression system. The integration therefore allows the complete flow of information through the mobile medical record framework.

Since the main focus of this project is the development for the mobile phone, the integration was only performed with the mobile application. The compression was integrated in such a way that allowed the medical record to be compressed before it was encrypted for storage.

Therefore in order to view the medical record, it must first be decrypted and then decompressed. Similarly when it is sent to a computer, it must be decrypted and then decompressed before it can be secured for the transmission.

Algorithm Key Length Block size AES 256 128

AESLight 256 128 AESFast 256 128 Twofish 256 128 XTEA 128 64

38

Chapter 5

Evaluation 5.1 Introduction In this chapter, we discuss both the criteria that were used and the methodology that was applied when conducting the functionality and performance tests. The results from these tests are then presented and the significance of these results is then discussed.

5.2 Functionality tests The primary goal of the functionality tests is to ensure that the algorithms are producing the correct output before they are subjected to performance testing. The aim is to also determine whether the goals that were set out in the design chapter have been realised, namely:

The secure transmission of the medical record between the mobile phone and a computer. The secure storage of the medical record on the mobile phone.

5.2.1 Sending the medical record from the mobile phone to the computer The goal of this test was to demonstrate that the design requirement of Bluetooth transmission between a mobile phone and a computer has been achieved.

This test was conducted on the sample medical records for all the possible combinations of algorithm and key length. The goal was to test the functionality of both the Bluetooth and encryption implementation as the size of the medical record increased. The medical record that arrived at the computer was compared to the record that was sent from the mobile phone in terms of the following:

The size of the medical record to ensure that the entire record was transmitted to the computer.

Correctness of the data within the record in order to ensure that the record that was decrypted on the computer is identical to the record that was encrypted on the mobile phone.

Although both of the above criteria were verified by using the digital signature in the application, they were also tested with the help of a command line file comparison tool (fc) that performs a full comparison between two files and outputs the differences.

This test was also conducted and evaluated in the same manner for the task of sending the medical record from the computer to the mobile phone.

These tests are particularly important due to the fact that we are dealing with medical data, and thus if the record is not identical before and after transmission, there could be serious consequences.

5.2.2 Encryption and decryption of the medical record on the mobile phone The purpose of this test was to ensure that the symmetric encryption and decryption of all the chosen symmetric block ciphers produce the correct output. This test is important since the medical record must be decrypted correctly before it is viewed on the mobile phone. The medical record must also be decrypted from storage before it can be secured for transmission. The performance of the algorithms also cannot be analysed thoroughly if they are not producing the correct output.

39

This test was performed on all the sample medical records after they had been compressed. The sample  medical   records,   in  plaintext   format,  were   transferred   to   the  mobile  phone’s  microSD card. Each record was then compressed before being encrypted and then decrypted and stored in a separate file.

The  decrypted  files  were  pulled  from  the  mobile  phone’s  microSD card and compared to the original sample medical records using the same file comparison tool as before. This test was repeated for all of the chosen symmetric block ciphers.

5.3 Performance tests The prerequisite for conducting the performance tests was that all of the functionality tests were passed. The aim with these tests was firstly to provide a practical analysis of the performance of RSA and ECC when used in the context of Bluetooth transmission. Secondly, the goal was to analyse the performance of the chosen symmetric block ciphers relative to the level of security provided by each algorithm.

5.3.1 Testing tools The Android operating system is based on the Linux operating system which therefore allowed us to make use of the Linux-based performance testing tools that are available. These tools can be accessed if the Android phone is connected to a computer via a USB cable by using the Android Debug Bridge Tool (adb). The adb allows a developer to communicate with and run applications on the Android device through the command line. However in order to access the Linux-based performance tools that were necessary, we needed the necessary admin permissions that are gained by rooting the Android phone.

Root access to the Ideos Gaining root access to the Ideos was simply done by downloading and running an application called Z4 Root [Chazen 2011]. Once this was completed, the necessary Linux-based tools could be executed in super user mode from the command line using adb.

Measuring CPU usage The goal with this performance measurement was to monitor the percentage of the CPU that the application was using whilst running each of the algorithms and their respective tasks. A Linux-based command line tool called top was chosen for this purpose as it printed out the CPU usage as a percentage and catered for command line parameters to adjust the frequency of its output.

Top prints out a range of measurements, including the CPU usage, of all the processes that are running on the system. The command was first placed within the running program whereby top printed a snapshot of the system to the log and we found the CPU usage of the application to be 0%.

It was then discovered that it is possible to run top in the background using the command line and then execute the application and measure CPU usage over time. The following commands were executed in order to measure CPU usage of the application over time:

adb shell top –d 1 > /sdcard/top.txt

The command must be executed from the android-sdk directory on the computer. The line adb shell initialises adb. The command line arguments – d 1 that are passed to the top command instruct it to output measurements of all processes every second. The output from top was written to the file top.txt on the microSD card. This file was then pulled onto the computer for analysis.

40

Figure 5.1: Example output from the top command for the mobile application.

Memory usage Memory management in Android is a complex topic since most of the memory in Linux systems is shared across multiple processes. This creates a challenge when wanting to measure the memory usage of an individual process. Over and above this, there are various values that can be measured, each of which has a different way of calculating the memory that is being used by a process.

The Resident Set Size (RSS) is one of the many memory measurements that are available and the one that allows the amount of memory used by an individual application to be analysed. The RSS value is the amount RAM that is being used by a process and is therefore an indication of the memory used by the process without being affected by shared memory measurements of other running processes.

This value was measured by reading the proc/self/status file on the Android phone and printing it to another file for analysis. Top also measures RSS memory, as can be seen from the screen shot in Figure 5.1 above, and therefore both measurements can be used as a means of verification that the values obtained for memory usage can be accepted.

Execution time Measuring execution time was done with the use of an Android class called TimingLogger. This class was chosen since it allows the timing of specific sections of code with the use of split points. This was helpful when trying to analyse the output in order to find the specific method calls that were slowing down the performance of the tasks that were executed. The time is measured in milliseconds and output to the Logcat in Eclipse.

Before TimingLogger can be used, it must first be initialised in order to produce any output. This is done by typing the following in the command line within the android-sdk directory:

adb shell setprop log.tag.timing VERBOSE

This must be executed with the phone connected to the computer via a USB cable. The following is a snapshot of the code that was used for TimingLogger:

The above sample code prints the execution time of the encryption operation and outputs it to Logcat.

41

5.3.2 Asymmetric cryptography performance The purpose of these tests was to compare the performance of RSA and ECC according to the recommended key lengths for both algorithms as specified in the design chapter. The algorithms were tested whilst performing the tasks of key generation, key exchange as well as creation and distribution of the digital signature via a Bluetooth channel.

The research claims that ECC is capable of providing the same level of security as RSA but with smaller key sizes thus making it a more efficient algorithm. The performance tests will allow us to draw conclusions and recommendations regarding the two algorithms based on practical evidence.

Hypothesis There were three hypotheses that were tested for the comparison of RSA and ECC that correspond to the three different performance measurements.

4. For the same strength security, there is a significant difference in execution time between RSA and ECC.

5. For the same strength security, there is a significant difference in CPU usage between RSA and ECC.

6. For the same strength security, there is a significant difference in memory usage between RSA and ECC.

Thus the null hypotheses for this experiment are as follows:

1. For the same strength security, there is no difference between the execution times of RSA and ECC.

2. For the same strength security, there is no difference between the CPU usage of RSA and ECC.

3. For the same strength security, there is no difference between the memory usage of RSA and ECC.

Independent and dependent variables In order to conduct a performance analysis between RSA and ECC, two independent variables were used.

The independent variables that were varied include:

1. Algorithm: the algorithm could either be RSA or ECC. 2. Key length (in bits): the key length could either be 1024 or 2048 for RSA, and either 192 or

256 for ECC.

In all cases, the dependent variables consisted of execution time, memory usage and the percentage of the CPU that is used by the algorithm whilst performing all three tasks. These variables will be measured using the tools discussed in the previous section for all the possible variations of the independent variables.

Key Generation This involved measuring the performance metrics with regard to generating the key pair for both RSA and ECC. This key is then used to generate the public and private key pairs for both algorithms. The parameters for the key generation method include the algorithm name and key length.

42

Key Exchange The purpose of using RSA and ECC in the context of the mobile application is to distribute the symmetric session key across the Bluetooth connection. The two algorithms have a different means of doing this and therefore provide an interesting practical comparison.

The key exchange performance measurements for RSA included all operations from generating the session key on the mobile phone up until the confirmation that the session key has reached the computer was received.

The key exchange performance measurements for ECC included all operations from generating the public part of the key pair on the mobile phone up until all the ingredients to create the session key had reached the computer and confirmation that the session key had been generated was received.

Digital Signature This was not originally part of the performance tasks but rather a part of the general implementation for the purposes of verifying the integrity of the medical record after transmission. However after implementation, it was realised that there were differences between RSA and ECC in the way that the digital signature was implemented.

The digital signature performance measurements for both RSA and ECC include all operations from when the digital signature is created on the mobile phone until confirmation is received from the computer verifying the correctness of the medical record.

Unlike the performance tasks of key generation and key exchange, the digital signature makes use of the medical record to perform its task. This performance test was conducted using only the largest medical record since it is always hashed to a 256 bit value, regardless of its size. Although the size of the record will affect the performance of the hashing algorithm, we were more interested in the differences in performance between the way in which the digital signature was distributed and therefore the size of the medical record was not considered important.

5.3.3 Symmetric cryptography performance The purpose of these tests was to compare the performance of the symmetric block ciphers that were outlined in the design chapter whilst performing both encryption and decryption of the medical record. The tests were performed on all the sample medical records after they were compressed.

The performance of the algorithms was compared relative to the strength of security that they provide. The aim is to provide recommendations with regard to all of the algorithms as part of a practical analysis. There are therefore no hypotheses that were included as part of this round of performance testing.

Independent and dependent variables In order to conduct a performance analysis between the chosen symmetric block ciphers, two independent variables were used. The two independent variables that were varied include:

1. Algorithm which was one of the following: AES AESLight AESFast Twofish XTEA

43

2. Size of the medical record (compressed size in kilobytes): 247 578 782

Encryption and decryption For the sake of completeness, measurements were taken for both encryption and decryption operations. The medical record was encrypted and then written to a separate file for decryption. The compression of the medical records was done before the encryption and decryption could take place; however this was not included as part of the performance measurements.

5.4 Results In this section, the results from the functionality and performance tests are presented. The significance of the results from these tests is presented in the discussion section.

5.4.1 Functionality tests The results from the functionality tests are represented in a concise tabular format. A test is considered successful if it is represented with a tick and unsuccessful if it is represented with a cross. The functionality tests form the basis upon which the performance tests are conducted and therefore all tests must be passed before performance testing can take place.

Sending the medical record from the mobile phone to the computer This test was conducted on all of the sample medical records using both RSA and ECC along with their respective key lengths. The data correctness column refers to whether the data in the transmitted medical record remains unchanged. The file size refers to whether the size of the transmitted medical record remains unchanged. The medical record was not compressed for the transmission and is thus represented by its original, uncompressed size in kilobytes.

Table 5.1: Results from the functionality test of sending the medical record from the mobile phone to the computer

The results for the functionality tests when sending the medical record from the computer to the mobile phone were all successful and therefore identical to the results presented above in Table 5.1.

Encryption and decryption on the mobile phone This test was performed in order to check that applying both encryption and decryption to the medical record does not alter the data in the record in any way. The test was conducted on all of the symmetric block ciphers for all of the sample medical records. The medical records were compressed before encryption and are therefore represented by their compressed sizes. The results are detailed below.

Algorithm Test Medical record 1 517 kb

Medical record 2 817 kb

Medical record 3 1055 kb

RSA 1024 Data Correctness File Size

RSA 2048 Data Correctness File Size

ECC 192 Data Correctness File Size

ECC 256 Data Correctness File Size

44

Table 5.2: Results from the functionality tests for symmetric encryption and decryption

Algorithm Medical record 1 (247kb) Medical record 2 (578kb) Medical record 3 (782kb) AES AESLight AESFast Twofish XTEA

5.4.2 Performance tests The results from the performance tests will determine whether we accept or reject the null hypotheses that were stated for the asymmetric algorithms and allow us to provide insight into the performance of the symmetric block ciphers.

Asymmetric cryptography performance The results that were obtained for all the performance measurements have been categorised according to the dependent variables. In order to determine the significance of the results that were achieved, a t-test was used with a significance level (alpha value) of 5%. This means that there is a probability of 5% that the null hypothesis will be rejected when it is in fact true [Underhill and Bradfield 2009]. We therefore reject the null hypothesis if the p-value obtained from the t-test is less than 0.05 and fail to reject it when the p-value is greater than 0.05.

The t-test for significance was chosen since in all cases we are only interested in comparing the means of two samples, namely RSA and ECC. Furthermore, the t-test also allows significance testing when the variances between the data in each sample are not equal. A two-sample t-test assuming unequal variances was conducted for all asymmetric performance test measurements.

Before the data collected for each performance task was analysed, any outliers present in the data were removed. A data point (n) is considered to be an outlier if:

n > m + 6 ( u – m ) OR n < m – 6 ( m – l )

Where m is the median, u is the upper quartile and l is the lower quartile [Underhill and Bradfield 2009].

The t-test requires that the data follow a normal distribution. In order to ensure that this was approximately the case for all data sets, a histogram was created and the general shape thereof was observed. The data was considered to be normal if it followed a bell-shaped curve and did not exhibit any peaks towards the two tails of the distribution.

The tests for each of the performance tasks were repeated 20 times for each algorithm and respective key length. It is recommended that in order to conduct significance tests for the difference between two means, the tests should be repeated over 100 times depending on the sample data in question [Underhill and Bradfield 2009]. This is due to the fact that the more samples there are of the data, the closer that data becomes to fitting the normal distribution, as well as locating the true mean. Furthermore, the true deviation from the mean can only be realised with a large number of samples.

45

However since these tests have been conducted in a controlled environment on the same mobile phone, and have a predictable output, it is highly unlikely that the mean and deviation will change significantly between 20 and 100 samples.

The results and analysis for each dependent variable are detailed below.

Execution time The execution time for all three performance tasks was measured independently for both RSA and ECC and their respective key lengths.

Key generation There were no outliers present in the data for this performance measurement. The data was found to follow a normal distribution after constructing and analysing the histogram that was generated. A t-test was therefore conducted using the execution time measurements in milliseconds for both algorithms and their comparative key lengths.

Table 5.3: Results from the t-test conducted on the key generation execution times

Algorithm Mean (ms) Variance (ms2) p-value RSA 1024 1952.50 327700.26 1.028E-09

ECC 192 530.15 3620.87 RSA 2048 15359.00 20704128.11 1.329E-11

ECC 256 845.30 1929.38

The p-values resulting from the t-test in the above table show that there is a significant difference in the time taken between RSA and ECC to perform the task of key generation.

One can also see from the resulting graph in Figure 5.2 below showing the execution time with standard deviation that RSA takes significantly longer compared to ECC to generate its key pair. This result is expected since the RSA keys are significantly larger than the ECC keys.

Figure 5.2: Graph showing the average execution time with standard deviation for key generation between RSA and ECC.

0

2000

4000

6000

8000

10000

12000

14000

16000

18000

20000

22000

RSA 1024 ECC 192 RSA 2048 ECC 256

Mill

isec

on

ds

Key Generation

46

The results have been presented in a single graph for this measurement for the purpose of comparison due to the vast differences in the execution time between the different algorithms and key lengths.

From the graph in Figure 5.2 we notice that generating a 2048 bit key for RSA takes significantly longer than generating a 1024 bit key. This however is not the case for ECC where there is small increase in the execution time. This is however expected since there is a 1024 bit difference between the two RSA keys and only a 64 bit difference between the two ECC keys.

Key exchange The existence of outliers was found in data for this performance measurement. This could be attributed to the uncertainty that exists with this measurement with regard to the Bluetooth transmission speed since the test required that the computer return a response to the mobile phone upon receiving the key.

The Box and Whisker plots below provide a graphical representation of the outliers that were present in the key exchange execution times.

Figure 5.3: Box and Whisker plots showing outliers for ECC 256 bit (left), RSA 2048 bit (centre) and RSA 1024 bit (right).

Once the outliers were removed from the data, a histogram was generated and analysed for each data set. The shape of the curves indicated that the data followed an approximate normal distribution and therefore qualified for the execution of a t-test.

Table 5.4: Results from the t-test conducted on the key exchange execution times

Algorithm Mean (ms) Variance (ms2) p-value RSA 1024 107.05 316.94 1.745E-20 ECC 192 756.75 6002.09 RSA 2048 178.27 22.21 4.507E-25

ECC 256 1144.5 3200.89

The p-values resulting from the t-test in Table 5.4 show that there is a significant difference between the time taken between RSA and ECC to perform the task of exchanging the session key.

47

From the graph in Figure 5.4 showing the execution time with standard deviation we notice that the execution time for ECC is significantly longer than that of RSA. This could be due to the different way in which the two algorithms perform this task. This result therefore requires further analysis and discussion.

Figure 5.4: Graph showing the average execution times with standard deviation for key exchange between RSA and ECC.

Digital Signature There were no outliers present in the data for this performance measurement. The data was therefore analysed using a histogram and considered to follow a normal distribution. A t-test was then conducted on the data sets in order to determine whether there was any significance in the difference between the means.

Table 5.5: Results from the t-test conducted on the digital signature execution times

Algorithm Mean (ms) Variance (ms2) p-value RSA 1024 216.95 37.31 5.098E-24

ECC 192 1108.85 3519.29 RSA 2048 304.20 40.38 1.689E-17 ECC 256 1399.25 26410.30

The p-values resulting from the t-test in Table 5.5 show that there is a significant difference between the time taken between RSA and ECC to perform the task of creating and exchanging the digital signature.

From the resulting graph in Figure 5.5 below showing the execution time taken to perform the digital signature, we can clearly see that for both key lengths, ECC takes significantly longer.

Similarly with the task of key exchange, the two algorithms differ in terms of their distribution of the digital signature and therefore differ in performance. This result requires further analysis and discussion regarding the way in which ECC implements this feature.

0

200

400

600

800

1000

1200

1400

RSA 1024 ECC 192 RSA 2048 ECC 256

Mill

ise

con

ds

Key Exchange

48

Figure 5.5: Graph showing the average execution times with standard deviation for the digital signature between RSA and ECC.

CPU usage The CPU usage was measured over time for the whole duration of sending the medical record to the computer. This was done since accurately measuring the CPU usage at the exact point at which the specific tasks were taking place proved to be quite a challenge. The CPU usage was therefore measured over time and the average CPU usage, as a percentage, was calculated for both RSA and ECC.

The execution time of the tasks was also measured in order to make it possible to locate the points on the graph of the CPU usage over time where the specific tasks were executing. All CPU measurements were taken on the mobile phone which is equipped with an ARMv6-compatible processor.

There were no outliers present in the data for this performance measurement. The data sets were considered to follow a normal distribution after the analysis and creation of the necessary histograms. The significance of the results were therefore analysed using a t-test.

Table 5.6: Results from the t-test conducted on the average CPU usage (%) measurement over time.

Algorithm Mean (%) Variance (%2) p-value RSA 1024 26.21 697.88 0.542

ECC 192 31.67 796.31 RSA 2048 34.38 855.89 0.897

ECC 256 33.31 808.79

The p-values resulting from the t-test show that the difference in the average CPU usage between RSA and ECC cannot be considered significant. Both p-values in Table 5.6 above are greater than 0.05 and therefore do not lie within the required 95% confidence interval.

The lack of significance in the results is also evident in the graph in Figure 5.6 showing the average CPU usage with standard deviation.

0

200

400

600

800

1000

1200

1400

1600

1800

RSA 1024 ECC 192 RSA 2048 ECC 256

Mill

ise

con

ds

Digital Signature

49

Figure 5.6: Graph showing the average CPU usage with standard deviation for both RSA and ECC over all the performance tasks.

From the graph in Figure 5.7 we notice that the general trend in terms of CPU usage over time for both RSA and ECC is similar. The data between the points A and B on the graph indicates the CPU usage for task of both key creation and exchange. We can see that the difference in the CPU usage over this time between the two algorithms is not significant.

The data between the points C and D indicate the CPU usage for the task of creating and distributing the digital signature. There is a visible peak in CPU usage for ECC and no visible change for RSA. This evidence, along with the measured execution time for the digital signature, shows the lack of efficiency in the ECC implementation of this task.

Figure 5.7: Graph showing the average CPU usage over time between RSA 1024 bits and ECC 192 bits.

0

10

20

30

40

50

60

70

80

90

100

RSA 1024 ECC 192 RSA 2048 ECC 256

Pe

rce

nta

ge (

%)

Average CPU usage

0

10

20

30

40

50

60

70

80

90

100

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

Pe

rcen

tage

(%

)

Seconds

CPU usage over time

RSA 1024

ECC 192

50

Figure 5.8: Graph showing the CPU usage over time for both RSA 2048 bits and ECC 256 bits.

Memory usage The amount of memory used was also measured over time due to the fact that measuring it at specific points within the program also proved to be a challenge. The average amount of memory used for the duration of sending the medical record from the mobile phone to the computer was measured and analysed.

There were no outliers present in the data for all measurements. The data was considered approximately normal following the analysis of the created histograms for all data sets. A t-test was therefore conducted to determine whether there were significant differences in the memory usage between the two algorithms.

Table 5.7: Results from the t-test conducted on the average memory usage in kilobytes over time.

Algorithm Mean (kb) Variance (kb2) p-value RSA 1024 21332.06 2298818.77 0.110

ECC 192 22274.93 4013644.00 RSA 2048 21929.13 6720132.60 0.019

ECC 256 23313.22 545284.80

The p-values obtained from the t-test indicate that there is a significant difference in memory usage between RSA 2048 bit and ECC 256 bit since the p-value is less than 0.05. However since the p-value is greater than 0.05 for the outcome between RSA 1024 bit and ECC 192 bit, the difference in memory usage cannot be considered significant.

From the graph below in Figure 5.9 we notice that ECC uses more memory on average than RSA. The difference however is more significant between the implementations of RSA 2048 bit and ECC 256 bit.

0

10

20

30

40

50

60

70

80

90

100

1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31

Pe

rcen

tage

(%

)

Seconds

CPU usage over time

RSA 2048

ECC 256

51

Furthermore, an interesting observation is that the implementation of ECC 192 bit uses more memory than the implementation of RSA 2048 bit. This result is unexpected due to the claims that have been made with regard to ECC in the literature. The reasons for these results warrant further analysis and discussion   regarding   ECC’s   implementation   of   the   various   performance tasks compared to that of RSA.

Figure 5.9: Graph showing the average memory usage with standard deviation between RSA and ECC over time for all three performance tasks.

Symmetric cryptography performance The results that were obtained for all the performance measurements have been categorised according to the dependent variables. The execution time, CPU usage, and memory usage performance tests were all repeated 10 times for each algorithm and for all of the sample medical records.

The goal with this round of tests was to provide recommendations regarding the chosen algorithms with respect to their performance as the medical record grew in size and compared to the level of security provided.

Execution time The execution time was measured for both encryption and decryption. The results from these tests are plotted below in Figure 5.10 and Figure 5.11 respectively. In order to create a line graph as we have done, more data points are typically required. However the aim here is to merely compare the algorithms in terms of their execution time as the size of the medical record increases. Ideally these tests should have been conducted on a wider range of medical records however, as stated in the design chapter, obtaining medical record data proved to be a challenge.

0

5000

10000

15000

20000

25000

30000

RSA 1024 ECC 192 RSA 2048 ECC 256

Kilo

byt

es

Memory usage

52

Figure 5.10: Graph showing the average encryption times as the medical record grows in size.

Figure 5.11: Graph showing the average decryption times as the medical record grows in size.

The graphs presented in Figure 5.10 and 5.11 show that the AESLight version of the AES algorithm has the longest execution time for both encryption and decryption. The AESFast implementation proves to be the most efficient of the AES variants.

0

1000

2000

3000

4000

5000

6000

7000

8000

9000

247 578 782

Mill

ise

con

ds

Compressed file size (kb)

Encryption Time

AES

AESLight

AESFast

Twofish

XTEA

0

1000

2000

3000

4000

5000

6000

7000

8000

9000

247 578 782

Mill

ise

con

ds

Compressed file size (kb)

Decryption Time

AES

AESLight

AESFast

Twofish

XTEA

53

The most efficient algorithm for both encryption and decryption is shown to be XTEA. This result is expected   due   to   the   simplicity   of   the   algorithm’s   implementation.   The   simplicity   of   the   XTEA  however makes it a concern regarding the level of security that it provides.

An interesting observation is that on average for all the algorithms, the execution time for decryption is longer than for the task of encryption. This is interesting since in most cases encryption and decryption are considered symmetric tasks and should therefore result in approximately the same average execution time.

CPU usage The CPU usage was measured over the whole duration of encrypting and decrypting the medical record. The average CPU usage measured over all the sample medical records is presented below.

Figure 5.12: Graph showing the average CPU usage with standard deviation over all of the sample medical records.

The graph presented in Figure 5.12 above shows that once again due to its simplicity, XTEA exhibits a conservative average use of the CPU. The Twofish algorithm also proves to be an efficient choice in terms of CPU usage.

In terms of the AES variants, we notice that AESLight is the most efficient in the case of CPU usage. The implementation of this algorithm is an optimised version of AES specifically for use in constrained environments such as mobile devices. The algorithm provides a trade-off between speed and memory usage and is therefore the worst when it comes to execution time but more conservative in its usage of the CPU.

0

10

20

30

40

50

60

70

80

90

100

AES AESLight AESFast Twofish XTEA

Pe

rce

nta

ge (

%)

CPU usage

54

Memory usage Memory usage was also measured for the duration of encrypting and decrypting the medical record. The average memory usage across all of the sample medical records was obtained and the results are presented below.

Figure 5.13: Graph showing the average memory usage with standard deviation taken over all three sample medical records.

The benefit of the simplicity in the implementation of XTEA is revealed once again in its use of memory shown in the above graph. The difference in memory usage of the other four algorithms is not significant although we notice that once again Twofish is among the most conservative in its usage of memory.

In order to compare the algorithms effectively and in terms of all three performance measurements, Table 5.8 details the average execution time, average CPU usage and average memory usage for all the sample medical records for the task of encryption and decryption.

Table 5.8: Summary of the results of the performance tests conducted on the symmetric block ciphers.

Algorithm Execution time (ms) CPU usage (%) Memory usage (kb) AES 3569.6 75 23536 AESLight 5196.1 72 24112 AESFast 1820.1 76 24219 Twofish 1438.2 59 23472 XTEA 1067.0 59 20537

0

5000

10000

15000

20000

25000

30000

AES AESLight AESFast Twofish XTEA

Kilo

byt

es

Memory usage

55

5.5 Discussion

5.5.1 Asymmetric cryptography performance

Execution time We found that there is a significant difference between the execution times of RSA and ECC for all three of the performance tasks and thus reject the null hypothesis. In particular we found that with both the task of key exchange and digital signature creation, ECC has shown to have a longer execution time. However for the task of key creation, ECC is significantly faster than RSA.

Key exchange A possible explanation as to why the ECC key exchange, namely ECDH, has a longer execution time is that the secret key must be generated by both parties (computer and mobile phone) once the ingredients to create it have been sent to the recipient. In contrast to this, the RSA key exchange only generates the secret key once by the sender who then sends it to the recipient. After observing the execution times in more detail, and timing each step that is performed in the key exchange, it was noticed that the time taken to create the secret key for the ECC implementation was significantly longer than the other tasks such as transmitting the necessary elements needed to create it. Therefore having to perform the most expensive task twice would lead to a significant difference in execution time.

Digital Signature The ECDSA that was used from the Spongy Castle implementation requires that all the ECC domain parameters be transmitted via Bluetooth in order for the recipient to create the public key that is required to decrypt the digital signature. The public key itself cannot be encoded into an appropriate format that will allow it to be transmitted as a whole.

The lack of an appropriate encoding scheme for the key results in a large amount of data that must be transmitted to the recipient and is ultimately the reason why ECC performs so poorly in this task. The RSA implementation transmits the public key as whole and is therefore more efficient.

Since the RSA public key can be encoded, there is surely a means whereby this can also be implemented for the ECC public key. In the event that this is done, the tests would need to be repeated for this specific task. The results for this test were therefore not a reflection on the algorithm itself but rather the implementation of it.

Key Creation The key creation execution time for ECC is significantly faster than RSA due to the difference in the key lengths. The RSA keys that are generated using large prime numbers thus take significantly longer than the smaller ECC keys that are generated.

CPU usage In terms of CPU usage, we found that the difference between RSA and ECC was not significant and thus fail to reject the null hypothesis.

This is most likely due to the fact that both algorithms, regardless of their difference in key lengths, require a fair amount of mathematical operations in order to perform the different tasks which thus leads to a generally high CPU usage.

56

Memory usage The results for memory usage between RSA 2048 bit and ECC 256 bit show that there is a significant difference in the amount of memory used between the two algorithms. However, the results for RSA 1024 bit and ECC 192 bit reveal that the difference in memory usage is not significant. Based on the results we cannot reject the null hypothesis and therefore recommend further investigation and performance testing in order to clarify the outcome.

We found that although the results for memory usage were not significant, ECC has shown to use more memory during its execution for both 192 and 256 bit key lengths. This result does not make sense given the smaller key sizes compared to RSA. However the most likely explanation for these results is once again attributed to the digital signature implementation. This is due to the fact that the domain parameters that are required in order to create the public key must be stored by both parties and thus results in extra, unnecessary memory usage.

5.5.2 Symmetric cryptography performance

Execution time The tests that were conducted for both encryption and decryption have shown that AESLight has the slowest execution time whereas XTEA has the fastest execution time. We expect this result since AES is accepted recommended by NIST and therefore considered to be the most secure of all the algorithms that were tested and thus takes the longest to execute. Furthermore, the AESLight implementation has a longer execution time in return for less time spent in the CPU. Given the key length of 128 bits and block size of 64 bits as well as the simplicity of its implementation, XTEA can be considered the least secure of the algorithms and thus it makes sense that it performs the fastest.

AESFast has the shortest execution time out of the three AES implementations, and is not significantly slower than XTEA thus making it a more suitable option due to the level of security it provides in comparison.

The Twofish algorithm also exhibits an execution time that is comparable to both AESFast and XTEA due to its performance driven design. Twofish has the same key length and block size as AES and is therefore comparable in terms of the level of security that it provides.

CPU usage We found that the AES variants require on average more processing power than both XTEA and Twofish. This is most likely attributed to the fact that AES is more complex in terms of the operations that it performs on the data in comparison to the other two algorithms.

Both Twofish and XTEA require on average the same processing power. This is unexpected since Twofish is considered to be more secure given that it was one of the five finalists in the search for AES. We expect this result from XTEA due its use of addition and subtraction as opposed to XOR. This result thus provides evidence regarding statements that Twofish was designed primarily with performance in mind. More specifically, Twofish is simple yet it provides more security than what is provably required and makes use of optimisations such as pre-computing keys for each round of encryption [Schneier et al. 1998].

Memory usage We found that XTEA requires the least amount of memory during its execution and AESFast requires the largest amount of memory due to the trade-off in its implementation with respect to speed versus memory.

57

The difference in memory required by the other three algorithms on average is not significant. The comparison of the algorithms in terms of their performance in relation to the strength of security that they provide should therefore be largely based on execution time and CPU usage as these measurements exhibit the most variation amongst the different algorithms.

58

Chapter 6

Conclusion The  use  of  a  mobile  phone  for  the  storage  and  management  of  a  patient’s  medical  record  has  proven  to be feasible. In order to demonstrate the feasibility of this we implemented a system that allowed for the secure storage of a compressed medical record on a mobile phone. The system also catered for the Bluetooth transfer of a medical record between a mobile phone and a computer. The implementation of the system provided a basis upon which performance testing was conducted on the both the symmetric and asymmetric cryptographic algorithms.

The Bluetooth transmission of the medical record served as a platform for comparing the performance of RSA and ECC. These tests allowed us to provide a practical comparison between these two algorithms when used to secure Bluetooth transmission in the context of the mobile medical record framework. The results from these tests allowed us to establish the following:

1. ECC takes significantly longer to execute in general, specifically for the tasks of key exchange and distributing the digital signature.

2. The difference in CPU usage between RSA and ECC cannot be considered significantly different however on average ECC spent more time in the CPU.

3. The difference in memory usage between RSA and ECC cannot be considered significantly different however ECC used on average more memory than RSA.

The results therefore show that although the literature claims that ECC is more efficient due to its smaller key lengths in comparison to RSA, their performance in this specific context has shown that this may not necessarily be the case. However this may not be a reflection of the algorithm itself but rather of the implementation that was used. It must also be noted that increasing the security strength of ECC (by increasing its key length) does not degrade the performance as significantly as with RSA. This was noticed specifically in the difference between the execution time of RSA 1024 and 2048 bit implementations in comparison to the difference between ECC 192 and 256 bit implementations.

The medical record was secured on the mobile phone using a combination of password-based encryption and login authentication. This formed the basis upon which the symmetric cryptographic algorithms could be compared according to their performance. The algorithms were tested based on their ability to encrypt and decrypt the medical record on the mobile phone. The tests have allowed us to make performance comparisons between symmetric block ciphers, namely AES, AESLight, AESFast, Twofish and XTEA. The results from the tests have shown the following:

1. XTEA outperforms the other algorithms in all performance measurements but provides a weaker form of security in comparison.

2. The AESFast implementation provides the best performance on average out of the AES variants.

3. The Twofish algorithm provides a high level of security and efficient performance and is therefore suitable for implementation on mobile devices.

Therefore, since the implementation of all the symmetric block ciphers was not an issue for the limited resources of the mobile device, it is recommended that the AESFast algorithm be used due to

59

its performance and due to the strength of security that it provides. However if it were the case that resources were limited, Twofish would be the algorithm of choice as it provides a sufficient level of security for sensitive data such as medical records and it has outperformed all other block ciphers with the same key length and block size. The algorithms need to cater for all types of patients and therefore one of the limitations of these performance tests is that they should have been conducted on a wider range of medical records in order for the results to be considered more accurate within this context.

The results from both sets of performance tests have lead us to conclude that there are both symmetric and asymmetric algorithms that can be used to secure the application within the limitations of a mobile phone. The research that has been conducted can therefore be applied in future iterations of the system in an attempt to create a mobile medical record application that can be used in order to improve the management of patient medical data.

6.1 Future work There are a number of elements within this project that can be implemented and expanded in future work. The following elements have been identified:

User interface Since the main goal of this project was to develop a system that achieved the transmission of a medical record to and from a computer, as well as the necessary security to ensure the privacy of the record, the user interface was not a priority. This element can therefore be extended whereby requirements analysis, prototyping and user testing is conducted in an iterative fashion in order to refine the usability of the interface.

Granular access to the medical record One of the requirements stated in the beginning of the project was that the patient should have granular access when viewing their medical record on a mobile phone. Unfortunately this was not implemented due to the other elements of the project taking priority. Since the medical record is in XML format, this element can be implemented by simply parsing through the medical record and extracting the relevant data between the XML tags.

Patient database The computer-based application that was implemented for the Bluetooth transmission of the medical record simply works with the XML file in its raw format for both sending and receiving. A possible extension for this application would include the creation of a patient database whereby the XML tags would map to tables and columns within the database. This would therefore be more convenient since any updates to the patient information would be inserted into the database.

Optimised ECC implementation The results from the performance tests showed that the implementation of ECC, specifically the digital signature, is inefficient. Therefore another element of future work exists in the optimisation of the current ECC implementation by investigating the mathematical elements that constitute each of the tasks required for encryption.

60

Performance testing on real medical data Besides testing the symmetric algorithms on a larger sample of medical records, it would be useful to conduct the performance tests using actual medical records or more specifically complete patient history files.

61

References AGOYI, M., AND SERAL, D. 2010. SMS Security: An Asymmetric Encryption Approach. In ICWMC   ’10:   Proceedings   of   the   6th   International   Conference on Wireless and Mobile Communications. IEEE Computer Society Washington, DC, USA, 448-452.

ALLAËRT, F.A. 2002. Security standards for healthcare information systems: a perspective from the EU ISIS MEDSEC Project. IOS Press. pp. 197.

ARTAIL, H., SAFA, H., AND NAHHAS, M. 2008. Enhancing Cache Invalidation in Mobile Environments. In Mobility '08: Proceedings of the International Conference on Mobile Technology, Applications, and Systems. ACM, New York, NY, USA, pp. 1-8.

BLUECOVE. 2011. BlueCove: Java library for Bluetooth. http://bluecove.org/

BLUETOOTH SIG. 2010. Specification of the Bluetooth system. [Online]. Available: https://www.bluetooth.org/Technical/Specifications/adopted.htm. Accessed: 11 September 2011.

BOULOS, M.N.K., WHEELER, S., TAVARES, C. AND JONES, R. 2011. How smartphones are changing the face of mobile and participatory healthcare: an overview, with example from eCAALYX. In BioMedical Engineering Online, 10(1), pp. 1-14.

BOUNCY CASTLE. 2011. Bouncy Castle Cryptographic Library. http://www.bouncycastle.org/

BURGSTEINER, H., AND PRIETL, J. 2008. A Framework for Secure Communication of Mobile E-health applications. In Medical Informatics meets eHealth, 2008, pp. 107-113.

CANALYS. 2011. Google’s   Android   becomes   the   world’s   leading   smart   phone   platform. Press release [Online]. Available: http://www.canalys.com/static/press_release/2011/r2011013.pdf. Accessed: 20 October 2011

CHAZEN, R. 2011. Z4Root Universal rooting application. http://www.amazon.com/RyanZA-z4root/dp/B004XNTFG0

CLARKE, N.L., AND FURNELL, S.M. 2007. Authenticating mobile phone users using Keystroke Analysis. In International Journal of Information Security. 6 (1), pp. 1-14.

CORNER, M.D., AND NOBLE, B.D. 2002. Zero-interaction Authentication. In MobiCom   ’02: Proceedings of the 8th annual International Conference on Mobile computing and Networking. ACM, New York, NY, USA, pp. 1-11.

CUSHMAN, R., FROOMKIN, A.M., CAVA, A., ABRIL, P. AND GOODMAN, K.W. 2010. Ethical, legal and social issues for personal health records and applications. In Journal of Biomedical Informatics. Elsevier Science, San Diego, USA, 43(5), pp. 551-555.

ELBAZ, L. 2002. Using Public Key Cryptography in Mobile Phones. Discretix Technologies Ltd. White Paper.[online]. Retrieved April 19, 2011 from http://www.discretix.com/PDF/Using%20Public%20Key%20Cryptography%20in%20Mobile%20Phones.pdf

62

ELMUFTI, K., WEERASINGHE, D., RAJARAJAN, M., RAKOCEVIC, V., AND KHAN, S. 2006. Privacy in Mobile Web Services eHealth. In Proceedings of Pervasive Health Conference and Workshops 2006. IEEE Press, pp. 1-6.

GARDNER, R.W., GARERA, S., PAGANO, M.W., GREEN, M., AND RUBIN, A.D. 2009. Securing Medical Records on Smart Phones. In SPIMACS   ’09:   Proceedings   of   the   first   ACM workshop on Security and Privacy in medical and home-care systems. ACM, New York, NY, USA, pp. 31-40.

GURA, N., PATEL, A., WANDER, A., EBERLE, H., AND SHANTZ, S.C. 2004. Comparing Elliptic Curve Cryptography and RSA on 8-bit CPUs. In Cryptographic Hardware and Embedded Systems – CHES 2004. Springer Berlin, pp. 925-943.

HANKERSON, D.R., VANSTONE, S.A., AND MENEZES, A.J. 2004. Guide to elliptical curve cryptography. Springer-Verlag, New York.

HAODONG, W., QUN, L. SIHAN, Q., AND NINGHUI, L. 2006. Efficient Implementation of Public key cryptosystems on mote sensors. In Lecture notes in computer science, volume 4307. Springer Berlin, pp. 519-528.

HEALTHFRAME. 2011. Records for Living: Sample PHRs. [Online]. Available: http://www.recordsforliving.com/PersonalHealthRecords/SamplePHRs.aspx

HUANG, X., JIANG, Y., LIU, Z., KANTER, T., AND ZHANG, T. 2010. Privacy for mHealth Presence. In International Journal of Next-Generation Networks. Academy & Industry Research Collaboration Center, India, 2(4), pp. 33-44.

HUAWEI. 2011. Huawei Ideos U8150 Specifications and Features. Available: http://www.huaweidevice.com/worldwide/productFeatures.do?pinfoId=2831&directoryId=6001&treeId=3745&tab=0

HUTCHISON, A. 2011. CSC4000W Network & Internetwork Security course notes.

INTERNATIONAL TELECOMMUNICATIONS UNION. 2010. Mobile cellular subscription statistics document. [online]. Available:http://www.itu.int/ITUD/icteye/Reporting/

JENKIN, M. AND DYMOND, P. 2002. Secure Communication between Lightweight Computing Devices over the Internet. In HICSS '02: Proceedings of the 35th Annual Hawaii International Conference on System Sciences. IEEE Computer Society, Washington, DC, USA, Volume 7, 195b.

KAPLIN, W.K. 2006. Can the ubiquitous power of mobile phones be used to improve health outcomes in developing countries? In Globalization and Health Journal. Biomed Central Publishers, 2(9).

KATIYAR, V., DUTTA, K., AND GUPTA, S. 2010. A Survey on Elliptic Curve Cryptography for Pervasive Computing Environment. In International Journal of Computer Applications. 11(10), 41-46.

KRISHNA, S., BOREN, S.A., AND BALAS, E.A. 2009. Healthcare via Cellphones: A systematic review. In Telemedicine Journal and eHealth: The official journal of the American Telemedicine Association. Mary Ann Liebert, Inc. NY, USA, 15(3), pp. 231-240.

63

LEGION OF BOUNCY CASTLE. 2011. Bouncy Castle API Documentation. [Online]. Available: http://www.bouncycastle.org/documentation.html

LISONEK, D. AND DRAHANSKÝ, M. 2008. SMS Encryption for Mobile Communication. In SECTECH '08: Proceedings of the 2008 International Conference on Security Technology. IEEE Computer Society, Washington, DC, USA, pp. 198-201.

MISIC, J. 2008. Traffic and Energy Consumption of an IEEE 802.15.4 network in the presence of authenticated, ECC Diffie-Hellman ephemeral key exchange. Computer Networks Journal. 52 (11), pp. 2227-2236.

MS, A. 2004. Elliptical Curve Cryptography: an implementation guide. Infosec Writers. [Online]. Available: http://www.infosecwriters.com/text_resources/pdf/Elliptic_Curve_AnnopMS.pdf

NEUSTADTER, D., AND ST. DENIS, T. 2008. Elliptical Curves over Prime and Binary Fields in Cryptography. Elliptical Semiconductor Inc. [Online]. Available: http://www.elliptictech.com/pdf/presentations/EC_overGF_in_cryptography.pdf

NICHOLSON, A.J., CORNER, M., AND NOBLE, B.D. 2006. Mobile Device Security Using Transient Authentication. IEEE Transactions on Mobile Computing. 5 (11). pp. 1489–1502.

NIE, J., AND HU, X. 2008. Mobile Banking Information Security and Protection Methods. In CSSE ’08:   International   Conference on Computer Science and Software Engineering. . IEEE Computer Society Washington, DC, USA, pp. 587-590.

NIST. 2001. Announcing the Advanced Encryption Standard (AES). [Online]. Available: http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf.

OSTROVSKY, R., SAHAI, A., AND WATERS, B. 2007. Attribute-based encryption with non-monotonic access structures. In CCS  ’07: Proceedings of the 14th ACM conference on Computer and communications security. ACM, New York, NY, USA, pp. 195-203.

PAGLIARI, C., AND FERNANDO, B. 2007. Portable Personal Health Records: Can they Improve Patient Safety? In Prescriber Journal. Wiley Online Publishers, 18(19), pp. 9-10.

PATRICK, K., GRISWOLD, W.D., RAAB, F. AND INTILLE, S.S. 2008. Health and the Mobile Phone. In American Journal of Preventive Medicine. Elsevier Science, USA, 35(2), pp. 177–181.

REN, Y., PAZZI, R.W.N., AND BOUKERCHE, A. 2010. Monitoring Patients via a Secure and Mobile Healthcare System. IEEE Wireless Communications for E-Healthcare. 17 (1), pp. 59–65.

RSA LABORATORIES. 1999. PKCS #5 v2.0: Password-Based Cryptography Standard. Available: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-5v2/pkcs5v2-0.pdf

SCHNEIER, B., KELSEY, J., WHITING, D., WAGNER, D., HALL, C., AND FERGUSON, N. 1998. TwoFish: A 128-Bit Block Cipher. In Proceedings of the 1st Advanced Encryption Standard (AES) Conference, Ventura, CA.

64

SOOD, S.P., NWABUEZE, S.N., MBARIKA, V.W.A., PRAKASH, N., CHATTERJEE, S., RAY, P., AND MISHRA, S. 2008. Electronic Medical Records: A Review Comparing the Challenges in Developed and Developing Countries. In HICSS   ’08:   Proceedings   of   the   41st   Annual   Hawaii  International Conference on System Sciences. IEEE Computer Society Washington, DC, USA, pp. 248-258.

TYLEY, R. 2011. Spongy Castle Cryptographic Library. https://github.com/rtyley/spongycastle

UNDERHILL, L.G., AND BRADFIELD, D. 2009. Introstat. University of Cape Town, Department of Mathematical Statistics.

WEERASINGHE, D., ELMUFTI, K., RAJARAJAN, M., AND RAKOCEVIC, V. 2007. Securing electronic health records with novel mobile encryption schemes. International Journal of Electronic Healthcare. 3 (4), pp. 395–416.

WHEELER, D., NEEDHAM, R., AND PRENEEL, B. 1995. TEA, a Tiny Encryption Algorithm. In Proceedings of Fast Software Encryption (FSE): Second international Workshop, Leuven, Belguim. Springer, Berlin, pp. 363-367.

WRIGHT, A., AND SITTIG, D.F. 2007. Encryption Characteristics of Two USB-based Personal Health Record Devices. In Journal of the American Medical Informatics Association. Elsevier Inc., 14(4), pp. 397-399.