Caveat (IoT) Emptor: Towards Transparency of IoT Device Presence

As many types of IoT devices worm their way into numerous settings and many aspects of our daily lives, awareness of their presence and functionality becomes a source of major concern. Hidden IoT devices can snoop (via sensing) on nearby unsuspecting users, and impact the environment where unaware users are present, via actuation. This prompts, respectively, privacy and security/safety issues. The dangers of hidden IoT devices have been recognized and prior research suggested some means of mitigation, mostly based on traffic analysis or using specialized hardware to uncover devices. While such approaches are partially effective, there is currently no comprehensive approach to IoT device transparency. Prompted in part by recent privacy regulations (GDPR and CCPA), this paper1 motivates and constructs a privacy-agile Root-of-Trust architecture for IoT devices, called PAISA: Privacy-Agile IoT Sensing and Actuation. It guarantees timely and secure announcements of nearby IoT devices' presence and their capabilities. PAISA has two components: one on the IoT device that guarantees periodic announcements of its presence even if all device software is compromised, and the other on the user device, which captures and processes announcements. PAISA requires no hardware modifications; it uses a popular off-the-shelf Trusted Execution Environment (TEE) -- ARM TrustZone. To demonstrate its viability, PAISA is instantiated as an open-source prototype which includes: an IoT device that makes announcements via IEEE 802.11 WiFi beacons and an Android smartphone-based app that captures and processes announcements. Security and performance of PAISA design and its prototype are also discussed.


INTRODUCTION
Internet of Things (IoT) and embedded (aka "smart") devices have become an integral part of modern society and are often (and increasingly) encountered in many spheres of everyday life, including homes, offices, vehicles, public spaces, ports, and warehouses.It is estimated that, by 2030, there will be over 29 billion Internetconnected IoT devices [115].
Unlike general-purpose computers, IoT devices are specialized and their main functions involve some forms of sensing and/or actuation.Some of them perform safety-critical tasks and collect sensitive personal information.IoT device manufacturers understandably prioritize (novel) functionality, external aesthetics, easeof-use, and other factors, while security is usually treated as a secondary issue or an afterthought.This is partly due to various constraints, including physical space, energy, and monetary cost.
All of the above are merely research proposals.Although device manufacturers sometimes integrate research-originated techniques into their products, they rarely acknowledge the adoption of external research results.Furthermore, there are no strong compelling factors nudging the manufacturers towards adoption of security features.
Although there are several guidelines 1 for IoT security, they do not consider user privacy in the general sense.Such well-intentioned guidelines are aimed at device owners or operators, who are generally well aware of device placement and capabilities.However, IoT devices impact all human users in their vicinity by sensing them and/or controlling their environment.
This occurs in public places, such as parks, public transport, office buildings, concert halls, stadiums, and airports.It also happens in less-public places, such as hotels and private rentals, e.g., Airbnb.In the latter, users tend to be wary of unfamiliar surroundings [74,132] partly because they are unaware of nearby devices, their capabilities, what data exactly is being collected, and how it is (or will be) used.In particular, the issue of undeclared and hidden cameras has plagued the private rental industry [130].
We believe that, ideally, there would be an agreed-upon means of informing nearby (and thus potentially impacted) users about the presence of IoT devices as well as their capabilities and current activities.This would facilitate an informed decision by the users, i.e., whether to stay or leave the IoT-instrumented space.

Motivation
Based on the preceding discussion, the main motivation for this work is the need to take a step towards a privacy-compliant IoT ecosystem where all impacted users are made aware of nearby IoT devices, which empowers them to make informed decisions.Another inspiration stems from recent data protection regulations, such as the European General Data Protection Regulation (GDPR) [103] and California Consumer Privacy Act (CCPA) [86].These regulations aim to protect user privacy by stipulating that service providers must be accountable and ask for user consent before collecting, processing, storing, and sharing user data.We want to apply the same principle to IoT devices.
Note that these regulations are clearly focused on privacy, meaning that, in the IoT context, they naturally apply to devices that sense the environment.Whereas, our scope is broader -it includes actuation-capable devices that can directly impact nearby users' security and even safety.For example, consider a situation where a hotel guest with epilepsy is unaware of a "smart" fire/smoke alarm in the room which turns on a strobe light when it detects smoke or fire.Unexpected light strobing can easily cause an epileptic seizure or worse. 2 Another example is an Airbnb renter who is unaware of a smart door-lock that can be (un)locked remotely which presents a risk of the door being closed or opened without the renter's knowledge.Whereas, if forewarned, the renter could disable it for the period of stay.To this point, a 2017 incident with an Austrian Hotel where all smart locks were hacked illustrates the danger. 3ddressing privacy concerns in the IoT context poses two challenges: (1) How to make users aware of the presence of nearby devices?
(2) How to ask for consent to: collect information (in case of sensing), or control the environment (in case of actuation)?In this paper, we take the first step by focusing on (1), while viewing (2) as its natural follow-up.Current means of achieving (2) mostly focus on obtaining user consent [40,58,62,70].For example, studies on Privacy Assistants [40,58,70] focus on automating the process of acquiring user preferences/consent efficiently.Another research direction [62,67,121] provides design (and implementation) guidelines for user privacy choices that address regulatory considerations.
Regarding (1), there are several approaches for informing users about ambient devices.One approach involves manually scanning the environment using specialized hardware [8,12,89,114].Another way is by monitoring wireless traffic, i.e., WiFi and/or Bluetooth [68,112,113].Though somewhat effective, such techniques are cumbersome and error-prone, since it is not always possible to thoroughly scan the entire ambient space.Also, these approaches can be evaded if a device is mis-configured or compromised.Nevertheless, they represent the only option for discovering hidden and non-compliant devices.
Instead of putting the burden on the users to monitor and analyze wireless traffic, we want to construct a technique that guarantees that all compliant IoT devices reliably announce their presence, which includes their types and capabilities.Consequently, a user entering an unfamiliar space can be quickly warned about nearby IoT activity.We believe that this is an important initial step towards making future IoT devices privacy-compliant.We imagine later integrating the proposed technique with other consent-seeking platforms.

Overview & Contributions
We construct a technique called PAISA: Privacy-Agile IoT Sensing and Actuation, that guarantees timely and secure announcements about IoT device presence and capabilities.We use the term privacyagile to denote PAISA service -explicit user awareness of all nearby PAISA-compliant IoT devices.Each PAISA-compliant device reliably broadcasts secure announcements at regular intervals, ensuring continuous awareness, unless it is compromised via physical attacks or is powered off.
PAISA has two main components: (1) one on the IoT device that guarantees periodic announcements of its presence, and (2) the other that runs on the user device (smartphone); it captures and processes announcements.To guarantee secure periodic announcements on the IoT device, PAISA relies on the presence of a Trusted Execution Environments (TEE) or some other active Root-of-Trust (RoT) component.The TEE ensures guaranteed and isolated execution of PAISA Trusted Computing Base (TCB).On the user device, PAISA imposes no special requirements to capture and process announcements: it simply uses standard network drivers to read announcement packets and validate them in an application.
Anticipated contributions are: • Motivation for, and comprehensive treatment of, a privacyagile RoT architecture for IoT devices.To the best of our (current) knowledge, no prior work systematically approached privacy compliance in the IoT ecosystem, given that relevant attempts [68,101,112,113], are either ad-hoc or not applicable to a wide range of devices.• Design and construction of PAISA, a secure and privacyagile TEE-based architecture that reliably informs nearby users about IoT devices.Notably, PAISA does not require any custom hardware, unlike some prior work, e.g., [22,46].It uses off-the-shelf popular TEE, e.g., ARM TrustZone [32].• A fully functional prototype implementation of PAISA, which includes: (a) a prototype IoT device based on ARM Cortex-M33 featuring announcements via IEEE 802.11WiFi beacons, and (b) an Andriod application running on Google Pixel 6, which extracts and displays the announcements to the user.All source code is publicly available at [28].

