{'fraction_non_alphanumeric': 0.02887108857258111, 'fraction_numerical': 0.005820319253155074, 'mean_word_length': 4.818357082984074, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 1, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 9, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Privacy-Preserving Protocols for Smart Cameras and Other IoT Devices

Millions of consumers depend on smart camera systems to remotely monitor their homes and businesses. However, the architecture and design of popular commercial systems require users to relinquish control of their data to untrusted third parties, such as service providers (e.g., the cloud). Third parties therefore can (and in some instances have) access the video footage without the users' knowledge or consent -- violating the core tenet of user privacy. In this paper, we introduce CaCTUs, a privacy-preserving smart camera system that returns control to the user; the root of trust begins with the user and is maintained through a series of cryptographic protocols designed to support popular features, such as sharing, deleting, and viewing videos live. In so doing, we demonstrate that it is feasible to implement a performant smart-camera system that leverages the convenience of a cloud-based model while retaining the ability to control access to (private) data. We then discuss how our techniques and protocols can also be extended to privacy-preserving designs of other IoT devices recording time series data.


INTRODUCTION
Smart camera systems are changing the way consumers secure their homes and businesses. Commercial camera systems have been remarkably successful; they have become the de facto monitoring system, as they offer the following essential services with plug-and-play support: (1) watch live and recorded video feeds, (2) share videos with others, (3) delete recorded videos, (4) recover access to the system, and (5) perform a full factory reset. Yet, while the market demand for smart camera systems continues to grow rapidly as reported by Ring [12,26,27,59], Wyze [60], and Arlo [4], consumers have come to realize that the costs of owning a smart camera system are not exclusively monetary.
Commercially available smart camera systems follow a threat model that mandates undue trust by design; the service provider is granted unfettered access to the video content of any consumer who uses their system. Ring has come under legal scrutiny [21,24] for allowing more than 2,000 government agencies to directly request videos from users without formal due process [9,34,46,49]. Perhaps even more troubling, employees are viewing and annotating live user streams for research [6,15] while others are abusing their access to view and share users' videos online [29,53]. Moreover, research has posited that these systems can be transformed into mass surveillance systems, given their widespread adoption [10-12, 32, 34, 38, 39, 48]. The message behind the underlying design of modern smart camera systems is clear: users do not have control over their own videos and system, compromising user privacy.
To this end, we answer the following question: can users afford all of the features present in commercial smart camera systems, without compromising their privacy? A cryptographic approach is a plausible way to protect users' privacy in that it enables users to solely assume control over videos stored in the cloud. However, practical realizations of such systems face several key challenges: cryptographic protections (e.g., encryption) incur computational overheads, affecting system performance, since stored videos are encrypted; a fine-grained sharing scheme (i.e., sharing specific video fragments) requires a user-controlled key management system; and generating, storing, rotating, and re-negotiating cryptographic keys poses further challenges on performance and usability. Troublingly, even if such challenges could be addressed, events have demonstrated that encryption alone is not sufficient to protect users from abuses by governments through coercion [23,33]. Thus, meeting performance, security, privacy, and usability goals demands a novel approach that is sensitive to the unique requirements of this domain.
In this paper, we present CaCTUs, a privacy-preserving smart Camera system Controlled Totally by Users. Inspired by information privacy laws, CaCTUs is designed to enforce three privacy goals through known security properties: (1) the right to not be seen: the user is assured confidentiality of stored videos and live video streams; (2) the right of sole ownership: the user (and only the user) is trusted, and has complete mediation over access to their data by others; (3) the right to be forgotten: deleted videos are not recoverable, even in cases of coercion. Moreover, we show that the protocols involved in CaCTUs can be generalized to other IoT devices.
To meet the required feature set of commercial systems and address the stringent technical challenges and privacy goals of smart camera systems, we design CaCTUs as follows: it allows the user to solely assume control of the smart camera system through a direct and physical pairing process (that is, without relying on or trusting third parties); isolates and protects access to video footage through encryption, key rotation, and key management; enables viewing live and stored videos through performance-aware cryptographic algorithms; supports video deletion and factory reset via key rotation and management; and provides fine-grained (i.e., on the scale of seconds) peer-to-peer delegation of video footage through a binary key tree. We make the following contributions: (1) We present CaCTUs, a privacy-preserving smart Camera system Controlled Totally by Users, that returns controls of the system to users without compromising features found in commercial smart camera systems.
(2) We perform a performance and functional user evaluations of our system and find that CaCTUs can serve a live video stream at a resolution of 480 p, at a frame rate of 10 fps, with a latency of 2 s and that it is natural and easy to use, all while meeting our privacy goals.
(3) We demonstrate how the protocols used in CaCTUs can be adapted to a broader class of devices.
To encourage the development of future privacy-preserving IoT devices, we release CaCTUs as open-source software available at https://github.com/siis/CaCTUs.

Smart Camera Systems
A smart camera system is a collection of cameras that are connected to the Internet, allowing owners (i.e., those who purchase and configure the system) to view live and recorded videos of their homes from anywhere. Most companies sell their systems as an integrated ecosystem: cameras work with a purpose-built smartphone application that allows the owner to view footage, delegate access, and administer their smart camera system. At the core of these systems are five functions: (1) recording and streaming, (2) sharing (delegation), (3) deleting, (4) access recovery, and (5) factory reset. Each function places requirements and motivates the architecture of the ecosystems available to consumers.
Recording and Streaming. Camera systems allow owners to view live and recorded footage from all cameras they own using a smartphone application, allowing them to monitor the current status of their property. As the most fundamental function provided by camera systems, this is expected to work reliably and globally: users want to be able to view footage anywhere, and recover footage even in the case of physical failures of the camera or home Internet connection.
To facilitate this, consumer smart camera systems currently entrust the data to a cloud provider, streaming camera data to cloud storage as it is captured and making it available to the owner's device. As a result, access to the footage is managed by the cloud provider, who must be trusted to prevent unauthorized access.
Delegation. Owners want to share access to their camera systems with others. We refer to this capability as delegation.
Whether used to provide a house-sitter with access to live footage during a vacation, or sharing video of an incident after the fact, this delegation is expected to be fine-grained, meaning it applies to specific users (delegatees) for only the portion of time that they need access. Consumer smart camera systems allow policy enforcement as a means of delegation: each user has an attached policy for the time range of live or recorded footage they may access, and cloud storage mediates this to prevent delegatees from exceeding their policies.
Deletion. Owners expect the ability to fully delete their data to prevent further access by any party. As recorded data from camera systems are saved to the cloud, owners must trust cloud providers to delete their data when requested, including copies stored elsewhere in the cloud.
Access Recovery. Since access to smart camera systems is mediated by a set of credentials (e.g., a username and password), these systems must account for the possibility of a user losing them. When authentication is performed by a cloud service, this is relatively straightforward: user's identity is verified via other means, such as a password reset through email. As we will discuss, however, such recovery is only trivial because of the trust assumptions of these systems, and we will see that this critical function requires careful thought under other trust models.
Reset. Finally, owners may wish to stop use of the smart camera system. In this case, they will expect all of their stored footage to be deleted, access to live footage revoked, and the device returned to a condition where it may be set up by another user. This is generally equivalent to a delete operation for all stored data, followed by resetting the physical camera itself.

Privacy in Smart Camera Systems
Smart camera systems have been shown to have both privacy and security risks [6,9,14,15,29,34,46,49,53]. Motivated by legal frameworks (e.g., the California Consumer Privacy Act (CCPA), California Privacy Rights Act (CPRA), and the European General Data Protection Regulation (GDPR), among others [8,35,36,[42][43][44]47]), we identify the following concrete rights that a privacy-preserving system should afford to the system owner, in practice, they imply that device owners must have exclusive control over the collection of data, its uses, and the access delegations to it: (1) Right to not be seen: no unauthorized user can view stored videos or live video streams.
(2) Right of sole ownership: the owner retains full control of their data and who they trust.
(3) Right to be forgotten: deleted videos are not recoverable, even in cases of coercion. Fig. 1. Overview of the components and actors in the privacy-preserving smart camera system CaCTUs: the camera devices and the users' devices are trusted while the cloud storage provider, the networks, and any other third party are untrusted.

Threat Model
Our goal in this work is to demonstrate a smart camera system that provides feature parity with commercial systems while placing no trust in a cloud provider or other third party. As such, we work under a threat model wherein edge devices (i.e., the smart camera and end-user devices) are trusted, but the cloud storage provider, network, and any other third-party service are untrusted (see Figure 1 for an overview of CaCTUs's threat model).
We only trust the devices owned by the users (cameras, smartphones, laptops, or tablets) to securely handle the encryption and decryption keys used in the system, and we trust the device manufacturer to provide us with a camera device that correctly executes its functionality. This additionally implies that supply-chain exploits against the camera manufacturer are out of scope. We trust the other applications running on the users' devices (or that the operating system sufficiently isolates these applications) and we assume that the cryptographic algorithms used provide the advertised guarantees (e.g., Diffie-Hellman assumption [16] and RSA public-key cryptosystem [52]).
We also acknowledge that access under our system may be universally delegated: once granted access to a video, a party is not prevented from sharing with others or downloading and storing the videos somewhere else. Partial mitigations to this may be considered, but as such sharing can occur outside the purview of our system complete prevention is not possible. Encrypted frames are assumed to be publicly accessible (as we do not trust the cloud to do any access control mediation), thus we acknowledge that access pattern to the cloud storage may be leaked in CaCTUs.
Ongoing research in Private Information Retrieval (PIR) or Oblivious RAM (ORAM) could provide potential mitigations through the use for example of random accesses and dummy writes to the cloud storage. Finally, physically tampering with the devices (modifying the hardware, chip-level changes to edit the software execution, etc.) and denial of service attacks are outside the scope of our work.

Overview
In the following sections, we will describe how CaCTUs meets the privacy goals described in Section 2 by providing the following three security properties: (1) confidentiality: stored videos and live video streams cannot be viewed by unauthorized parties, (2) complete mediation: the user fully controls access to their data by others, and (3) deletion: deleted videos are not recoverable, even in cases of coercion. Each subsection motivates the privacy goals before providing technical details of the feature. We refer to Appendix A for the notation used in our cryptographic constructions and algorithms and to Appendix D for the storyboard of the CaCTUs's smartphone application. For clarity, we consider only a single camera, though our approach readily generalizes to multi-camera systems by applying the described protocols to each camera individually. Figure 2 shows an overview and state diagram of CaCTUs. The camera locally encrypts recorded video frames before uploading them to cloud storage. The smartphone application performs the reverse operations: it downloads the frames, decrypts them locally, and plays the video. Regular key rotation and secure key management allow the system to support secure streaming, delegation, deletion, recovery, and reset.

Initialization
During initialization, the user's smartphone and camera establish a trust association used for all other steps, so the security of this step is critical to that of the system as a whole. In CaCTUs, we adapt the Seeing-Is-Believing (SiB) technique introduced by McCune, Perrig, and Reiter [37] to establish an authenticated communication channel between devices that share no prior context (and without having to trust any third party). Specifically, we use the visual channel as an out-of-band means to verify the authenticity of each end of a Bluetooth channel.
This secure pairing bootstraps the system to allow the owner of the device to communicate directly with the camera (for system initialization) while ensuring confidentiality and integrity. Thus, negotiation of encryption keys to establish the root of trust can be done without any other party involved. Moreover, the required proximity and physical interaction Table 1. Protocol followed by the camera and the owner's smartphone during the initialization, and respectively correspond to what is obtained through the visual and Bluetooth channels.

Camera
Smartphone between the devices would render attack attempts easily detectable by the system owners. The initialization protocol between the camera and the owner's smartphone application is as follows (see Table 1): (1) A pair of factory-generated asymmetric keys ( , ) is present on the camera device, and the hash of its public key ℎ is embedded into a QR code on the back of the device (recall from Section 2.3 that the supply chain is trusted). The owner's smartphone scans this QR code and stores its content.
(2) The camera and the owner's smartphone connect through Bluetooth and the camera sends its public key to the owner, who computes the hash of the camera's public key ℎ ′ and checks that it matches the hash retrieved from the QR code.
(3) If they match, the owner's smartphone generates its own asymmetric pair of keys ( , ) and sends its public key through Bluetooth, the camera computes the hash ℎ ′ of the owner's public key.
(4) On the screen of the owner's smartphone is displayed the QR code with the hash of the owner's public key. The camera retrieves the content from the QR code and checks that it matches ℎ ′ .
(5) If the key hashes match, both devices now verify that the other device knows the secret key corresponding to the public key that they advertised earlier. This is can be done for instance by applying the Diffie-Hellman key exchange to compute their shared secret and then by exchanging a series of encrypted messages where both parties prove their knowledge.
(6) The camera then generates a new asymmetric key pair ( , ) that it will use for future communication (to avoid further reliance on the factory-generated key). The camera then shares its public key with the owner through Bluetooth in an authenticated way using RSA and the factory-generated asymmetric key pair ( , ).
Note that we could have used the shared secret computed at the previous step through Diffie-Hellman, however, we chose to use RSA to align this step of our initialization protocol with the future protocols presented in CaCTUs as well as because we want authentication of the messages.
(7) Next, the owner sends their secrets to the camera device to complete system setup, this is done in a secure and authenticated way using RSA, but this time the new asymmetric key pair of the camera is used ( , ). First, they send wifi credentials of the wifi network the camera should connect to. Then, they generate and send a seed key that will be used to derive the keys to encrypt video frames. Lastly, they send escrow material (protected by a non-recoverable passphrase) that may be used by the owner to recover access to the system (see Section 3.6 for details about the escrow material). If necessary, during this step the owner could also configure the cloud storage option they want to use if different than the default one.
At this point, the system is initialized, the camera begins recording, and the owner can execute other functions.

Recording and Streaming Videos
Here we describe how to ensure the confidentiality, integrity, authenticity, and freshness of the recorded video footage.
The video frames and metadata are encrypted locally at the camera and asymmetrically signed in blocks of frames, before being uploaded to cloud storage. At each key rotation, the camera device securely erases the encryption keys previously used as it does not need them anymore. To view a video, users of the system download the encrypted data from the cloud storage, derive the decryption keys locally (if they have access to them), and decrypt the frames to rebuild the video. Thus, only users with access to the appropriate decryption keys can view the footage. As the camera is recording, it performs the following: (1) Consider a block of frames. Each frame is recorded at timestamp .
(2) A key rotation scheme is used to derive encryption keys for a given frame (this will prove useful for delegation, discussed in Section 3.4). The rotation scheme K provides a key , the key used to encrypt frame . An initialization vector is randomly generated.
Authenticated encryption is used to symmetrically encrypt each frame (confidentiality) into the corresponding ciphertext using the AES algorithm in Galois/Counter Mode (GCM, chosen for its performance) with a 256-bit key. Additional authenticated data is passed along and a tag is generated (freshness and integrity). Each user who has access to the correct decryption keys can download these encrypted and authenticated frames { || , , | ∈ 1, }, . To view the video, the user performs the following: (1) We consider a block of frames of signature downloaded on demand. Each ciphertext along with its tag , encrypted using the initialization vector , corresponds to a frame recorded at timestamp .
(2) The signature of the block is verified with the public key of the camera and the tags of the frames in this block (authenticity).
(3) If the signature is correct, the corresponding symmetric key is extracted from key rotation scheme K. Then, symmetric authenticated decryption turns each ciphertext into the corresponding frame (confidentiality) while checking data integrity (integrity and freshness) Encryption is performed end-to-end: data is encrypted locally at the camera before being stored in the cloud and decrypted locally at the smartphone after being retrieved. Furthermore, integrity is ensured using an authenticated encryption scheme, so that the video footage cannot be tampered with during transmission or storage. Lastly, the identity of the camera is embedded into the video frames (and signed) so that users can attest the authenticity of the video footage. This scheme allows the user to verify the integrity, authenticity, and freshness of an arbitrary set of video frames, so that they then decrypt the frames and rebuild the video for playback.

Delegation
Users must have complete mediation over access to their videos. CaCTUs achieves this by ensuring that the owner has control of the keys used to encrypt the video footage. However, they may also want to delegate access to their videos (e.g., to friends or family) for different periods of time. Achieving fine-grained sharing capabilities for delegatees is nontrivial: we want to support delegation without knowing beforehand to whom the owners will delegate access or for how long. To enable this, we rotate the keys used to encrypt the video frames at the end of every epoch (a fixed-size time interval). We use a binary key tree construction to facilitate the management of all the keys for the camera device, owners, and delegatees. A peer-to-peer pairing is adopted for sharing keys so that there is no reliance on a third party.
Recall that frames are encrypted using a symmetric key derived from a key rotation scheme K. In practice, to support delegation, this rotation scheme is a binary key tree, inspired by the key tree introduced by Kocher [31]. The tree is of a fixed depth K . In the tree, each leaf node holds some cryptographic key and covers a specific epoch: a time interval [ , +1 ) of fixed-size K . The root node of the tree is initialized with a seed key that is negotiated during the initialization of CaCTUs (see Section 3.2). The timestamp of this negotiation is used for 0 , with +1 = + K .
The leaf nodes in the tree hold the encryption keys for every epoch. Each node in the tree can be derived from the root node knowing the derivation equations and relations between the parent node and its two children. Within each epoch, the symmetric key used for each frame is identical. The derivation of keys is based on a Hash-Based Key Derivation function (HKDF), which is a one-way process [28]. If we have , then = ( ) and ℎ = ( ⊕ 1). Therefore, for a given key in the tree, a user can only derive the keys below it but not the ones above (see Figure 3a for an illustration).
The binary key tree is useful for several reasons. First, it decreases the amount of keys that need to be shared with the delegatees, as the derivation algorithm is publicly known by the Kerckhoffs's principle and a specific part of the key tree can be reconstructed on-demand by a delegatee that is given access to a node of the tree. Moreover, it is storage space-efficient, as the key rotation mechanism generates a large number of encryption keys. When key rotation happens and the camera device securely erases the previous encryption keys, the camera device only needs to save at most K Seed key (a) Key Tree Construction used by CaCTUs, the keys to be shared to give access to the corresponding footage are framed.
(b) Establishment of a secure and authenticated Bluetooth pairing with a delegatee.

Fig. 3. Delegation in CaCTUs
nodes to keep functioning. Further, it is simple to find which node is responsible for the encryption or decryption of a specific timestamped frame (through a binary search). Lastly, it facilitates the recovery process for the owners as only a subset of keys needs to be recovered to rebuild the tree from the escrow material.
Delegation is supported by giving some keys of the key tree to each delegatee (an example is given in Figure 3a where keys to share and their corresponding epochs are framed). From there, each delegatee can derive the associated keys to correctly decrypt and view only video footage captured within the time window they were authorized for. The depth K and the epoch size K are configurable parameters of the system. The size of an epoch K corresponds to the lowest delegation granularity achievable in CaCTUs.
Delegation uses a peer-to-peer approach similar to the physical pairing of the initialization with the camera. Table 2 shows the details of the operations performed during the delegation protocol between the owner and a delegatee: (1) The pair of asymmetric keys ( , ) is present on the smartphone of the owner. When the delegation process starts, the smartphone application of the owner displays a QR code in which the hash of the owner's public key ℎ is embedded. The delegatee's smartphone scans this QR code and stores its content.
(2) The delegatee and the owner's smartphone connect through Bluetooth and the owner sends its public key to the delegatee, who computes the hash of the owner's public key ℎ ′ and checks that it matches the hash retrieved from the QR code.
(3) If they match, the delegatee's smartphone generates its own asymmetric pair of keys ( , ) and sends its public key through Bluetooth, the owner computes the hash ℎ ′ of the delegatee's public key.
(4) On the screen of the delegatee's smartphone is displayed the QR code with the hash of the delegatee's public key.
The owner retrieves the content from the QR code and checks that it matches ℎ ′ .
(5) If the key hashes match, both devices now verify that the other device knows the secret key corresponding to the public key that they advertised earlier. This is can be done for instance by applying the Diffie-Hellman key exchange to compute their shared secret and then by exchanging a series of encrypted messages where both parties prove their knowledge.
(6) Then, the owner extracts the keys { } to share and send them in an encrypted and authenticated way using RSA to the delegatee to give them access to the corresponding videos. Note that this last step does not necessary need to be done through Bluetooth and could be done over the Internet too without undermining the security of the delegation protocol. Table 2. Protocol followed by the smartphone application of the owner and the delegatee during delegation, and respectively correspond to what is obtained through the visual and Bluetooth channels.

Deleting Videos and Factory Reset
CaCTUs users must be able to delete their videos and factory reset their system. As video frames are uploaded to the cloud, deleting them would require trusting the cloud storage provider to do so. However, as video frames can not be decrypted without the decryption keys, deleting these keys is equivalent to deleting the corresponding video. Owners can achieve this by deleting select decryption keys (i.e., a subset of nodes in the key tree) and by updating the escrow material, so that the keys below them in the tree cannot be recomputed, even in cases of coercion. Thus, with a tree depth of K , for each portion of video content composed of epochs to delete, the upper bound of the number of nodes that must be deleted from the tree is O ( K ). To provide an example: in Figure 3a, to delete (key for epoch A), keys { , , } must also be deleted. Thus, { , , } must be saved in this sparser key tree so that the corresponding videos can still be decrypted. Recall also that the camera device securely deletes the encryption keys as soon as it does not need them anymore due to key rotation. Note that with this mechanism, delegatees may still know some decryption keys that were deleted from the owner's device. As discussed in our threat model (see Section 2.3), once granted access to a video, a party is not prevented anyway from having already shared or downloaded the video.
To factory reset, the camera and the owner must forget about all the encryption keys (symmetric and asymmetric), as well as the secrets exchanged during initialization, and the escrow material. Thus, for both cases (see Table 3a): (1) The owner sends the timestamped and authenticated request encoding the operation as well as any updated key material encrypted and authenticated with RSA (recall that the owner and the camera have shared their asymmetric public keys during initialization). This can be done through Bluetooth or remotely over the Internet.
(2) At reception, the camera verifies the authenticity of the deletion or reset operation; if valid it sends an ack and performs it. When receiving the ack, the owner's smartphone applications completes the delete or reset operation locally. Table 3. Deletion, factory reset, and access recovery protocols.
(a) Protocol followed by the owner and the camera during deletion or factory reset operations. and respectively corresponds to the Bluetooth or any other channel such as the Internet.
Owner or Camera Protocol followed by the camera and the smartphone application of the user trying to recover access. correspond to what is obtained through the Bluetooth channel.
New smartphone Camera

Access Recovery
In case owners lose access to their smartphone, they must be able to recover access to the system. However, in a privacy-preserving system where no third party is trusted, achieving this is nontrivial. To solve this, we generate an escrow material during the initialization step that contains all of the information needed by the owners to recover access to their system. The escrow material is encrypted by an unrecoverable passphrase only known by the owner and stored on the camera. The escrow material gives access to the following secrets : • The owner's asymmetric key pair ( , ) encrypted with a randomly generated key of size 128 bits and corresponding to the passphrase displayed to the owner during initialization. • The key material necessary to build the key tree K (for details about this key tree see Section 3.4) asymmetrically encrypted with the owner's key.
• The asymmetric public key of the camera (does not need to be encrypted). Table 3b details the steps executed during access recovery to the system: (1) The owner uses their new smartphone to request through Bluetooth to the camera the escrow material.
(2) The camera sends back the escrow material. Note that no assumption regarding the status of the owner has been made so far; anyone who is in physical range from the camera can request the escrow material. However, only the owners have knowledge of the recovery passphrase and can use it to decrypt the escrow material.
(3) If the passphrase is known, they are able to recover access to the asymmetric key pair ( , ) of the owner, the public key of the camera, and the key material necessary to build the key tree K.

EVALUATION
The goal of this section is to evaluate the effectiveness and efficiency of CaCTUs with respect to four metrics: security, privacy, usability, and performance. To this end, we evaluate three research questions: • RQ1: Does CaCTUs enforce our privacy requirements, while offering the same feature set of commercial systems?
• RQ2: Is CaCTUs easy to use for end users?
• RQ3: Can CaCTUs operate at sufficient resolution, frame rate, and latency to meet the needs of users?
Experimental Setup. Experiments were performed using a Raspberry Pi 4 Model B with 2GB of RAM, equipped with a camera module. Our implementation of the CaCTUs camera system is written in C, while the paired mobile companion application was written in Java and installed on a Nokia 4.2 smartphone, running Android 10. Further evaluation setup details are described in Appendix B.

Privacy and Security Analysis (RQ1)
We begin by analyzing how CaCTUs achieves the security and privacy properties discussed in Section 2.2.
Confidentiality. CaCTUs aims to protect user data from being read by unauthorized third parties. As such, end-to-end encryption is used to enforce that only the owners have access to their videos; data is encrypted locally at the camera before being stored in the cloud and decrypted locally at the smartphone after being retrieved. The encryption keys are exclusively located on the camera device and the owner's smartphone. Owners manage access to the decryption keys and decide with whom to share them. As a result, parties who have not been delegated access through key sharing are unable to view the encrypted frames, protecting confidentiality of the footage, which ensures the right to not be seen.
It is also worth noting that the key-tree construction of CaCTUs allows to delegate access at a fine granularity; users exactly control which portion of their video footage they are sharing with others.
Complete Mediation. CaCTUs uses end-to-end encryption which means that the owners of the systems are the only ones to have access to the decryption keys. Thus, delegation can only be performed by the owner (who holds the material necessary to build the key tree); and no other party is able to grant access to the footage, this provides complete access mediation to the videos. The key tree ensures this mediation cryptographically; a user without the seed or delegated keys is unable to decrypt footage regardless of access control on the encrypted data, assuming the cryptographic primitives are secure. This enforces the right to sole ownership of the videos recorded by the system. Additionally, during initialization a root of trust is established between the camera device and the owner's smartphone, specifically they have exchanged their public keys. The camera device will perform some administrative actions such as updating the escrow material or factory resetting if and only if the request is authenticated and signed by the owner's asymmetric key. This is another aspect of CaCTUs that enforces that owners have sole control over their systems.

Data
Deletion. An emerging property of the previous two ones is that owners have sole ownership and control over the encryption keys. As the recorded footage can not be decrypted without having these keys, deleting the keys is equivalent to deleting the corresponding video files that are by themselves just meaningless blobs of data (as they are encrypted). As a result, if owners decide they want to delete some or all of their videos, they can simply delete the corresponding encryption keys on their smartphone as well as in the escrow material on the camera device, which makes it impossible for them to view the corresponding encrypted footage stored in the cloud, even in case of coercion.
Note that no third party needs to be trusted to perform this operation and that this ensures owners' right to be forgotten.

Functional User Evaluation (RQ2)
In order to assess the functional ease of use of CaCTUs and identify what aspects of the system could be improved, we performed a functional user evaluation of our implementation with ten participants. Studies have shown that this group size is sufficient to identify most of the issues within a system design [40,41]. To this end, participants were asked to initialize the system and use the different functionalities as if they had just bought it: view live and recorded streams, share videos with a delegatee, recover access after simulating the loss of their smartphone, and reset the system. The detailed protocol that was followed is described in Appendix C. We obtained approval from the Institutional Review Board (IRB) of our university and all other institutional requirements were met for this evaluation. Out of the ten participants, four were female and six male, seven of them were between 20-25 years old and the three between 45-55 years old.
Goals and Limitations. Our modest goals through this functional user evaluation of CaCTUs were to assess whether guided users can perform the functions of the system that we laid out and identify where our proof-of-concept of the implementation fell short (with respect to performance or feature design) and how it could be improved. As a consequence, our participants knew they were evaluating CaCTUs. Thus, our functional evaluation differs from traditional usability studies that may compare different system designs to identify which is the most usable, has the best interface, or what UX options are optimal for ensuring that users understand a specific privacy concept of the system. We defer a more comprehensive usability study to future work.
User Interface. Overall, the participants thought that the interface of the implemented smart camera system was simple to understand and navigate through. They liked that for every process there were step-by-step instructions displayed to them. They noted that these directions were clear, straightforward, and self-explanatory.
Secure and Authenticated Pairing. Despite that pairing requires both setting up a Bluetooth connection and scanning QR codes, the participants found the process simple and easy. They expressed that it was more straightforward than steps they had to perform with other systems. They also felt that using both Bluetooth and a visual channel was more secure even if they did not explicitly always know why.
Quality of the Footage. As shown in Figure 4, the participants agreed that the image quality of the video stream (480 p) and the frame rate (10 fps) were sufficient for security and surveillance purposes. However, some believed that the latency of the system was a bit of a downside as it tended to defeat the initial purpose of being able to monitor what was recorded by the smart camera system in real-time. We took this comment into account and further improved our implementation to achieve the results presented in Section 4.3, we also discuss in Section 5 other potential optimizations to CaCTUs.
Granularity Options. The participants were impressed by the granularity to which they could view specific segments of video footage (up to the second), but believed that the same granularity option for delegation was not necessary; they stated that the primary use case would be to share access for several hours or days. This concern can easily be addressed by modifying the granularity options displayed in the application. The majority of the participants also expressed desire to have an option to quickly delegate unlimited access, but then figured out that they would not be able to revoke such access without having to reset the system.

Access Recovery and Factory Reset.
Regarding the recovery process, the participants were divided on whether the recovery passphrase should be randomly generated by the system or if it should give the owner the opportunity to choose it. They felt that they could lose the recovery passphrase or forget about it if they did not choose it. However, they agreed that as this passphrase allows to recover full access to the system, it might be less secure to let the owners pick their own. One participant remarked that the ability to recover access without needing to trust a third party (i.e., without using a recovery email address for instance) was interesting. As shown on Figure 4, most participants found it important to be able to recover access to and factory reset their system, as oftentimes owners may want to recover access (to retrieve videos) before factory resetting it. The participants found the recovery and factory reset processes easy to perform.
Missing Features. Participants expressed that they would like to see the following features implemented in a commercial system: motion detection-triggered recording, remote pairing and delegation, two-way audio support to listen in on and remotely speak through devices, password-locked smartphone application for additional security, and application availability across different platforms (e.g., Android, iOS, and web interface). See Section 5 for details about such extensions to CaCTUs.

Performance Evaluation (RQ3)
We now evaluate the streaming performance of CaCTUs, focusing our efforts on three key metrics: latency (delay from time of recording), stream image resolution, and frame rate. As a baseline, commercial systems achieve frame rates of 30 fps in 1080 p (1920 x 1080 pixels), with a latency on the order of milliseconds. However, we note that these systems have been largely optimized for commercial use and lack privacy-preserving features as CaCTUs. We discuss additional potential optimizations to CaCTUs than the ones presented in this section in Section 5.
System Latency. Recall that users pointed out in our functional evaluation that the latency of the system was too high. Taking that into account, we have since introduced a new optimization in our implementation to improve the streaming experience and reduce the latency without sacrificing security; uniform frame dropping based on the delay that the live stream is at. Thus, for the parameters considered in the functional user evaluation, we obtained a latency of 2 s at a frame rate of 10 fps for a video resolution of 480 p. Figure 5a displays the evolution of the latency of our implementation without and with frame dropping while live streaming at different frame rates and video qualities. Frame dropping clearly improves the latency of CaCTUs as the implementation is now able to keep the delay, between the recording and rendering times, to a lower value than previously by uniformly dropping frames. Specifically, at high frame rates our unoptimized implementation was not (a) Latency (± standard deviation represented by the shaded areas) for different frame rates of live streaming at a quality of 480 p and 720 p using frame dropping or no, averaged over 1,000 frames.
(b) Proportion of frames dropped by our implementation while live streaming at different frame rates for a video quality of 480 p and 720 p. able to keep up with the live stream as too many frames needed to be processed. As we use uniform frame droping based on the current delay where the stream is at, the transition between the frames of the output video on the smartphone application still looks smooth and does not appear as if it was lagging or buffering. Figure 5b shows the proportion of frames being dropped for different frame rates and video qualities by our system; the higher the frame rate, the more frames are dropped in proportion. These two figures show that our implementation of CaCTUs behaves the best for a lower video quality and a lower frame rate, confirming our choice of using a frame rate of 10 fps and a video resolution of 480 p for the rest of our evaluation. As expressed by the users of our study, these parameters are sufficient for streams recorded by a security camera (see Section 5 for other optimizations).
System Bottlenecks. Next, we measure the effect that each phase of streaming has on the stream latency. The values have been averaged over 1,000 frames. For this evaluation, we picked the same parameters as for a worst-case scenario (i.e., K = 32 and K = 10 s), to show the performance baseline that can be expected from CaCTUs. Table 4b shows the results when the camera device is recording for a video quality of 480 p. As shown, the largest contributor to the latency is the upload/download of the encrypted frames to/from the cloud storage server during live stream, this would have the same contribution to latency in a system not using encryption techniques. We leave to future work improving that aspect and discuss means to do so in Section 5. Note that within the same epoch the same key is used, but between epochs, we need to derive the new key, that is why the standard deviation is larger than the average for the key extraction.
Lifespan and storage space. The depth K and the epoch size K are configurable parameters of the system. For our implementation, we selected K = 32 and K = 10 s. Importantly, this choice of parameters demonstrates the worst-case performance users can expect from CaCTUs. Specifically, these parameters result in a key tree that covers a lifespan of 1362 years at a 10 s level of granularity. We provide more reasonable parameter choices (and, thus, expected performance at deployment) in Table 4a, where we also present the storage space required in the worst-case scenario where every other epoch videos have been deleted by the user. In practice, such a scenario is very unlikely to happen as it will render the system unusable as well as because owners are unlikely to delete beforehand keys that would have been used to encrypt future videos. Thus, far less amount of storage space is required; moreover, our binary key tree structure enables dynamic derivation of lower keys.

DISCUSSION
In the following, we discuss potential optimizations for improving the performance of CaCTUs and practical considerations for deploying it as a commercial system.

Improving Latency
We identify several components that could be improved to reduce the overall latency of the system, namely; (1) cryptographic accelerators, (2) network relays, (3) streaming libraries, and (4) video compression techniques. Such improvements are described below.
As discussed in Section 4, our implementation used a Raspberry Pi, wherein the (relatively weak) CPU was responsible for handling all processing, including encryption. Since cryptographic operations dominate many of the features in CaCTUs, we expect substantial gains in latency by leveraging dedicated cryptographic accelerators as seen in many other crypto-dominated applications, such as in IoT [30].
Streaming live video can be demanding on the network. Specifically, popular video streaming platforms (such as Netflix, Hulu, and Disney Plus) employ a variety of techniques to bring video data as close to the user as possible. These techniques often take the form of caches, content delivery networks, or dedicated network infrastructure designed to serve high-bandwidth content quickly [1,20,54]. Naturally, these techniques could substantially improve the performance of CaCTUs to be even closer to commercial-grade systems.
The smart camera systems available today use optimized streaming protocols to deliver video content quickly [1].
Given that it was necessary for us to implement our video streaming protocol from scratch (to support our encryption and key rotation schemes), we could see further improvements by augmenting current protocols to support our design.
In a similar vein, our current implementation operates at the frame-level, while commercial systems operate at the block-level (and thus exploit compression algorithms commonly used in video streaming applications [3]). Moreover, popular techniques such as adaptive video playback or more advanced frame dropping could also be used to improve the throughput of CaCTUs. We defer such improvements to future work.

Deploying CaCTUS as a Commercial System
Here, we highlight some challenges (motivated by notable features in commercial systems and suggestions from our functional user evaluation of CaCTUs) that should be addressed to realize commercial implementations of CaCTUs without compromising any of our privacy goals.
Relaxing Proximity. To uphold our privacy goals, delegatees need to be within local proximity of the owners (e.g., to perform delegation and pairing through the QR codes). While this was not an area of concern in the functional user evaluation of CaCTUs since participants were always close to the camera system, this can be challenging if users wish to delegate access remotely. We did conceptually derive a scheme to support this capability, while upholding our privacy goals. Specifically, CaCTUs could be extended to asymmetrically 1 encrypt the keys needed by delegatees and upload them to the cloud storage or use another third party service like email, from where the remote delegatee could retrieve, decrypt, and then use these keys to access the video stream for some predetermined period of time.
Revoking Access to Unrecorded Videos. Note that a similar scheme to the one described in the previous paragraph could also be used to allow owners to revoke access to delegatees to unrecorded videos without needing to factory reset the system. The sharing of the keys only needs to be done periodically at a certain interval that could be configured by the owner for each delegatee.
Supporting Audio. In our current implementation, we focused on supporting video data only, and not audio. However, the system design does not prohibit extensions to support audio-video recording and streaming. The extension is straightforward: we can treat some audio sample as a "frame", as it is done for video, and apply similar encryption operations. For sampling, a Linear Predictive Coding (LPC), which is widely deployed by telephone companies for speech encoding and processing, could be used [55]. Moreover, LPC can even be leveraged to transmit audio in reverse; that is, be applied so the users could speak into their smartphones and have the audio replayed through the camera, as commonly seen in commercial systems.
Supporting Motion Detection. Many commercial systems support forms of motion detection to notify users of events they may be interested in viewing. We find this feature valuable for both users as well as the camera system in that video recording need only be saved if motion was detected 2 . CaCTUs could support this capability through addition of a physical hardware sensor or a software solution. This addition would save significant space in cloud storage systems and reduce the cost related to storage. In a similar vein older data could be overwritten at a fixed interval that could be configured by the owner.
Physical Security. Finally, as explained in our threat model, we did not take into consideration physical tampering attacks against the camera device. Techniques such as package design so that the device is tamper-proof should be explored. Specifically, local storage, battery, reset buttons, serial ports, firmware, etc., should be protected to prevent physical access by untrusted parties.

EXTENDING TO OTHER DEVICES
The protocols used in CaCTUs could be easily extended to other IoT devices recording time series data or monitoring some events such as; temperature, humidity level, power usage, sensors, etc. Instead of video stream, which is bandwidthintensive, any other blob of data recorded by the considered IoT device can be encrypted by following the same exact protocol and by using the same key tree construction; room condition temperature and humidity, current power consumption of some devices around a house, or status of different sensors in a factory, etc. If it appears to not be convenient to use blocks of elements for the encryption, one can fix = 1. Moreover, as video stream is most likely the most bandwidth-intensive of these applications, performance for such devices is expected to be even better.
Privacy Concerns. As for CaCTUs, owners should also be concerned that these devices usually located inside their homes can record and transmit valuable data about them or their behaviors. Thus, users of such systems should have similar rights than the ones enforced in CaCTUs; owners must have exclusive control over the collection of data, how that data is used, and by whom it is accessed. As a result, the threat and trust models considered in this work readily apply to these devices too; the device manufacturer and the service or cloud providers do not have to be trusted more than for what they are needed; manufacture the product, maintain the software, and provide the infrastructure, which can be performed as demonstrated by CaCTUs without having access to the recorded data.
Functionality. Additionally, if we consider the life cycle of these IoT devices, similarities with the functionality of CaCTUs start to emerge; they also need to be initialized, record data, support access recovery, etc. As other IoT devices require an initialization phase during their setup, a physical pairing similar to the one we presented for CaCTUs can be followed to establish a root of trust between the owner and their IoT device without having to trust any third party.
The protocols presented in this work were designed to build a privacy-preserving smart camera system, however, in practice our techniques do not require the recorded data to be video frames or the device to be a smart camera, making this extension to other IoT devices possible. Sometimes, IoT devices are connected to a hub or a base station in users' homes; in that case, the hub could be considered as a shared user to whom access was delegated.
Potential Adaptations. The physical pairing presented in CaCTUs was leveraging the fact that both devices had a camera sensors, however, this may not be the case for other IoT devices. In that case, the step can either be skipped and we defer to the Seeing-Is-Believing (SiB) technique introduced by McCune, Perrig, and Reiter [37] for a full discussion of the guarantees provided in such a case, or replaced with another mechanism as long as it still requires the owner to perform an action demonstrating to the device that they are in its physical proximity. For that, we should normally easily be able to come up with some physical task for the owner to perform that involves the capability of the sensor embedded in the device. For instance during pairing, a thermostat could ask to be placed closer to a warmer or colder source (e.g., chimney, freezer, etc.), a smart outlet could require the owner to plug a device and use it for a moment, a proximity or physically-activated sensor could ask the owner to trigger it in a simple pattern, etc. Similarly, any wireless protocol other than Bluetooth can be used for the pairing.

Research Systems
While this work is the first to examine a smart camera system that is privacy-preserving, there is already a large body of research studying the security of smart camera systems. Here, we detail the gaps in prior work and how CaCTUs addresses them. Refer to Table 5 for a comparison of the privacy guarantees of these systems.  [57] ✗ (ROI only) ✗ (trusts a central station) ✗ TrustEYE.M4 [58] ✓ ✗ ✗ SoC-based [25] ✓ ✗ (relies on a Trusted Authority) ✗ Signcryption [56] ✓ ✗ (uses a Key Distribution Center) ✗ Pinto [62] ✗ (ROI only) ✗ ✗ ✓ Eufy [18] ✓ ✗ ✓ Nest [22] ✗ ✗ ✓ Ring [51] ✓(opt-in) ✗ ✓ Wyze [61] ✗ ✗ ✓ Alharbi and Aspinall introduced a security analysis framework for IoT smart cameras that weighs the threat of significant risks (e.g., unencrypted video streaming) across various platforms [2]. However, it focuses on the security of the camera device and only partially addresses some vulnerabilities of other components of the system. For instance, the authors do not discuss the use of cloud storage to remotely access recordings, nor procedures for securely pairing a smartphone and camera. CaCTUs provides an end-to-end secure solution starting from camera initialization to protect the secrecy and integrity of both communications and data.
Haider and Rinner proposed a SoC-based smart camera that uses physically unclonable functions (PUFs) to generate encryption keys [25]. The keys are used to encrypt video frames at the camera before storing them in remote cloud storage, thus removing the requirement that the owner trust the cloud service provider. However, this approach has several limitations. First, a trusted authority is required to create camera device fingerprints during key generation; in a commercial system, the trusted authority will likely be the manufacturer, whom in general is not trusted by the camera owner. Moreover, the key extraction procedure using PUFs only produces a fixed number of encryption keys, which does not align with the feature-set typically desired by smart-camera owners-e.g., being able to delegate camera access to other people with fine granularity. Finally, as the fingerprint is physically embedded into the hardware, camera owners will likely need to get a brand new device if the encryption keys are leaked. CaCTUs addresses these shortcomings by making the owner (i.e., their smartphone) the root of trust: they store the secrets and share expendable keys with both the camera and delegatees. This simultaneously gives control back to the owner while enabling delegation and system reset without specialized (or new) hardware.
Winkler and Rinner introduced TrustEYE.MP4 [58], a monitoring framework that provides similar secrecy and integrity guarantees envisioned by CaCTUs. However, as the same key is used to encrypt all the videos, they do not address the unique challenges in delegating access (e.g., how to share and revoke access to video data at particular timescales) or deleting videos. Similarly, Ullah, Rinner, and Marcenaro proposed using signencryption [56] to encrypt and sign video frames at once, but they also did not consider the challenges related to video deletion and delegation.
CaCTUs addresses these issues by storing the system secrets at the owner's smartphone and using a secure key rotation scheme to enable fine-grained delegation.
Finally, PrivacyCam [13], TrustCAM [57], and Pinto [62] do not fully address the privacy challenges in a smart camera system as they attempt to solve a problem of a different nature and setting. These systems try to protect the anonymity of people or of vehicle license plates recorded in public spaces by detecting privacy sensitive regions and selectively encrypting or blurring them while leaving the rest of the video frame unperturbed. However, even this approach is limited in protecting anonymity: people can still be identified through their clothes or actions, and blurred videos still disclose behavior patterns such as when users are at home. Moreover, the system does not address data privacy of the video recordings.

Commercial Systems
As of May 2022, among the most popular smart camera systems commercially available, we find mainly doorbells, indoor and outdoor security cameras, as well as some baby monitors from the following companies; Arlo [5], Blink (Amazon company) [7], Eufy [18], Nest (Google company) [22], Ring (Amazon company) [51], or Wyze [61]. All these systems offer a cloud-based solution for video storage and streaming, with the exception of Eufy that primarily uses a base station installed in users' homes to store videos (Eufy also has a cloud storage available in option).
We analyzed these commercial systems with the public information sourced from product data sheets and technical reports or other documents published by the company. Our analysis revealed that some of these systems while they provide security, fail to provide end-to-end encryption. End-to-end encryption is an encryption mechanism through which two parties (can be extended to more than two) are able to communicate between each other with the guarantee that they are the only ones able to see the content of their exchange, i.e., no third party is able to access the data that is being communicated. End-to-end encryption is generally achieved by encrypting the data with encryption keys only known by the parties that should be able to access and see that data, essentially transforming the issue into managing properly the encryption keys. In the context of smart camera systems, we are mainly concerned by the fact that videos recorded by the system are end-to-end encrypted between the camera device and the users, i.e., the service and cloud providers as well as any other third party are unable to access and see these videos in clear.
Out of the six companies considered in this section (see Table 5), only Eufy and Ring offer some commercial systems that let users have access to end-to-end encryption. The other commercial systems require users to trust the service or cloud providers to handle at some point their data in clear; videos are usually encrypted in transit (TLS) between the camera and the cloud. Then, in the cloud, videos are encrypted at rest with some encryption mechanism put in place by the service provider. This encryption sometimes leverages an underlying mechanism offered by the cloud provider (e.g., S3 bucket encryption on AWS). The bottom point of this approach (encryption in transit and then at rest) is that users are not in control of the encryption keys; they need to trust the service or cloud providers with their videos. This is why in these systems access mediation is enforced by the service provider; users need to authenticate themselves, proving who they are in order to decrypt their videos. This is also the technical explanation on how these companies are able to serve a valid search warrant and provide videos to authorities; they are the ones mediating the access control mechanism-users are not solely in control here, which does not align with the threat model considered in our work. Moreover, similar trust in the platform is needed when users want to delete their recorded footage.
Eufy sells a smart camera system that stores and encrypts the videos on a base station directly located in users' homes. While it seems that this system takes into account different privacy aspects, limitations might appear. For instance, it is unclear how the keys used to encrypt and decrypt the videos are generated, where and how they are stored, who can access them, how they are linked to an account and obtained by a user, or if they are rotated or not, specifically in light of the incident that occurred in 2021; when Eufy deployed an update on their servers that caused users to see other users' feeds in their apps [45]. Moreover, it is unclear if they are using end-to-end encryption-as defined earlier-, how they can disclose video recordings when being served with a valid search warrant [19].
Ring offers end-to-end encryption on an opt-in basis on some of their devices, the enrollment protocol to establish the root of trust between the owner's smartphone and the camera device has some similarities with the one presented in CaCTUs. However, by enabling end-to-end encryption, Ring users lose access to some features of their system (shared users unable to see videos, impossibility to access live stream from different devices at the same time, etc.), specifically, the end-to-end protocols of Ring were not designed to enable fine grained delegation as opposed to CaCTUs [50].
To summarize, the main differences with CaCTUs are that these commercial systems have a different trust model that the one we considered and entrust at some point in their life cycle the service or cloud providers with users data and access control to it. With CaCTUs, we proposed techniques that do not require users to operate in such threat models or trust the service or cloud providers, and still be offered the same feature set as of commercial systems.

CONCLUSION
This paper presented privacy-preserving protocols to design CaCTUs; a smart camera system that provides users with full control over their system, isolation and protection of the access to their video footage, deletion and factory reset, as well as peer-to-peer and fine-grained delegation of their videos. However, these protocols are not only restricted to video streaming but are readily extensible to IoT devices recording other time series data. Specifically, we showed how to leverage physical and direct pairing between devices to initialize systems without having to trust third parties, use performance-aware cryptographic algorithms for real time data streaming, and efficiently manage encryption keys through a binary key tree to support key rotation and enable data deletion and fine-grained (i.e., on the order of seconds) peer-to-peer delegation. CaCTUs serves as an existence proof that smart camera systems and other IoT devices need not compromise the privacy of users to be afforded the modern capabilities that commercial systems offer today. Cloud Storage. An AWS EC2 t3.small instance was used to deploy a Nginx web server. Upon request, we serve the list of encrypted frames that were recorded during the time frame specified in the request.

C FUNCTIONAL USER EVALUATION PROTOCOL
All institutional requirements were met for this functional user evaluation of CaCTUs. We obtained approval from the Institutional Review Board (IRB) of our university and a consent form was signed by the participants at the beginning of their session. We also tested the protocol with coworkers and collaborators beforehand to identify possible limitations.
All the material was provided to the participants that were guided by a researcher through the different tasks to perform. We introduced each task with a real-life scenario to help the participants behave as if they were using the system in their real life. To collect feedback, we observed a talk aloud process asking the participants to express aloud what they are doing or looking for while performing the task, allowing us to better identify potential issues in the system. Between each task, we also asked specific questions about the process that had just been completed.

C.1 Before Each Session
Before each session, we verified that all the material needed for the session was provided, working, and its initial state: (1) Camera Device: 1 Raspberry Pi 4 Model B 2GB, with camera sensor and our software installed.
(2) Android Smartphone Devices: 3 Nokia 4.2 with application pre-installed, wifi configured, location enabled (for Bluetooth discovery of nearby devices), and Bluetooth disabled with no prior device paired.
(3) Other: Piece of paper and pen provided (to write down the recovery passphrase).

C.2 During Each Session
We first started by asking some preliminary questions about their background and their experience with smart camera systems. Next, we explained that the objective of the session was to evaluate the functional usability of the smart camera system that we designed. Details about privacy violations in current available systems were briefly described to help the participants understand the motivation of the project. Then, we presented at very high level how the system we implemented was giving back full control to the users by using end-to-end encryption and strict access mediation to the decryption keys. We also verified that the participants were either familiar with Android or we showed them how to navigate between applications on Android.
C.2.1 Initialization. You want to secure your home, so you just bought this new smart camera system online. You received the package with the camera and just downloaded the application on your smartphone. Go ahead with the rest of the configuration.
(1) What did you like about the initialization?
(2) What did you dislike about the initialization? (1) How do you feel about the quality of the video streaming?
(2) What is your opinion about the following statements (Likert scale: strongly disagree, disagree, neutral, agree, strongly agree)?
(a) I am happy with the image quality of the streaming.
(b) I am happy with the latency of the streaming.
(c) I am happy with the frame rate of the streaming.
(3) What did you like about the usage of the system/application? (4) What did you dislike about the usage of the system/application? (1) What did you like about the delegation process?
(2) What did you dislike about the delegation process?
(3) What is your opinion about the following statement: It is easy to add a new delegatee (Likert scale: strongly disagree, disagree, neutral, agree, strongly agree)?
(4) Would you like to see any change in the delegation process or the options for the access control?
(5) Who would you typically add as a delegatee and for how long?
(6) What do you think of the granularity of the delegation control?
C.2.4 Access Recovery. Unfortunately, on your way back home during the layover, you lost your smartphone, which was the device you used to access your camera system, and when you come back home, you figured out that someone has broken in during your holidays and robbed you. You buy a new smartphone, install back the application on it, and want to recover access to your system to see what happened. Luckily, you wrote down your recovery passphrase.
(1) What did you like about the recovery process?
(2) What did you dislike about the recovery process?
(3) What is your opinion about the following statement: It is important for me to have a recovery process. (Likert scale: strongly disagree, disagree, neutral, agree, strongly agree)?
C.2.5 Factory Reset. Finally, you want to reconfigure your system as you lost your smartphone, but before you want to make sure to factory reset the system.
(1) What did you like about the factory reset process?
(2) What did you dislike about the factory reset process?
(3) What is your opinion about the following statement: It is important for me to have a factory reset process. (Likert scale: strongly disagree, disagree, neutral, agree, strongly agree)?

C.3 After Each Session
After each session, we made sure that every device was reset and back into its initial state, as if the session had not occurred.

D STORYBOARD
Following is the storyboard of the CaCTUs's smartphone application.