Aggregator to connect in-body sensors to the health record system

(1)

Juni 2021

Aggregator to connect in-body

sensors to the health record system

Pedro Gomes Freire

Institutionen för informationsteknologi

(2)

(3)

Teknisk- naturvetenskaplig fakultet UTH-enheten

Besöksadress:

Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0 Postadress:

Box 536 751 21 Uppsala Telefon:

018 – 471 30 03 Telefax:

018 – 471 30 00 Hemsida:

http://www.teknat.uu.se/student

Aggregator to connect in-body sensors to the health record system

Pedro Gomes Freire

Wireless connected Implanted Medical Devices are becoming more and more common. Also, the increasing connectivity of medical sensors opens room for improving one important field of Health Care, Remote Patients Monitoring. Therefore, to explore this scenario, this

thesis aims to create a device that works as an Aggregator of data arising from Implanted Medical Devices. This Aggregator will then transmit the data autonomously to a Health Care monitoring provider.

The main objective of the Aggregator is to provide the technology for constant monitoring of the patients' Implanted Health Care Sensors. To do that, in this thesis, we developed a prototype of the Aggregator using a general-purpose embedded platform. The objective is to test the functioning of the system by receiving data,

processing, encrypt and send it through Bluetooth to a specialized remote monitoring Health Application Platform called IHAP by Intel®.

This platform provides a standard commercial platform to connect the Aggregator to the Health Care Monitoring providers. In the case of this thesis, the Swedish company Alleato provides a server to which the data was forwarded. Once in the server, Alleato can decrypt the data and provide it to the medical specialist.

A prototype was developed in a Raspberry PI so the software platform of the Aggregator could be certified. A series of performance tests were made to determine the main constraints of this project. The objective is to establish the grounds for the future development of an Aggregator in a specialized embedded platform. Therefore, the main code parts of the Aggregator were tested and compared with a General-Purpose Microcontroller, the ARM Cortex M0 STM32F072, and also with the SoC from Nordic Semiconductors, the nRF52840.

The STM32 results gave a reference of performance on how the functions perform in General Purposes Microcontrollers. However, as expected, the Nordic nRF52840 showed to be the fastest platform for processing the Aggregator's functions. Therefore, it represents the best candidate for future projects with the platform developed in this thesis.

Examinator: Philipp Rümmer Ämnesgranskare: Thiemo Voigt Handledare: Christian Rohner

(4)

(5)

Acknowledgement

I would like to express my gratitude to my supervisor Doctor Christian Rohner without whom this project would not be possible, for dedicating a lot of his time to give me valuable advice for the completion of this thesis.

I would like to thank Doctor Thiemo Voigt for reviewing this project and giving important feedback during its development.

I would like to thank the companies Alleato and Intel for the valuable partnership in this project.

(6)

Glossary

ADB Android Debugger.

AES Advanced Encryption Standard.

API Application programming interface.

ASCII American Standard Code for Information In- terchange.

BLE Bluetooth Low Energy.

CFB Cipher feedback.

ECDH Elliptic-Curve Diffie-Helman.

EMA European Medicines Agency.

FDA United States of America Food and Drug Ad- ministration Agency.

GFSK Gaussian Frequency-shift key.

HDO Health Delivery Organization.

HTML HyperText Markup Language.

HTTP Hypertext Transfer Protocol.

HTTPS Hypertext Transfer Protocol Secure.

IDE Integrated Development Environment.

IEEE Institute of Electrical and Electronics Engi- neers.

IHAP Intel Health Application Platform.

IMD Implanted Medical Devices.

IoT Internet of Things.

ISM Industrial, scientific and Medical Radio Bands.

ISO International Organization for Standardiza- tion.

JSON JavaScript Object Notation.

(9)

L2CAP Logical Link Control and Adaptation.

MAC Medium Access Control.

MCU Microcontroller Unit.

MIME Multipurpose Internet Mail Extensions.

NFC Near-Field Communication.

NIST National Institute of Standards and Technol- ogy.

OOB Out-of-Band.

OS Operating System.

PHY Physical Layer.

PIN Personal Identification Number.

PMDA Pharmaceuticals and Medical Devices Agency.

RF Radio Frequency.

RFCOMM Radio frequency communication.

RFID Radio-Frequency Identification.

RSA Rivest–Shamir–Adleman Encryption Algo- rithm.

SDK Software development Kit.

SDP Service discovery protocol.

SMTP Simple Mail Transfer Protocol.

SoC System-on-a-chip.

SSL Secure Socket Layer.

TCS Telephone Control.

TLS Transport Layer Security.

UART universal asynchronous receiver-transmitter.

UI User Interface.

URL Uniform Resource Locator.

UUID Universally Unique Identifier.

(10)

WBSN Wireless Body Sensors Network.

(11)

1 Introduction

1.1 In-body networks

Nowadays an increasing number of people are relying on Implanted Medical Devices - IMD for the most diverse types of medical procedures. IMDs can be used for many di↵erent purposes. Among them are, drug delivery devices, intracranial pressure monitors, pacemakers, or cochlear devices. Therefore, the most di↵erent functions can be performed by IMDs, from physiological parameters monitoring until permanent medical treatment.

With the advent of the miniaturization of microelectronics, integrated cir- cuit manufacturing techniques are reaching remarkable small sizes. With the current miniaturization capabilities, a new set of possibilities have been re- vealed with di↵erent kinds of functions in which IMDs can be applied and it is increasing systematically.

Uppsala University has been developing research in new technologies that could help to connect IMDs. Recent results have shown that the human body’s fat tissue can be used as communication channels for RF transmissions [1] [2] [3]. As a result of that, it allows energy-efficient and high data rate communication among IMDs of a single patient.

This discovery opened a possibility to implement an RF network system in which the IMDs can share data through the fat tissue of the patient. This technology shows great potential to improve the applicability of IMD since standard wireless technologies still su↵er from the low bandwidth inside the human body throughout di↵erent body tissues.

However, it is necessary to consider that this kind of network system needs to preserve the patient’s privacy. The RF communication between the di↵erent IMDs needs to be encrypted because, even with the difficulty to transmit RF signals in and out of the human body, there is still the possibility for it to be captured by an external antenna. To address that problem and create an IMD network as safe as possible, Uppsala University also is developing research to create a dynamical encryption key. This encryption infrastructure is based on physical and physiological measurements of the patient that can be detected by the di↵erent IMDs and generate the same key [4].

(12)

1.2 Aggregator to Connect the IMD to the Health Record System

The IMDs network of a patient needs to be connected to the exterior of their body to be accessed by a doctor or any health care professional. Therefore, the goal of this Master Thesis is to develop a device that will serve as an interface between the in-body network system and the internet, and trans- mitting the patient’s data to the Swedish National Health Service Platform.

This Master Thesis is part of ongoing research projects of Uppsala Uni- versity called “LifeSec: Don’t hack my body!” and ”Connect my Body”.