Scope, Limitations, & Caveats
As with most new designs, PAISA has certain limitations: • With regard to scope, it applies to a class of devices equipped with some basic security features, e.g., ARM TrustZone.Thus, it is unsuitable for simple "bare-metal" devices or even slightly higher-end ones that lack a secure hardware element.• In terms of the security level, it offers protection against hacked (directly re-programmed) or malware-infected devices.However, it does not defend against non-compliant devices.This includes devices that are home-made, jerryrigged, or produced by non-compliant manufacturers.• Furthermore, PAISA does not defend against local jamming or wormhole attacks [71,78]. 4The latter is nearly impossible to thwart.However, we propose a method to partially handle these attacks in Sections 4.3 and 5.2.• Finally, we do not explore policy issues and implications, i.e., the focus is on reliably informing users about adjacent devices.What users do with that information is left to future work.While we acknowledge that a practical system must include this component, space limitations make it hard to treat this topic with the attention it deserves.

Targeted IoT Devices
This work focuses on resource-limited IoT devices that have strict cost and energy constraints.Such devices tend to be deployed on a large scale and are meant to perform simple tasks, e.g., thermostats, security cameras, and smoke detectors.Due to the constraints, they are often equipped with micro-controller units (MCU), such as ARM Cortex-M series [19].Nonetheless, our work is also applicable to higher-end computing devices (e.g., smartwatches, drones, and infotainment units) that are equipped with a TEE.Recall that very simple devices that have no security features are out of scope.
Figure 1 shows a general architecture of a device with an MCU and multiple peripherals.An MCU is a low-power computing unit that integrates a core processor, main memory, and memory bus on a single System-on-a-Chip (SoC).Its main memory is usually divided between program memory (or flash) where the software resides, and data memory (or RAM), which the software uses for its stack, heap, and peripheral memory access.A typical MCU also contains several internal peripherals such as a timer, General-Purpose Input/Output (GPIO), Universal Asynchronous Receiver/Transmitter (UART), Inter-Integrated Circuit (I2C), and Serial Peripheral Interface (SPI).
Sensors & Actuators: Multiple purpose-specific sensors and actuators are connected to the MCU via internal peripherals.While sensors collect information from the environment, actuators control it.Examples of sensors are microphones, GPS units, cameras, as well as smoke and motion detectors.Examples of actuators are speakers, light switches, door locks, alarms, and sprinklers.Network Interfaces: IoT devices are often connected to the Internet and other devices, either directly or via a controller hub or a router.Thus, they are typically equipped with at least one network interface (such as WiFi, Bluetooth, Cellular, Ethernet, or Zigbee) attached to the MCU via internal network peripherals, e.g., UART, I2C, or SPI.WiFi and Cellular are used for wireless Internet connectivity at relatively high speeds.Bluetooth and Zigbee are used for relatively low-speed short-range communication with other devices, e.g., a smartphone for Bluetooth, or a controller hub for Zigbee.Since WiFi is currently the most common interface available for IoT devices [122], PAISA uses it for broadcasting device announcements.However, any other broadcast media (wired or wireless) can be supported; see Section 8 for more details.
Table 1 shows some examples of (low-end) commodity IoT devices with sensors, actuators, and their network interfaces.

Trusted Execution Environments (TEEs)
A TEE is a hardware-enforced primitive that protects the confidentiality and integrity of sensitive software and data from untrusted software, including user programs and the OS.Similar to some prior work [20,35,73,102], we use ARM TrustZone-M as the TEE for the PAISA prototype.TrustZone-M is available on ARM Cortex-M23/M33/M55 MCUs [32].However, any TEE that offers trusted peripheral interfaces can be used instead.ARM TrustZone-M ARM TrustZone partitions the hardware and software within the MCU into two separate isolated regions: Secure and Normal.The former contains trusted security-critical code and data, while the latter houses user programs (or the device software).The MCU switches between secure and non-secure modes when accessing Secure and Normal regions, respectively.TrustZone hardware controllers prevent the MCU from accessing memory assigned to Secure region when it is running in non-secure mode, resulting in a secure execution environment.Moreover, at boot time, TrustZone verifies the integrity of trusted code via secure boot and always begins executing from the Secure region before jumping into the Normal region.TrustZone for ARMv8-M MCUs is called TrustZone-M (TZ-M).
TZ-M features non-secure callable functions (NSC) for Normal region software to invoke trusted code.Also, TZ-M can lock internal peripherals into the Secure region making them inaccessible to the Normal region via the TrustZone Security Controller (TZSC) that, when configured at boot, maps desired peripherals into the Secure region.This mapping configuration is controlled by TZSC and is checked by the secure-boot process at boot time.Furthermore, interrupts attached to secure peripherals are always directed to the corresponding Interrupt Service Routines (ISR) in the Secure region.Also, TrustZone Illegal Access Controller (TZAC) raises a SecureFault exception, when a security violation is observed, to the Nested Vectored Interrupt Controller (NVIC) which is then securely processed by exception handlers.

Sensor
Actuator Network I/F X-Sense smart smoke detector [17] smoke, carbon monoxide detector alarm WiFi Amazon smart plug [1] switch WiFi Blink Mini Security Camera [3] microphone, motion, camera speaker WiFi Google Nest thermostat [6] light, motion, temperature, humidity heating, cooling WiFi iRobot Roomba 694 [9] cliff, dirt, optical brush/vaccum motor, drive motor WiFi Fitbit -fitness tracker [5] accelerometer, heart rate monitor, GPS, altimeter vibrating motor, speaker Bluetooth Wyze Lock Bolt -smart lock [16] fingerprint lock, speaker Bluetooth PAISA relies on TZ-M for enabling a secure execution environment for its TCB and for implementing secure peripherals.For a comprehensive overview of TrustZone, see [129].Other Active Roots-of-Trust (RoTs) Active RoTs prevent security violations, unlike their passive counterparts that detect them [44,63,111,116].TEEs are considered active RoTs since they prevent violations by raising hardware-faults/exceptions, which are handled in the secure mode.Besides TEEs, some active RoTs have been proposed in the research literature, e.g., [22,47,99,128].Notably, GAROTA [22] and AWDT [128] offer guaranteed execution of secure ISRs when a configured peripheral is triggered.Although the current focus is on off-the-shelf devices, we believe that PAISA can be applied to either GAROTA or AWDT devices.Section 8 discusses the applicability of PAISA to other architectures.

Remote Attestation (RA)
RA is a security service that enables the detection of malware presence on a remote device (Prv) by allowing a trusted verifier (Vrf) to remotely measure software running on Prv.RA is a challengeresponse protocol, usually realized as follows: (1) Vrf sends an RA request with a challenge (Chal) to Prv.
(2) Prv receives the attestation request, computes an authenticated integrity check over its software memory region (in program memory) and Chal, and returns the result to Vrf. (3) Vrf verifies the result and decides if Prv is in a valid state.The integrity check is performed by computing either a Message Authentication Code (e.g., HMAC) or a digital signature (e.g., ECDSA) over Prv's program memory.Computing a MAC requires Prv to share a symmetric key with Vrf, while computing a signature requires Prv to have a private key with the corresponding public key known to Vrf.Both approaches require secure key storage on Prv.RA architectures for low-end MCUs [44,99] use MACs whereas higher-end TEEs (e.g., Intel SGX [77] and AMD SEV [24]) use signatures.
PAISA uses RA to ensure integrity of normal device operation, i.e. the device software controlling sensors and actuators.However, PAISA relies on TZ-M on the MCU to perform attestation locally, instead of via an interactive protocol.Also, it uses signatures to report the attestation result, similar to [24,77].

