Privacy and Security in Internet of Things and Wearable...

2332-7766 (c) 2015 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.

This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TMSCS.2015.2498605, IEEETransactions on Multi-Scale Computing Systems

1

Privacy and Security in Internet of Things and WearableDevices

Orlando Arias, Student Member, IEEE , Jacob Wurm, Khoa Hoang, and Yier Jin, Member, IEEE

Abstract—Enter the nascent era of Internet of Things (IoT) and wearable devices, where small embedded devices loaded withsensors collect information from its surroundings, process it and relay it to remote locations for further analysis. Albeit lookingharmless, this nascent technologies raise security and privacy concerns. We pose the question of the possibility and effects ofcompromising such devices. Concentrating on the design flow of IoT and wearable devices, we discuss some common designpractices and their implications on security and privacy. Two representatives from each category, the Google Nest Thermostat and theNike+ Fuelband, are selected as examples on how current industry practices of security as an afterthought or an add-on affect theresulting device and the potential consequences to the user’s security and privacy. We then discuss design flow enhancements,through which security mechanisms can efficiently be added into a device, vastly differing from traditional practices.

Index Terms—Hardware Security, User Privacy, Internet of Things (IoT), Wearable Devices

F

1 INTRODUCTION

Within the past decade, the number of Internet of Things(IoT) devices introduced in the market has increased dras-tically. With totals approaching 15 billion, the staggeringconclusion that there are roughly two connected devicesper living human is reached [1]. This trend is expected tocontinue, with an estimate of 26 billion connected devices bythe year 2020, the majority of which being IoT and wearabledevices [2]. Much like the embedded systems they derivefrom, IoT and wearable devices are armed with an arrayof sensors whilst also offering the means to establish a net-work connection, enabling the transmission of the collectedinformation to a remote node.

The collected information can range from a simple heart-beat, to temperature and humidity data, to the location ofthe user himself and his living habits. As such, privacyissues arise. Also, because of the information these devicescan gather and store, they become prime target for attackerslooking to obtain this data. Further, given the always onnetwork connectivity some of these devices hold and thedifferent usage pattern, these devices could be targeted bymalware, increasing the potential for harmful usage.

While IoT manufacturers are aware of the privacy andsecurity implications, security in IoT devices is either ne-glected or treated as an afterthought. This is often due tothe short time to market and reduction of costs drivingthe device’s design and development process. The fewdevices that do choose to add any protection usually em-ploy software level solutions, such as firmware signing andthe execution of signed binaries, methods which resemblethose used in regular computing [3]–[12]. These solutions,however, do not consider the different usage patterns of IoTand wearable devices compared to traditional embedded

• O. Arias, J. Wurm, K. Hoang, and Y. Jin are with the Departmentof Electrical Engineering and Computer Science, University of CentralFlorida, FL, 32816.E-mail: [email protected], [email protected], [email protected], [email protected]

systems or personal computers, proving to be insufficientat times. Furthermore, concentrating on the software-basedprotection schemes often leaves the hardware unintendedlyvulnerable, allowing for new attack vectors.

In order to better understand the security and privacyissues associated with current IoT device design flow andtheir implications, we used the Google Nest Learning Ther-mostat and the Nike+ Fuelband SE Fitness Tracker, hereafterreferred to as the Nest Thermostat and Nike+ Fuelband, astest devices. Our selection of these units was based on thefact that both Nest Labs and Nike Inc. are among the fewmanufacturers who have taken steps towards securing theirdevices and protecting user data. Nest Labs further claims to“use best-in-class data security tools” to protect its productsand user’s data from unauthorized access [13]. However, aswe shall demonstrate in this paper, the protection schemesused in these devices are not sufficient to secure the unitsthemselves.

The remainder of this paper follows the ensuing orga-nization. Section 2 introduces related work in security andprivacy assurance on IoT and wearable devices. Section 3discusses common IoT device design methodologies andpossible pitfalls that may be encountered in the process. Sec-tion 4 presents our case study regarding the Nest Thermo-stat focusing on how to bypass software protection mecha-nisms using a hardware exploit. This particular attack vectorand its possibilities for exploitation are then discussed inSection 5. Section 6 presents the other case study on Nike+Fuelband. The attack vector on the wearable devices is intro-duced in Section 7. Further elaborating on the impact of suchattacks, Section 8 explores the consequences of introducingcompromised IoT and wearable devices within a network.Recommended security enhancement approaches dedicatedfor IoT and wearable devices are discussed in Section 9.Conclusions are drawn in Section 10.



2

2 RELATED WORK

Current IoT and wearable device literature often treats IoTfrom a network perspective or provide solutions that areinherently incompatible with the needs of a manufacturer.Few works have been published discussing the security ofIoT devices themselves [14], [15]. In the ensuing sections,we summarize some of the previous work that has beenpresented in this area.

2.1 IoT Secure Protocols and Network ProtectionAn early survey about the IoT has shown that security andprivacy are the main concerns that need to be addressedbefore IoT devices are widely adopted [16]. Proposed solu-tions for security rely on network protocols to ensure IoTsecurity. Meanwhile, encrypted communication is treated asthe effective solution for privacy protection. However, theseproposed approaches do not consider the unique propertiesof IoT devices. The authors in [17] summarized all currentsecurity threats to the IoT network but these threat modelsare mostly derived from network security. They claim thathardware level attacks, such as differential power analysis(DPA) [18], are of high cost and therefore less harmful.Similarly, the authors in [4] treat IoT as an extremely inter-connected network and list possible solutions to secure theIoT network including protocol and network security, dataand privacy, identity management, trust and governance,fault tolerance, cryptography and protocols, identity andownership, and privacy protection. All these methods try toregulate the communication between IoT devices under theassumption that all IoT devices are operating properly. Theauthors in [5] tried to solve IoT security through differentIoT topologies: centralized architectures [6] and distributedarchitectures [7], [8]. Again, the network based solutionsonly emphasize high level structures without consideringwhether the available resources in IoT devices can affordthese topologies.

Other research focuses on the secure communicationbetween IoT nodes. For example, the authors in [9] focuson secure communication between IoT devices and presentan Identity Authentication and Capability based AccessControl (IACAC) model to protect IoT from man-in-the-middle, replay and denial of service (DoS) attacks. Theauthors in [10], [11] expand the definition of IoT to includefour nodes in a typical IoT network: person, intelligentobject, technological ecosystem, and process. The authorsclaim that IoT security cannot be solved at a single-layer,but should require the analysis of the interactions betweenthese nodes. A 2D version of the systemic approach was de-veloped, which was expanded to a 3D version highlightingnew functional plans of security [12]. Following this route,communication protocols were then developed to secure theinteractions between IoT nodes such as 6LoWPAN [19] andConstrained Application Protocol (CoAP) [20]. The CoAPwas constructed based on Datagram Transport Layer Secu-rity (DTLS) [21] and IPsec [22]. To counter the attacks atthe transport layer, protocols were enhanced to use eitherHTTP/TLS or CoAP/DTLS by proposing a mapping be-tween TLS and DTLS [23] or using secure tunneling on thetransport layer [24]. However, these communication layersecurity analyses and protection methods ignore device