This last project is being developed in partnership with two companies: Al- leato AB and Intel Corporation. The first one, Alleato AB, is specialized in monitoring elderly patients and provide their health care data to medical professionals. Therefore, this project aims to integrate the Aggregator, and, by extension, all the patient’s IMDs, with the Alleato webserver. With that, they will be able to have real-time information from the patient and feed the Swedish National Health Service Platform with real-time data. That provides a faster and more responsive treatment for the patient.

The second company, Intel Corporation, provides a proprietary health care data online platform called IHAP – Intel Health Application Platform.

The IHAP will be used as a medium to connect Alleato Server and the Aggre- gator. As it can be seen in figure 1, the Aggregator will serve as an interface between the in-body IMDs network and the outside body, to connect with the Alleato server using Intel’s IHAP as a communication application platform.

All things considered, the goal of this thesis project is to develop an Ag- gregator platform with the following characteristics:

• It needs to detect the data from the IMDs.

• Encode the data into a standard format agreed and understandable by Alleato.

(13)

Figure 1: Aggregator diagram

• Design a security framework for secure end-to-end encryption and implement it.

The boundaries of this project are on the prototyping aspects. For the scope of this thesis, the Aggregator will be developed in a commercial embedded computing platform, more specifically the Raspberry Pi. Also, feasibility analysis will be conducted on Embedded Systems platforms that can be more appropriate for a real application of the Aggregator.

1.3 Results Summary

As an overall result evaluation, the prototype that, was developed in Rasp- berry Pi, was able to monitor the data inputs arising from the UART port.

This data was successfully detected, encoded into the standard JSON file format, encrypted with AES and RSA algorithms, and transmitted to Alleato’s server using the IHAP system.

The data received by Alleato was successfully decrypted and the simulated patient’s information was recovered. This process guarantees that the end-to-end encryption system works as expected since the transmitted information could be recovered using the private key of the RSA encryption algorithm. Finally, the recovered information can be displayed to a health care specialist in a future real application.

(14)

A performance evaluation was conducted on the main software components of the Aggregator prototype’s code. The time performance of five dif- ferent components was compared. The code was divided into the following parts: JSON encoding, RSA encryption, AES encryption, Base64 encoding, and Final JSON message wrapping.

As a result of the statistical time evaluation, the two most time-consuming components were JSON and RSA, with 43,93% and 41,86% respectively. To- gether they represent the absolute biggest part of the computation time.

Therefore, they should be taken into consideration in future software en- hancement.

A time performance test was also conducted in two other embedded platforms: the General-Purpose Microcontroller STM32F072 and the Nordic Semiconductors SoC nRF52840. The software components used in this comparison were AES and RSA encryption, and Base64 encoding. As a result, the Raspberry Pi outperformed the STM32 by a factor of 154 and 23 when running AES and Base64 algorithm respectively. When compared to the nRF52840, the Raspberry was 17.4 times faster in AES, 4.2 times in Base64, and 3.6 in RSA.

Power consumption evaluation was performed in the nRF52840. The components tested were RSA, AES, and Base64. The objective is to determine how much energy by operation those main software components will consume in a real application with this platform. The results were 18,48µJ per RSA operation, 5,82µJ for AES, and 5,51µJ in Base64.

1.4 Thesis Report Structure

This thesis report is formatted as follows: Chapter 2, Related Work, brings a set of research projects that have similarities with this thesis and other research paper that explores the integration of IMDs as connected devices.

Chapter 3, Background, reviews the theoretical background of Cryptography and Encoding, introduces the INTEL’s proprietary platform, the IHAP, and describes the Bluetooth technology. Chapter 4, Software Development, describes the software implementation of the prototype in the Raspberry Pi, the data format created to send the message to Alleato, the AES and RSA

(15)

algorithms usage, the Base64 encoding, the JSON formatting, and the IHAP Android implementation. Chapter 5, Results, brings an explanation of the criteria of evaluation of the basic functionalities of the whole system, a time performance evaluation of the main components of the code, a comparison of three di↵erent embedded platforms, and a power consumption evaluation with the Nordics nRF52840. Finally, Chapter 6 concludes this thesis and opens a discussion for improvement of this project in future works.

(16)

2 Related Work

Remote patient monitoring is an area of great scientific relevance and it is present in di↵erent research projects. Also, wirelessly connected health care monitors, both implanted and noninvasive devices, can be consistently found in the industry. More of those devices are launched as new technologies are developed. A number of research papers cover these topics which corroborate the relevance of this project.

The paper A Survey on Secured Wireless Body Sensor Networks [5] brings a relevant analysis of di↵erent research projects of wireless body sensors.

Throughout the paper, the authors describe a network of wireless sensors that acts in a very similar way as the system proposed in this Thesis Project.

They define the “Wireless Body Sensor Network - WBSN as a central node which acts as a master and some small nodes placed in, or around the human body acts as slaves” [5]. According to this description, it is possible to compare this network with the Aggregator and the IMDs in this project. In fact, according to their definition, this project’s system is a WBSN.

The related research projects on health care monitors have di↵erent pro- posals in what concerns connectivity. Some of the projects include a device that servers as an interface between the sensors and the desired destination of the information. For example, [6] proposes a cost-e↵ective MCU for WBSN.

In this proposed network, several sensor nodes capture the physical signals.

The sensor’s data can be an analog bio-signal or from an image detection.

Then the node encrypts the information and transmits it to a collection point node. This root note is then responsible to re-transmit the data to the medical expert.

Other research projects do not include a data aggregator in their systems.

Some of them are focused on a specific biomedical sensor application and the ways to improve their connectivity. An example is in [7], in which it is proposed a contact lens for monitoring intraocular pressure. The proposal is to use strain gages to measure deformations in the patient’s cornea curvature.

This contact lens is wireless powered by a body-worn power unit that also serves as a gateway to upload the measured data to a PC via Bluetooth [8].

Another aspect frequently presented in the related projects is data se-

(17)

curity. Most of the papers that deal with remote patient monitoring have as one of its central parts the cryptography of the data. In [6] the WBSN platform proposed has a specialized Encryption Encoder based on ElGamal cryptography which is an Asymmetric Cryptography algorithm. In this case, the data gathered in the sensors is encrypted with a public key. Also, in [9], public-key encryption is used to encode the data at the sensor’s side.

(18)

3 Background

This chapter reviews the theoretical background on which the main parts of this project are based. In the Cryptography part, the concept of secure communication is introduced, as well as the most common categories of modern cryptography regarding key exchange methods.

It is also introduced the IHAP technology by Intel. It is explained how the system works, which hardware is used, what are its usabilities, the main parts of the system data flow, and its constraints. In addition, this chapter also contains a brief introduction to the concept of encoding. The Base64 encoding algorithm is summarized and it is explained its applicability in this project.