DESIGN OVERVIEW
PAISA primarily involves two parties: an IoT device (  ) and a user device (  ), e.g., a smartphone or a smartwatch.PAISA is composed of two modules: announcement on   and reception on   .Announcement: On   , the announcement module is trusted and housed inside a TEE.It ensures that, at periodic intervals,   broadcasts an announcement to other devices within its immediate network reach.Such "reach", i.e. distance, is specified by the network interface, e.g., 802.11WiFi beacons go up to 100 meters [15].Importantly, PAISA guarantees that announcement packets are broadcast in a timely manner, even if all device software is compromised.This is achieved via a secure timer and a secure network interface, available on TZ-M.
An announcement packet consists of a fresh timestamp, a device description (sensors, actuators, and their purpose) and a signature that authenticates the origin of the packet as a legitimate   .
Reception: On   , the reception module captures the announcement packet via its network interface (of the same type as on   ).The module then parses the packet, validates its timestamp and signature, and conveys the presence of   and functionality to the user.
The proposed design presents some challenges: Device State & Attestation: Merely broadcasting static information, such as a device description, is not enough.If   software is compromised, information disseminated via announcement packets is invalid since   software does not match the device description.For example, consider a user who enters an Airbnb rental and learns about a motion detector/tracker from PAISA announcements.Suppose that this motion detector is compromised and the malware notifies the adversary about the user's presence and movements.To handle such cases, the user needs authentic real-time information about the software running on   at the announcement time.Therefore, PAISA attests   software and includes the timestamped attestation report in the announcement.The reception module on   must check the attestation report as part of validating the announcement.If the attestation check fails,   must be compromised and cannot be trusted, regardless of the description in the announcement.Replay Attacks & Freshness: To protect against replay attacks and establish freshness of announcements (via timestamps),   needs a reliable source of time.However, a real-time clock is generally not viable for resource-constrained devices [27,29,97].To this end, PAISA includes a time synchronization technique: at boot time,   synchronizes with a trusted server managed by the device manufacturer.See Sections 4.2 and 5.2 for details.
To summarize, PAISA is comprised of all aforementioned components.Figure 2 presents a high-level overview of PAISA workflow.As soon as   boots, it synchronizes its time with the manufacturer server.Next, it attests its software and composes an announcement packet including the current timestamp, the attestation result, the device description, and a signature.Then,   broadcasts the packet via WiFi.This is repeated for every timer interrupt, which is scheduled (likely configured by the manufacturer 5 ) according to the desired use-case.Each announcement is received by the PAISA app on every user device within range.After validating the announcement, the app alerts the user to   's presence.

Entities Involved
PAISA considers three entities:   ,   , and the manufacturer server (  ), which is responsible for provisioning   at production time.  is a resource-constrained IoT device installed either (1) in a public space, e.g., airports, restaurants concert/sports venues, or stores, or (2) in a semi-private space, e.g., hotel rooms or Airbnb rentals.  is assumed to be equipped with a TEE to protect PAISA TCB from untrusted software (including the OS).  is the personal and trusted device of the user.It is assumed to be within network transmission range of   .  has an app that receives and verifies PAISA announcements.  is a back-end (and sufficiently powerful) trusted server hosted by   manufacturer.
PAISA assumes multiple   -s and multiple   -s in the same IoT-instrumented space, i.e., within network transmission range.  receives announcements from multiple   -s.  -s are unaware of   -s in their vicinity.PAISA uses public key signatures to authenticate and verify announcements.We assume a publicprivate key-pair (   ,    ) for each   and another key-pair (   ,    ) for each   .   is used to authenticate   as part of announcement verification.

PAISA Protocol Overview
PAISA protocol has three phases: Registration, BootTime, and Runtime.Figure 3 shows its overview.Registration phase takes place when   is manufactured and provisioned.At the time of the registration, besides installing software,   installs PAISA TCB on   and provisions it with a device ID, a description, and a keypair (   ,    ) using Provision request.Further details about the device description are in Section 5.2.A provisioned   is eventually sold and deployed by its owner/operator.BootTime phase is executed at   boot, after a reset or a power-on.Before going into normal operation,   synchronizes its time with   using TimeSync 3-way protocol.At the end of this phase, the initial announcement is generated.Runtime phase corresponds to   's normal operation.In this phase,   announces its presence based on a preset timer interval.Announcement periodicity is set by   .(We are not advocating allowing owners to set this.) Whenever triggered by the timer, Announcement procedure is invoked.It attests   software and broadcasts an announcement (Msg anno ).A nearby   receives Msg anno using its Reception app, which parses and verifies Msg anno .If the verification succeeds, Msg anno is displayed to the user.
For the complete protocol description, see Section 5.2.

Adversary Model
We consider an adversary Adv that has full control over   memory, including flash and RAM, except for the TCB and its data inside the TEE.Adv can attempt to tamper with any   components and peripherals, including sensors, actuators, network interfaces, and debug ports, unless they are configured as secure by the TEE.All messages exchanged among   ,   , and   are subject to eavesdropping and manipulation by Adv, following the wellknown Dolev-Yao model [56].Furthermore, Registration phase is considered secure -  is trusted to correctly provision   and keep the latter's secrets.Also, Reception app on   is also considered trusted.
DoS Attacks: Adv can essentially incapacitate ("brick")   by consuming all of its resources by malware.It can also keep all peripherals busy in an attempt to prevent PAISA TCB from broadcasting Msg anno packets.It can ignore or drop outgoing packets or flood   with incoming malicious packets.We also consider DoS attacks whereby a malware-controlled   reboots continuously and floods   with frivolous TimeSync requests.However, we do not consider Adv that uses signal jammers to block   from receiving Msg anno .Such attacks are out of scope and there are techniques [95,96,105] to prevent them.
Replay Attacks: we consider replay attacks whereby Adv replays old/stale Msg anno -s from any PAISA-compliant   -s.We also consider DoS attacks on   , e.g., Adv replays old Msg anno -s to swamp   network interface.
However, PAISA provides to   coarse-grained location information, i.e., where   was manufactured and where it was deployed at Registration phase.Physical Attacks: PAISA does not protect against physically invasive attacks on   , e.g., via hardware faults, modifying code in ROM, and extracting secrets via side-channels.We refer to [106] for protection against such attacks.However, PAISA protects against non-invasive physical attacks, i.e., if Adv tries to physically reprogram the device using wired debug interfaces such as JTAG.Such attacks are prevented using the secure boot feature of the TEE on   .Non-Compliant Devices: We do not consider attacks where Adv physically infiltrates and deploys malicious (non-compliant) hidden devices in an IoT-instrumented space.As mentioned earlier, there are "spyware-type" techniques, such as [12,89,114], and other prior work, such as [112,113], that scan the area for hidden devices.Albeit, even these techniques are error-prone, potentially computationally expensive, and time-consuming for users, and/or require additional equipment.Runtime Attacks: Another limitation of PAISA is that it does not handle runtime control-flow attacks, such as buffer overflows, as well as non-control-flow and data-only attacks.PAISA can only detect software modifications via attestation.For mitigating these runtime attacks, there are techniques such as Control Flow Attestation (CFA) and Control Flow Integrity (CFI) [20,43,49,52,93,116].
Dealing with these attacks and deploying countermeasures is a good idea, though it is out-of-scope of this paper.Furthermore, many CFA/CFI techniques are resource-intensive, making their use challenging in IoT settings.

Security & Performance Requirements
Recall that the main objective of PAISA is to make   privacy-agile i.e., by guaranteed periodic announcements from   about its activity to adjacent   -s, in the presence of Adv defined in Section 4.3.To that end, PAISA must adhere to the following properties: • Unforgeability: Announcements must be authenticated.  should be able to verify whether Msg anno is from a legitimate   , i.e., Adv should not be able to forge Msg anno .
• Timeliness: Announcements must be released at fixed time intervals.Adv should not be able to prevent Msg anno -s from being sent out.• Freshness: Announcements must be fresh and must reflect the current (software) health of   .Adv should not be able to launch replay attacks.
With respect to performance, PAISA must achieve the following: • Low latency of Announcement: Announcements must be quick with minimal impact on   normal utility.• Low bandwidth of Announcement: Announcements must be short to consume minimal network bandwidth on   and   .

PAISA DESIGN
This section elaborates on the design and protocol overview presented in Sections 3 and 4.