level vulnerabilities and often impose unrealistic constraintson device deployment.

2.2 Hardware Based Protection

Besides network level protection, researchers from the in-dustry have also tried to develop highly secure processor/-SoC architectures for IoT protection. ARM TrustZone is anindustry landmark in providing a basis of trust for variousapplications such as secure payment, digital rights manage-ment (DRM), enterprise and web-based services. TrustZonetechnology provides infrastructure foundations that allow aSoC designer to choose from a range of components that canperform specific functions within the security environment[25]. Intel proposed the concept of enclaves recently [26],[27]. An enclave contains software code, data, and a stackthat are protected by hardware enforced access controlpolicies. Samsung KNOX has also been developed withprotection in mind [28]. KNOX provides a safe execution en-vironment in a KNOX-enabled device where the userland isverified and a KNOX container holds sensitive data, such ascorporate contacts and e-mails in a cellphone. If the deviceis deemed to be compromised by altering the bootloader,an e-fuse is blown inside the SoC driving the unit, thusbranding it as untrusted. However, these hardware-basedsecure architectures are developed with passive protectionin mind, whereas they do not detect and mitigate hardwareand software level attacks. Samsung KNOX is possibly anexception to this, however, it remains to be proven whetheror not it is possible to bypass any checks to the e-fuseprotection in the bootloader. TrustZone environments havebeen proven to be compromised as shown in [29]–[31] byexploiting bugs in the software stack. Furthermore, thesesolutions do not transfer well to low power embedded units.For example, at the time of writing, Samsung KNOX isonly available in select Android-based cellular phones andtablets.

3 IOT DEVICE DESIGN FLOW PRACTICES

3.1 Reliance on Vendor Designs

Throughout our investigation of the design flow of IoTdevices we have found that there are cases where the lackof familiarity with the hardware being used has led to overreliance on vendor designs. That is, products are directlybased on a design or application solution a vendor hasprovided. Whereas for targeted applications this may besufficient, when the only available designs are for generalpurpose computing devices or development boards, it maylead to the unintentional exposure of interfaces that aremeant for debugging or reprogramming purposes. An at-tacker can easily leverage these interfaces to leak internalsensitive information or even install malicious firmware tocontrol device operation.

3.2 Open vs. Closed Source SoftwareAt the device firmware level, it is common to find Linux-based stacks, although other devices utilize FreeRTOS [32]or other open source projects, thus leveraging pre-existingsoftware solutions to build upon. Other manufacturers optfor proprietary solutions, such as Wind River’s vxWorks



3

[33] or Blackberry’s QNX [34]. The question of open sourceversus closed source software in security is a hard one toanswer. With open source software, an attacker just needsto find a potential vector to target the device by lookingfor errors in the source code. However, a manufacturerdoes not have to rely on the system’s vendor in order topatch the bug, thus enabling for a faster response time.With a closed source system, however, an attacker is facedwith a problem in reverse engineering interfaces lookingfor potential errors in the software stack. Manufacturers,however, need to rely on vendors once vulnerabilities arefound. The stack chosen should then be selected based ondesign requirements, availability of support, documentationand amount of security offered.

3.3 Weak or Bad Cryptographic ImplementationsIf a device is designed to be remotely updated, it mustbe able to verify the downloaded image for both integrityand authenticity. This usually involves a cryptographicalgorithm, sometimes many. Cryptographically securing aproduct is a complicated task, as proven by the countlessvulnerabilities found in software, not only because of themathematics involved, but because of implementation er-rors [35]–[40]. Two of these vulnerabilities are of criticalimportance to our research as it shows how weakly imple-mented cryptographic systems can be bypassed, providingfor a way to remotely attack the device. These exploitsdescribe how an attacker can remotely compromise a BelkinWeMo Home Automation device by exploiting the faultyusage of SSL, allowing remote firmware installation byspoofing a distribution server, or by spoofing SSL serversvia arbitrary certificates.

3.4 Debug Interfaces on Production RunsIt is often cheaper to write images to flash chips whenassembling the device, rather than purchasing prepro-grammed parts. Furthermore, the device must be function-ally tested before it leaves production. This implies thatthe circuit board must expose programming interfaces andtest points for the different components present within.Although at times unlabeled, these often unpopulated inter-faces are not removed after testing. An attacker can utilizethem to inject his own code on the unit or alter theirfunctional behavior. The software component may also fallprey to this issue, as compilers can generate binaries thatinclude debugging symbols, expressing the constructs thatgenerated a certain block of machine code. Leaving thesedebugging symbols in production runs aids an attackerin reconstructing the original sources, allowing for easiervulnerability detection.

3.5 Supply Chain ThreatsHardware Trojans also pose a serious threat to IoT security.These malicious modifications to integrated circuits canleak key data to an attacker, cause a device to operateoutside specified parameters, or otherwise render the deviceinoperable. Hardware Trojans further pose the threat of notbeing detected by normal testing methodologies, requiringexpensive specialized tests to detect them. For example, amalicious adversary could insert a hardware Trojan in acryptographic IP core utilized in a System-on-Chip (SoC)used in an IoT device [41]. When triggered, this Trojan

weakens the entropy of the random number generator usedto generate keys. If these keys are used to encrypt sensitivedata that is being transmitted by the device, the amount ofcomputational effort required by the attacker to decrypt thedata is severely reduced.

4 CASE STUDY 1: NEST THERMOSTAT

As part of our research, we present the Nest Thermostat asa case study. We disassembled the device and explored itsfunctionality with the objective to find any vulnerabilitiesthat were left in the hardware and software stack.

4.1 High Level OverviewThe Nest Thermostat is a smart device designed to control astandard heating, ventilation and air conditioning (HVAC)unit based on heuristics and learned behavior. The ther-mostat is also equipped with a motion sensor capable ofdetecting whether users are at the installed location andcontrol the HVAC unit accordingly. Coupled with a WiFimodule, the unit is able to connect to the user’s home oroffice network and interface with the Nest Cloud, therebyallowing for remote control of the unit. It also exhibits aZigBee module for communication with other Nest devices,but has remained dormant as of firmware versions up to thecurrent 4.2.x series.

The Nest Thermostat runs a Linux kernel, coupled withsome GNU userland tools, Busybox, other miscellaneousutilities in order to run a proprietary stack designed andwritten by Nest Labs. To remain GPL compliant, the modi-fied source code used within the device has been publishedand is available for downloading from Nest Lab’s OpenSource Compliance page [42], with the notable exceptionof the C library. Build scripts to generate binaries from thesesources are provided, whereas a toolchain was unavailableto users until shortly after preliminary results of our re-search were presented.