Finally, the Bluetooth technology is described focusing on the most relevant characteristics necessary for its implementation in this project. More- over, it is also described the di↵erent pairing processes and some of the most common communication protocols.

3.1 Cryptography

Cryptography is the study of methods of secure communication between two parties [10]. It represents a central part of this project. Because it is necessary to secure the communication between the Aggregator and the Alleato server to guarantee the patient’s data privacy.

In Cryptography, encryption is the process of converting the original data into an unintelligible set of characters called cyphertext. In modern cryptography, this process is done by a complex set of math calculations that aims to be virtually impossible or extremely time-consuming to revert. In most cases, this math algorithm is controlled by an array of numbers or characters called an Encryption Key. Similarly, the Decryption is the process to revert the ciphertext and recover the original message. It also needs, in most cases, the corresponding decryption key and algorithm to revert the encryption process.

Modern Cryptography can be classified into two di↵erent categories: Sym- metric Cryptography and Asymmetric Cryptography [10, p71]. Symmetric Cryptography, also known as Secret-Key Cryptography, is a method used

(19)

to cipher plaintext in which both sides of the communication use the same encryption key to encrypt and decrypt the data. The figure 2 shows the diagram of encryption with a symmetric key. It is possible to see that both Alice and Bob use the same key, which is kept secret, so it is never available in the public area. Therefore, nobody in the public area can decrypt the message since they do not have access to the secret key.

Figure 2: Symmetric Key encryption scheme

However, symmetric cryptography has one security issue, the key exchange. Because both sides of the communication need to agree on which secret key to use in the encryption. Therefore, this key needs to be transmitted in a secure way between the two sides. But, sometimes, the only mean of communication is through the insecure public area. One way to solve this problem is by using the second category of encryption, Asymmetric Cryp- tography [11, p50].

The Asymmetric or Public-Key Cryptography is another category of encryption in which both sides use a Key-Pair to cipher the data. This pair is composed of a Public and Private Key. They are mathematically generated in a way that a text encrypted by one key can only be decrypted by its corresponding pair. Considering this characteristic, one of the keys can be kept secret and the other one can be transmitted or published in the public area. In this scenario, anyone can encrypt a text, but only the holder of the

(20)

private key can decrypt it.

The Figure 3 shows the diagram of encryption with an asymmetric key between Alice and Bob. In this case, Bob generates the Key-Pair and keeps the private key secret. He publishes the Public Key in a public place, or he sends it to Alice in plain text through insecure communication. In possession of the Public key, Alice can encrypt her data and transmit it to Bob, know- ing that only Bob can decrypt it because he is the only holder of the Key-Pair.

Figure 3: Asymmetric Key encryption scheme

The symmetric and asymmetric encryptions categorize the type of key exchange in the encryption method. Another important aspect is the Cypher Algorithm, which is the set of mathematical operations used for encrypting and decrypt the message. However, it is not part of the scope of this project to explore details about the cryptography algorithms. The most widely used algorithms were considered and compared to find the most suitable one for this application.

Another key exchange method used as an alternative to Asymmetric Key is Elliptic-Curve Diffie-Helman ECDH. This algorithm is a key exchange protocol that allows two parties to exchange random key values over an insecure channel, perform some calculation with them, and generating the same private key pair [10, p. p169]. This is done by transitioning the key values and

(21)

their calculation results over the channel a few times. This process aims to generate a pair of identical private keys on both sides of the communication without ever sending it through the channel public area. Finally, an associa- tion with Asymmetric Key encryption guarantees that ECDH does not su↵er from a man-in-the-middle attack [10, p. 178].

3.2 IHAP – Intel ® Heath Application Platform

The IHAP is an application software platform that can be used by remote care solution providers to enable a variety of remote health care usage mod- els [12]. This solution provides a software platform for managing health care data and securely delivering it to internet servers or remote devices.

The Flex IoT Compute Engine is a company that o↵ers the hardware solution for IHAP’s implementation. Together, they o↵er a comprehensive software and hardware solution for remote health care monitoring devices, o↵ering proper IP protection and data privacy [13].

The Flex IoT hardware solution operates with Android OS, making it possible to create Android Java applications for customized third parties’ solutions like the one in this project. It comes with the following set of wireless communication technologies: Bluetooth, Wi-Fi, 3G, and NFC. Its basic operation consists in connect and gather data from the di↵erent wireless health care sensors paired to it. And, after bu↵ering the data, it sends them in the IHAP’s chosen format to the pre-configured server through its internet connection.

The IHAP solution was chosen for this project because it o↵ers a specialized and standard solution for both remote health care monitoring devices and remote care solution providers, like Alleato. IHAP is, consequently, a standard that not only Alleato is already adapted to, but also is an industry- standard that can be used by a variety of di↵erent parties.

Figure 4 shows the software diagram of the IHAP Remote Healthcare Monitor System. The dataflow works from the bottom to the top of the image. The data path used in this project is highlighted in red. It starts with the sensors that send the measured data to the IHAP local hardware device

(22)

through Bluetooth. The sensors’ input di↵ers directly whether they support the Continua standard or if they are Non-Continua devices.

Figure 4: IHAP Remote Healthcare Monitoring System software diagram [14]

The Continua Health Care Alliance – CHA is a non-profit industry alliance of health care and technology companies. The aim is to maintain a standard in the transfer of medical information and improve the quality of personal health care services [15]. CHA uses the ISO/IEEE standards 11073 to enable health care data transfer.

Once the data is received by the Bluetooth of the IHAP hardware, the

(23)

IHAP software environment, referred by Austonio in INTEL’s documentation, process the data to deliver it to the server. If the sensor has Continua support, it is automatically processed inside the Austonio environment. How- ever, if the sensor does not support Continua, the third-party developer, responsible for this sensor, needs to implement the peripheral support inside the Austinio environment. To accomplish that, INTEL provides to the third- party developers an SDK that can be used to program the peripheral support inside the Android environment.

In the dataflow diagram in Figure 4, it is possible to notice that moving up the data path from the sensor towards the server, there is a division between FDA Database and Non-FDA Database. FDA stands for the United States of America Food and Drug Administration Agency. This agency is responsible for protecting, promote and regulate public health care in the USA. In what concerns health care devices, this agency analyses and grants approvals for the usage of medical devices. Therefore, if the sensor does not have FDA approval, it cannot be publicly used in health care inside the USA, and, by consequence, it cannot be processed in the Intel IHAP’s FDA approved database. However, Non-FDA Approved Database can still be used for testing and development usage. Moreover, it can also be used for devices destined for countries other than the USA. As long as they are approved by their local regulatory agencies, for example, the European Medicines Agency – EMA in EU or Pharmaceuticals and Medical Devices Agency – PMDA in Japan. However, the FDA and Non-FDA Database do not interfere in the overall dataflow of IHAP. It rather just feed the data in the proper database according to its FDA approval situation.