Design Challenges
There are a few design challenges (besides those mentioned in Section 3) to be addressed in order to achieve the security and performance requirements of PAISA.DoS Attacks Prevention on   : Adv can launch DoS attacks by either keeping the MCU or the network peripherals busy, as mentioned in Section 4.3.To prevent such attacks, PAISA configures both the timer and the network peripheral as secure peripherals controlled by the TEE.By doing so, PAISA ensures that the MCU jumps into the TCB whenever the secure timer raises an interrupt according to scheduled periodicity.Moreover, the timer interrupt is marked with the highest priority so that no other interrupt can preempt it.This configuration (that determines which timer and network peripheral are trusted, and their interrupt priorities) is securely stored within the TEE.Hence, Adv cannot tamper with it.This also prevents DoS attacks that attempt to keep   from executing PAISA TCB that provides guaranteed periodic broadcast of Msg anno -s.A typical target   might have 2-6 timers and multiple network peripherals, such as UART, SPI, and I2C on an MCU.PAISA reserves one timer and one network peripheral for TCB usage.This means that the network interface (e.g., WiFi or BlueTooth) connected to that reserved network peripheral is marked as exclusive.We admit that reserving a network interface exclusively for TCB use might be expensive for   , since at least one other interface (for regular use) would be needed.
To address this issue, we implement a secure stub, akin to the ideas from [65,87,125], to share the reserved network interface between secure and non-secure applications, detailed in Section 6.3.For further discussion on this issue, see Section 8. Bandwidth of Msg anno : Broadcast messages are subject to size constraints that impact network efficiency and transmission capacity, regardless of the network type.Since the device description can be of arbitrary size, to minimize the size of Msg anno , PAISA uses a fixed size broadcast message by placing all pertinent   information in a manifest file (Manifest I dev ).  -generated Msg anno -s carry only: (1) a URL that points to Manifest I dev , and (2) some metadata:

PAISA Protocol
Recall that PAISA includes three phases: Registration, BootTime, and Runtime.Below we describe each phase in detail.

Registration.
In this phase,   interacts with   to provision it with secrets and information needed to enable PAISA.Figure 5 depicts this phase.Device Manifest:   creates Manifest I dev for   , including device ID (  ), a description which includes: 7device type/model, manufacturer, date/location of manufacture, types of sensors/actuators, deployment purpose, network interfaces, owner ID, and location of deployment Figure 4 shows Manifest I dev examples.Manifest I dev can also contain a link to   developer documentation, as mentioned in [42].Note that, whenever the owner changes   's location, the corresponding manifest must be updated accordingly.The granularity of this location information influences the ability to mitigate wormhole attacks.We believe that the contents of Manifest I dev suffice to make a user aware of   capabilities.However, the exact contents of Manifest I dev are left up to the manufacturer.
stores each Manifest I dev it in its database and generates a publicly accessible link URL Man .Since URL Man can be long, we recommend using a URL shortening service (such as Bitly [2] or TinyURL[14]) to keep URL Man short and of fixed size.
Hereafter, we use URL Man to denote the short URL and URL Man Fullthe original URL.(Note that if the shortening service is not used, then URL Man is identical to URL Man Full .)For simplicity's sake, besides manufacturing   , we assume that   is responsible for deploying and maintaining the software (  ) on   .However, in practical scenarios, other entities, such as software vendors, can be involved in managing individual applications on   .In such cases, vendors must be integrated into the trust-chain by including their information and certificates into Manifest I dev .Whenever a vendor-imposed software update occurs, Manifest I dev must be updated and re-signed by   .We further discuss this update process in Section 8. Provision:   installs   and PAISA TCB ( PAISA ) into the normal and secure regions of   , respectively.  ensures that the timer and the network peripheral are configured as secure and exclusively accessible to  PAISA .Also,   sends    and a hash of   to   to be stored in  PAISA .Next,  PAISA picks a new public/private key-pair (   ,    ) and sends    to   for certification.  also gives the current timestamp to  PAISA , to be used for implementing a clock on   (see Section  [13] powered by a separate power source, thus ensuring that   time is always accurate.However, most resource-constrained IoT devices lack such an RTC.To this end, PAISA includes a secure time synchronization (TimeSync) protocol between   and   .It assumes that   is both reachable and available at all times.
The main idea of TimeSync is to receive the latest timestamp from   whenever   (re)boots, or (optionally) at regular intervals.Figure 6 shows the BootTime protocol.TimeSync: After completing the boot-up sequence,   sends a time synchronization request SyncReq to   , which includes   and the previous timestamp time prev given by   at Provision or TimeSync of the last boot.SyncReq also contains a signature to authenticate its origin as a legitimate   , and prevent DoS attacks on   via flooding of fake requests. 8Upon receiving SyncReq,   verifies the signature using    and responds with SyncResp that includes the current timestamp time cur .Upon receipt of a SyncResp,   verifies the signature using    obtained at Provision.If verification succeeds,   updates its local timestamp and sends an authenticated acknowledgment SyncAck to   .Finally,   verifies SyncAck and updates its local registered time database for   .Next time   requests a TimeSync,   will know whether the signature is based on the same time prev it previously sent.At the end of the protocol,   and   have the same time cur .Given the unavoidable network transmission latency, we suggest keeping a window of acceptance  when verifying timestamps.
Subsequently,   can be synchronized with   by re-starting the secure timer after receiving and updating time prev .Thereafter,   computes the latest time by adding time prev and the secure timer value; we denote this time as time dev .However, since this secure timer value might still deviate due to hardware inconsistencies, repeating TimeSync at regular intervals is recommended.

Runtime.
The current PAISA design uses a push model, whereby   periodically transmits Msg anno -s at fixed intervals.An intuitive alternative is to use a pull model, in which   announces its presence first and, in response, solicits information from all nearby   -s.This is similar to the Access Point (AP) discovery process in WiFi:   emits a "Probe Request" to which an AP responds with a "Probe Response" containing information about the various network parameters to establish the connection.In the same fashion,   that receives a "Probe Request" could include Msg anno in the "Probe Response" and send it to   .One advantage of the pull model is that Msg anno -s are only sent when they are needed, thus reducing the burden on individual   -s and easing the network traffic congestion.On the other hand, it becomes more challenging to deal with "sleeping" or intermittently powered-off   -s, thereby raising the energy consumption issues.In any case, we intend to explore the pull model further as part of near-future work.
PAISA runtime shown in Figure 7   Attest and Announce periodicity: If T Attest is the same as T Announce , then attestation and announcement are performed sequentially.This is recommended so that   always receives the latest information about   .However, periodicity can be adjusted based on device capabilities and desired use-cases.If   is a weak low-end device and/or must prioritize its normal applications, T Attest can be longer than T Announce . 9 We note that user linkage might occur if   fetches multiple Manifest I dev -s from the same   , assuming the latter is honestbut-curious.To mitigate this, there are well-known techniques for anonymous retrieval, such as Tor.Although this issue is somewhat outside the scope of this paper, we discuss it further in Section 8.

IMPLEMENTATION
This section describes PAISA implementation details.All source code is publicly available at [28].

Implementation Setup
As   , we use NXP LPC55S69-EVK [11] development board, based on ARM Cortex-M33 MCU (in turn based on ARMv8-M architecture) equipped with ARM TrustZone-M (TZ-M).The board runs at 150 MHz with 640KB flash and 320KB SRAM.For the network interface, we connect a ESP32-C3-DevKitC-02 [4] board, via UART to the NXP board.This network interface runs 2.4 GHz WiFi (802.11b/g/n) and it is connected to the internet via a local router.
is emulated using a Python application running on a Ubuntu 20.04 LTS desktop with an Intel i5-11400 processor at 2.6GHz with 16GB RAM.  is connected to   using UDP for TimeSync.
As   , we use a Google Pixel 6 [7], with 8 cores running at up to 2.8GHz, which is used for   .Both   and   use WiFi as their network interface to transmit/receive announcements.Figure 8 depicts the implementation architecture and Figure 10 illustrates the complete prototype.TCB configuration on TZ-M: CTIMER2 and UART4 peripherals are configured as secure, ensuring that only TCB can access them.This assurance is provided by TZ-M which raises a Se-cureFault (i.e., a hardware fault) whenever a non-secure application attempts to modify the configuration or access the secure peripherals directly.When a SecureFault is issued, the MCU enters into the SecureFault handler within the TCB, where PAISA resets the MCU.Therefore, even if Adv attempts to cause a DoS attack by raising SecureFaults, PAISA issues announcements by transmitting new Msg anno as soon as the device awakes, before any normal activity.Also, the secure timer is configured, with the highest priority, to interrupt the MCU via the NVIC every T Announce .Hence, no other user-level interrupt can preempt the announcement schedule.

