Investigating the Privacy and Security of the SimpliSafe Security System on Android and iOS

: The emergence of the Internet of Things technologies and the increase and convenience of smart home devices have contributed to the growth of self-installed home security systems. While home security devices have become more accessible and can help users monitor and secure their homes, they can also become targets of cyberattacks and/or witnesses of criminal activities, hence sources of forensic evidence. To date, there is little existing literature on forensic analysis and the security and privacy of home security systems. In this paper, we seek to better understand and assess the forensic artifacts that can be extracted, the security and privacy concerns around the use of home security devices, and the challenges forensic investigators might encounter, by performing a comprehensive investigation of the SimpliSafe security system. We investigated the interaction of the security system with the SimpliSafe companion app on both Android and iOS devices. We analyzed the network trafﬁc as the user interacts with the system to identify any security or privacy concerns. Our method can help investigators working on other home security systems, and our ﬁndings can further help developers to improve the conﬁdentiality and privacy of user data in home security devices and their applications.


Introduction
Home security systems have been growing and are expected to grow to USD 84.4 billion by 2027 [1]. While home security and smart home devices provide convenience and ease of mind for users, their associated data are also increasingly used as forensic evidence in criminal cases [2,3]. Although home security devices help secure and monitor homes, they can become great sources of forensic evidence. With the rise of self-installed home security devices, the important question to ask is how well these devices protect user data. Home security systems are categorized into (1) traditional, professionally installed and monitored systems, (2) self-installed and professionally monitored, and (3) self-installed and self-monitored smart IoT devices. The do-it-yourself self-installed systems are predicted to have the fastest growth and surpass USD 32 million by 2030 [4]. The growth is due to an increase in awareness of home security systems, the emergence of Internet of things (IoT) technologies, and easy-to-use do-it-yourself (DIY) home security systems. Among the self-installed home security systems, SimpliSafe [5] is usually ranked in the top three favorite systems [6].
In this paper, we investigate the SimpliSafe home monitoring system due to its high popularity, focusing on the interaction between the companion app and devices, as well as a network analysis while the base device connects to servers. SimpliSafe is a self-installed smart home security system that includes monitoring sensors and cameras.
The main contributions of our study are as follows: • We conducted a mobile forensic analysis of the SimpliSafe home security app on both Android and iOS smartphones. • We performed a forensic analysis of the network traffic generated when a user interacts with the SimpliSafe home security system. • We identified any privacy and security concerns that arose due to the way the SimpliSafe home security app stores data on smartphones and transmits data over a network. • We provide a forensic road map to investigators tasked with examining this and similar home security systems.
This paper is organized as follows. In the next section, we share background information and related works. In Section 3, we explain the methodology followed in this paper. Section 4 describes our findings. In Section 5, we discuss our results and challenges. Finally, in Section 6, we conclude our analysis and discuss future work.