The data stored in the database, FDA or Non-FDA, is saved in persistent memory. So, in case of a power shutdown or a connection lost, the data is preserved and it can be forwarded in the next section. After storing the data, an INTEL’s application called Heath Delivery Organization (HDO) extracts it from the database and sends it to the configured destination in the Cloud according to the Configuration files settings.

(24)

3.3 Encoding

The Cambridge Dictionary’s definition for Encoding is the following: “to change something into a system for sending messages secretly, or to represent complicated information in a simple or short way” [16]. Therefore, cryptography is a type of encoding. However, both etymologically [17] and in several di↵erent pieces of literature [10] [18], cryptography is defined as a method to secure communication.

The encoding algorithm chosen for this project is Base64. Although it is also considered a cryptography algorithm, its main purpose is not to secure the communication. In this case, Base64 is simply used to represent the same information with characters with a di↵erent size base.

Base64 is necessary to represent the data in ASCII when transmitted through the di↵erent communication environments, especially in legacy environments that are restricted to US-ASCII data [19]. Base64 was created specifically to adapt legacy Multipurpose Internet Mail Extensions MIME, like SMTP which were limited 7 bits ASCII characters, to bigger character coding standards. In other words, Base64 converts newer and longer character coding standards, or any type of data with more than 7bits, to the base of 6 bits. Therefore, Base64 is suitable for encoding any binary format to be reliably transmitted over channels designed for text format only, such as HTML and CSS [20].

3.4 Bluetooth

Bluetooth is a short-range low-power wireless technology that operates in the ISM band centered in 2.45GHz [21]. It was first designed to replace the need for short-range cables in consumer electronics with robustness, low-power, and low-cost [22]. Over the years, this technology became extremely popular in the market. According to the Bluetooth Market Update Report from Bluetooth SIG Inc., over 4 billion devices were produced with Bluetooth technology in 2018 [23].

Throughout the decade of 2010, Bluetooth became extremely popular in short-range audio and stereo communications. In addition to that, the most

(25)

recent updates of the technology to Bluetooth 5 allowed higher data rates, reaching up to 3Mbits/s in Enhanced Data Rate [24, p. 188]. Therefore, the maturity and the popularity of the technology made the industry expand Bluetooth’s applicability in the Internet of Things (IoT) [25].

Bluetooth Low Energy is the communication technology used by Flex IoT Inc in its device. This version is also referred to as BLE and it characterizes by the lower power consumption in comparison with the classical Bluetooth version. The power-saving is between 2 and 10 times the reference value, which is the Bluetooth Classic [26].

The basic radio characteristics of BLE is GFSK modulation over a frequency band of 40 channels with 2MHz spacing between 2.402 and 2.480GHz [16]. The channel usage is based on Frequency-Hopping Spread Spectrum in which 3 of the 40 channels are used for advertisement and the remaining 37 are used for data transfer [26].

3.4.1 Bluetooth Pairing

To start a Bluetooth connection, the devices need to go through a pairing process. During it, the devices will exchange information to create a secure and encrypted network between themselves. This process is what creates and establishes the rules of the physical layer of the Bluetooth communication.

However, before understanding the paring process, it is necessary to un- derstand how the Bluetooth devices are identified in the network. Estab- lishing an analogy with the Internet, in which the Data Link Layer uses the MAC-Address, the Bluetooth also has a similar universal unique 48bit identification number. But, di↵erently from the TCP/IP network that replaces the MAC Address for a corresponding IP Address in higher layers of the network protocol stack, the Bluetooth keeps using its 48Bit Bluetooth Address throughout all layers [27, p19].

Before the paring process itself, one important aspect of the Bluetooth operation is the discoverability option. It can be divided into three categories: Silent, Private, and Public.

(26)

• Silent: Bluetooth traffic monitoring mode. It does not accept connection [19].

• Private: It is not visible in the network. It can only be connected if the master device knows its 48-bit Bluetooth Unique Address [28].

• Public: The device can be discovered and connected [28].

As mentioned before, BLE uses 3 of its 40 channels for advertisement.

Those are the channels in which the devices perform the pairing protocol.

At this point, the devices perform a ECDH key exchange to create a pair of private keys. During this process, a PIN code is often shared between the two devices, or normally it is added by the user with a UI of the device.

After the pairing process, the devices can start a routine of Frequency- Hopping throughout the other 38 channels. Finally, at this point, the data can start being transmitted.

3.4.2 Bluetooth Communication Protocol

The Bluetooth communication protocol starts with the physical layer (PHY), also referred to as Bluetooth Radio Layer [29]. It receives bitstream from the Medium Access Control – MAC and modulates accordingly and transmits it through the RF channel. MAC is composed of three main parts, the Base- band, the Link Manager, and the L2CAP.

The Physical Layer interfaces with the Baseband layer inside the MAC.

It is responsible for managing the physical channels, establishing the links and controlling the frequency-hopping. The Link Manager monitors and controls the links, like the pairing, authentication key exchange, etc. Fi- nally, the Logical Link Control and Adaptation Layer(L2CAP) controls the protocol multiplexing between di↵erent applications, packet composing, and de-composing [30]. Figure 5 shows the Bluetooth Protocol Stack.

As mentioned before L2CAP have protocol multiplexing capabilities. As it can be seen in figure 5, L2CAP stands between the baseband and the communication protocol, in this example, RFCOMM. Therefore, L2CAP provides an interface to the di↵erent higher layer communication protocols, like

(27)

Figure 5: Bluetooth Protocol Stack with RFCOMM [30]

Bluetooth Service Discovery Protocol (SDP), Telephone Control (TCS), and RFCOMM.

Bluetooth Service Discovery Protocol - SDP

The Service Discovery Protocol is a mechanism that allows devices to discover the services available and supported by its pair in the network. The protocol creates an SDP server that corresponds with an SDP Client. The Client communicates with the Server that contains the list of services and their corresponding attributes [22, p. 338].

After the SDP Client retrieved the service information, it can open a direct connection with the desired application. The SDP provides a way of discovering the services. However, it does not provide a mechanism for uti- lizing those services [22, p339]. Each service registered in the SDP Server has a Universally Unique Identifier, also known as UUID. The UUID consists of a 128bit number, but Bluetooth SDP also specifies a shorter version with 16bits, known as UUID16.

RFCOMM

The RFCOMM is a Bluetooth protocol that emulates serial port communication. Build over the L2CAP protocol, RFCOMM creates a direct link between two di↵erent device applications. It is a widely used protocol since it is quite simple to use and can be easily implemented in an application that

(28)

was designed for standard serial ports. Moreover, it is widely available in open-sources API and is supported by many operating systems [31].

The RFCOMM can emulate up to 60 di↵erent simultaneous ports. How- ever, the number of ports that can be used by applications in each device varies among di↵erent implementations [22, p. 401]. Therefore, in the RF- COMM application implementation, there must be specified a port number between 2 and 61. With that, the application recognizes the specific serial link from which it needs to read the input bitstream.