Energy savings are attempted by gathering usage statis-tics and environmental factors to systematically build auser profile. As these metrics are coupled with user input,they provide a comfortable environment. The profile is alsouploaded to Nest Cloud, a service where users can remotelyinteract with their device. The manufacturer proceeds togather and study this information with the hopes of aidingenergy providers with the means to achieve optimal energygeneration.

4.2 Device SecurityThe Nest Thermostat contains two wireless communicationchannels, a WiFi interface and a ZigBee interface. At thetime of writing, only the WiFi interface is active and used.The Thermostat is capable of connecting to wireless net-works encrypted using WPA2–Personal but it is incapable ofconnecting to WPA2–Enterprise encrypted networks. Otherlegacy connection standards are also supported. Any log-related communication started by the unit is encryptedusing TLS 1.2 from the beginning, making it hard to in-tercept any data that is being transmitted by these means.This includes access to the Nest Cloud, which authenticatescredentials using OAuth tokens. OAuth tokens have theadvantage that they can easily be revoked by the issuer(in this case, Nest Cloud) and can be used to limit access



4

to certain account features. Updates and non-critical datasuch as weather is obtained over a plain-text communica-tion channel. This data can be potentially intercepted andmodified. However, update images are cryptographicallysigned using PKCS #7 certificates, thus modifying an updateimage results in invalidating the cryptographic signature.The Nest Thermostat’s internal software stack rejects anyupdate image which does not contain a valid signature.

4.3 Device Descriptive OverviewThe thermostat is divided into two main components, abackplate which interfaces with the HVAC unit and a frontplate which presents the main user interface.

The backplate is managed by a ST Microelectronics ARMCortex-M3 based microcontroller. An SHT20 temperaturesensor communicates with the microcontroller using the I2Cbus protocol. A rectifier bridge and switching supply is usedin order to retrieve power from the HVAC unit. A few drivercircuits are also present, as to manipulate the control signalsutilized by most HVAC systems. The backplate contains a2 by 20 connector which provides access to some of themicrocontroller peripherals, such as UART, power rails andother control signals.

The largest part count is found in the front plate of thethermostat, which is driven by a Texas Instruments SitaraAM3703 system-on-chip (SoC) [43], interfacing directly witha Micron ECC NAND flash memory module, a SamsungSDRAM memory module and a LCD screen. The front platealso holds two wireless connectivity modules (an EmberEM3567 for ZigBee and a TI WL1270B coupled with aSkyworks SKY2463 for WiFi), a button, a long range anda short range motion sensor, an optical navigation module(ADBM-A350) and other miscellaneous components. Powerdistribution within the front plate is managed by a TexasInstruments TPS65921B power management module, whichalso provides high speed USB capabilities. A customizedGNU/Linux stack provides the backbone of the softwareinterface, with our research units running kernel version2.6.37. Figures 1 and 2 show the device internals and devicemap, respectively.

4.4 The AM3703 - A Close LookThe TI AM3703 SoC is composed of a 32 Channel DMAcontroller, a dual-output three-layer display processor, HighSpeed USB controller with USB OTG capabilities, an em-ulation module for debugging, a General Purpose Mem-ory Controller (GPMC) to handle NAND/NOR flash, anSDRAM memory scheduler and controller, an 112KiB on-chip ROM which contains boot code, a 64KiB on-chipSRAM all connected by a Level 3 (L3) interconnect whichruns at 200MHz. The ARM core within the MPU subsys-tem uses a 256KiB cache to reach the L3 interconnect.Furthermore, a Level 4 interconnect adds the peripheralmodule to the memory map. This peripheral module han-dles the GPIO, UARTs, high speed multimaster I2C bus,memory card controller, memory stick pro controller, watch-dog timer, general purpose timers and other miscellaneoussubsystems [43].

The ARM subchip integrates an ARM Cortex-A8 core,with Version 7 of the instruction set architecture, providingstandard ARM instructions and Thumb-2 mode, the JazelleX

Java accelerator and media extensions. It also integrates anARM NEON core SIMD coprocessor. The subchip connectsto 32KiB/32KiB instruction/data caches which proceeds tointerface with a 256KiB 8-way associative cache supportingparity and ECC. The core also provides integrated traceand debug features [43]. A simplified memory map of theAM3703 is shown in Figure 3.4.5 Boot Process and Device InitializationUpon normal power on conditions, the Sitara AM3703 startsto execute the code in its internal ROM. This code initializesthe most basic peripherals, including the General PurposeMemory Controller (GPMC). It then looks for the first stagebootloader, x-loader, and places it into SRAM. Once thisoperation finishes, the ROM code jumps into x-loader,which proceeds to initialize other peripherals and SDRAM.Afterwards, it copies the second stage bootloader, u-boot,into SDRAM and proceeds to execute it. At this point,u-boot initializes the remaining subsystems and executesthe uImage in NAND flash with the configured environ-ment. The system finishes booting from NAND flash as ini-tialization scripts are executed and services are run, culmi-nating with the loading of the Nest Thermostat proprietarysoftware stack. Figure 4 shows the normal boot sequence ofthe device.

Power connections, clock and reset signals must beproperly initialized before the AM3703 boots. The de-vice boot configuration is given by six external pins,sys_boot[5:0]. After power-on reset, the value on thesepins are latched into the CONTROL.CONTROL_STATUS reg-ister. Table 1 describes the boot selection process for aselected set of configurations.

sys_boot[5:0] First Second Third Fourth Fifth001101 XIP USB UART3 MMC1001110 XIPwait DOC USB UART3 MMC1001111 NAND USB UART3 MMC1101101 USB UART3 MMC1 XIP101110 USB UART3 MMC1 XIPwait DOC101111 USB UART3 MMC1 NAND

TABLE 1: Selected boot configurations

After performing basic initialization tasks, the on-chipROM may jump into a connected execute in place (XIP)memory, if the sys_boot pins are configured as such. Thisboot mode is executed as a blind jump to the externaladdressable memory as soon as it is available. Otherwise,the ROM constructs a boot device list to be searched forboot images and stores it in the first location of availablescratchpad memory. The construction of this list depends onwhether or not the device is booting from a power-on resetstate. If the device is booting from a power-on reset, theboot configuration is read directly from the sys_boot pinsand latched into the CONTROL.CONTROL_STATUS register.Otherwise, the ROM will look in the scratchpad area ofSRAM for a valid boot configuration. If it finds one, it willutilize it, otherwise it will build one from permanent devicesas configured in the sys_boot pins. The flowchart in Figure5 provides a graphical view of this process.