Implementation Challenges
How to announce?An interesting challenge is how to broadcast Msg anno when   does not have a connection with   .A naive option is to broadcast Msg anno via UDP packets.However, this is not a robust model, since the local WiFi router in the subnet must be trusted to relay packets to   -s.Moreover, it requires   -s to be connected to the router to receive Msg anno -s, which is not a fair assumption.To mitigate this issue, we use the IEEE 802.11 standard WiFi Beacon Frames [15].Beacon frames are typically used by routers or APs to advertise their presence.PAISA can implement such beacon frames to broadcast its Msg anno letting other devices know   presence, akin to a router.More specifically, PAISA uses vendor-specific elements in the beacon frame to populate Msg anno .Msg anno size limitation: Msg anno size is limited to 255 bytes as per the length of a vendor-specific element in a beacon frame.Hence, to fit into that size, we minimized all fields in Msg anno .By using Bitly, URL Man can be reduced to 11 bytes.By using ECDSA with Prime256v1 curve, Sig anno can be reduced to 64 bytes.By using the UNIX Epoch format, time dev requires only 4 bytes.Only 5 bytes are needed for the attestation report, including one byte for the attestation result (a boolean) and 4 bytes for the attestation timestamp.In total, Msg anno size is about 116 bytes including a 32-byte nonce.
A typical WiFi router beacon frame observed in our experiments is between 200 and 450 bytes.The beacon frame generated by PAISA Msg anno is 240 bytes.It is relatively small since it contains only one vendor-specific element and no other optional tags (besides required fields), in contrast with a typical beacon frame that carries multiple proprietary optional tags.Signing overhead: Computing a signature is performance-intensive.Some very low-end devices cannot even afford them due to heavy cryptographic computations, and some take several seconds to do so.Fortunately, TEEs such as TrustZone, are (although optional) usually equipped with cryptographic hardware support.In our implementation, we use the cryptographic accelerator, CASPER, on the NXP board to perform Elliptic Curve Cryptography (ECC) to reduce signing overhead.

Trusted Software in 𝐼 𝑑𝑒𝑣
Figure 8 shows that   contains three applications: non-secure application in the normal region, PAISA TCB in the secure region, and network stack connected to the secure UART4 interface.Non-secure application: We implemented a sample thermal sensor software as a non-secure application in the normal region.The software reads temperature data from the sensor (on the NXP board) every second and sends it to an external server via the network interface.Since the network interface is exclusive to the secure world, we implemented a secure stub that can be invoked by an NSC function, allowing non-secure applications to access the network interface.This stub always prioritizes PAISA announcements over other requests.
For cryptographic operations, we use Mbed TLS library [10] on both   and   .At Provision,   and   both sample new pairs of ECC keys based on the Prime256v1 curve.PAISA TCB mainly contains three modules: Secure Timer ISR, Attestation, and Announcement.Secure Timer ISR, connected to CTIMER2, is executed when the announcement interval T Announce is triggered via the NVIC.This ISR first calls Attestation module, if T Attest is met, and then invokes Announcement module.Attestation module computes SHA256 over application program memory, in 4KB chunks, and generates Att report , as shown in Figure 7. Next, Announcement module creates Msg anno and sends it to the WiFi interface using USART_WriteBlocking().Network Stack: The ESP32-C3-DevKitC-02 board houses WiFi and Bluetooth on a single board, running on a 32-bit RISC-V singlecore processor running at 160 MHz.The board complies with IEEE 802.11b/g/n protocol and supports Station mode, SoftAP mode, and SoftAP + Station mode.PAISA TCB uses Station mode for TimeSync with   and SoftAP mode for Announcement to   .
After receiving Msg anno via uart_read_bytes(), WiFi module generates a beacon frame using esp_wifi_80211_tx() API and sets SSID="PAISA".Figure 9 shows an example beacon frame produced.It includes Msg anno in the vendor-specific element: first byte (0) indicates Element ID, second byte (083) denotes length of the tag, and next three bytes (000, 014, 06) represent Organizationally Unique Identifier (OUI) for Netgear, while remaining bytes carry Msg anno contents.The beacon frame is transmitted according to same WiFi beacon standard.

Reception App in 𝑈 𝑑𝑒𝑣
We implemented Reception as an Android app on   -Google Pixel 6.It was developed using Android Studio.To scan for beacon frames, Reception requires location and WiFi access permissions enabled by setting ACCESS_FINE_LOCATION and CHANGE_WIFI_STATE in the app configuration.
Reception uses getScanResult() API in wifi.ScanResult library to scan and identify WiFi beacon frames containing SSID= "PAISA".Then, it uses marshall() API from os.Parcel library to extract the list of vendor-specific elements from the frame.Next, the app parses Msg anno and fetches Manifest I dev from URL Man using getInputStream API in net.HttpURLConnection library.After receiving Manifest I dev , it verifies signatures in Manifest I dev and Msg anno using the corresponding public keys via java.security library.Finally, it displays the device description and the attestation report on   screen, as shown in Figure 10.Reception app also has "SCAN PAISA DEVICE" button (as shown in the figure) to explicitly scan for   .

EVALUATION
This section presents the security and performance analysis of PAISA.

Security Analysis
We argue the security of   by showing an Adv (defined in Section 4.3) that attempts to attack TimeSync and Announcement modules, and how PAISA defends against such Adv.Adv who controls the normal region of   , can attack PAISA in the following ways: (a) attempt to modify the code, data, and configuration of the secure modules, or try to read    (b) attempt to keep normal application busy (for e.g., by running an infinite loop), (c) attempt to continuously raise interrupts to escalate into the privileged mode of execution in the normal region, (d) attempt to broadcast fake or replay old Msg anno -s, (e) tamper with or drop TimeSync messages, and (f) attempt to leak privacy of   .
First, the TZSC in TZ-M hardware ensures the protection of all memory within the secure region including the secure peripheral configuration.Thus, it raises a SecureFault when (a) occurs and gives control back to the secure region handler.
Second, the NVIC configuration of MCU ensures that the secure timer has the highest priority (i.e., not preemptible), and when that timer interrupt occurs, it guarantees to invoke the secure timer ISR within the secure region.Hence, despite Adv attempts to block announcements by (b) or (c), Announcement is executed in a timely manner.Moreover, the network module is under the control of secure UART, thus, even that cannot be blocked by malicious applications.Additionally, since the announcements reach   within one hop, Adv on the internet is totally harmless.
Third, the unforgeability guarantee of signature schemes ensures that Adv cannot generate a correct Msg anno without knowing    .This entails, Adv cannot modify the Attest report to hide compromised applications, modify the timestamp of old Msg anno to create fake new ones, or make a Msg anno point to a wrong Manifest I dev ; as   catches these during Verify.And similarly, Adv cannot get away with replaying old Msg anno with valid Attest report because   detects obsolete messages based on the timestamp in it.Hence, (d) is not possible.
Fourth, messages exchanged in TimeSync are all authenticated with signatures, so tampering is not viable.Next, since the network module on   is secure, Adv cannot drop packets going out of   .However, Adv on the internet can intercept and drop messages that are in transit between   and   .For that, PAISA carefully retransmits when necessary as mentioned in Section 5.2.Additionally, Adv can launch network DoS attacks by flooding   or   during TimeSync.Nonetheless, this does not harm the purpose of PAISA because, in that case,   did not even boot to resume its activity, so no need to announce Msg anno anyway.
Lastly, Adv compromising one or more   can attempt to trace   location.However, by virtue of PKC,   need not connect to any   to learn about the IoT activity in the vicinity.Therefore, there is no user privacy leakage at all.
The above five points conclude the security argument of PAISA, ensuring it meets all security requirements stated in Section 4.4.

