Projects:2016s1-160c Cyber Security - Personal Networks and Devices
Group Members: Michael Hua, Olga Rodionova, Petko Stefanov Supervisor: Matthew Sorell
Contents
NFC Security
Author: Michael Hua
Introduction
Near Field Communication (NFC) is a form of wireless communication over a very short range in the order of centimeters [1]. NFC technology differentiates from other forms of wireless communication with its speed and efficiency. The communication between two devices is able to occur in just seconds with minimal overhead setup costs that is associated with Bluetooth and QR Codes. Communication can happen in various modes: Active – Active, Active – Passive, Passive – Active; where active devices have their own power supply and passive devices are powered from active devices via induction [1, 2]. An example of an active device may be a smart phone and a passive device may be an NFC Tag. NFC tags are a common technology where a tag is able to store data (a simple message or data structure) and is able to be read by an NFC capable device, such as a smart phone [1].
The Security Issue
In a society where technology is advancing at an astonishing rate, technology such as NFC seems very promising. NFC technology markets itself as quick and easy, however, the compromise or trade off would be security [1]. NFC is able to enhance the quality of our current technology and opens up more possibilities. Thus the motivation behind this research project is to strengthen NFC security in attempt to promote further development and utilisation of NFC-Tag based applications and NFC based technology.
Because the NFC scanning process is so quick and easy, there are major security issues involving confidentiality, authentication, integrity and access/availability. Upon further investigation, there are have been multiple studies and analyses which delve into this issue further. However, by breaking down the entire end-to-end NFC scanning process, it is evident the current investigations and research targets the middle stages of the process, mainly considering the stored data itself.
A recent security exploit in NFC revealed that a hacker was able to implant an NFC-capable chip in his hand (refer to right image) and able to exploit members of the public by infecting their device with malware [3]. Although, the malware is quite simplistic and limited with numerous drawbacks, the fact that these devices could be easy compromised is an issue of concern [3].
A breakdown of the NFC scanning process into four steps:
1. Scanning of the NFC capable devices (devices or tags);
2. Notification;
3. Authentication, encryption and integrity check;
4. Network and content integrity.
Proposed Solution
To directly combat this issue, a solution has been proposed making the first step of the NFC scanning process more deliberate by incorporating numerous conditions. If and only if these conditions are met, will the NFC scanning process be allowed to proceed. Previously, if an unlocked NFC device and NFC tag were brought into very close proximity of each other, the device would successfully scan without permission from the user; this was the fundamental problem with the security breach where the hacker implanted a chip into his hand.
The underlying principle behind the proposed solution is to make the process of NFC require active input but still remain as quick and as convenient as it were before. Basically, the NFC capabilities will indefinitely remain disabled until certain conditions are met. Once these conditions are met, the NFC capabilities will be enables for a short period of time where the user is then able to scan and utilise the NFC functions. After this brief period, the NFC capabilities will then again be disabled indefinitely.
To test the feasibility and demonstrate this, a simple android application was developed. The application disables the phones NFC capabilities and only enables it only for a short period of time if the proximity sensor is not obstructed and the phone detects a shaking motion.
As the reputation and major selling point of NFC technology is that is quick, easy and convenient, the conditions to enable NFC communication must align with this very idea. The conditions required deliberate human action but must remain quick and convenient because if it becomes too complex, there would be nothing deterring developers and users towards Bluetooth or QR Code technology – other forms of short range wireless communication.
The first condition which must be met is proximity. Under normal circumstances when a user decides to scan another device or an NFC Tag, the proximity sensor is unobstructed – it is counter intuitive and very unlikely a user will purposely scan their device with the proximity sensor obstructed. The idea behind this condition is to prevent a device being unknowingly scanned by a hacker if it is faced down, in the user’s pocket or bag, etc. This is just one of the two conditions proposed in attempt to improve the security of NFC technology.
The other condition which must be met is a deliberate action. This deliberate action takes advantage of the phones accelerometer. This is a personalised action set by the user and could be a swish, a shake or any personalised action which can be recreated by the user. This deliberate action condition in most cases completely removes the possibility accidental and unwarranted scanning of devices. Furthermore, it idea of a simple physical action as one of the conditions to enable NFC capabilities still align with the fundamental idea and selling point of NFC technology. Although it does require an additional active input to enable the function it is still very quick, easy and convenient.
Conclusion
The application was successfully implemented with all the designed features. It was then able to be tested with NFC Tags. The overall conclusion is that this idea is feasible although there is a slight delay in the NFC being toggled on/off. Furthermore, the shaking motion is quite generic so this method will only be able to prevent some forms of unwarranted scanning. Where the original idea was to make this shake any form of custom motion, the next logical step would be to implement this and further build on the application. This next step should be able to have a “capture mode” where for a short period of time, records and stores a personalised motion through manipulation of the accelerometer. This can then replace the shake detector module; so if the phone is unlocked, the proximity sensor if not obstructed and the personalised motion is recreated, the phones NFC capabilities will be enabled for a short period of time.
Though the application is not the main purpose or goal of this research, it is just a simple and easy method to practically demonstrate and test the feasibility of the idea. If it is determined this method is feasible and practical, phone developers may consider incorporating this additional security measure into their phones; this could be achieved much more easily without all the limitations encountered as an amateur application developer. Furthermore, it wouldn’t be in the form of an application, it would have to be implemented into the phones operating system and always running as a background operation.Although the protocol has been proposed for the use with NFC Tags, if technology is further developed, the same concept should be able to be utilised in all modes of NFC communication (active-active, active-passive, etc).
Future Works
As the NFC scanning process has been broken down, it is evident another aspect of security in the NFC process which has yet to be considered is security from the back end. This is at the final stages of the process where the user has intentionally communicated with another device where the stored information has passed all checks for authenticity and integrity. Some ideas which can be further research would be along the lines of some network based security solutions. This may entail checking the software against a known blacklist/whitelist etc. Another alternative can be the use of an antivirus; this could potentially extend to an online antivirus of some sort as the device may be limited in size. Furthermore, a sandbox environment could also be utilised where the program is executed in an environment which is isolated and not able to interact with other elements of the system.
These are just some aspects of NFC security that can be further investigated. Overall, the future of NFC is promising; it is a quick, easy and convenient method of wireless communication with much potential. However, further research and development is required to strengthen and improve its security before it is utilised more widely in a commercial sense.
An analysis of security flaws in the NFC functionality of modern mobile devices
Author: Petko Stefanov:
Introduction
Problem Statement
Near Field Communication (NFC) is a relatively new communications protocol used in most modern mobile devices. It is used for very close range communication between devices or compatible NFC capable objects. One such object is a NFC tag, which can store instructions to be executed by any device that ``scans" it via NFC (e.g Go to a website, call a phone number or access an application). While convenient, such tags can be manipulated to store malicious instructions which can harm or compromise the device. The lack of security protocols on mobile devices make this form of malware infection very easy to execute. This project aims to introduce a solution to this problem by implementing a method in which a user may be able to stop their device from performing instructions transmitted by a malicious NFC tag, after it has been scanned.
Motivation and Significance
NFC is a tool that is being more and more widely used in mobile devices. However, the security flaws associated with it hinder is implementation. This project is important as it helps address these issues and possibly find a solution to them, thus providing a safer device to the user with the convenience and flexibility NFC allows for.
Objectives
1. Prepare an in-depth literature review covering security flaws in NFC tags, methods of attack and past attempts to provide solutions.
2. Propose and design a solution. At this point in time, this is likely to be a system which takes into account prevention of scanning malicious NFC tags and limited protection once a tag is scanned.
3. Analyse designed solution and identify strengths and weaknesses.
What is NFC?
NFC or Near Field Communications is a set of wireless communication protocols, mainly used in mobile devices. It is a derivation of RFID technology in the sense that it uses electromagnetic induction to power NFC compatible objects and transmit data to devices[1]. It transmits data at 13.56MHz and very short ranges (around 4-10cm)[4] and can transmit from device to device or via passive NFC objects (called tags) to device simply by placing the appropriate device or object within range of each other. Because of this short range, NFC uses very little power and does not require any pairing code[4]. Thus primary uses of NFC are for very quick transmissions of data from devices, normally for user convenience in replacing mundane actions.
NFC Tags
Among the many functions of NFC, many utilise objects called NFC tags. NFC tags are passive objects that contain a computer chip which allows for interaction with NFC compatible devices. Their general purpose is simply to store instructions which (if compatible) are executed by the device that scans it via NFC. These instructions can be simple as ``call a phone number", ``access a URL", ``open an application", or as complicated as ``open this electronic lock", ``deduct payment from my funds"[5].
NFC tags contain no power source, thus are deemed ``passive"[5]. They are powered exclusively by electromagnetic induction from the scanning device and are automatically scanned when within range of an NFC enabled device. Specifically speaking, one only needs to place their phone within close proximity of a tag, and if compatible, whatever instructions it contains will be scanned executed without need of input. This convenience is a major driving point in the implementation of NFC in consumer electronics.
However, it is important to note that of the major mobile brands, only Android devices have the capability of scanning NFC tags. Apple devices, while they do possess peer to peer capabilities for services such as apple pay, do NOT possess the ability to scan tags at will[6]. This is likely to do with the security issues that come associated with the ``convenience" of having tag instructions being executed automatically with no user interaction. Apple having a very user friendly and secure public image likely does not want to implement NFC in its full form due to these security issues.
Security Flaws
Phishing attacks
This is the most commonly encountered attack type for NFC tags. The basic definition of such an attack is the NFC tag containing a URL link to a website that has the possibility of compromising the victim's device. Such attacks are normally carried out by convincing the victim that they website they are accessing is legitimate and trustworthy [7]
A defining aspect of a phishing attack is the victim willingly inputting sensitive information, believing the source to be a reputable and secure party [7]. Such attacks can easily be executed via NFC. Taking the smart poster example from stage 1, an attacker can mimic a smart poster but program the embedded tag for malicious purposes. For example the poster can advertise a promotion which is accessible via a social media website, which the embedded tag links to. However, unknown to the victim is that the linked social media website is counterfeit and the data they are inputting is being received by the hacker's database[8]. In other words, the attacker has essentially created a website that ``looks" like the legitimate version and storing personal and sensitive information from the user, which can then be used by the hacker for nefarious purposes. After the victim has successfully entered their personal information (such as login credentials and/or name), they are then redirected to the legitimate website and thus unaware of what has transpired[8].
Malware Infection
Malware infection via NFC is done by using the wireless connection to instruct the phone to access an outside piece of software which infects the device.
The end goal of such an attack is to infect a device with malware. However this normally can't be done by directly sending software over via the NFC tag, as they contain too little memory to store large files. Thus, the most common form of malware infection via NFC is to store a link to a website on the tag. The website then downloads a piece of malware to the device via an internet connection, thus infecting it[8].
But why? Malware is software designed to damage or disrupt a device. The type of malware depends on the intention of the hacker. In cases of infecting mobile devices, these are some common types of malware the hacker can employ:
-Spyware: which records user activity on the phone. This gives sensitive information to the hacker such as login credentials, identity credentials or financial credentials [9]
-Bots: which can give the hacker remote access to he device and the ability to control it [9]
-Worm: which is the most commonly used type of malware. Worms can replicate themselves and then attempt to spread to other devices in the victim's connected network [9]. It's very possible that a worm infecting a mobile device via NFC is only using it as a mode of transportation until the phone connects to a home network to which the worm can spread to the victim's personal computer.
Proposed Solution
Overall security design will have 2 components. A ``front end", which prevents unwanted tags from being scanned in the first place at the user's discretion, and a ``back end" that analyses a scanned tag's contents and determines if it is harmful to the device, blocking it if so
Front End
The chosen design incorporates a combination of the Proximity Detector and Accelerometer methods. The reason for this is they both are non intrusive additions to the NFC protocol by only requiring the user to hold a device a certain distance or move it a certain way. As well as this, using both these methods covers a wide range of attack methods. The requirement for phone movement when scanning the tag provides an input which only the user can make when they wish to scan the tag, preventing most attacks. The proximity sensor then provides a nice backup requirement for when there is unwanted movement on the device (such as when it's in the user's pocket). Thus, the combination of both provides a secure front-end protection ensuring that if a tag is scanned, the user was the one who initiated it.
Back End
When considering the above options as to how to organise the Back-End Security layer, the design can be divided into 3 possible sub-layers of protection:
1. Browser Level
2. File Level
Browser Level Protection
The browser-level protection focusses on stopping a scanned tag from linking malicious URLs. In this design, browser protection is implemented much like Browser protection seen in most Desktop security suits: with a Blacklist of untrustworthy and malicious URLs. When a new tag is scanned, and its NDEF message is detected as a URL, the user device will scan through the blacklist to see if it matches a known malicious site. If so, then the execution of this instruction is halted and the user is presented a pop-up message which states ``This URL links to a harmful website. Do you still wish to proceed?". The use now has a final choice in continuing on (ideally, then should press ``no"), if so the URL proceeds to open as normal. If the user pressed ``no" on the prompt then the execution of the tag's instructions stops. It is important to note that this ``final warning" is a pop-up prompt. Whilst it was discussed that such messages detract from the convenience of NFC and are seen as an annoyance, in this case, where the device is CONFIRMED to be in real danger, such a warning is necessary. As well as this, such prompts will not occur often unless the user is seeking out malicious tags on purpose.
Along with the blacklist, there will also be a whitelist to work in conjunction with it. What this does is allow for the possible detection of several different types of malicious URLs that were not found in the blacklist. So if the URL in question:
1. Links to a phishing website: The website in question will not be whitelisted, thus a message/icon is shown to the user, stating that this website is not secure/confirmed. If the phishing site in question is attempting to mimic a legitimate site that IS whitelisted, then the user will be able to know that the URL liked by the tag is fake.
2. Links to a site that downloads malware: In this case, the browser security cannot check if a piece of software is legitimate, thus if software is downloaded, then it is passed onto the File-Level sub-layer for a security scan.
In either case the user has some form protection against the URL in question which is vastly more secure than the current form of the technology. It is also important to note that the lists themselves must be frequently updated to keep up with new sites being created, and come from a trustworthy source. For Android devices, it is in the best interests of the developer/manufacturer to ensure this list comes directly from them as they can have confidence in their device security, thus guarantee safety to the consumer.
File Level Protection
The design on protecting the device at a File-Level will mimic the structure of a desktop Anti-Virus program in the sense that it shall use Signature, Heuristic and Behavioural detection methods. The combination of these 3 security checks on a file should be sufficient to detect malicious behaviour and successfully flag it as malware.
When a file is detected via NFC tag or NFC linked URL, the system shall first check a whitelist of file signatures to see if the file in question has been deemed ``safe to execute". If the system finds a match in the list, then the file is immediately executed with no check. This list is initially created by the 1st party developer (e.g Google), but after which it will be added to by the security system as files are deemed ``safe" by the subsequent detection systems. The reason for this is to save processing power, particularly in the behaviour based detection which shall use sandboxing, which is computationally intensive. Thus, to avoid long wait times, the whitelist shall be used to allow previously scanned files to execute normally.
If a match is not found, then the file first undergoes Signature based detection. The signature based detection shall once again, utilise a blacklist of known malware to compare the tag's contents' signature with. A file, whose signature matches a known malware shall be blocked and the user shall be notified with a pop-up notification. The user is then given an option to either delete the file (recommended), or proceed at their discretion, at which point the file is executed as normal. Like the whitelist, the blacklist shall also be developed initially by the 1st party developer, but as well as this, any detections in the later methods will add the detected file's signature to the blacklist for quicker detection in the future.
If the file passes the signature based detection, it shall undergo heuristic based detection. If possible, the contents of the file in question are accessed and analysed. The code of the file in question is analysed by the system with the intention of locating common instructions associated with malicious behaviour. These actions can include (but are not limited to):
-Excessive amounts of copying of the file to different locations on the device
-A program that attempts to access, modify or replace core system files
-A program that seeks to write to restricted device memory without permission
-A program that remains in memory after execution
-A program that remains dormant but behaves differently after a certain period of time
-A program that creates a back door by monitoring wifi connections for a specific signal (I.e Malware awaiting remote instructions from an outside source via WiFi. Most common in bots)
-A program whose code is noticeably similar to that of known Blacklisted malware
If the analysed program's code exhibits any of these features, the program is flagged as malware and a pop-up notification is presented to the user where they can decide how to proceed. As well as this, the file's signature is added to the blacklist for faster detection in the future.
Finally, if the file in question, passes the heuristic detection, it undergoes behaviour based detection. To test a program's absolute behaviour, it must first be executed. Obviously, doing this on the device itself is counter-intuitive as the goal is to protect it from possible malware. So to counteract this, the ability for the system to create a sandbox environment to test the program shall be added. The methodology used for behaviour analysis is the approach of using machine learning to establish a model of how software interacts with the system. This allows the sandbox to safety predict and evaluate which interactions are safe and which are malicious as the program executes in real-time based off previous data obtained. This model will likely include interactions such as those described in the heuristic detection and categorise them as malicious. If the system determines the executing file as displaying malicious tenancies, it is flagged as malware and the same pop-up notification mentioned before is displayed. To ensure trust in the system, the model used should come from a trusted developer (e.g. Google directly) to ensure the data used in system predictions is trustworthy.
However, if after all these security checks, the file has not been flagged as malware, it is free to execute as normal. As well as this, the signature of the file is added to the whitelist, to allow for faster execution in the future. The primary reason for this is that behaviour monitoring methods (particularly the sandbox) are computationally intensive, thus take a noticeable amount of time to perform. To preserve the convenience of NFC, it is desirable to keep functions that slow down the use of the protocol to a minimum. Thus, whitelisting established ``safe" files avoids unnecessary repetition of the malware scanning processes.
Conclusion
The proposed design addressed the security flaws in NFC by implementing 2 security layers, which each addresses specific security flaws in the NFC protocol. The Front End layer adds more control to the user on when NFC is active on their device. This is done by putting in a distance and movement requirement on the device which the user must first perform, signifying their input in order for NFC to be active. This stops a wide variety of attacks that seek to forcible initiate a NFC scan without the user's knowledge. The main downside to such an attack is using the user's consent against them, by tricking them into scanning malicious tags.
This is addressed in the Back-End layer, which implements an automated system to check if the contents of the tag are malicious before executing, and stopping execution if so. This is implemented by first checking if the tag links to a URL or sends a file. In the case of a URL, the system employs blacklisting to determine if the site is confirmed malicious (blocking if so), and whitelisting to determine if it is trustworthy. In they case of a file being sent via NFC or downloaded via URL link, the Back-End layer employs an Anti-Virus architecture by utilising Signature based detection, Heuristic based Detection and Behavioural based detection via sandboxing to determine if the file is malware, and blocking it if so. This layer is successful in detecting a wide variety of malware, but does experience some difficulties. It can't detect content beyond URLs/Files, prone to false positive detections depending on the precision of the behaviour detection model, and is susceptible to malware that can detect sandboxes and change it's behaviour. However, such files are rare to encounter and can still be detected by the other 2 detection styles.
Overall, despite some weaknesses in that can be improved in future work, the design covers a wide variety of attacks and is vastly more secure than the existing state of NFC.
Future Work
Implement Design
With a basic design outlined, the next step is to test its effectiveness by implementing it in a test environment. As tag scanning are primarily aimed at Android-based devices, the logical first step is implementing an Android app to implement the security layers. Google offers the Android Software Development kit for free use. This offers a software package to program apps and a testbed for emulating android device, or the ability to download and execute to a real device, thus testing it.
Add Malicious Instruction Detection
As explained, a weakness in the Back-End layer is the inability to detect tag content outside of URLs and Files. NFC tags can send instructions to the mobile advice, opening the internet browser and executing the file are just one of many. An attacker can easily add an instruction to connect their device to the victim device via another form of wireless communication (e.g. Bluetooth), and exploit this to send malware. As such, an issue that must be addressed is researching methods of detecting these malicious instructions as a whole, instead of focussing on just the two most common ones
Detect Environment Aware Malware Behaviour
Another weakness of the Back-End security layer was the file level sub-layer's inability to detect malware with the capacity to recognise when it's being executed within a sandbox, thus disguising its behaviour, avoiding detection. As of now, this type of malware is the biggest weakness the design has, and while it is possible to detect such files via Signature and Heuristic execution, there is still the possibility of avoiding detection. As such, adding another form of detection to the file level sub-layer specifically to detect this type of malware would be invaluable to the overall security of the system.
References
[1] M. Mareli, S. Rimer, B. S. Paul, K. Ouahada, and A. Pitsillides, "Experimental evaluation of NFC reliability between an RFID tag and a smartphone," in AFRICON, 2013, 2013, pp. 1-5.
[2] M. Roland, Security Issues in Mobile NFC Devices: Springer International Publishing, ISBN 978-3-319-15487-9, 2015.
[3] M. R. (2014, 2 April 2016). Taking “being connected” to the next level: Man implants NFC chip into his hand. Available: http://www.phonearena.com/news/Taking-being-connected-to-the-next-level-Man-implants-NFC-chip-into-his-hand_id62057
[4] R. Triggs, ``What is NFC \& how does it work?", Android Authority, 2013. [Online]. Available: http://www.androidauthority.com/what-is-nfc-270730/. [Accessed: 30- Mar- 2016].
[5] R. Triggs, ``All you need to know about NFC Tags", Android Authority, 2016. [Online]. Available: http://www.androidauthority.com/nfc-tags-explained-271872/. [Accessed: 30- Mar- 2016].
[6] ``What Happens When iPhone NFC Opens Up ?", Rapidnfc.com, 2016. [Online]. Available: http://rapidnfc.com/blog/121/what\_happens\_when\_iphone\_nfc\_opens\_up. [Accessed: 02- Apr- 2016].
[7] R. Dhamija, J. Tygar and M. Hearst, ``Why Phishing Works", in SIGCHI Conference on Human Factors in Computing Systems, New York, 2006, pp. 581-590.
[8] K. Gold, S. Shetty and T. Rogers, ``A testbed for modeling and detecting attacks on NFC enabled mobile devices", in Military Communications Conference, MILCOM 2015, Tampa, FL, 2015, pp. 635 - 640.
[9] N. Lord, ``Common Malware Types: Cybersecurity 101", Veracode, 2012. [Online]. Available: https://www.veracode.com/blog/2012/10/common-malware-types-cybersecurity-101. [Accessed: 09- May- 2016].
Medical Data Security in wearable fitness devices
Author: Olga Rodionova
Introduction
With an increasing number of hospitals implementing an electronic patient record system, IoT (Internet of Things) devices will soon become integrated into hospitals. Recent trends show commercially available wearable fitness devices collect a great amount of medical fitness information, such as the user's heart rate. This trend indicates a possibility of implementing fitness bands as medical devices in the future. This project aims to explore security and feasibility aspects involved with the potential integration of off-the-shelf devices into a hospital environment. Fitness band security is a major concern, as medical devices may require a higher level of security than the one currently present in commercial fitness bands. Hence, an in-depth analysis of fitness band network security, as well as data integrity is required in order to determine whether fitness bands are suitable for a hospital environment.
Significance
Long-term cardiac monitoring does not allow for real-time data analysis, as the medical practitioner obtains the data from the holter monitor once the procedure is complete. Even though real-time monitoring is possible for inpatients, emergency alerts still rely on patient- triggered alarms and CCTV footage rather than cardiac monitoring. The use of internet- connected sensors can solve this problem by alerting the medical staff instantly if there is a change in the patient's condition. In addition, the patient is no longer required to activate an alarm or alert emergency services manually, as this task can be performed by the inter- net connected device. This service is crucial in emergency situations, as the patient may not have time to alert emergency services, or lose consciousness. The development of this service in hospitals or in the patient's home can save lives, as well as improve the efficiency of medical and emergency services.
Fitness band use could also provide an inexpensive and simple way to track in and out patients and collect patient information in a comprehensive online database on the cloud. The integration of medical e-health records with already existing fitness device cloud services can aid in its fast development. The use of existing fitness band user accounts with medical data could also empower the patients by allowing real-time access to their medical statistics. Furthermore, fitness devices are designed for long-term wear, and will provide more comfort than current holter monitoring which relies on strapping the monitor to the patient's chest. Hence, wearable fitness devices can be implemented in hospital for a wide range of medical purposes from critical patient monitoring to long-term heart rate and sleep measurement procedures.
Background
Wearable Fitness Device Market
The wearable fitness band industry is growing rapidly and is predicted to expand from $2 billion to $5.4 billion by 2019 [1]
In 2014 alone, the wearable fitness device market has grown by 223.20% . This indicates a trend of further wearable device development that will provide the user with more advanced data than before. For example, Google is developing a smart contact lens that measures the wearer's blood sugar levels [3].
Currently, popular brands include FitBit, Apple and Garmin, with many others on the market. Wearable fitness bands are designed to be worn by the user 24 hours a day and collect data such as a user's heartbeat and step count. The type of physical activity, GPS location, sleep duration and floors ascended can also be recorded. This data is stored in the user's social media profile, which is a part of the fitness band's cloud service. In addition, the users are encouraged to record their meals, moods and fitness goals using their social media profile.
Fitness Band Communication
Fitbit devices can typically store data for up to 30 days [4]. However, the fitness device is intended to be synced to a smart phone or laptop frequently, allowing real-time data to be displayed on the user's device when the fitness band is connected.
Data storage is a three-level process: user statistics are tracked and stored on the fitness band until they can be transferred to a fitness band application on a smart device (smartphone or laptop) via BLE. From a smart device, the data is passed on via the Internet to the cloud service, linked to the user's account.
Proposed Hospital Architectures
Since it is likely that wearable devices will be merged with an already existing e-hospital system, the architecture for allowing the device integration will need to be carefully considered. This section outlines some potential high-level architectures that will incorporate wearable medical devices into a hospital system, allowing both the patient and the medical staff access to the data. The device architecture will resemble current commercially available devices as closely as possible in order to simplify integration and take advantage of existing features. Hence, each fitness band will be synced with a smart device, such as a tablet by the patient's bed or a Smartphone, which will then connect to the wider hospital system.
There are many advantages in implementing a cloud service in a medical environment. Adopting cloud computing would provide a comprehensive, on-demand service that is scalable for future medical expansion. These features would allow the hospital system to process and analyse data from the fitness bands in ways currently not possible by commercial applications. For example, the data received can be categorised depending on the type or patient (eg. emergency data) with a medical report provided accordingly. In addition, other services involving different internet-connected devices can be implemented into the cloud system in the future. Furthermore, a 2011 Microsoft case study has demonstrated that using cloud computing has reduced costs in an Italian paediatric research and treatment center. [5]
Previous studies on medical cloud computing feasibility have expressed the need for an Electronic Health Record infrastructure [5] for the service to contain full functionality. Implementing cloud systems separately will result in disconnected modules of cloud records that cannot communicate between themselves. In Australia, digital health record infrastructure already exists in the form of My Health Record and can be potentially integrated together with a cloud system.
The Australian national Electronic health record, known as My Health Record (previously titled 'Personally Controlled Electronic Health Record') is a digital record that is available on an opt-in basis. The user's digital record is accessed through their myGov (the Australian government services) account, with the user allowing medical professionals to access their record. Access settings can be modified by the patient by either controlling the access to individual documents, or setting a 'record health code' that can be shared with healthcare professionals to allow them to view the patient's whole record. In addition, the user can see which organisations have accessed their information, as well as the time of access and its purpose. Figure 13 displays a sample home page of a user's account. The 'Health Snapshot" section contains a summary of the user's results and their information settings. These settings empower the patient and encourage them to take control of their health and medical information, similar to what the medical fitness band system proposes. Another panel can be integrated into the user's home page to allow for real-time medical monitoring from their fitness band.
The information currently provided through the My Health Record system is medical prescriptions, hospital discharge information, pathology and digital imaging reports such as blood tests or X-rays [6]. Users are also encouraged to provide additional information like allergies or healthcare preferences in case of an emergency. A fitness band device can be incorporated directly into the My Health Record system, as the measured data can be classified as a pathology report. There are two potential methods of using this system: allowing the data to be uploaded directly to the patient account, or indirectly through their medical professional.
In the first instance, the user's My Health Record is integrated with the original fitness band account. Raw fitness band data can be accessed by the fitness band user directly through the My Health Record account. The patient will then allow their health professional to access the data, and a pathological report will then be provided by the medical staff.
Conclusions
With the recent trends of the wearable fitness band market converging on the medical IOT space, this study has considered the feasibility of integrating wearable fitness bands directly into the hospital system. It was assumed that the data collected by fitness bands medically reliable for hospital use, while the device security and data integrity analysed. The three-step Fitbit communication system between the device, a smartphone and the cloud was used for the security aspect study.
This paper has demonstrated various benefits of replacing current hospital heart rate monitors with an internet-connected fitness band system. Firstly, fitness bands provide more comfort for long-term wear than heart rate monitors and the associated applications encourage the user to be involved in observing their heath information. Secondly, the associated system will increase productivity and reduce hospital costs, with cloud computing systems demonstrating lower costs previously. Finally, the fitness band system and its cloud computing service can be integrated into a comprehensive, universal digital health record.
Although the medical system would benefit from the introduction of fitness bands, several changes will need to be applied to ensure the system has appropriate security. Previous studies have shown that most fitness band devices contain a static BLE address, which would allow any Bluetooth device in range to track its user. The BLE protocol and a statement from Fitbit have established that a dynamic address can be employed in the future, which would allow for untraceable BLE communication. In addition, it has been found that Fitbit smartphone application reports private addresses of nearby devices to its server. To protect the privacy of medical patients, nearby device reporting should be removed.
Current fitness band privacy policies will also need to be modified before the devices can be employed in a medical setting. This study has shown that there are several inconsistencies between the privacy policies of different device manufacturers. The definition of "personally identifiable information" will have to be applied universally to all data collected by the device in a medical setting and appropriate data deletion and protection policies will be required to apply.
By taking into consideration the overall hospital system, medical fitness band architectures were designed. This study has proposed various high-level-architectures for both in and out patients as well as medical staff. There key difference between the proposed solutions was the use of the hospital server and the cloud, and the advantages and disadvantages of both were presented. It was shown that while a hospital server-only system provides more security and data control for the hospital, it lacks many functionalities provided by the cloud service. Reliability was also a key factor taken into consideration, with the best architectures containing a backup system between the local server and cloud. An in-depth case study of current successful hospital use of cloud computing around the world has indicated that the benefits of implementing a cloud service outweigh the potential risks. The security points of vulnerability can be addressed by implementing security measures such as data encryption and virtual local area networks. System reliability in power failure situations is also considered to ensure patients in critical condition can receive medical care. Hence, a three level system is proposed, classified by the type of data (outpatient, inpatient and critical) collected by the fitness band.
Lastly, this project has conducted a study into the Australian and Estonian e-health systems and assessed the ease of integration with a fitness band system. The Estonian digital health structure was discovered to be more flexible for constructing additional services, however integration with the Australian services EPAS and My Health Record is also possible. This finding indicates that hospital cloud computing can be developed and made available in the future.
To conclude, fitness band manufacturers and hospitals will need to collaborate to provide a tailored medical wearable product. Fitbit's new strategy to move into the health industry demonstrates this trend.
References
[1] Paul Lamkin. 2014. Wearable tech market to grow 130% in 2014. Available at: http://www.wareable.com/smartwatches/wearable-tech-market-to-grow-130-in-2014.
[2] A. Tilley, Forbes. 2015. Jawbone Sues Fitbit For Allegedly Stealing Trade Secrets. [ONLINE] Available at: http://www.forbes.com/sites/aarontilley/2015/05/27/jawbone-sues-fitbit-for-allegedly-stealing-employees-and-trade-secrets#5416b48519b2
[3] https://www.theguardian.com/society/2015/may/19/digital-fitness-technology-data-heath-medicine
[4] Fitbit Inc, "How do Fitbit trackers sync their data?," Fitbit Help, 2016. [Online]. Available: http://help.fitbit.com/articles/en\_US/Help\_article/1877. Accessed: Oct. 20, 2016.
[5] J.-W. Lian, D. C. Yen, and Y.-T. Wang, "An exploratory study to understand the critical factors affecting the decision to adopt cloud computing in Taiwan hospital," International Journal of Information Management, vol. 34, no. 1, pp. 28–36, Feb. 2014. [Online]. Available: http://www.sciencedirect.com/science/article/pii/S0268401213001138\#bib0140. Accessed: Oct. 17, 2016.
[6] Australian Government, "My Health record" Australian Government Department of Health, 2015. [Online]. Available: http://www.health.gov.au/internet/main/publishing.nsf/content/ehealth-record.