5 ATTACK VECTOR ON NEST THERMOSTAT

Examination of the circuit board for the Nest Thermostatshows that the sys_boot[5] pin is not only exposed in a



5

Fig. 1: Front (left) and backplate (right) of a Nest Thermostat (credit: Nest, iFixit)

SitaraAM3703

NAND

SDRAM

TPS655912

EM3567

WL1270BSKY2463

LCDST32L151SHT20

HVACdrivers

Backplate

Motion sensors

PiezospeakerADBM-A350LED

Fig. 2: Device map of the Nest Thermostat

0x3fffffff0x400000000x40013fff0x402000000x4020ffff0x40210000

0x7fffffff0x80000000

0xbfffffff0xc0000000

GPMC

Boot ROMSRAM

SDRAM

Reserved/SDRC/SMS

0x00000000

0xffffffff

Fig. 3: Simplified memory map (shaded areas are internal tothe AM3703)

pad, but also in an unpopulated header. As shown before, ifthis pin is pulled high, the processor is made to boot from aperipheral interface, namely USB or UART3. This behaviorcan be exploited to insert our own code into the device.Furthermore, by pressing the button in the thermostat forabout 10 seconds, it is possible to trigger a hard reset ofthe device causing the sys_boot[5] pin to be driven high,ensuing the same behavior. Since ROM does not run anykind of verification on the code being injected, we are ableto run it without restriction. Only the timing windows fordevice detection and programming must be met. The firstpayload must be x-loader, which is copied into SRAM.Subsequent payloads are copied into SDRAM.

5.1 Initial AttackOur initial attack consisted of sending x-loader into theunit by means of USB, coupled with a custom u-bootcrafted with an argument list to be passed to the on-board kernel. Our u-boot image was sent along a customramdisk which contained the final payload. As the on-board kernel booted, our ramdisk was utilized as the initfilesystem. This gave us a very rustic shell upon whichto modify the device’s behavior. By mounting the device’sfilesystem, we enabled remote access to the unit using thealready onboard netcat binary. The device’s init scriptwas also modified in order to activate this shell upon anysubsequent boot.

Reconstruction of the userland by means of the shellallowed us to start initial forensic analysis of the device. Thisensued in obtaining toolchain information, Application Bi-nary Interface (ABI) information and other missing areas ofthe userland. With the information at hand, a full toolchainwas developed which enabled us to build arbitrary payloadstargeting the Nest Thermostat.

5.2 Refining BackdoorsWith the new tools, the dropbear secure shell and sftpserver was cross compiled, providing us with a better wayto access the unit, after making the respective changes to thesystem’s /etc/passwd, /etc/shadow and /etc/groupsfiles, enabling a user account.

With secure shell having been enabled, accessing thedevice within the local network became easier and morereliable. Further forensic analysis of the unit was performedthis way, discovering the storage of all logged data and thepossibility of its retrieval by unauthorized sources.

5.3 Dialing from IlionUnder regular operating conditions, the Nest Thermostatis behind a Network Address Translation (NAT) firewall,meaning that accessing it from a remote location by meansof standard secure shell requires a user to enable portforwarding in their firewall. As such, we developed aproof of concept Trojan horse, codenamed Odysseus whichis designed to dial into a remote server, Achaea, and awaitcommands. The Trojan was injected into a thermostat unitand deployed into a proof of concept smart house we namedIlion. Within its network, Ilion contained laptop and desktopcomputers, cellular smartphones, tablets and a few otherdevices, as to emulate a real life setting.

Since the Nest Thermostat was now a part of Ilion,we were able to utilize Odysseus to extract the network



6

Boot ROMstarts execution

ROMinitializes basic

subsystems

ROM copiesX-Loaderto SRAM

X-Loaderexecutes

X-LoaderinitializesSDRAM

X-Loadercopies u-boot

to SDRAM

u-bootexecutes

u-bootconfigures

environment

u-bootexecutes

Linux kernel

Userlandloaded

Fig. 4: Standard Nest Thermostat boot process

Boot deviceselection

Poweron reset

Validbootconf

Use permanentdevices fromsys_boot

Use sys_boot

Use softwareconfiguration

No

No

Yes

Yes

Fig. 5: Boot device setup

credentials. Odysseus was also used to scan the network forother devices, sending this information to Achaea, where theremote attacker can collect it. Figure 6 shows traffic froma session of Odysseus relaying collected information. OurTrojan also enabled us to deploy a rogue DHCP server,allowing us to shape the outgoing traffic by redirecting DNSrequests to our servers, thus enabling us to launch a widervariety of attacks against other connected devices.

Fig. 6: Sample traffic between Odysseus and Achaea

5.4 Remote Updates and the Linux KernelThe Nest Thermostat receives signed updates from up-dates.nest.com over standard, plain-text HTTP. As such, theconnection can be eavesdropped and images can be down-loaded to an alternate location and analyzed for contents.The update images are not encrypted, but they contain amanifest file with signing keys. These signatures are veri-fied against a public certificate found on the device. It ispossible then to alter the certificate verification within acompromised unit to accept updates from a different source.

With our current toolset, we were able to obtain thekernel configuration file generated within /proc filesystem.Further study of the device can be accomplished by meansof intercepting system calls and kernel level debugging. Assuch, using this configuration file as a base, a custom kernelwas built with debugging features added. Since u-bootmust provide the layout of NAND flash to the kernel,analysis of its sources yielded a possible place of storagefor our customized kernel.

Our custom kernel has been patched to allow polling inthe OMAP serial driver, allowing us to use the kernel leveldebugger kgdb through one of the exposed serial ports. Wehave permanently written this kernel to the boot1 sectionof NAND flash and use a custom u-boot to select whetherto use the stock kernel or ours upon powering on the unit.With a custom kernel in place, as mentioned above, we canintercept system calls, potentially disabling reads and writesto specific sections of NAND flash. This enables us to blockcertain files from being deleted, even if we allow officialNest updates to run, giving persistence to any softwarebackdoors injected within the device.

6 CASE STUDY 2: NIKE+ FUELBAND

Architecture wise, wearable and medical devices resembleIoT devices, however, they tend to have much less com-putational power and limited communication interfaces.Nevertheless, these units perform as much if not more datacollection than IoT devices do. Although closely related toIoT devices, security vulnerabilities on wearable devices canlead to safety concerns for users. A pacemaker with wirelesscapabilities was proven to be vulnerable and could be usedto affect the health of the patient [44]. Information leaks fromfitness devices owned by corporate executives could be usedagainst them, causing the corporation’s value to deteriorateon the market, severely affecting its performance.

Much like our work with the Nest Thermostat, we per-formed a similar analysis on medical and wearable devices,looking for possible hardware vulnerabilities which may



7