Performance Analysis
Note that we measure the mean and standard deviation of each performance value over 50 iterations.
Performance of   : PAISA overhead on   is measured in two phases: BootTime and Runtime.
BootTime comprises the time taken for device initiation (InitDevice), TimeSync, and Announcement.During InitDevice,   initiates the MCU itself and peripherals including timers, sensors, actuators, and network interfaces.Next, during TimeSync,   initiates its WiFi module in Station mode to connect to   using UDP.After a successful connection,   and   communicate to synchronize the former's clock.Then,   executes Announcement to issue its first Msg anno .As shown in Table 2, the time for InitDevice is 9.66ms with negligible standard deviation.Whereas, average latency of TimeSync is 1,076ms with a significant deviation of 187ms.This is because TimeSync includes network delay and all messages exchanged between the parties.Another reason for the high mean latency of TimeSync is due to: (a) two signing operations during SyncReq and SyncAck, and (b) one verification operation during SyncResp.Each ECDSA signing/verification operation takes ≈ 230ms at 150MHz.Finally, Announcement takes 236ms, which includes one signing operation and a beacon frame transmission.Adding all these, the total boot time is about 1.3s, which is mostly due to TimeSync and Announcement.However, since this happens infrequently, we believe it is reasonable.Runtime overhead stems from the PAISA Announcement module.Figure 11 shows the performance of Announcement with variable size of the attested region.The latency for generating and signing an Msg anno is constant since the signature is over a fixedsized value.Attestation latency grows linearly with the attested memory size since it requires hashing.However, signing takes significantly longer, about 230ms, than attestation, which only requires 1ms for 64KB.This is because public key operations naturally take more time than hashing.Therefore, Announcement latency almost equals that of one signature operation.Also, the software size of mid-to-low-tier devices is typically under 100KB.Even if it reaches 1MB, attestation would take only ≈ 16ms, which is 14 times less than one signature.Furthermore, during Announcement, the runtime overhead of the network interface is negligible, amounting to ≈ 135s, which has minimal impact on overall latency.

DISCUSSION & LIMITATIONS
We now discuss some limitations of PAISA and potential mitigations.

Run-time Overhead:
To measure run-time overhead on   , we define CPU utilization ( ) as the percentage of CPU cycles that can be used by the normal application amidst the announcements, denoted by  =     +  .Here,   is the CPU cycles for the normal application between two announcements, which equals to T Announce , and   is the time taken for one announcement, which is nearly 250 ms (from Section 7.2).So if T Announce = 1, then  = 80% of normal utility, which is not good for general applications.If T Announce = 100, then  = 99.7%, but it is not good for the users since they could not be aware of   up to 100s.Therefore, depending on the application, there is a desired balance between the normal utility and the announcement interval.
There are other ways to reduce the overhead of PAISA.
If the normal application binary size is large, T Attest can be increased to lower the overhead at every T Announce .However, this might not yield much of a reduction since, as can be seen in Figure 11, signing incurs higher overhead than attestation.Therefore, we consider the following option.
If the activity schedule of   is known, it can pre-compute multiple Msg anno -s during idle time and later release one at a time.In this case, amortized (real-time) overhead would be significantly lower, since it would be only due to broadcasting Msg anno .For example, a smart speaker can precompute a day's worth of announcements at midnight and gradually release them.However, this approach is only applicable to devices that are not real-time and/or safetycritical.Also, in settings where a group of very low-end devices (e.g., smart bulbs) is connected to a local hub or controller, the latter can act as a PAISA proxy, i.e., it can broadcast a collective announcement on behalf of the entire group of its constituent devices.Compatibility with other RoTs: PAISA can be applied to any architecture that offers a secure timer and a secure network interface.ARM TrustZone-A (TZ-A) is widely available in higher-end IoT devices that rely on ARM Cortex-A-based microprocessors (e.g., Raspberry Pi and Rock Pi).Since TZ-A offers similar guarantees to TZ-M, PAISA can be directly realized on the former.
For lowest-end MCUs, such as TI MSP430 [76] and AVR ATMega8 [18], an active RoT, called GAROTA [22], offers a secure timer, GPIO, and UART peripheral support based on some additional custom hardware.PAISA can be applied to GAROTA by extending the secure timer TCB of GAROTA to include periodic announcements.
Furthermore, there is a software-based MultiZone TEE [69] for RISC-V-based MCUs.Relying on Physical Memory Protection Unit (PMP), Multizone divides memory and peripherals into well-isolated regions, called Zones, which are configured at compile-time.PAISA can be implemented as one of the Zones with a timer peripheral and a network peripheral assigned to it.Compatibility with Other Network Interfaces: We believe that PAISA is compatible with other network interfaces besides WiFi, such as Bluetooth-Low-Energy and Cellular.For example, with Bluetooth version 5.0 and above, devices scan for other nearby devices by broadcasting packets that contain the sender address and advertising payload which can be up to 255 bytes.A PAISA announcement (116 bytes) can easily fit into this payload.Secure Update on   : To support secure software updates on   ,   or software vendors can initiate an update request by sending the new software along with its authorization token.This token is generated using a private key for which the corresponding public key is known to   .Implementing this process requires extending PAISA TCB to include token verification and update installation.We expect that this update procedure can be implemented in a manner similar to existing frameworks, such as [47,82,109].User Linkage: There are both practical and conceptual techniques for anonymous retrieval that can be used to fetch Manifest I dev -s.The former include Tor, Mix Networks (e.g., Jondo and Nym), and peer-to-peer networks (e.g., I2P, Freenet).They all facilitate anonymous communication, however, their use might be illegal in some jurisdictions, while in others their use might be impractical due to additional requirements, such as Virtual Private Network (VPN).Conceptual techniques include privacy-preserving cryptographic constructs, such as Private Information Retrieval (PIR) [26,94] and Oblivious RAM (ORAM) [88,124].Using these types of techniques would require building customized "wrappers" for PAISA.PAISA TCB: As discussed in Section 7.2, though the TCB size of the main device is small, the total size (including the network driver) increases the attack surface.
Unfortunately, this is unavoidable because PAISA's main objective is guaranteed announcements which necessitates its reliance on a trusted network interface.However, to alleviate this problem, we suggest pruning the network module to only contain what is absolutely necessary.For example, PAISA only requires the driver to establish a UDP connection with   and broadcast WiFi beacon frames.The rest of the driver module (including TCP, HTTP, etc.) can be removed, thus significantly reducing the binary size.However, if normal applications want to use these protocols (via the secure stub mentioned earlier), the driver has to retain them.Exclusive Network Module: To ensure protection from DoS attacks, PAISA requires exclusive access to a network peripheral on   .This is because a shared network interface can be easily exploited by Adv by keeping the interface busy and not allowing Msg anno packets to be sent out.
However, reserving a network interface exclusively for TCB use is expensive, since the   budget might not permit an additional interface (in terms of cost and/or energy) for normal use.To address this concern, we suggest using techniques such as [65,87,125] that involve a secure stub that shares peripherals between secure and non-secure programs.The main idea is to lock the network interface as a trusted peripheral controllable only by TZ-M.Also, a stub is implemented in the secure region that carefully parses inputs and relays them to the trusted interface.This stub is made available to normal applications by exposing an NSC function callable from the normal region.Furthermore, the stub must also implement a scheduling queue for handling requests from both secure and non-secure applications.This way, there is no need to equip   with an additional interface.We implement a basic functionality of this approach as a proof-of-concept.It is available as part of [28].Nonetheless, we emphasize that, for the "timeliness" property of PAISA, the Announcement module is always given higher priority for accessing the network interface.Role of   : PAISA relies on   for TimeSync and hosting a database for Manifest I dev .If the number of   -s provisioned by   is high and   is consistently overloaded with requests, we suggest using helper third-party servers in the local area of deployment.Of course, such servers must be certified by   to prove their authenticity when responding to TimeSync and Manifest I dev retrieval requests.