Related Work
In this section, we discuss some of the related work in mobile application forensics of smart home devices, smart home forensic investigations, and home security system investigations. An overview of the reviewed research and its shortcomings are presented in Table 1.
There have been several previous efforts in recovering forensic artifacts from smart home IoT devices. For example, Hutchinson et al. [7] conducted a forensic investigation of various smart home devices in a lab setup and discussed possible threat scenarios. They were able to recover several private pieces of information such as email, full name, OAUTH credentials, etc., from the smart home devices and their companion apps and discussed the privacy concerns and security vulnerabilities when using these smart home devices. Chung et al. [8] analyzed client-centric and cloud artifacts stored within companion apps of the Amazon Echo. Dorai et al. [9] investigated the forensic artifacts produced by Nest ecosystems such as Nest thermostats and Nest cameras. Other studies have looked at smart devices' ecosystems and their interaction with each other. In [10], Hutchinson et al. investigated the August Smart Doorbell Cam and Lock devices and the interaction between these devices to determine what information could be acquired.
Although forensic investigations into home security systems and specifically Sim-pliSafe has been limited, there are a few previous works that have investigated security and privacy issues that we describe in this section. Janes et al. [11] evaluated the susceptibility of 19 common security cameras and doorbells to a persistent attack after access revocation, in situations when multiple users share a single account. Specifically, they looked at design flaws that failed to revoke a user's access that was requested to be removed by the account owner. In their study, they also included SimpliSafe Doorbell and Camera, and their results showed that the video stream on the Android companion app was still available for over 30 min after the account's password was changed. OConnor et al. [12] studied the design and implementation flaws of twenty smart home device companion apps. Their results showed that sixteen of these vendors suffered from some form of a design flaw that failed to properly validate certificates or protect the integrity of the message traffic. In particular, they showed that they were able to manipulate or clear alarm log files for SimpliSafe.
Through IoT and network forensics, Hutchinson et al. [7] also investigated the network traffic for over 10 IoT smart devices including the Google Nest Hub Max, Amazon Fire TV Cube, and the August smart lock and smart doorbell [10]. By investigating both the mobile applications and network traffic of these devices, the authors highlighted the serious security risks that threatened these devices' users. For instance, although some of the information found such as zip code, the make and model of the devices used, etc., may not be useful to a forensic investigation, they can be used as reconnaissance to gain further access into the home network which can lead to spear-phishing or blackmail.
Additionally, ref. [13] showed how Wireshark could be utilized for network protocol diagnosis and aid in network forensics. This was done by conducting multiple attack scenarios such as covert FTP and IRC channels, ICMP-based attacks, and distributed denial of service (DDoS) attacks while running Wireshark concurrently to capture network traffic. The traffic was then analyzed to identify the attack vectors.
In [14], the authors used recognizable network traffic patterns to predict incoming distributed denial-of-service (DDoS) attacks. More specifically, they used Wireshark's I/O graph tool to discover five unique network traffic patterns that emerged when their home IoT environment was under a DDoS attack. The authors also provided guidelines to filter for specific traffic such as the TCP error flags and protocols used in Wireshark. To determine what data from IoT devices can be recovered, how to recover the data, and where these data reside.
The authors created an IoT forensics laboratory. They used XRY to create a physical image and XAMN to analyze the image for artifacts and evidence of privacy leaks.
The authors investigated individual home security devices such as an August Smart Lock Pro and August Smart Doorbell Pro but not a smart home monitoring system.
Chung et al. [8] To investigate methods for digital forensics pertaining to the IVA Alexa's ecosystem.
The authors proposed a new integrative approach combining cloud-native and client-centric forensics for the Amazon Alexa ecosystem. They also introduced an implementation, CIFT, to acquire native artifacts from Alexa and analyze local artifacts from companion clients.
The authors did not perform their investigation on the hardware level of the Alexa-enabled devices. They also did not perform memory forensics for volatile artifacts.
Dorai et al. [9] To examine the logical backup structure of an iPhone used to control a Nest thermostat, Nest indoor camera, and a Nest outdoor camera.
The authors built an open-source forensic tool called Forensic Evidence Acquisition and Analysis System (FEAAS), that consolidated evidentiary data into a readable report that could infer user events.
The study was only limited to iPhones and focused on data that were logically acquired from the mobile device, which meant that it only worked if data had not been deleted from the phone under examination.
Hutchinson and Karabiyik [10] To determine what type of data forensic investigators may be able to recover about the August Smart Doorbell Pro and the August Smart Lock Pro, with their controlling app, August Home.
The authors used Magnet AXIOM Examiner and MSAB XRY to examine artifacts acquired from imaging one iOS and two Android smartphones.
The authors investigated two individual IoT devices (August Smart Lock Pro and August Smart Doorbell Pro) but not a smart home monitoring system.
OConnor et al. [12] To better understand IoT security and privacy by studying the design flaws of this distributed communication channel for smart home devices.
The authors implemented a smart home lab environment with devices from 20 different vendors to explore the severity and pervasiveness of attacks against IoT devices.
The authors showed that they were able to manipulate or clear alarm log files for SimpliSafe. However, they only focused on whether the attack was successful or transparent. They did not investigate any recoverable artifacts related to user interactions with the system.
Ndatinya et al. [13] To demonstrate how Wireshark can be applied in network protocol diagnosis and can be used to discover traditional network attacks.
The authors used Wireshark to identify certain types of network attacks that resulted in unusual activities as well as present case studies for typical network attacks by using Wireshark. Ho et al. [14] To discover network traffic patterns that emerge when IoT devices are under a DDoS attack.
The authors used LOIC and Slow Loris to perform a DDoS attack on the IoT devices. They used Wireshark to capture and examine the network packet captures while the attack was running The authors only used Wireshark to analyze the network packet captures. Different software and metrics could be used to conduct both the attacks and the investigation processes.