be utilized against an unsuspecting user. In the followingsubsections, we introduce as a secondary case study ourwork with the Nike+ Fuelband, a wearable device withfitness monitoring capabilities.

6.1 High Level Overview

Fig. 7: Nike+ Fuelband SE Fitness Tracker (credit: Nike)

The Nike+ Fuelband is a low-power Bluetooth 4.0-enabled fitness wristband designed to measure daily physi-cal activity, such as the amount of steps taken, sleep patternsand estimate the amount of calories burned (see Figure 7).This is done by means of reading data from the on-board 3-axis accelerometer, which is subsequently stored within theunit. By means of software provided by the manufacturer,the unit can communicate with a Windows or OS X basedcomputer, as well as Android and iOS devices. The collecteddata can then be analyzed, tracked and shared with theNike+ online community. Periodic synchronization with thedevice can be achieved with the mobile applications andreal-time feedback is performed with the on-board LEDmatrix display. The device is powered by two Lithium-polymer batteries, advertised to provide up to four daysof continuous usage.

6.2 Device SecurityThe Nike+ Fuelband contains a Bluetooth interface whichit uses to communicate with a smartphone. Some settingsof the Fuelband can be configured through these meansand information from the band can be sent back to thesmartphone using this channel. Firmware updates, how-ever, are performed by means of the Nike+ application ona Windows or OS X based personal computer. Most of thecommunications from the smartband are done through thesmartphone or personal computer application. Upon boot,the firmware is checked against a checksum before it is runensuring a valid image.

6.3 Device Descriptive OverviewThe main processing unit in this device is the ST Mi-croelectronics STM32L151QCH6 microcontroller. Built uponan ARM Cortex-M3 core, this microcontroller is describedin greater detail in Section 6.4. An LIS3DH 3-axis MEMSaccelerometer from the same manufacturer interfaces withthe STM32 by means of a Silego SLG46300 programmablemixed signal array. The 120-LED matrix is driven by anAMS AS1130 driver, which simplifies some LED matrixrelated operations. Power management is provided by the

ST Microelectronics RS12, which also facilitates communi-cations over USB 2.0. Bluetooth communication is achievedby means of a Cambridge Silicon Radio CSR1010 BluetoothLow Energy module. Figure 8 shows the device map of theunit.

STM32L

LEDMatrix

LEDDriver

PowerManagement

Batteries

1MB Flash Memory

BluetoothSmartRadio Mixed

SignalArray

Accelerometer

Fig. 8: Device map of the fuelband

6.4 The STM32L151QCH6 - A Closer LookThe ST Microelectronics STM32L151QCH6 system on achip (SoC), hereafter referred to as STM32, is an ultra-low-power platform offering a 12 channel DMA controller, 23capacitive sensing channels and a CRC calculation unit. TheSoC further includes a 96bit unique ID, a preprogrammedbootloader supporting both USB and USART programming,116 fast input/output pins which are mappable to a 16interrupt vector table. Storage wise, the STM32 in questionoffers 256KiB of flash storage with ECC support, 32KiBof SRAM, 8KiB of ECC supporting EEPROM and a 128Bbackup register. Included peripherals range from an LCDdriver, to communication interfaces supporting USB 2.0,USART, SPI and I2C [45].

The included ARM Cortex-M3 core supports both theThumb and Thumb-2 instruction set architectures. Ad-vanced low-power optimizations are achieved by meansof multiple power and clock domains, architecture definedsleep modes and support for advanced low-power tech-nologies such as State Retention Power Gating. A JTAGmechanism is provided by means of serial wire debug,which provides real-time access to system memory withouthalting the processor.

A simplified memory map of the STM32 is illustrated infigure 9. The highlighted block of addresses in the figure aremultiplexed between Flash or System Memory, dependingon the status of the external BOOT0 pin (see Section 6.5).

6.5 Boot Process and Device InitializationUpon device power on, the STM32 executes the code storedin its internal ROM, initializing the device’s basic periph-erals. Execution then continues from internal flash memory,which proceeds to finish device setup into a working model.Specific to the Nike+ Fuelband, this entails activation of the



8

0x08000000

0x0803ffff0x08080000

0x08081fff0x1ff00000

0x1ff01fff0x1ff80000

0x1ff8001f0x40000000

Flash or System Memory

Flash Memory

Data EEPROM

System Memory

Option Byte

Peripheral Initialization

0x00000000

0x400267ff

Fig. 9: Simplified memory map of the STM32L151QCH6

Bluetooth radio, mixed signal array and LED driver, alongwith the calibration of the accelerometer. At this point, thedevice is ready for regular usage.

The STM32, however, implements a secondary bootmode, which is triggered by holding the BOOT0 pin to alogic 1 as the device starts. If started this way, the deviceinitializes a basic set of peripherals and configures the USBsubsystem. Then, if a USB cable is detected whilst beingdriven by the proper clock signal, the internal PLL recon-figures the system clock to 32MHz and the USB subsystemclock to 48MHz. The system proceeds to execute the DFUbootloader with USB interrupts enabled, as to allow forcommunication. Using this mechanism, the STM32 can besent commands which allow for read and write operationsto memory, changing memory protection modes and statusretrieval.

7 ATTACK VECTOR ON THE NIKE+ FUELBANDAlthough the STM32 documentation states that the micro-processor contains the necessary capabilities to lock externalreads and writes against the internal flash, thus isolating thedevice’s firmware from the external world, this protectionwas not employed on the Nike+ Fuelband. As such, thecontents of flash can be freely modified by an attacker withaccess to the device.

The Nike+ Fuelband contains a standard USB connectorwhich is used for both device charging and synchronization.This connector can also be used to write new firmware ontothe device, however, the necessary access to the BOOT0 pin isnot externally provided. As such, the device must be openedin order to trigger the alternate boot sequence. Furthercomplicating the issue is the fact that the microcontrolleris packaged as a Ball Grid Array (BGA) and thus no directaccess to the BOOT0 pin can be obtained. Traces on the circuitboard must then be followed in order to encounter a testpoint indirectly exposing the pin in question.

After following this process, we were able to indirectlylocate the BOOT0 pin, which was subsequently driven a logic1 state by means of a 100Ω resistor connected to VDD. Thisallowed us to enter the alternate boot mechanism and ex-ploit the lack of read and write protection on the device. Bymeans of standard ST Microelectronics development tools,communication over USB with the STM32 was achieved andthe device’s firmware was obtained.

With the device’s firmware in our hand, we set on tomodify it. The simplest change is one of string replacement,that is, find a string in the program that gets displayed at

some point and change it to something else. With the changemade, the modified firmware was written to the device, onlyto find normal functionality had ceased to exist. Furthertesting demonstrated that this was caused by a failure tocompute the proper CRC for the image. Since the imagewas modified, the check failed.