Related work can be classified into six categories:
Active RoTs proactively monitor activity on MCUs to prevent (or minimize the extent of) compromises.For example, [22,46,47] are co-design (hardware/software) architectures that guarantee the execution of critical software even when all device software is compromised.[46] guarantees sensor data privacy by letting only authorized software access sensor data via secure GPIO peripherals.On the other hand, [47] prevents code injection attacks by allowing only authorized software to run on the MCU while preventing any other software from modifying it except via secure authorized updates.Whereas, [72,128] rely on ARM TrustZone or a similar class of MCUs to protect devices from being "bricked", by resetting and updating the device whenever it does not respond to a watchdog timer.Remote Attestation: There is a large body of research proposing remote attestation architectures on wide-range of devices.[25,36,44,45,57,84,91,99,100,108,111,120] propose attestation architectures for MCUs.There are also other architectures such as [20,48,49,52,53,63,116,131] that discuss runtime attestation techniques, including control-flow, data-flow attestation, for lowend MCUs.All the aforementioned attestation architectures can be integrated with active RoTs mentioned earlier to enable PAISA.
For servers and high-end IoT, there are TEE architectures such as Intel SGX [77], AMD SEV [24], Sanctum [41] and Keystone [85] that provide attestation APIs for attesting in-enclave applications.However, these are not applicable for PAISA because PAISA attests and reports the normal region instead of the secure region.ARM TrustZone: Lots of prior work leveraged TrustZone to improve the security of systems from various perspectives.[35,73,92] use TZ-A as an authorization tool for non-secure applications.[35] proposes an authorization architecture to regulate smaller user devices connected to IoT hubs, enabled by TZ-A.[73] implements a user authentication scheme based on TZ-A on smartphones.Besides these, TZ-M is also used to enhance security in several constrained settings, e.g., to optimize secure interrupt latencies [102], improve real-time systems [126], mitigate control-flow attacks [20,90], and add support for virtualization [104].Similarly, in PAISA, we use TZ-M to trigger announcements at regular intervals.Hidden IoT Device Detection: To detect hidden IoT devices in unfamiliar environments, there are a few approaches proposed in recent years."spyware" solutions such as [12,114] are popular detectors; however, the detector should be in close proximity to the IoT device.[89] designs specialized hardware -a portable millimeter-wave probe -to detect electronic devices.[107] leverages the time-of-flight sensor on commodity smartphones to find hidden cameras.However, they either take significant time or require specialized hardware to detect the devices.Moreover, they can only detect IoT devices, but cannot identify them.
On the other hand, [68,101,112,113] observe WiFi traffic to identify hidden devices.In particular, [112] monitors coarse attributes in the WiFi 802.11 layer to classify IoT devices.[113] establishes causality between WiFi traffic patterns to identify and localize an IoT device.[101] uses autoencoders for automatically learning features from IoT network traffic to classify them.However, all the aforementioned techniques rely upon probabilistic models, hence, they can be error-prone, especially when there are newer devices or when the adversary is strong enough to bypass the detection logic; moreover, they are computationally intensive.Conversely, PAISA takes a systematic approach to make users aware of the devices with minimal computation on their end.Furthermore, PAISA announcements convey more information regarding the device such as its revocation status, software validity, and complete device description, which is not possible with other approaches.Broadcasting Beacon Frames: [38] proposes a technique, Beaconstuffing, that allows Wi-Fi stations to communicate with APs without associating with any network.Subsequently, many applications of Beacon-stuffing have been introduced over the past decade.[23] uses beacon frames to figure out if a given device is physically located nearby a user device while the user is using the former for Two-Factor Authentication.[118] achieves two-way data encryption transmission by injecting custom data into the probe request frame.[54] proposes a smartphone-based Car2X communication system to alert users about imminent collisions by replacing the SSID field in the beacon frame with the alert message.Following the 802.11standard, [66] shows that custom information can be embedded in a beacon frame by modifying vendor-specific fields.IoT Privacy: Some prior work focused on enhancing user privacy in the context of IoT via Privacy Assistants (PA-s) user notices, and consent.PA-s [58,70,79] provide users with an automated platform to configure their privacy preferences on nearby IoT resources.For example, a recent study [40] interviews 17 participants to learn user perceptions of several existing PA-s and identifies issues with them.It then suggests ideas to improve PA-s in terms of automated consent, and helping them opt out of public data collections.[62] explores a comprehensive design space for privacy choices based on a user-centered analysis by organizing it around five dimensions (e.g.type, functionality, and timing).It also devises a concrete use case and demonstrates an IoT privacy choice platform in real-world systems.
Furthermore, some research efforts have explored privacy and security labels (akin to food nutrition labels) for IoT devices.For example, [59] suggests a set of IoT privacy and security labels based on interviews and surveys.It identifies 47 crucial factors and proposes a layered label approach to convey them.[60] conducts a survey with 1, 371 online participants to evaluate the privacy factors proposed in prior research with two key dimensions: an ability to convey risk to consumers and an impact on their willingness to purchase an IoT device.Also, the study yields actionable insights on optimizing existing privacy and security attributes of IoT labels.Similarly, [61] conducts a survey with 180 online participants in order to evaluate the impact of five security and privacy factors (e.g.access control) on participants' purchase behaviors when individually or collectively presented with an IoT label.The study underscores participants' willingness to pay a substantial premium for devices with better security and privacy practices.
These prior results are valuable and relevant to this paper since they provide guidelines for which privacy-related factors should be reflected in Manifest I dev and how to utilize them in order to attain acceptable user experience with effective privacy configurations.

CONCLUSIONS
This paper suggests taking a systematic approach to making IoT devices privacy-agile by advocating that devices periodically inform nearby users about their presence and activity.As a concrete example of this approach, we presented the design and construction of PAISA: a secure and privacy-agile TEE-based architecture that guarantees secure periodic announcements of device presence via secure timer and network peripherals.We implemented PAISA as an end-to-end open-source prototype [28] on: (1) an ARM Cortex-M33 device equipped with TrustZone-M that broadcasts announcements using IEEE 802.11WiFi beacons, and (2) an Android-based app that captures and processes them.The evaluation shows that   takes 236ms to transmit an announcement and it only takes 1sec for the app to process it.

Figure 1 :
Figure 1: Architecture of an IoT Device.This example shows the peripherals of a security camera.

Figure 4 :
Figure 4: Examples of Manifest I dev .Left one is for Google Thermostat [6] and right one is for Blink Security Camera [3].

Figure 7 :
Figure 7: Runtime Phase of PAISA update, maintenance shutdown, or a change of the shortened URL,),   sends the updated URL Man to   at the time of TimeSync.Attest and Announce periodicity: If T Attest is the same as T Announce , then attestation and announcement are performed sequentially.This is recommended so that   always receives the latest information about   .However, periodicity can be adjusted based on device capabilities and desired use-cases.If   is a weak low-end device and/or must prioritize its normal applications, T Attest can be longer than T Announce .9In our experiments, Attest time is much smaller than Announce time because signing takes more time than just hashing a small amount of memory.Reception: After receiving Msg anno from   ,   first parses it and checks if the received time dev is within [time U dev −, time U dev ], where time U dev is the clock value of   , and  is the toleration delay window of the assumed network.If Msg anno is fresh, then   fetches Manifest I dev from the link URL Man and verifies Manifest I dev based on the public key    and the signature Sig Man embedded in Manifest I dev .Next, it verifies the signature of Msg anno with the public key of   , also embedded in Manifest I dev .Upon successful verification of the signatures,   acknowledges the legitimacy of the announcement source, thereby confirming that the corresponding   is in its network reach.Furthermore, by reading Attest,   learns whether   is a trustworthy state since the last attestation.If Attest fails,   disregards Msg anno and alerts the user of a potentially compromised   .

Figure 10 :
Figure 10: PAISA Proof-of-Concept.The Phone screenshot on the right side shows Reception app with device details of   (emulated on the NXP board beside it).

Figure 11 :
Figure 11: PAISA Announcement Overhead on   at Runtime.