(29)

4 Software Development

This chapter contains in detail the software implementation of the Aggre- gator in the Raspberry Pi platform, along with the software and hardware design choices made during the development of this project. It is also described the data format created to organize the message to be sent to Alleato.

The encryption algorithms used in this project are delineated in this chapter. Both AES and RSA encryption algorithms are used and the reason for this design decision is also exposed. Afterward, the final encoding and the Bluetooth transmission to the IHAP device are detailed.

Finally, it is explained the process of programming the IHAP environment using an Android Development Environment. Because, in this part of the project, the android application is responsible to forward the data received through Bluetooth to the Alleato server using the IHAP SDK.

4.1 Embedded Platform

The embedded platform chosen to be used in the prototype of the Aggregator was the Raspberry PI 3. It is, nowadays, one of the most popular embedded platforms or, also referred to as single-board computers. This device’s most relevant specifications for this project are the following [32]:

• Processor: Quad-Core 1.2GHz Broadcom BCM43438 64bit ARMv8- ACPU

• SDRAM Memory: 1GB

• Bluetooth 4.1 BLE

The Raspberry PI 3 was chosen because it is a widely used Linux platform that enables quick implementation of the first version of the Aggregator. The availability of Bluetooth in this platform is also an advantage because it will not be necessary to adapt any hardware in this first part of the Aggregator’s implementation, for example, an external Bluetooth module.

(30)

4.2 Basic Functioning Structure

Figure 6 illustrates the data flow of this project. The data is generated by the di↵erent implanted sensors in the body and it is transmitted through the fat channel to the Aggregator’s In-body part. Since the inside body part of the Aggregator is not in the scope of this project, the Aggregator In-body will be simulated as a standard embedded device generating random data.

The communication between the aggregator’s in-body and outside-body will be made through a serial UART port.

After received at the Aggregator’s outside-body part, the data will be formatted in a JSON file. This file will be encrypted with an AES algorithm and the private key will be encrypted with RSA. Then, the result of the encryption processes will be encoded in Base64. Finally, the encoded result will be reassembled in another JSON file and sent through Bluetooth to the IHAP. When the Android application running on the Flex IoT Device receives a Bluetooth incoming message, it will format it in the IHAP’s standard HashMap format and forward it to Alleato’s server through a Wi-Fi connection.

Figure 6: Aggregator data flow

The overall data flow of the system works with the IHAP/Flex IoT De- vice listening to the data sent by the Aggregator. This strategy was preferred oppositely to actively pooling data. The main reason for that is to eliminate unnecessary communication between the Aggregator and the IHAP/Flex IoT Device. Since a diverse type of IMDs can be used and integrated into the

(31)

system, it is not possible to determine the ideal pooling rate. The IMDs can generate data at di↵erent time rates. Therefore, it would be necessary to have di↵erent pooling rates for the di↵erent combinations of IMDs types connected to the system. As a result of that, the Aggregator can be configured to send data according to the set of IMD’s connected to the system.

Consequently, the Bluetooth will only be activated when there is valid data to be transmitted. This is important to avoid the waste of battery.

4.3 Aggregator In-Body

The Aggregator In-Body was simulated in this project by an STM32F072RB ARM microcontroller. The simulator generates pseudorandom data in float number format with di↵erent ranges. They range accordingly to five mockup sensor types that simulate a scenario of an aggregator receiving data from five di↵erent IMDs.

The simulated IMDs have a corresponding sensor identification number that serves as a Unique ID. It identifies the type of sensor data that is being received and it will be used in the Aggregator Outside-Body to find all the relevant information about that sensor in the database. The sensor ID is concatenated with its corresponding simulated data separated with a semicolon. This string is then surrounded by a minor “<” and greater ”>”

characters to mark the beginning and the end of the data string. The final string format is: <[ID];[Value]>. An example of this representation can be:

<123456,2.345>where ID=123456 and its value is 2.345.

The data is forwarded to the Aggregator Outside-Body through a serial port UART. The configurations of the UART port were: Baud Rate 115200, 9 bits including parity, Odd Parity, and 1 Bit Stop. This configuration was used during the test performed in this project. However, it was not target of any specific and relevant consideration to this project or future project.

The UART communication interface has been chosen due to the availability in both STM32 and Raspberry PI.

(32)

4.4 Data Formatting

The data received from the In-body Aggregator needs to be integrated with the relevant metadata according to its specific sensor ID. Therefore, the Ag- gregator has a lookup table in a JSON file format that stores all the metadata for the IMDs for that specific patient. Therefore, for every patient, the Ag- gregator will have its JSON file containing the list of IMDs.

The JSON file is a standard format for storing and exchange of data. It is widely used in web service and it is a compatible format for the IHAP system. It provides a simple format of attribute-value pair that allows the organization of the lookup table of the sensor ID with its corresponding parameters.

The lookup table created for this project also works as a template for the format of the message. Therefore, it contains all the parameters that will be present in the final message. Those parameters stored in the lookup table for one sensor are the following:

• “ID”: Sensor ID Type

• “UniqID”: Unique ID of the IMD, that works as a serial number of the device.

• “Unit”: Data measurement unit

• “Value”: Field for measured data

• “measurementTime”: Time of the measurement

For every ID received by the UART port, the Aggregator will have a corresponding value in its lookup table. Then, it is possible to correlate it with the Unique ID of the IMD. This value is a serial number of the IMD and can be used at Alleato’s server to correlate this specific sensor with the patient’s data. In other words, it can be used as a reference to insert the data received through the IHAP system in the patient’s database in Alleato’s server.

The Unit field determines in which unit the IMD is measuring its corresponding physical quantity. This information is not received through UART

(33)

communication, because it is necessary to keep the data exchange in the Inside-body part as minimal as possible due to the limited bandwidth. There- fore, since the same IMD can take measurements in di↵erent units, the current IMD setting will be registered in the Aggregator’s lookup table.

The Value attribute will be used to store the actual sensor data received from UART. It will store a floating-point number that corresponds to the instant measurement of the IMD. In addition, the Measurement Time will be considered the exact time in which the Aggregator Outside-Body receives the information from UART. The format chosen to store the timing information is a standard used in IHAP and documented in its SDK file. The format is the following: ”yyyy-MM-ddTkk:mm:ss”.

Figure 7 shows a testing lookup table JSON file used for the project simulation. The mockup data is consistent with the standard used in IHAP, for example, the measurement units in percentage, mg/dL, mg, etc. The attributes names were defined using the same standardization criteria. Only the ID and UniqID do not have similar parameters used in IHAP.

Figure 7: Aggregator’s testing lookup table of sensors parameters

After extracting the corresponding sensor information in the lookup table, the sensor value received from UART is filled in the JSON object in the corresponding parameter tag. The same procedure is made with the current computer time which is filled in the JSON object accordingly. Finally, this JSON object contains all the sensor information.