Closer examination of the disassembled firmware imagedemonstrated that it utilized the CRC engine within theSTM32 microcontroller in order to verify itself as genuine bychecking the result of the CRC computation against a storedvalue. This value was found within the image itself, andthus easily modifiable. With the proper checksum added,the modified firmware was sent to the device and proven towork.

8 DISCUSSIONS

8.1 Security Impact to Network

A compromised IoT device can be utilized to further attackother units in an unsuspecting victim’s network. Effectscould range from simple backdoor injection to leaking userinformation and credentials to even causing physical harmto the user. As shown with the case of the Nest Thermostat,it can be used as a beachhead to other nodes within thenetwork, allowing for discovery and attack of those nodes.

Furthermore, rogue services may be installed on thedevice, aiming to disrupt regular network operations. Forinstance, a rogue DHCP server may be utilized to injectDNS requests to a poisoned server which would return falseinformation, allowing for traffic shaping. Address Resolu-tion Protocol (ARP) based attacks are also possible, with thecompromised device masquerading as the router, allowingfor the capture and redirection of a target computer’s net-work traffic.

Security issues with backdoored IoT devices are exac-erbated by the fact that local network credentials need tobe stored within the unit, thus becoming accessible to anattacker. Leveraging the extraction of network credentialsallows for the introduction of extraneous devices into thelocal network, granting for new methods of exploitationagainst other nodes. In the case of the Nest Thermostat, thenetwork credentials are stored in regular text files, and evenif these were encrypted, the algorithms necessary to obtainthe clear text would necessarily be present on the device,granting the attacker the means to collect them.

8.2 Safety Concerns

Safety concerns arise when compromised IoT and wearabledevices see on-field deployment. Due to the services theseunits provide, from communications to medical applica-tions, a compromised device could then be used to causephysical harm to its user [44]. The Nest Thermostat couldbe employed to overstress the HVAC unit it is connected to,causing it to malfunction. Furthermore, all the informationstored within the device can be utilized by the attacker tobuild a profile of the victim, aiding on the determination ofa daily routine, the usage of which can result in facilitatingthe burglarizing of the victim’s property.



9

8.3 Privacy ConcernsAlmost all IoT and wearable devices, upon setup, will startcollecting user information. For example, the Nest Ther-mostat will collect information such as the location of thethermostat, whether it is being used in a home or business,the postal code of the area and device information from theHVAC system to determine its capabilities. The on-boardsensors on the thermostat will also collect temperaturedata, humidity and ambient light data, and by means ofthe onboard passive infrared sensor, whether somebody ismoving in the room. Any direct temperature adjustmentsto the device are also recorded and utilized in algorithms tolearn and compute comfort levels under different situations.Whenever the HVAC unit is activated, the thermostat willrecord the time and duration for which this happened.Using this information, the thermostat builds a profile forthe users in order to help them feel comfortable whilst alsoproviding energy savings. The Nike+ Fuelband will storethe user’s heartbeat and sleeping patterns, which can thenbe learned by the attacker. The information could potentiallybe used against the user, or against any entity the user is partof.

Although there are laws and standards defining data col-lection policies, some of these have proven to be ineffectiveand often antiquated, as demonstrated by information leaksfrom companies [46]–[48]. User information collected by theNest Thermostat is stored within the unit and uploadedto the Nest Cloud. Local log files are sent to Nest as welland removed from the unit as to save space. System andsoftware logs contain information such as the user’s Zipcode, device settings, HVAC settings and wiring configu-ration. Forensic analysis of the unit yields that the NestThermostat has code to prompt the user for informationabout their place of residence or office. Reports indicate thatNest plans to share this information with energy providersin order to aid with efficient power generation [49]. As forthe Nike+ Fuelband, the information collected and storedby the unit is then sent to a personal computer or mobiledevice, from where it can be publically shared with otherusers. Even if the information is not shared, an unauthorizedthird party still has access to the data from a compromiseddevice and can use it for their own purposes. AlthoughIoT manufacturers have gone through considerable effortsto ensure the secure transmission of this data, it is all fornaught if it can be leaked at the source.

9 DEVICE SECURITY ENHANCEMENT

9.1 Security Solutions Common to IoT and WearableDevices

Verifying the firmware at update time is a step towardssecuring IoT devices, however, this is often done by the on-board software. As with the Nest Thermostat and the Nike+Fuelband, the on-board software is trusted to be authentic.The implementation of this check, however, must be sound.For example, schemes that utilize random numbers mustensure the usage of a cryptographically secure randomnumber generator, any used cryptographic certificates mustbe validated by a trusted Certificate Authority [39]. Aweakly implemented cryptographic algorithm is no betterthan a lack of a cryptographic algorithm.

However, as we have demonstrated with our case stud-ies, it is insufficient to authenticate an update image. Thesoftware stack must also be authenticated before it canreliably determine if an update is valid or not. With thedevices compromised, we are free to bypass any checks onthe update image, thus rendering the protection mechanismineffective. A proper chain of trust in the hardware infras-tructure of the device can aid the process of determining anauthentic software stack [50].

The attack in both the Nest Thermostat and the Nike+Fuelband could have been avoided had a proper chainof trust been implemented. Inherently, this needs the typeof hardware support which is not available in either theSitara AM 3703 used in the Nest Thermostat or the STM32microcontroller used in the Nike+ Fuelband.

The exposure of debug interfaces in these devices fur-ther presents a risk. These are often left as residues fromdevelopment prototypes or as testpoints used during man-ufacturing. These debug interfaces can also serve as themeans to service IoT or wearable devices on the field, asto ease repairs. As such, we can see why they may beneeded. However, these interfaces must be protected againstattackers. For example, FRAM devices in the MSP430 linesprovide means to both secure JTAG access and to pro-tect certain memory segments from access using a builtin IP Encapsulation Module [51]. Other microcontrollersand microprocessors offer the same kind of functionality,implementing means to restrict access to its debug units. Assuch, manufacturers are able to still expose these interfacesfor testing purposes and lock them before they are deployed.Ideally, however, any debug interfaces should be removedfrom production runs or have proper protections.

9.2 Specific Solutions for IoT DevicesOften, IoT devices provide a full operating system in whichbinaries are loaded into an userland. This simplifies theinterface to the hardware and provides high level Applica-tion Programming Interfaces (APIs). The Nest Thermostat,for example, employs an embedded Linux stack which isused to launch the proprietary Nest application which relayscommands to the backplate of the unit and controls thecommunications channels. As we demonstrated in our casestudy, binaries can be injected into the filesystem of the unitand executed in devices that utilize this model. As such,extra protection must be added to devices that load binariesinto a userland. A possible approach is to only load andexecute cryptographically signed binaries. This requires thekernel to have a custom loader that verifies these binaries asthey are prepared for execution. If the signature verificationfails, then the binary is not run and the device is set into afailsafe mode, notifying the user of possible tampering.