Table 1 :
Various Types of IoT Devices with different Sensors, Actuators, and Network Interface.
, where  PAISA is PAISA TCB software, time cur is the current timestamp, URL Man Full is the full URL of URL Man if the URL is shortened, and URL Man is the shortened URL.(d)  PAISA in   picks a new keypair (   ,   ), stores    , and outputs    to   .(e)   computes Sig Man := SIG(  , Manifest I dev ), where SIG is a signature function, and appends Sig Man and   to Manifest I dev hosted at URL Man .Registration Phase of PAISA.a timestamp, and a signature of Msg anno .For the sake of simplicity, we assume that Manifest I dev is hosted on   .  receives Msg anno , verifies it, extracts the URL, and fetches Manifest I dev from   .Note that Manifest I dev can also be hosted by other third parties or on a blockchain; its authenticity is based on   's signature at the time of provisioning.
5.2.2).   appends    and the hash of   to Manifest I dev .Finally, to authenticate Manifest I dev ,   signs Manifest I dev using    and appends the signature and its own certificate to Manifest I dev .Alternatively,   could directly register    with a Certificate Authority (CA) if there is a suitable deployed public key infrastructure (PKI), and include   's certificate in Manifest I dev .Also, URL Man Full is included in Manifest I dev so that   , when it later uses URL Man , can detect if the redirection is wrong.Also, for sanity purposes,   can include a "status" flag in Manifest I dev to indicate if   is revoked, e.g., reported stolen.5.2.2 BootTime.As mentioned earlier, Msg anno must contain the timestamp of   to prevent replay attacks.Some IoT devices Protocol 2. PAISA BootTime consists of one procedure, TimeSync, and is realized as follows.TimeSync [  ←→   ]: Assume a map   :=<    , time I dev > maintained by   , where    is ID of   provisioned using Provision and time I dev is the latest registered timestamp of   .TimeSync is defined by three interactions [SyncReq, SyncResp, SyncAck ]: (a) SyncReq [  −→   ] : When   boots: (i) Computes SyncReq := (   , N 1 dev , time prev , Sig Req ), where N 1 dev is a nonce, time prev is the previous timestamp, and Sig Req := SIG(   , H (   | |N 1 dev | |time prev + 1) ) (2) (ii) Sends SyncReq to   .(b) SyncResp [  ←−   ] : Upon receiving SyncReq,   : (i) Checks if time prev + 1 is consistent with the latest registered timestamp in   .If fails, outputs ⊥ and ignores SyncReq.(ii) Verifies Sig Req using    .If fails, outputs ⊥ and ignores SyncReq; otherwise, continues.(iii) Computes SyncResp := (   , N 1 dev , N 1 svr , time cur , Sig Resp ), where N 1 svr is a nonce and time cur is the current timestamp of   , and Sig Req := SIG(  , H (   | |N 1 dev | |N 1 Msvr | |time cur ) ) (3) (iv) Sends SyncResp to   .(c) SyncAck [  −→   ] : Upon receiving SyncResp,   : (i) Verifies SyncResp using   .If fails, outputs ⊥, ignores SyncResp, and repeats TimeSync; otherwise continues.(ii) Sets time prev := time cur from SyncResp.Sig Ack := SIG(   , H (   | |N 2 dev | |N 1 Msvr | |time prev ) ) (4) (iv) Sends SyncAck to   .Finally,   verifies Sig Ack with   .If successful,   stores time prev as the latest registered timestamp of   .
Announcement on   is part of  PAISA , installed at Provision time, and (2) Reception is an app on   , installed by the user.Announcement: PAISA implements two time intervals using secure timer on   , T Attest and T Announce , which govern when Attest and Announce must be executed, respectively, triggered by the timer interrupt.During Attest, i.e., when time dev matches T Attest , PAISA measures   memory containing   and compares it with the hash of   stored at Provision time.If the measurements match,   sets Att result =  and Att report = (Att result , time dev ) and stores the latter in secure RAM.During Announce, i.e., when time dev matches T Announce ,   generates new Msg anno composed of: a nonce, the current timestamp time dev , URL Man given at Provision time, Att report from the latest attestation as per T Attest , and a signature over its content.The size of Msg anno depends on the signature algorithm used.Also, whenever the Manifest I dev or URL Man is updated (e.g., software Protocol 3. PAISA runtime consists of two procedures: Announcement and Reception: Announcement [  ←→   ]: Let time dev be   clock realized using a secure timer and the latest timestamp received via TimeSync.Announcement is defined by two sub-procedures [Attest, Announce ].Also, let T Attest and T Announce be the periodicity of Attest and Announce, respectively.(a) Attest [  −→   ] : If time dev % T Attest == 0,   generates an attestation report: (i) Measures program memory:   := H (  ).(ii) Sets Att result := 1 if   ==    , where    is the expected hash of   software installed during Provision.Otherwise, Att result = 0. (iii) Outputs Att report := (Att result , time dev ), where time dev is the timestamp when the attestation report is generated.(b) Announce [  −→   ] : If time dev % T Announce == 0,   broadcasts an announcement packet: (i) Generates Msg anno := (N dev , time dev , URL Man , Attest, Sig anno ), where N dev is a nonce, time dev is the current timestamp, URL Man is the stored link pointing to Manifest I dev given at Provision, and Sig anno := SIG(   , H (   | |N dev | |time dev | |URL Man | | Attest) ) (5) (ii) Broadcasts Msg anno .Reception [  ←→   ]:   maintains a timer time U dev synchronized with the world clock.Upon receiving Msg anno from a   ,   executes Reception.Reception is defined by a sub-procedure [Verify ] : (a) Parses Msg anno and extracts: (time dev , URL Man , Attest, Sig anno ).Next, fetches Manifest I dev from URL Man .(b) Verify [  −→   ] : Upon receipt of Manifest I dev , verifies Msg anno : (i) Checks if (time U dev −  ) < time dev , where  is the tolerance delay window.If not, discards and outputs ⊥. (ii) Retrieves Sig Man and   from Manifest I dev , and verifies Sig Man using   .If fails, aborts and outputs ⊥. (iii) Retrieves    and verifies Sig anno .If fails, aborts and outputs ⊥.(c) Outputs (Manifest I dev , Attest).
(1)olves two procedures:(1) In our experiments, Attest time is much smaller than Announce time because signing takes more time than just hashing a small amount of memory.Reception: After receiving Msg anno from   ,   first parses it and checks if the received time dev is within [time U dev −, time U dev ], where time U dev is the clock value of   , and  is the toleration delay window of the assumed network.If Msg anno is fresh, then   fetches Manifest I dev from the link URL Man and verifies Manifest I dev based on the public key    and the signature Sig Man embedded in Manifest I dev .Next, it verifies the signature of Msg anno with the public key of   , also embedded in Manifest I dev .Upon successful verification of the signatures,   acknowledges the legitimacy of the announcement source, thereby confirming that the corresponding   is in its network reach.Furthermore, by reading Attest,   learns whether   is a trustworthy state since the last attestation.If Attest fails,   disregards Msg anno and alerts the user of a potentially compromised   .

Table 2 :
PAISA Overhead on   at BootTime.Performance of   : The latency of Reception application is shown in Table3.It takes 1,070ms with a deviation of 247ms to receive one Msg anno .This large deviation is due to two factors: the time to fetch Manifest I dev depending on network delay and frequency, plus context switching time on the smartphone.Note that Google Pixel 6 has heterogeneous cores (2 cores @ 2.8GHz, 2 cores @ 2.25GHz, and 4 cores @ 1.8GHz), thus, the overall frequency is represented as [1.8-2.8]GHz in Table3.Despite it taking 1s for one message, there is not much impact in case of multiple   -s, because Msg anno processing can be done concurrently via threading (AsyncTask).Therefore, upon launching the Reception app, the delay in receiving most announcements is expected to be within a few seconds.

Table 3 :
PAISA Overhead on   and   .Performance of   : TimeSync has one signing and two verification operations which take about 1ms each at 2.6GHz.Hence, the average latency of TimeSync is 5.6ms with a deviation of 2.77ms, mostly due to network delay.This latency is reasonable, despite   handling multiple devices, because they can be served in parallel.Moreover, TimeSync only occurs at reboot which is quite infrequent for each   .Manifest I dev size: Many factors, such as device description, cryptographic algorithm, key size, type of certificates, and encoding method used in certificates, influence the size of Manifest I dev .Thus, Manifest I dev can vary from a few to a few hundred KB-s.The size of Manifest I dev used in our evaluation is 2,857 bytes.TCB size: As mentioned in Section 6.3, PAISA TCB consists of software in TZ-M of the main NXP board and the driver in the network ESP32 board.On the main board, the TCB is 184KB (includes Mbed TLS), and 682KB on the network board (includes the network stack).