A subset of mobile applications is explicitly marketed to military-affiliated personnel. These Military-Marketed Mobile Apps (MMM-apps) collect privacy-sensitive data using the same mechanisms as general-purpose apps. However, when such data belongs to military-affiliated personnel, it may be exploited by malicious actors in ways that threaten personal safety, unit operations, and national security. Despite these risks, the data practices and code provenance of MMMapps, as well as how this population perceives and attempts to mitigate these risks, remain poorly understood. In this paper, we address this gap by combining large-scale app analysis with a user study. We first curate a dataset of 242 MMMapps and leverage app analysis techniques to characterize their data practices and code provenance. Then, we conduct a user study with n = 103 military-affiliated participants in the United States to examine which data practices and code provenance characteristics they consider inappropriate, what threat scenarios they believe those practices enable, and which mitigations they view as most effective. Our results show that MMMapps frequently exhibit data practices and code provenance characteristics that are misaligned with the privacy expectations of military-affiliated personnel. For instance, 40% of MMMapps collect more data than they disclose in their privacy labels or data safety sections. 83.5% of our study participants report using at least one MMMapp that engages in data practices they are uncomfortable with. Additionally, although military-affiliated personnel are generally concerned about third-party libraries accessing their data, 64% of MMMapps include third-party SDKs, some developed in countries perceived as adversarial by a majority of the participants. Overall, our findings reveal a substantial misalignment between the privacy expectations of military-affiliated personnel and the data practices and software supply chains of MMMapps. We propose recommendations at the federal, DoD, app store, and device levels to improve privacy risk mitigation for this at-risk population.

Android smartphones use a dedicated component, Keymaster, to perform all their cryptographic, security-sensitive operations (e.g., storing cryptographic material and performing signing operations). While all Android Keymaster implementations need to expose a specific interface, their internals are hard to analyze, since their source code is generally not available. Moreover, Android Keymasters' code normally runs in a Trusted Execution Environment (TEE), where typical debugging functionality is not available. For these reasons, Keymaster implementations cannot be analyzed using white-box or gray-box automated approaches.

Wearable devices are becoming increasingly important, helping us stay healthy and connected. There are a variety of app-based wearable platforms that can be used to manage these devices. The apps on wearable devices often work with a companion app on users’ smartphones. The wearable device and the smartphone typically use two separate permission models that work synchronously to protect sensitive data. However, this design creates an opaque view of the management of permission-protected data, resulting in over-privileged data access without the user’s explicit consent. In this paper, we performed the first systematic analysis of the interaction between the Android and Wear OS permission models. Our analysis is two-fold. First, through taint analysis, we showed that cross-device flows of permission-protected data happen in the wild, demonstrating that 28 apps (out of the 150 we studied) on Google Play have sensitive data flows between the wearable app and its companion app. We found that these data flows occur without the users’ explicit consent, introducing the risk of violating user expectations. Second, we conducted an in-lab user study to assess users’ understanding of permissions when subject to cross-device communication (n = 63). We found that 66.7% of the users are unaware of the possibility of cross-device sensitive data flows, which impairs their understanding of permissions in the context of wearable devices and puts their sensitive data at risk. We also showed that users are vulnerable to a new class of attacks that we call cross-device permission phishing attacks on wearable devices. Lastly, we performed a preliminary study on other watch platforms (i.e., Apple’s watchOS, Fitbit, Garmin OS) and found that all these platforms suffer from similar privacy issues. As countermeasures for the potential privacy violations in cross-device apps, we suggest improvements in the system prompts and the permission model to enable users to make better-informed decisions, as well as on app markets to identify malicious cross-device data flows.

Many apps performing security-sensitive tasks (e.g., online banking) attempt to verify the integrity of the device they are running in and the integrity of their own code. To ease this goal, Android provides an API, called the SafetyNet Attestation API, that can be used to detect if the device an app is running in is in a "safe" state (e.g., non-rooted) and if the app's code has not been modified (using, for instance, app repackaging). In this paper, we perform the first large-scale systematic analysis of the usage of the SafetyNet API. Our study identifies many common mistakes that app developers make when attempting to use this API. Specifically, we provide a systematic categorization of the possible misusages of this API, and we analyze how frequent each misuse is. Our results show that, for instance, more than half of the analyzed apps check SafetyNet results locally (as opposed to using a remote trusted server), rendering their checks trivially bypassable. Even more surprisingly, we found that none of the analyzed apps invoking the SafetyNet API uses it in a fully correct way.