9.3 Specific Solutions for Wearable DevicesIn devices whose architecture is self contained, that is, mi-crocontroller based systems, it becomes necessary to secureall update channels. External reprogrammability of the mi-crocontroller and any debug interfaces it may feature mustbe disabled. The microcontroller must also be programmedbefore being placed in the circuit board, as to avoid addingunnecessary interfaces which could expose functionality.



10

9.4 Overhead of Security SolutionsThere is usually a certain degree of overhead associatedwith any protection mechanism. Cryptography necessarilyadds computational overhead to any protection scheme thatutilizes it. It may be reasonable to expect then that anydevice which utilizes encryption or any other cryptographicfunction to require binaries with functions to include thenecessary checks and have higher memory and CPU re-quirements in order to perform better. However, current in-dustry solutions include parts which are capable of acceler-ating these processes, much like the microcontroller utilizedin the Nike+ Fuelband which can accelerate CRC32 com-putations [45]. This reduces the software overhead neededto perform these checks, but slightly increases the areaand power consumption of these parts. It should be noted,however that for most parts, power can be gated to the SoCsubsystems that are not being utilized, thus reducing powerconsumption in the device.

10 CONCLUSIONS AND FUTURE WORK

As our case studies demonstrated, a non-secure hardwareplatform will inevitably lead to a non-secure software stack.A vulnerability in the design of the unit can result in itscompromise. Furthermore, without being able to authenti-cate the running software, it can not be trusted to makedecisions about its own validity. Due to the short time tomarket engineers are given to finish a product, we believethat most of the current IoT and wearable devices sufferfrom similar issues. Software protection becomes ineffectiveif the hardware is vulnerable to attack. This raises safety andprivacy issues with users, is their information safe?

Moving forward, we will continue to probe other IoTdevices for security, with the goal of finding vulnerabilitiesin their hardware. Ultimately, this will lead us to a betterunderstanding of design issues and how to correct them.We will attempt to build prototypes of smart devices thatutilize our proposed chain of trust to test for their viabilityand ability to prevent malicious attacks.

ACKNOWLEDGEMENT

Mr. Orlando Arias and Mr. Khoa Hoang are partly sup-ported by the REU Supplement of an NSF award (CNS-1319105).

REFERENCES

[1] D. Evans, “The internet of things - how the next evolution of theinternet is chaging everything,” White Paper. Cisco Internet BusinessSolutions Group (IBSG), 2011.

[2] P. Middleton, P. Kjeldsen, and J. Tully, “Forecast: The internet ofthings, worldwide, 2013,” Gartner, 2013.

[3] D. Welch and S. Lathrop, “Wireless security threat taxonomy,”in Information Assurance Workshop, 2003. IEEE Systems, Man andCybernetics Society, 2003, pp. 76–83.

[4] R. Roman, P. Najera, and J. Lopez, “Securing the internet ofthings,” Computer, vol. 44, no. 9, pp. 51–58, 2011.

[5] R. Roman, J. Zhou, and J. Lopez, “On the features and challengesof security and privacy in distributed internet of things,” ComputerNetworks, vol. 57, no. 10, pp. 2266–2279, 2013.

[6] A. Williams, “How the internet of things helpsus understand radiation levels,” 2011, [Online].http://readwrite.com/2011/04/01/ow-the-internet-of-things-help.

[7] D. Viehland and F. Zhao, “The future of personal area networks ina ubiquitous computing world,” International Journal of AdvancedPervasive and Ubiquitous Computing (IJAPUC), vol. 2, no. 2, pp. 30–44, 2010.

[8] H. Schaffers, N. Komninos, M. Pallot, B. Trousse, M. Nilsson, andA. Oliveira, “Smart cities and the future internet: Towards cooper-ation frameworks for open innovation,” in The Future Internet, ser.Lecture Notes in Computer Science. Springer Berlin Heidelberg,2011, vol. 6656, pp. 431–446.

[9] P. N. Mahalle, B. Anggorojati, N. R. Prasad, and R. Prasad, “Iden-tify authentication and capability based access control (IACAC)for the internet of things,” Journal of Cyber Security and Mobility,vol. 1, pp. 309–348, 2013.

[10] Y. Challal, “Internet of things security: towards a cognitive andsystemic approach,” Ph.D. dissertation, 2012.

[11] A. Riahi, Y. Challal, E. Natalizio, Z. Chtourou, and A. Bouabdallah,“A systemic approach for IoT security,” in 2013 IEEE InternationalConference on Distributed Computing in Sensor Systems (DCOSS),2013, pp. 351–355.

[12] A. Riahi, E. Natalizio, Y. Challal, N. Mitton, and A. Iera, “Asystemic and cognitive approach for IoT security,” in 2014 Inter-national Conference on Computing, Networking and Communications(ICNC), 2014, pp. 183–188.

[13] Nest Labs, “Privacy statement,” [Online].https://nest.com/legal/privacy-statement/.

[14] J. H. Ziegeldorf, O. G. Morchon, and K. Wehrle, “Privacy in theinternet of things: threats and challenges,” Security and Communi-cation Networks, vol. 7, no. 12, pp. 2728–2742, 2014.

[15] A. D. Thierer, “The internet of things and wearable technology:Addressing privacy and security concerns without derailing inno-vation,” Rich. JL & Tech., vol. 21, pp. 6–15, 2015.

[16] L. Atzori, A. Iera, and G. Morabito, “The internet of things: Asurvey,” Computer Networks, vol. 54, no. 15, pp. 2787–2805, 2010.

[17] S. Babar, P. Mahalle, A. Stango, N. Prasad, and R. Prasad, “Pro-posed security model and threat taxonomy for the internet ofthings (IoT),” in Recent Trends in Network Security and Applica-tions, ser. Communications in Computer and Information Science.Springer Berlin Heidelberg, 2010, vol. 89, pp. 420–429.

[18] P. Kocher, J. Jaffe, and B. Jun, “Differential power analysis,” inAdvances in Cryptology – CRYPTO’99, 1999, pp. 789–789.

[19] G. Mulligan, “The 6lowpan architecture,” in Proceedings of the 4thWorkshop on Embedded Networked Sensors, ser. EmNets ’07, 2007, pp.78–82.

[20] Z. Shelby, K. Hartke, C. Bormann, and B. Frank, “Constrainedapplication protocol (coap), draft-ietf-core-coap-13,” in The InternetEngineering Task Force (IETF), 2012.

[21] E. Rescorla and N. Modadugu, “Datagram transport layer secu-rity,” RFC 4347, 2006.

[22] S. Kent and K. Seo, “Security architecture for the internet proto-col,” RFC 4301, 2005.