However, before forwarding the JSON object to the encryption part of the algorithm, the header information is added to the message. This file contains specific information about the current aggregator. The parameters are Aggre-

(34)

gators ID, Manufacturer’s name, Patient’s Unique ID Number, Production Date, and Firmware Version. The content of the header in the Aggregator’s message can be seen in Figure 8 .

Figure 8: Aggregator’s JSON file with the message’s header

4.5 Encryption

One important parameter considered on the comparison of di↵erent encryption algorithms was availability in open-source libraries and type of key exchange. The encryption algorithm needs to be widely used for two main reasons. First, because there must be a library in C language available for use in Linux and embedded platforms. Second, because Alleato, and any possible third party that might end-up using this platform, needs to have the possibility to easily decrypt the message without over-complications. For that reason, only the most common algorithms were considered.

The OpenSSL library has been chosen to be used in this project. It is a robust full-featured open-source general-purpose cryptography library [33].

It has a comprehensive list of cryptography and encoding libraries for usage in C language and it is available in most UNIX-based Operating System, including the Raspberry PI OS. In this project, OpenSSL will provide the algorithms for RSA, AES, and Base64.

RSA cryptography is a commonly used asymmetric-key encryption system. In RSA, one of the parts of the communication generates a pair of keys, one public, and another private key. The main characteristic of this kind of algorithm is that a message encrypted by the RSA’s public key can only be

(35)

decrypted by its corresponding private key pair. Considering that, the public key can be shared publicly with the second part of the communication.

And, any possible message encrypted with this key will only be able to be decrypted by its pair, the private key, which is kept in secret.

The ECDH was considered because of its reliability and for being widely used in TLS connections. However, this would add an over-complication in the application, since it would be necessary to implement this handshake protocol with Alleato. Moreover, the communication between the IHAP and the Alleato sever will be implemented with an HTTPS. This protocol is already a TLS/SSL protocol that implements this key exchange, and it will provide the same security desired by the ECDH implementation in this application.

During the implementation of the RSA encryption, one practical problem was found. The message maximum size is limited by the size of the encryption key. In this algorithm of the OpenSSL library, the encrypted message size has a fixed value equal to the size of the encryption key regardless of the original message size. Figure 2 shows a graph of the encrypted message size in function of the original message size. This graph was generated using the OpenSSL library of an RSA algorithm. A series of a pseudo-random string of ASCII characters data was encrypted.

Figure 9: Graph encrypted size by original message size of RSA in OpenSSL library

As it is possible to see in figure 9, the encrypted message size is constant,

(36)

at 256 bytes, with the original message size. However, the maximum message size is 211 bytes, after that, the output results in an error. This maximum value is determined by the key size, in this example 256 bytes minus heap and header size which results in 211 bytes.

One of the possible solutions for this limitation was to split the message into smaller parts, concatenate them and send it. From the server-side, it would be necessary to decrypt the message in parts as well. However, this would add unnecessary complexity to the system because the decryption algorithm from Alleato’s side would need to decrypt the di↵erent parts of the exact same size.

The next proposed alternative is the Advanced Encryption System – AES.

This algorithm was chosen by the National Institute of Standards and Tech- nology - NIST to be its new standard. This standard is based on the Rijndael algorithm, which is a symmetric block cipher that can process data blocks of 128 bits using keys of 128, 192, or 256 bits [34].

The OpenSSL AES library did not limit the size of the message, it handles automatically the block size limit and allows any message size. The same simulation was the one performed for RSA was done for AES to test the proportion between Original Message Size and Encrypted Size. The result can be seen in figure 10 and it shows a direct proportion in which the Encrypted Size results in the same size as the original message.

Figure 10: Graph encrypted size by original message size of RSA in OpenSSL library

(37)

The adoption of AES creates the necessity for both parties of the communication to share the same secret key. However, this is not desired for this application since this key would need to be shared somehow between the two parties. This represents the main problem in symmetric encryption systems.

To solve this issue, it was proposed the usage of both RSA and AES.

The objective is to ally the encryption size and the common standard usage of AES with the asymmetric key benefit of RSA. The proposed solution in- volves the encryption of the message, containing the actual data, with the AES algorithm with a secret key generated by the aggregator. After that, the AES secret key is encrypted with the RSA algorithm, using the public key generated by Alleato.

4.5.1 AES

The OpenSSL implementation of AES provides a set of di↵erent AES algorithms and modes. The implementation in this project uses a CFB mode with a 128-bit size private key. For the testing purposes of this project, the 128-bit private key will be hardcoded in the source code. This key was generated by an OpenSSL random key generator. In the same process is also generated an Initialization Vector – IV which is necessary for the AES algorithm. Finally, both private key and IV are then used in the encryption functions to encrypt the string that contains the message in JSON format.

4.5.2 RSA

After the AES encryption of the message, the RSA encryption algorithm is used to encrypt the AES symmetric key and the IV used for that session of encryption.

The pair of public and private encryption keys were generated by the OpenSSL key generation function RSA generate key ex(). The pseudo-random number generator must be seeded before calling this function [35]. For practical purposes, this seed number must come from an unpredictable source of numbers. However, the discussion of the predictability of pseudo-random key generators is not the focus of this project. Therefore, for the testing

(38)

purposes of this project, the key pair was generated with the plain random function without seed initialization.

4.6 Base64

Base64 will be used in the Aggregator due to the combination of two factors.

First is the format of communication between IHAP and the Alleato Server, which will be performed in HTTP post requests. Second is the fact that the encryption process from the RSA and AES algorithms generates binary data that is not compatible with HTTP. Therefore, it is necessary to encode the binary encrypted data into Base64 to send it through HTTP. Three strings are originated from the encryption process with AES and RSA OpenSSL library. Before, proceeding to the Bluetooth transmission, they need to be encoded in Base64 as explained before.

The Base64 encoding process increases the size of the string by a factor of 1/3. This is because the encoding process replaces a string in the base of 8bits and recode in a base of 6bits, which causes this overhead of approxi- mately 33% depending on the total size of the string. Figure 11 shows an experimental result of the size comparison of encoding in Base64.

Figure 11: The encoded size of Base64 for di↵erent message sizes

After the encoding process, the resulting strings are added into another JSON file format. The used JSON attributes keys were UserKey, Ivec, and

(39)

Info, and they correspond to the AES private key, IV, and aggregators data.

Finally, the following attribute is added to the JSON object: ”Encryption”:

”AES-RSA”. It identifies the type of encryption used in the transmission.

4.7 Bluetooth

4.7.1 Bluetooth Pairing

The discoverability option of the Bluetooth in the Flex IoT device is in silent mode. This means that the device cannot be paired by any external device, but only the Flex IoT can pair other Bluetooth modules. The paring process in Flex IoT IHAP hardware is done by RFID tag. This increases the safety of the system since the only paring procedure starts with an Out-of-Band (OOB) channel. The RFID tag transmits the Bluetooth name and Blue- tooth Unique Address. With this data, it can request the pairing procedure with the Bluetooth Client.