Methodology
There is little to no forensic work related to IoT home security systems such as Sim-pliSafe, which leaves a wide area of possibilities for research stretching from the privacy and security of these systems to their potential for compromise. The aim of our study was to determine how much evidence can be obtained during a forensic investigation involving such a security system, particularly concerning the ability to recover artifacts related to user interactions with the system, alert notifications, and camera images. This information can be helpful in situations where a crime has occurred and investigators are looking for digital evidence from the security system. We were also interested in comparing the type and number of forensic artifacts that could be recovered from both operating systems investigated. To accomplish these goals, the SimpliSafe security system was forensically investigated via its controlling application on Android and iOS smartphones as well as the system's network communications. Similar methodologies were used in [7,10]. The result of our study is also useful in identifying any privacy and security concerns that arise for the homeowner as a result of using such systems.

Device Setup and App Installation
A typical SimpliSafe security system includes a base station which is the heart of the system that all sensors connect to. The base station sounds the alarm or alerts the monitoring station when a sensor is triggered. It also contains a wireless keypad that allows the user to arm or disarm the system and change settings. The system comes with a companion app where the user can monitor camera images or change settings. The SimpliSafe security system allows users to subscribe to monitoring services which enable users to record and store camera feeds to the cloud or connect the system directly to emergency response services. In this study, we used the free (unmonitored) subscription plan in which the user can only monitor everything through the app, but the system was not connected to an emergency response service. In our setup, we used the base station, the wireless keypad, an indoor security camera, two entry sensors, and a motion sensor (see Figure 1). All SimpliSafe devices (hub, keypad, sensors, and camera) were new so there was no need for reverting them to factory settings. Prior to activating the system, a Google email address (p****lab@gmail.com) was used to set up the SimpliSafe account. We also obtained a SIM card for cellular connection and the plan that needed to be associated with the security system.