[23] M. Brachmann, S. L. Keoh, O. Morchon, and S. Kumar, “End-to-end transport security in the ip-based internet of things,” in 21stInternational Conference on Computer Communications and Networks(ICCCN), 2012, pp. 1–5.

[24] R. Seggelmann, “Sctp: Strategies to secure end-to-end communi-cation,” Ph.D. dissertation, University of Duisburg-Essen, 2012.

[25] ARM, “Building a secure system using trustzone technology,”ARM Limited, 2009.

[26] F. McKeen, I. Alexandrovich, A. Berenzon, C. Rozas, H. Shafi,V. Shanbhogue, and U. Savagaonkar, “Innovative instruction anssoftware model for isolated execution,” in Hardware and Architec-tural Support for Security and Privacy, 2013.

[27] I. Anati, S. Gueron, S. P. Johnson, and V. R. Scarlata, “Innovativetechnology for cpu based attestation and sealing,” in The 2ndInternational Workshop on Hardware and Architectural Support forSecurity and Privacy (HASP), 2013.

[28] Samsung, “Samsung KNOX: Mobile Enterprise Security,” 2015.[Online]. Available: https://www.samsungknox.com/en

[29] N. Keltner and C. Holmes, “Here be dragons: A bedtime tale forsleepless nights,” in RedCon, 2014.

[30] D. Rosenberg, “Reflections on trusting trustzone,” in BlackHatUSA, 2014.

[31] T. Wei and Y. Zhang, “To swipe or not to swipe: A challenge foryour fingers,” in RSA Conference, 2015.

[32] “Freertos reference manual: Api functions and configuration op-tions,” Real Time Engineers Limited, Tech. Rep., 2009.



11

[33] A. Barbalace, A. Luchetta, G. Manduchi, M. Moro, A. Soppelsa,and C. Taliercio, “Performance comparison of vxworks, linux,rtai and xenomai in a hard real-time application,” in Real-TimeConference, 2007 15th IEEE-NPSS, 2007, pp. 1–5.

[34] “Qnx operating systems,” 1982-2014,http://www.qnx.com/products/neutrino-rtos/index.html.

[35] “CVE-2014-0160,” Common Vulnerabilities and Exposures [On-line]. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160.

[36] “CVE-2014-2783,” Common Vulnerabilities and Ex-posures [Online]. http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-2783.

[37] “CVE-2014-2001,” Common Vulnerabilities and Exposures [On-line]. http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-2001.




[41] G. Becker, F. Regazzoni, C. Paar, and W. P. Burleson, “Stealthydopant-level hardware trojans,” in Cryptographic Hardware andEmbedded Systems - CHES 2013, ser. Lecture Notes in ComputerScience, 2013, vol. 8086, pp. 197–214.

[42] Nest Labs, “Open source compliance,” [online].https://nest.com/legal/compliance.

[43] Texas Instruments, “AM3715, AM3703 Sitara ARM Microproces-sor,” 2011.

[44] D. Halperin, T. Heydt-Benjamin, B. Ransford, S. Clark, B. Defend,W. Morgan, K. Fu, T. Kohno, and W. Maisel, “Pacemakers andimplantable cardiac defibrillators: Software radio attacks and zero-power defenses,” in IEEE Symposium on Security and Privacy (SP),2008, pp. 129–142.

[45] ST Microelectronics, “STM32L15xQC, STM32L15xRC-A,STM32L15xVC-A, STM32L15xZC Ultra-low-power 32b MCUARM-based Cortex-M3, 256KB Flash 32KB SRAM, 8KB EEPROM,LCD, USB, ADC, DAC,” no. 026119 Rev 5, 2015.

[46] M. BARBARO and T. Z. Jr., “A face is exposed for aol searcher no.4417749,” The New York Times, 2006.

[47] I. Reynolds and C. Fujioka, “Update 2-sony removes dataposted by hackers, delays playstation restart,” Reuters, 2011,[Online]. http://www.reuters.com/article/2011/05/07/sony-idUSL3E7G701T20110507.

[48] Z. Whittaker, “Amazon’s zappos in massive databreach 24 million affected,” ZDNet, 2012, [Online].http://www.zdnet.com/article/amazons-zappos-in-massive-data-breach-24-million-affected/.

[49] M. Mombrea, “Googles real plan behind the pur-chase of the nest thermostat,” 2014, [Online].http://www.itworld.com/consumerization-it/416110/googles-plan-rake-cash-nest-thermostat.

[50] W. Arbaugh, D. Farber, and J. Smith, “A secure and reliablebootstrap architecture,” in Security and Privacy, 1997. Proceedings.,1997 IEEE Symposium on, 1997, pp. 65–71.

[51] Texas Instruments, “MSP430 Programming Via the JTAG Inter-face,” 2015.

Orlando Arias is a senior Computer Engineer-ing student at the University of Central Florida.He is currently working as a research assistantin the Security in Silicon Laboratory at his in-stitution of study. His research interests includedevice security, secure computer architectures,network security, IP core design and integrationand cryptosystems. Mr. Arias was also a recipi-ent of the Best Paper Award in the 52nd DesignAutomation Conference as part of his work inhardware-assisted control flow integrity systems.

Jacob Wurm is currently a senior undergradu-ate student studying Computer Engineering atthe University of Central Florida. He is currently aresearch assistant in the Security in Silicon labo-ratory lead by Dr. Yier Jin. His research interestsinclude embedded device security, secure com-munication protocols, and network traffic analy-sis.

Khoa Hoang is an undergraduate student at theUniversity of Central Florida. He enjoys tinker-ing with electronics, technology, and jailbreakingdevices. Khoa has disclosed exploits of variousInternet of Things (IoT) device and other smartdevices to multiple vendors. He is currently listedon multiple “Security Hall of Fame” pages forsuccessful bug bounty submissions.

Yier Jin is currently an assistant professor in theEECS Department at the University of CentralFlorida. He received his PhD degree in ElectricalEngineering in 2012 from Yale University afterhe got the B.S. and M.S. degrees in ElectricalEngineering from Zhejiang University, China, in2005 and 2007, respectively. His research fo-cuses on the areas of trusted embedded sys-tems, trusted hardware intellectual property (IP)cores and hardware-software co-protection oncomputer systems. He proposed various ap-

proaches in the area of hardware security, including the hardware Trojandetection methodology relying on local side-channel information, thepost-deployment hardware trust assessment framework, and the proof-carrying hardware IP protection scheme. He is also interested in thesecurity analysis on Internet of Things (IoT) and wearable devices withparticular emphasis on information integrity and privacy protection inthe IoT era. He is the best paper award recipient of the 52nd DesignAutomation Conference in 2015.

Date post:	14-Sep-2019
Category:	Documents
Upload:	others
View:	2 times
Download:	0 times

Privacy and Security in Internet of Things and Wearable...

Documents