For this project, the RFID tag was created through an Android App available in Google’s Play Store which is called TagWriter. This application was developed by NXP Semiconductor. It allows to write di↵erent kids of bitstream to be transmitted through the NFC embedded in the Android smartphone.

In the Flex IoT Device, di↵erent kinds of settings can be made using RFID tags. In this project, both Bluetooth and Wi-Fi setup were made using RFID with the help of the TagWriter App. In the Appendix 1, it is possible to find the description of the string format used to program the Flex IoT Device through NFC.

4.7.2 Bluetooth Programming

The Bluetooth library Bluez was chosen to be used in this project. It came as a natural choice because it is the official Linux Bluetooth Protocol Stack.

Bluez provides support to core Bluetooth Layers and Protocols. As specified by Bluez Project on its website [36], this library consists of many separate modules, among them are the following:

(40)

• Bluetooth kernel subsystem core

• L2CAP and SCO audio kernel layers

• RFCOMM, BNEP, CMTP, and HIDP kernel implementations

• General Bluetooth and SDP libraries and daemons

SDP was implemented as a mean to discover the corresponding service between the Aggregator and the IHAP Android Application. SDP has been chosen to be implemented in this case because, in IHAP’s Android environment, multiple Bluetooth applications may be implemented at the same time in the same connection. Therefore, it is necessary to guarantee that the connection link does not conflict with those di↵erent applications. An example is when two di↵erent services are registered to use the same RFCOMM port.

To avoid this scenario, in SDP, every service has a UUID that cannot be registered multiple times in the Service List. With that, it is guaranteed that every service has its own identifier, and the SDP protocol can assign di↵erent ports for each service when requested.

At the Aggregator’s side, the Bluetooth implementation is a Client that is programmed in C using the Bluez library. It will connect and send the encrypted data to a service registered in the IHAP’s side running in the Flex IoT Device. The client will start by connecting to the SDP server running on the remote device, in this case, the IHAP. For the connection, the IHAP Device Bluetooth Unique address is used for locating the correct device in the Bluetooth network. This number is coded in the Aggregator C code and, for the device used in this project, the number is: ”00:21:7E:01:59:D2”.

After a successful connection, it will search the corresponding service by the UUID. This service UUID has been added in the IHAP Android software.

Then, this UUID can be registered in the SDP server. And the same number was hardcoded in the Client’s side to be used to search the corresponding service. The UUID number used for the testing purpose of this project was generated using the function uuidgen, which is a native command-line function of Linux.

(41)

After locating the service at the SDP server, the attributes list is ap- pended so all the service’s records can be checked for compatibility with the client. In this case, no compatibility problems should be detected since the development of both server and client are made together. But, for standardization of the Bluetooth library usage, this process is kept during this implementation.

The port for the RFCOMM connection is extracted from the service’s attributes. With that, a Bluetooth Proto-Socket connection is performed with the IHAP device and data can start to be shared between the devices.

4.7.3 IHAP Configuration Files

The IHAP Flex IoT Device has a set of configuration files that are used to control several characteristics of the IHAP’s device operation. They are divided into two di↵erent groups of files: Communication Files and Man- agement. The IHAP Device file system does not allow manipulating, nor even reading, those files once they are inside the IHAP device. Therefore, to change those configurations, the files must be created in an external computer and sent to the IHAP Device using a tool called Android Debugger - ADB. The ADB allows the Android software developer to interact with an Android device, like manipulate files in its files systems.

In the IHAP device, the configuration files are located in two di↵erent folders at the root of its internal SD Card. The Communication files are in the path /sdcard/Communication and the Management files in /sdcard/Management.

The Communication folder contains the following files:

• Configuration FDA

• Configuration NonFDA

• And other specific sensors data templates

And Management folder contains files to adjust the specifics of the device, for example, set the Start-Up Application or enable the NFC Beam.

(42)

The names of the files in this folder are the following:

• Configuration

• DisplayConfig

4.7.4 The Configuration file

The Configuration FDA and NonFDA files consist of the same files. They di↵er whether the system will send the data through the FDA approved peripheral protocol or through the Non-FDA. In this file it is possible to set the configuration parameters, the most relevant ones are the following:

• Data Format: It can be set the format to the JSON structure.

• Security Format: To add another layer of encryption. The type of encryption is not specified in the IHAP documentation, but there is a field to configure a secretKey in the Configuration file which suggests symmetric key encryption. This option was not adopted in this project since the data is already encrypted directly in the Aggregator.

• syncTarget: This parameter is used to define if the data needs to be delivered to an HTTP server or another IHAP device. For this project the option chosen was the HTTP server, to send the data to Alleato’s server.

• Data Server IP: It is used to define the IP address of the target device, whether it is a HTTP server or an external device. For the testing purposes of this project, Alleato set a server with the following address:

http://tk.omsorgsportal.se/Receiver/

The other parameters configurable in this file are: Consumer Key, Date Format, External App Package Name, Request Method, Secret Key, Token Content-Type, Token Response Code, Upload Content-Type, and Upload Data API.

(43)

4.8 Android Application

4.8.1 IHAP SDK

The IHAP application is developed on the Android IDE provided by Google, the Android Studio. With this IDE is possible to program and debug An- droid Applications. The programming language used was JAVA, which is the most common program language used in Android native applications. Also, JAVA is the programming language supported by the IHAP SDK.

Intel provides, together with the IHAP SDK, an example code for simulating the IHAP in hardware. This code sends mockup data from three di↵erent simulated sensors. All the data originates from constants inside the code, consequently, no external Bluetooth connection is used for this purpose. This data is then organized in a HashMap object and then pushed to the corresponding database, in this case, Non-FDA.

This example code was important for simulating the functioning of the IHAP system with the hardware. And for testing the configuration files created for testing. Because, initially, a local HTTP server was developed in Python to simulate the reception of the data sent by this example code. As a result, the simulation worked as expected and the data could be read by the Python server.

The development of the Android application shows to be straight forward from the point of view of the IHAP SDK usage. That is because only a small part of the IHAP implementation is made by third parties’ development.

Only the Peripheral Support needs development, as explained in section 2.2 of this report. Therefore, pushing new data to the Database using the SDK function is the only part of the SDK actually used in the development, all the rest of Austinio parts works on the “background” from the developer’s perspective.

4.8.2 Bluetooth Server

The Android Application starts by creating a Bluetooth server and register- ing the service UUID in the SDP server. This is done by using the Blue- toothAdapter Class and calling its function that registers and listens to this

(44)

service number’s port. After setting the adapter to the correct service number, a Bluetooth Server Socket is created and is called its Accept() function.

By doing that, it will wait indefinitely for a client to connect through that socket.