Lab and Scenario Setup
The physical location of the security system was within a single research lab. We formulated a burglary scenario to guide our investigation and set up the devices in locations to represent a one-story home with a basement. The location of devices in this scenario can be seen in Figure 2. Our burglary scenario involved someone breaking into the front door (entry sensor #1), walking past the indoor security camera in the living room, opening the basement door (entry sensor #2), triggering the motion sensor in the basement, and breaking into a safe stored in the basement.  Figure 3 illustrates the research methodology followed in this study including the processes to populate, acquire, and analyze the relevant apps on both smartphones. Similarly, Figure 4 depicts the network and communication links among all devices used in the study. In this scenario, motion and entry sensors, as well as the keypad, were directly connected to the base station which was wirelessly connected to the access point provided by the laptop. The laptop acted as the bridge between the Internet and the local network, allowing us to capture the network traffic using Wireshark and further analyze the packets. The laptop with the Nmap [15] software allowed us to keep track of the IP addresses assigned to the base station, camera, and smartphones. Additionally, Figure 4 shows the indoor camera being connected directly to the laptop and not to the base station like other sensors. This is due to the camera's ability to operate independently of the base station and sensors.

Data Population
During the data population phase, we made sure to use test accounts that were never previously associated with the SimpliSafe system. The steps to populate our experimental devices with user data included (1) factory resetting the iPhone X (model: A1865) to default, (2) rooting and verifying root access on the Google Pixel 5a smartphone using a root checker app, and (3) entering data in devices according to the National Institute of Standards and Technology (NIST) [16] guidelines for populating a mobile device. This meant that we installed the SimpliSafe app from the App Store and the Google Play Store on both devices. A short summary of the steps we performed for the data population on both apps is as follows: • We created an account and signed into the app. • We set up the SimpliSafe devices on the account. This included connecting the base station and camera to the Internet. • We interacted with the system by changing the alarm mode, OFF, HOME, or AWAY, via the app on the phone and the keypad. • We triggered the alarm via each sensor. • We viewed the camera feed from the app.
For the full timeline of the actions please refer to Appendix A.1 for Android and Appendix A.2 for iOS.

Data Acquisition
Once the data population was completed, we immediately created the forensic image of the smartphone using either Cellebrite UFED 4PC [17] to acquire the iPhone X (advance logical image) and Magnet AXIOM Process [18] to acquire the Google Pixel 5a (logical image). Cellebrite UFED 4PC is equipped with the checkra1n exploit which was capable of jailbreaking our test iPhone. Similarly, because we rooted the Google Pixel 5a device, we expected full access to the file system. However, neither Cellebrite nor Magnet was able to provide a full/physical image of this Pixel device. All the software tools used throughout the process are shown in Table 2.

Examination and Analysis
We performed the examination and analysis of both forensic images using Magnet AXIOM Examine as this commercial tool suite has the capability to process both .tar (Google Pixel 5a) and .zip (iPhone X, A1865) image formats.
All artifacts discussed hereunder were recovered from the apps' packages. The iOS app package was found in the \private\var\mobile\Containers\Data\Application\ 8E91EBEE-4046-4220-86EE-94CAA7DF32FD and the Android app package was found in the \data\data\com.simplisafe.mobile folders in the respective file systems.

Network Traffic Capture
Wireshark, an open-source packet analyzer was used to collect network traffic during the data acquisition phase. Wireshark was selected specifically for this investigation as it provides a packet-by-packet view of network traffic [19]. The mode was initially set to OFF in the SimpliSafe application. The network capture was started in live view, then the mode was switched to Away, and the network capture was stopped. This scenario was repeated 10 times to ensure accuracy and consistency in the network traffic collected. Wireshark's built-in "I/O Graphs" tool was used to graphically represent the data for a visual information analysis. Each capture was converted into an I/O graph and then analyzed to see if there were any unexpected traffic patterns.
Additionally, Splunk [20] was used to further analyze the packet captures. Specifically, "PCAP Analyzer for Splunk" [21] was used as it uses the tshark component to convert pcap files into readable csv files. This allowed for the creation of many graphs including but not limited to bytes transferred by conversation, TCP flags over time, packet count by protocol, and TCP errors over time by source IP. The network traffic was then analyzed to see if there were any unexpected or outlying traffic patterns. If there was any unanticipated traffic detected, it could be a sign of a vulnerability or an insecure network.
The security of the network traffic was also analyzed to see if the levels of encryption and encoding were enough to prevent us from reading plaintext or unencrypted data. Specifically, we looked into the digital signature, key exchange, and session key generation protocols using Wireshark itself.

Results
After completing our comprehensive digital forensic analysis of both Android and iOS images, we identified all forensically relevant artifacts that could be extracted and would benefit forensic investigators. In this section, we present our findings in detail.

Android Findings
Most notably, the recovered Android artifacts may help paint a picture of when and where the user used the app or the system, respectively. Session-related logs were recovered from both the \app_bugfender folder and the \databases\com.amplitude.api database. Figure 5 depicts the content of the long_store table within this database. These logs include session, device, and user ID numbers, network connection, failure logs, and session start and end timestamps, among others ( Figure 6).
The \shared_prefs\FirebaseHeartBeatW0RFRkFVTFRd+MTo2MDgzNjI2NDEwNzY6YW5 kcm9pZDplZjYzOGI5ZGUxZWI2ZWU3.xml file held the last date the app was used as well as a record of each day the app was used on the current device. Since the testing took place over two days, we were only able to confirm this list recorded at least two days of app usage (see Figure 7). Similarly, the first time the app was opened on the current device and the last time the app was paused (i.e., put into the background) could be recovered from the \shared_prefs\com.google.android.gms.measurement.prefs.xml file.
Two of the more relevant .xml files found within the \shared_prefs folder were the SS_MISC.PREFERENCES.xml file and the SS_TOKENS.PREFERENCES.xml file (see Figure 8). With these two files, investigators were able to identify (1) current_location_sid, (2) the number of times the user viewed the live camera feed, (3) the last time the app was opened, (4) the SID of the monitoring location, (4) the name of the camera that was set up, (5) the SID of the camera's location, and (6) the user's user ID and email address.    Investigators may be able to use current_location_sid to elicit the physical address from SimpliSafe (e.g., the home address) where the system is being used. This may be necessary if the smartphone is the only piece of evidence that investigators have access to during a time-sensitive investigation, such as a kidnapping case.
Other usage-related artifacts were also recovered, including the timestamps of when pop-up notifications were shown to the user on the app (\shared_prefs\SS_USER_ACTIONS. PREFERENCES.xml file), authentication keys/tokens, and IV's for the SimpliSafe app along with expiration timestamps (\shared_prefs\com.auth0.authentication.storage.xml file).

iOS Findings
A variety of methods and tools were utilized to retrieve the information in this section. For the data acquisition, Cellebrite UFED 4PC was used and the generated .dar image file was placed in Magnet AXIOM Process to create the case which was later used for the examination and analysis via Magnet AXIOM Examine. In order to make it easier to display the findings, the initial portion of the path \private\var\mobile\Containers\ Data\Application\8E91EBEE-4046-4220-86EE-94CAA7DF32FD is removed in the following discussions.
The first finding for iOS was at the \Library\ApplicationSupport\Google\ Measurement location within the google-app-measurement.sql database and events table. This table shows events throughout the data population (see Figure 9). The highlighted item's (Auth0_Login_Success) timestamp matched our timeline (Appendix A.2) when we logged into the app on 5 January 2023 around 10:37. Similarly, Camera_View_Live_Failed matched the timeline when the camera was accessed unsuccessfully. These are only two examples while the table contained 49 records in total.
Various sessions were found in the \Library\Caches\com.bugfender. BugfenderSDK\BFPersistedStringQueues folder. We found two sessions, one of less value and one containing valuable information for the investigation. Within the session-24842698825 folder and session.json file, information such as udid, key, device type, OS version, and starting time of the session was found (shown in Figure 10). This time matched the time when we signed into the application for the first time.  Moreover, the \Library\Caches\com.bugfender.BugfenderSDK\session-24842698 825\logs folder contained logs stored throughout the session. The log records started right after the first login. The logs were consistent with the app being opened and used. For example, on 5 January 2023, logs were only created during the times of the data population (see Figure 11). We were able to locate records associated with different events performed as part of the study. For example, Figure 12 presents the file 61708060319.txt containing information that shows when the alarm was switched off, which also matched our timestamp of this event. Figure 13 shows the log related to the action of pairing the camera with the application by scanning the QR code on the camera device during the setup. Figure 14 shows the information such as uid, sid, wlanMac, and serial number presented in file 69196065763.txt.   As it can be seen in Figure 15, we changed the state of the system from OFF to Home on 6 January 2023 at 10:17. The request did not show the initial state of the system; however, it showed the requested state, which in the previous image was Home. This was also consistent since the system was reverted back to OFF at 10:18 (see Figure 16).         The SimpliSafe system has the ability to be disarmed remotely using the application. This feature was tested and we were able to extract the information shown in Figure 21. We found a thumbnail photo ( Figure 22) stored at \Library\Camera-Thumbnails. To the best of our knowledge and based on the logs we kept of all the actions we performed, this thumbnail was not created as a result of any of our intentional actions. The metadata analysis performed on the photo showed three different times, accessed, modified, and changed. Accessed and modified times matched 6 January 2023 at 10:29 which was when the camera was first opened. The changed time was 6 January 2023 at 10:34, when the whole system was powered down leading us to believe that the camera took a thumbnail photo on the initial opening of the camera lens. Finally, the email address associated with the SimpliSafe application was found in the .plist file at the location FullFileSystem.1.dar\8E91EBEE-4046-4220-86EE-94 CAA7DF32FD\Library\Preferences\com.simplisafe.mobile.plist (see Figure 23). In summary, Table 3 summarizes the recovered artifacts from both platforms. In this table, "System Location" refers to any artifacts related to the physical location of the SimpliSafe system; "User Interactions" refer to any artifacts relating to user changes to the system, such as changing the system alarm state, viewing the camera feed, etc.; lastly, "App Usage" relates to any artifacts that can relate to how the user used the app or made setting changes, etc.

Network Findings
The analysis of network captures did not show any unexpected or inexplainable patterns in the network traffic. Figure 24 shows the I/O graph from the first Wireshark capture. All spikes in network traffic were consistent with regular network traffic. TCP error packets increased only when the number of total transferred packets increased, which was consistent with normal traffic patterns. As mentioned earlier, during the data acquisition phase, we changed the state from OFF to Away while capturing the network traffic and repeated this scenario ten times. Using PCAP Analyzer for Splunk, we were able to automatically generate various visual representations of the ten repeated packet captures and combine them onto a dashboard. Figure 25 shows a section of the PCAP Analyzer for the Splunk dashboard. Based on the ten packet captures, there were a total of 1491 total packets transferred, with a packet loss of 3.89%. Regarding the bytes transferred by protocol and the packet count by protocol, most bytes and packets were transferred using the TCP and TLSv1 protocols. The majority of the TCP flags over time were ACK flags. TCP errors over time increased and decreased, depending on the number of packets transferred, which was consistent with normal network traffic. Nothing unusual from the maximum round trip times and window sizes was detected.
The "tls && ip.src==192.168.137.141" was used to filter only Transport Layer Security (TLS) packets that came from the 192.168.137.141 source IP address (Android phone) to inspect the encrypted packets further. The Wireshark analysis showed that SimpliSafe was using TLSv1.2 to authenticate and encrypt data over the network. It was found that the key-exchange protocol used elliptic-curve Diffie-Hellman with a 65-bit public key. The Change Cipher Spec protocol was used to generate a session key and let the other party know that the message was encrypted. A 256-bit signature was used.
Given that SimpliSafe uses secure TLS, elliptic-curve cryptography, and best keyexchange practices, this may be a reason why most network traffic analysis findings were as expected. SimpliSafe follows the best practices for network security as determined by [22] when it comes to safeguarding its network traffic. As such, a substantial amount of the SimpliSafe network traffic that was analyzed was encrypted.

Discussion
Smart security systems continue to infiltrate homes at pace. However, with respect to the security and privacy of homeowners, these systems carry various risks. For instance, we were able to determine the time of entry and exit of the residents by analyzing the retrieved log records from an iPhone X. Should these log files hold data spanning multiple weeks, the homeowners' "pattern of life" could be determined. This insight could compromise the user's privacy and possibly pose a security risk. If such data were accessible by malicious parties, it would enable them to strategically plan and carry out heinous crimes, such as robbery, kidnapping, or murder.
The use of an indoor camera also adds to the potential for privacy concerns. Our findings from both operating systems indicated that it was possible to recover thumbnails from the camera. Such artifacts may capture the moment of interest when considering a criminal investigation.
Due to SimpliSafe's implementation of essential security standards and best practices, the majority of the collected network traffic was encrypted. This prevented the means of discovering what network traffic could be captured and what could not. No distinct patterns that could report behaviors related to various actions taken on the SimpliSafe mobile application were found. Although this hindered the investigation process in terms of network findings, it showed that the network artifacts that can be recovered from SimpliSafe devices are limited.

Challenges
The results of this research also highlighted numerous challenges that forensic examiners might face, particularly the disparities in the quantity of retrieved data available on different smartphones and operating systems. Moreover, it was found that the time between the data population and the device acquisition could have an impact on how many data could be retrieved. During this investigation, we used two different iOS devices, an iPhone SE and the iPhone X. At first, we used the iPhone SE with iOS version 14.0.1. After the data population, the image acquisition process involved Cellebrite UFED 4PC and Physical Analyzer acquiring the advanced logical image. Upon further examination and analysis of the created image, no significant data were found related to the SimpliSafe application and the activities carried out. The time between the data population and the data acquisition was more than a few days. The initial data population was conducted on 19 August 2022, and the acquisition was performed on 24 August 2022. This could be a possible explanation for the missing data. The second data population was performed on an iPhone X with iOS 14.2 (18B92). The process for the data population was very similar to the first, with some minor variations. The main difference was the phone and the time between the data population and the acquisition, which was performed on the same day. The second method generated more results. Due to negligent relevant findings from the first acquisition of the iPhone SE, only the findings recovered from the iPhone X were reported in this research in Section 4.2 (iOS Findings). The data population process was the same for both devices, leading us to believe that the time between population and acquisition might be essential to the investigation. This hypothesis, however, needs to be tested further to prove the exact reason for the variation in the quantity of recoverable data.
During the data population phase, the SimpliSafe system needed to be unlinked from the Android account (email address) before it could be used with the Apple account. For this to happen, SimpliSafe requires customers to contact customer service to have them unlink the system on their end, a time-consuming process. Despite the inconvenience, this step adds another layer of protection for customers, since a stolen or second-hand preconfigured SimpliSafe system cannot be linked to a new account without having prior information about the previous owner.

Conclusions and Future Work
This paper addressed the need for transparency and increased user awareness concerning the use of IoT-enabled home security systems. Due to the lack of forensic research involving IoT-enabled security systems and the widespread use of these systems by American homeowners, the current work is uniquely positioned to both (1) document the forensically relevant artifacts available on Android and iOS smartphones for forensic investigators and (2) elucidate the privacy concerns that these systems' users may experience.
In this regard, we focused on self-installed home security systems, as their popularity is increasing. We performed a comprehensive forensic investigation of the SimpliSafe security system on both Android and iOS devices, and the system's network traffic by using state-of-the-art forensic software. The aim of our efforts was to detect any security and privacy concerns that arose when using such systems and to equip other investigators with a road map to study similar home security systems. Our findings highlighted the disparity in recoverable artifacts from various media. For instance, the actions the user performed on the app (e.g., changing the system state) were recovered from JSON and PList files on the iOS image, but such artifacts were not recoverable from the Android image. In terms of network traffic, SimpliSafe follows security standards and best practices according to [22]. The SimpliSafe system uses secure TLS, and elliptic-curve encryption, and properly generates session keys using the Change Cipher Spec protocol.
Future work for this project includes reconstructing the data population and taking images during different time intervals to determine the level of artifacts and their degradation over time. The results can be helpful for digital forensic investigators if there is limited time for the data acquisition process. Furthermore, the camera took a photo as a thumbnail, which can have an impact and reveal sensitive information. To better understand the time and anticipate when the camera is taking the thumbnail, we plan to place a clock in front of the camera showing the date and time. We also plan to further investigate the network traffic and recoverable artifacts while using the different subscription plans in which the system is being monitored remotely by SimpliSafe, where they can dispatch fire/police services when the alarm is triggered. Of course, this requires advanced planning and possibly SimpliSafe's cooperation in order to simulate a test environment without actually dispatching the emergency services.

Conflicts of Interest:
The authors declare no conflict of interest.