Once the connection and the transfer from the client are completed, the data starts being processed. For that, another class is created to handle the JSON file. This class reads all the parameter names and separates them into a specific class. The format of this class parameters was created according to the JSON standard format created for this project and described in section 3.4.

The application has a counter that was implemented in the example code of IHAP SDK. This is an important value that keeps track of how many times data was pushed through the IHAP system to the Database. This counter is initiated and saved at the DataSharedPreference of the Android. This is a class from the Android API that stores key-parameters in persistent memory controlled by the Android OS. Therefore, this class was implemented using a Singleton Design Pattern, which makes sure that this class is only instan- tiated once during the running time of the application. This is done because the counter cannot be reinitiated under any circumstances to prevent data with the same counter number.

After the data is segregated into JSON objects, the corresponding parameters are reorganized in HashMap Objects. The counter is added to the HashMap to identify the number of the transmission. Finally, the resulting HashMap is pushed to the corresponding Database, in this case, Non-FDA Database, and the counter is incremented for the next transmission.

(45)

5 Results

5.1 Aggregator Outcome Testing

During the development of the project, the Aggregator outcome could be observed and evaluated by the performance of the di↵erent components of the code. The major parts of the Aggregator’s implementation consist in UART, JSON file manipulation, AES encryption, RSA encryption, Base64 Encoding, and Bluetooth transfer.

The UART port reading performed accordingly and the data received from the ST Microcontroller could be read. The UART reading functions were tested for its reliability. The main point used for testing is the con- sistency of the inputted data. The received string is tested to find out if the string is in the correct standard. Therefore, di↵erent testing scenarios were created with inconsistent data. The reading function was e↵ective in rejecting all wrong data in all tested scenarios.

The JSON file manipulation could be tested by printing on the console the final JSON string that resulted from the simulations. In Figure 12, it is possible to observe a simulation with a sensor with an ID equal to 123456 that measured a value of 0.5%. At this point of the code, it was possible to test the program efficiency in locating the specific sensor information from the Sensors Lookup Table. Besides that, it is possible to observe the consis- tency of the assembling of the final JSON string before encryption.

Figure 12: Simulation of final data string in JSON format with mockup sensor reading.

The encryption functions both for AES and RSA were tested with a round

(46)

of encryption and decryption of the JSON string. After the process, the integrity of the message is checked, and no data was corrupted in the process.

The tests were performed with strings of multiple sizes to guarantee that more information can be included in the final message.

The same testing process of the encryption was performed with the Base64 encoding. Besides that, the resulting encoded text with the mockup data was printed in the terminal. With that, the characteristics of the Base64 encoded could be checked for the presence of only characters of the Base64 index table.

The resulting string with the encrypted data can be seen in Figure 13.

This string is already formatted in the final JSON string with the corresponding tags, Encryption, UserKey, IVEC, and Info. In Figure 13, the UserKey and the Ivec are highlighted in blue, and the Data is highlighted in red.

Figure 13: Resulting string of the encrypted and encoded Aggregator’s data.

5.2 IHAP Application Outcome Testing

The IHAP Application was continuously tested during the development of the project. The IHAP implementation is composed of two main parts: Blue- tooth Receiver and IHAP Transmission.

The Bluetooth Receiver part could be tested initially by the capability of the Aggregator to create a socket via Bluetooth with the IHAP device. The connectivity of the Android application was tested checking the integrity of

(47)

the string received through the Bluetooth Socket. For testing purposes, the un-encrypted message was used to check if all the data was being transmitted correctly. Also, the Bluetooth connectivity from the Android perspective was tested considering its cyclicality. In other words, after fully processing the data as push it to the IHAP database, the Bluetooth needs to be available for a new socket connection. Finally, this aspect was tested, and the cyclicality of the system was correct.

To check the integrity of the data transmitted through the IHAP HDO, the transmission was tested in two di↵erent phases. First, it was testing the connection locally, and second testing with Alleato’s server.

For the local connection, an HTTP server was programed in python and set to run locally. The IHAP configuration files were set to transmit to the local IP address. As a result of this test, post requests started being received in the local python server. A new request was made every time a new Blue- tooth transmission was made by the Aggregator hardware. Consequently, with this testing setup, it was possible to verify some aspects of the transmission. First, and one more time, the integrity of the data with the same process used in the previous tests. Because it is necessary to guarantee this aspect throughout the entire process. The second aspect was the data persis- tency in the IHAP Hardware. For that, two di↵erent scenarios were tested.

Power shutdown or internet connection lost during the transmissions. During both tests, the data was preserved, and the transmission could be done in the next section and the data was lost. This could be verified by checking the data counter generated by the Android IHAP SDK. If no number in the sequence was lost, it means that no data was lost.

The test of connection with the Alleato’s server first started with a direct post request made from the Aggregator. Linux provides a tool call CURL that allows post requests from the terminal. The curl library was implemented in the Aggregator’s C program to test the availability of Alleato’s server. The test was successful, although it is not transparent since the server is only accessible by Alleato. As consequence, it was not possible to read the message back. The only feedback received is an HTML page with the message “OK”.

After testing the connectivity with the server, the Configuration Files

(48)

were updated with Alleato’s server URL. The IHAP was then run and the data started being transmitted by the Aggregator. However, since it was not possible to monitor the server’s input, it was necessary to rely only on the IHAP’s display for information about the successful transmission.

5.3 Alleato’s response

After the final tests were performed, Alleato AB sent back the content up- loaded to their server. In figure 14, there is the upload received by Alleato in their server resulting from the Aggregator’s transmission. It is highlighted the JSON parameters and their corresponding data. It is possible to notice the parameter Pulse as well, which corresponds to the count number of the IHAP application. In this case, the count is 1718 which was the number of test transmissions made during the project until this specific transmission.

Figure 14: Aggregator’s upload results received by Alleato

Another parameter included in the IHAP environment is the peripheral identifier of IHAP, the “unknown peripheral type”. This parameter indicates that the peripheral transmitted is not register in the IHAP as a standard device.

Aggregator to connect in-body sensors to the health record system

Juni 2021

Aggregator to connect in-body

sensors to the health record system

Pedro Gomes Freire

Institutionen för informationsteknologi

Aggregator to connect in-body sensors to the health record system

Acknowledgement

Contents

Glossary

1 Introduction

1.1 In-body networks

1.2 Aggregator to Connect the IMD to the Health Record System

1.3 Results Summary

1.4 Thesis Report Structure

2 Related Work

3 Background

3.1 Cryptography

3.2 IHAP – Intel ® Heath Application Platform

3.3 Encoding

3.4 Bluetooth

4 Software Development

4.1 Embedded Platform

4.2 Basic Functioning Structure

4.3 Aggregator In-Body

4.4 Data Formatting

4.5 Encryption

4.6 Base64

4.7 Bluetooth

4.8 Android Application

5 Results

5.1 Aggregator Outcome Testing

5.2 IHAP Application Outcome Testing

5.3 Alleato’s response