Pith. sign in

REVIEW 4 major objections 4 minor 97 references

KeyDroid: A Large-Scale Analysis of Secure Key Storage in Android Apps

T0 review · 4 major / 4 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Most Android apps handling sensitive data skip hardware-backed key storage; only 5.03% use the strongest option, StrongBox, which the paper finds too slow for common operations.

desk verdict A large, mostly sound measurement study whose real contribution is the performance data; the adoption headlines are credible upper bounds but rest on a fragile label-based denominator and a few sloppy abstract claims. read the letter →

arxiv 2507.07927 v1 pith:7FKGUTMT submitted 2025-07-10 cs.CR

Jenny Blessing , Ross J. Anderson , Alastair R. Beresford This is my paper · ORCID
classification cs.CR
keywords hardware-backedkeystorageAndroidKeystoreStrongBoxsecureelementtrustedexecutionenvironmentappsecuritystaticanalysisPlayStoredatasafetylabelscryptographicperformance
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper asks whether Android apps actually use the hardware-backed key storage built into their devices, and whether performance explains the gaps. Analyzing 490,119 Play Store apps, the authors find that 56.3% of apps whose developers report collecting sensitive user data never reference the Android Keystore API at all, and only 5.03% use StrongBox, the strongest option, a secure element separate from the main processor. Their measurements show the trusted-execution-environment keystore is fast enough for nearly every common operation, while StrongBox takes 15.43 seconds to encrypt a single megabyte with AES-GCM, which rules it out for bulk symmetric encryption and for most asymmetric operations. Together the two halves quantify the gap between industry promotion of trusted hardware and actual developer uptake, and supply the performance numbers developers need to choose a security tier.

What carries the argument

The central object is the Android Keystore API, which fronts two hardware backends: a trusted execution environment (a protected secure mode of the main processor, used by default) and StrongBox Keymaster, a secure element that must have its own CPU, tamper-resistant packaging, and a true random number generator, and that developers must explicitly request. The analysis instrument is KeyDroid, a static-analysis pipeline that decompiles each app, builds an inter-procedural call graph, extracts 64 Keystore-related API calls with their arguments, and classifies each call as first-party or third-party; the adoption claims ride on that classification, while the performance claims ride on a benchmarking app that times key generation, encryption, and signing across the software, TEE, and StrongBox keystores on physical devices. The thread joining the two halves is the trade-off the paper makes quantitative: stronger hardware costs runtime, and the measurements state exactly how much, per operation and per payload size.

What would settle it

Re-run the paper's benchmark on a current flagship phone: if 1 MiB AES-GCM encryption in StrongBox completes in well under a second, or if RSA-2048 key generation finishes in under a second, the performance half of the claim is overturned. For the adoption half, instrument a random sample of the 159,241 apps labeled sensitive and check at runtime whether they actually store sensitive data on-device; if most never do, the 56.3% non-use figure is miscalibrated.

Watch

Extended reading notes

Core claim

The central claim is that hardware-backed key storage is decisively underused across the Android ecosystem, and that the strongest tier, the secure element, is underused partly because it is impractically slow. On the usage side, of the 159,241 apps whose Play Store data safety labels report sensitive data collection, at most 43.7% reference the Keystore API, only 5.03% reference StrongBox, and 94.7% of key initialization calls sit inside third-party libraries rather than app-written code; the paper therefore presents its adoption figures as upper bounds on real secure storage. On the performance side, TEE-backed encryption is indistinguishable from software storage for payloads up to 1 MiB, whereas StrongBox on the Pixel 8 takes 15.43 seconds to encrypt 1 MiB with AES-GCM, 9.22 seconds to generate an RSA-2048 key, and over four minutes for 16 MiB, which the paper argues makes StrongBox infeasible for non-negligible payloads and most asymmetric operations.

Load-bearing premise

The load-bearing premise is that Play Store data safety labels, which are self-reported by developers and count data transmitted off-device rather than data processed locally, correctly identify which apps handle sensitive user data, because the entire denominator behind the 56.3% and 5.03% adoption figures is built from those labels.

Editorial extensions

If this is right

  • Google's stated goal of making the secure element the 'lowest common denominator' for Android credential storage is far from met: only about one in ten apps that use any trusted hardware ever use StrongBox.
  • Developers can adopt TEE-backed keystores for typical payloads under 1 MiB with no user-visible performance penalty, so performance is not a valid reason to keep sensitive keys in a software keystore for those cases.
  • StrongBox is practical only for small payloads, such as wrapping a key that is later used in a faster keystore, or for one-time operations; the paper's tables let developers compute the exact cost of each choice.
  • Because 94.7% of key initialization calls come from third-party libraries, most trusted-hardware usage in the ecosystem is inherited from SDKs rather than chosen by the app's own developers.
  • The 8.45% of keystore-backed keys that disable randomized encryption show that secure API defaults do not by themselves guarantee secure deployments, since developers can and do deliberately opt out.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Because data safety labels count only data transmitted off-device, apps that process sensitive data purely locally are invisible to the paper's denominator; if such apps are common, the true share of sensitive-data apps without hardware protection is larger than 56.3%, making the headline figures optimistic upper bounds.
  • The concentration of keystore calls in a handful of widely distributed SDKs suggests the cheaper adoption lever is library-level: app-store scanning and SDK vendors could push hardware-backed defaults where the keystore decision actually happens, and the paper's first-party-versus-third-party split makes that effect measurable within a release cycle.
  • The performance jump between secure-element hardware generations implies StrongBox usability is largely a property of the device fleet, not the app; a testable prediction is that StrongBox adoption tracks the installed base's age and that restricting analysis to devices containing secure elements would push the 5.03% figure upward.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 4 minor

Summary. The paper presents KeyDroid, a static-analysis pipeline applied to 490,119 Android apps from AndroZoo, and uses it to measure adoption of the Android Keystore API (TEE-backed) and StrongBox (secure-element) across the ecosystem. Cross-referencing with Play Store data-safety labels, the authors report that 56.3% of apps self-reporting sensitive data do not reference trusted-hardware APIs and that 5.03% reference StrongBox. They further report that 94.7% of Keystore initialization calls reside in third-party libraries and that about 8.45% of hardware-backed keys disable randomized encryption. The paper also benchmarks symmetric and asymmetric operations across software, TEE, and StrongBox keystores on Pixel and other devices, finding TEE performance viable for most operations while StrongBox is slow for large payloads (e.g., 15.43 s for 1 MiB AES-GCM, 9.22 s for RSA-2048 key generation on Pixel 8). A small developer survey and a discussion of adoption barriers complete the paper.

Significance. If the measurements hold, this is the first systematic, large-scale study combining adoption and performance data for hardware-backed key storage on Android, and it provides useful empirical grounding for developer guidance. The open-sourced dataset and tooling (Section 11) are a valuable community resource, and the authors are appropriately careful to frame many usage statistics as upper bounds. The performance measurements are novel relative to prior work and directly address a gap in Android's documentation. However, the headline adoption percentages rest on self-reported Play Store data-safety labels and on static-analysis reachability heuristics, and the abstract and introduction contain internal numerical inconsistencies that will mislead readers if not corrected.

major comments (4)
  1. [§A.2, §4.1, §8] The denominator for the headline adoption figures (56.3% non-use, 5.03% StrongBox) is the set of 159,241 apps identified from Play Store data-safety labels. The paper itself acknowledges that only 74.47% of apps have submitted the form and that Google's definition of 'collected' covers data transmitted off-device, so apps that process sensitive data locally but do not transmit it are excluded from the denominator. The hypothesis in §A.2 that non-reporting apps are unlikely to use secure storage is not evidence. A sensitivity analysis against an independent sensitive-data proxy (e.g., permission-based classification or a manually labeled sample) is needed to bound the effect of label error on the headline ratios; without it, the Discussion's generalization to 'apps processing sensitive data' is not supported.
  2. [Abstract, §1, §5.1] The abstract's claim that StrongBox makes 'any kind of asymmetric encryption' infeasible is contradicted by the paper's own measurement in §5.1: asymmetric encryption of a 256-bit payload on the Pixel 8 takes 0.0125 s in StrongBox. The actual performance barrier is asymmetric key generation (9.22 s for RSA-2048) and large-payload operations, not small-payload asymmetric encryption. This wording should be corrected so the abstract accurately reflects the reported data.
  3. [§1 vs. §5.1 and Table 5] The Introduction states that encrypting a 1 MiB message with AES-GCM in StrongBox takes 'around 3 seconds' on the Pixel 8, but §5.1 and Table 5 report 15.43 s for this operation. This factor-of-five discrepancy is a factual error in the summary of the paper's own measurements and must be corrected before publication.
  4. [§4.1, §7, Abstract] The 56.3% non-use figure is presented in the abstract and Introduction as a precise measurement, but §4.1 defines the 43.7% usage rate as an upper bound and §7 states that the results provide an 'empirical upper bound' on secure key storage usage. Consequently, 56.3% is a lower bound on non-use, not an exact figure. The abstract should carry this qualifier (e.g., 'at least 56.3%' or 'as an upper bound, only 43.7%').
minor comments (4)
  1. [§5.2, Table 5] The reported runtimes are non-monotonic for both TEE (7.67 s at 8 MiB vs. 5.83 s at 10 MiB) and SE (159.61 s at 8 MiB vs. 127.01 s at 10 MiB), which is inconsistent with the claim that runtime increases linearly with message length; the entries should be checked or the measurement anomaly should be explained.
  2. [§6] The developer survey received only 42 responses from 10,000 emails for the Sensitive-NonKeystore group and zero responses for the StrongBox-Disabled group; conclusions such as 'API usability did not appear to be a widespread concern' should be tempered given the low response rate, and the survey should not be used to support quantitative generalizations.
  3. [Abstract, §1, §9] The claims of being the 'first comprehensive survey' and 'first empirical analysis' should be hedged in light of the concurrently published work by Bove [33] on TEE-based API prevalence, which the paper itself cites; a phrase such as 'to the best of our knowledge' or a precise differentiator ('the first study combining usage and performance across TEE and SE') would be more accurate.
  4. [§3.3, §4.2] The first/third-party classification heuristic (a package is third-party if referenced by multiple APKs from different developers) could misclassify first-party packages that are shared across apps from the same developer or libraries bundled under an app-specific package; a brief discussion of the expected error direction would help interpret the 94.7% third-party figure.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: all central claims are direct measurements and counts, with no fitted parameters, derived equations, or load-bearing self-citation.

full rationale

The paper's central claims are empirical counts and benchmark timings. The 56.3% figure is a ratio computed directly from observed Android Keystore API references among apps labeled sensitive by Play Store data safety forms; the label is an independent input, not defined by the outcome, and the API-reference measurement is not fitted to that label. The 5.03% StrongBox figure similarly comes from counting setIsStrongBoxBacked calls, with an explicit correction for calls that pass false. Performance results are measured wall-clock times from a benchmark application across devices, so they cannot reduce to their own input definitions. The only self-citation of note (Hugenroth et al. [50], which shares a co-author) is used as background for secure-element availability and for prior HMAC measurements; it is not used to derive any headline number, and its claim is independently measured and externally falsifiable. The paper's own Appendix A.2 candidly flags the data-safety-label denominator limitation: labels cover data transmitted off-device, so locally processed sensitive data may be excluded. That is a validity/calibration concern about self-reported labels, not a circularity, because the label is not defined in terms of the paper's conclusions. No equations are derived and no parameters are fitted, so no step reduces by construction to its own input.

Assumptions & free parameters 4 free parameters · 3 assumptions · 0 invented entities

The central claims rest on a small set of measurement choices: which apps count as 'sensitive' (12 of 14 data-safety categories), which packages count as third-party (cross-app reuse), how deep reachability tracing goes (1,000 nodes), and which apps are in scope (free, >=10k downloads). None of these are fitted to make a derivation work; they are pragmatic thresholds that move the headline percentages in a defensible direction (upper bounds). The performance claims additionally assume cloud device farm runs approximate real-device behavior.

free parameters (4)
  • sensitive_data_category_filter = 12 of 14 Play Store data-type categories
    The team excludes 'App info and performance' and 'Device or other IDs' from the definition of sensitive data. This hand-set choice defines the denominator from which the headline 56.3% and 5.03% figures are computed (§A.2).
  • third_party_classification_threshold = package referenced by 2+ APKs from different developers
    A package is labeled third-party if it appears in multiple apps from different developers; this heuristic drives the 94.7% third-party claim and could misclassify shared first-party code or per-developer forks (§3.3).
  • backward_reachability_limit = 1,000 call-graph nodes
    Reachability tracing stops after 1,000 nodes; API calls beyond that depth are treated as unreachable, so the usage figures are upper bounds and may miss some reachable calls (§3.3).
  • app_population_filter = free apps with at least 10,000 downloads
    AndroZoo contains only free apps; the analysis further filters to apps with at least 10,000 downloads and a live Play Store listing in the crawl window. Results may not generalize to paid or long-tail apps (§3.1).
assumptions (3)
  • domain assumption Data safety labels are an adequate proxy for whether an app processes sensitive data
    The labels are self-reported, cover data transmitted off-device rather than locally processed, and are incomplete in about 25% of scraped apps (§A.2). The paper's central statistics depend on this proxy.
  • domain assumption Static analysis of packaged bytecode faithfully reveals API usage
    The analysis assumes obfuscation, reflection, and dynamic code loading do not hide Keystore calls, and that decompiled bytecode corresponds to the code users run (§7).
  • domain assumption AWS Device Farm environments are representative of real user devices
    Performance is measured on cloud-hosted devices, which may differ from personal devices in thermal state, battery, and background load; cross-run variance is visible in Table 5 but not controlled for (Figures 2-4).

how reviews work

0 comments
Cite this review

Pith. "Pith review of KeyDroid: A Large-Scale Analysis of Secure Key Storage in Android Apps." pith.science (2026). https://pith.science/paper/7FKGUTMT

@misc{pith2026250707927,
  author       = {Pith},
  title        = {Pith review of: KeyDroid: A Large-Scale Analysis of Secure Key Storage in Android Apps},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/7FKGUTMT}},
  note         = {Machine review of arXiv:2507.07927}
}
read the original abstract

Most contemporary mobile devices offer hardware-backed storage for cryptographic keys, user data, and other sensitive credentials. Such hardware protects credentials from extraction by an adversary who has compromised the main operating system, such as a malicious third-party app. Since 2011, Android app developers can access trusted hardware via the Android Keystore API. In this work, we conduct the first comprehensive survey of hardware-backed key storage in Android devices. We analyze 490 119 Android apps, collecting data on how trusted hardware is used by app developers (if used at all) and cross-referencing our findings with sensitive user data collected by each app, as self-reported by developers via the Play Store's data safety labels. We find that despite industry-wide initiatives to encourage adoption, 56.3% of apps self-reporting as processing sensitive user data do not use Android's trusted hardware capabilities at all, while just 5.03% of apps collecting some form of sensitive data use the strongest form of trusted hardware, a secure element distinct from the main processor. To better understand the potential downsides of using secure hardware, we conduct the first empirical analysis of trusted hardware performance in mobile devices, measuring the runtime of common cryptographic operations across both software- and hardware-backed keystores. We find that while hardware-backed key storage using a coprocessor is viable for most common cryptographic operations, secure elements capable of preventing more advanced attacks make performance infeasible for symmetric encryption with non-negligible payloads and any kind of asymmetric encryption.

Figures

Figures reproduced from arXiv: 2507.07927 by the authors.

Figure 1
Figure 1. KeyDroid Stages: We (1) scrape Play Store meta￾data and data safety information for all apps in the AndroZoo dataset with at least 10,000 downloads and (2) decompile each app and pre-screen for any relevant API references. If an app contains a reference to the Android Keystore API, we run KeyDroid, our in-depth static analysis tool, to generate the app call graph and extract all API references, arguments, and call p… view at source ↗
Figure 2
Figure 2. Performance evolution of encrypting 1 MiB with AES-GCM in Pixel devices. Each data point corresponds to the Pixel device released in that year (e.g., 2023 represents measurements taken from the Pixel 8). The y-axis is log￾scaled. velopers to circumvent Android Keystore’s secure default settings and implement known insecure configurations by setting Keystore’s setRandomizedEncryption(boolean) API [19], which mandates… view at source ↗
Figure 4
Figure 4. Runtime duration of encrypting 1 MiB with AES￾GCM within a TEE across a range of Android devices recently released in the past two years. While four of the five devices cluster around 0.1 seconds, the runtime of the Pixel 8 is no￾ticeably longer and with a wider range. standard deviations for all message sizes tested on the Pixel 8 (shown visually in [PITH_FULL_IMAGE:figures/full_fig_p011_4.png] view at source ↗
Figures from the paper (1 more)
Figure 5
Figure 5. Figure 5: Percentages of Android apps using TEE and SE APIs, respectively, across major categories within the Google Play Store. StrongBox usage is shown here as a subset of An￾droid Keystore API usage (i.e., any app that uses StrongBox necessarily uses the Android Keystore API)…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

97 extracted references · 77 canonical work pages

  1. [1]

    https://aws.amazon.com/dev ice-farm/

    AWS Device Farm. https://aws.amazon.com/dev ice-farm/

  2. [2]

    https://soot-oss.github.io/soot/

    Soot. https://soot-oss.github.io/soot/

  3. [3]

    https://developers.google

    Android Ready SE. https://developers.google. com/android/security/android-ready-se , 2021. Last accessed August 25th 2024

    2021

  4. [4]

    https://mobile-sec urity.gitbook.io/mobile-security-testing-g uide/general-mobile-app-testing-guide/0x0 4g-testing-cryptography, 2024

    Cryptography in Mobile Apps. https://mobile-sec urity.gitbook.io/mobile-security-testing-g uide/general-mobile-app-testing-guide/0x0 4g-testing-cryptography, 2024

    2024

  5. [5]

    Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design, October 2023

    2023

  6. [6]

    Androzoo: Collecting millions of android apps for the research community

    Kevin Allix, Tegawendé F Bissyandé, Jacques Klein, and Yves Le Traon. Androzoo: Collecting millions of android apps for the research community. In Pro- ceedings of the 13th international conference on mining software repositories, pages 468–471, 2016

    2016

  7. [7]

    AndroidKeyStoreBCWorkaround- Provider.java

    Android. AndroidKeyStoreBCWorkaround- Provider.java. https://android.googlesour ce.com/platform/frameworks/base/+/marshmal low-mr1-release/keystore/java/android/sec urity/keystore/AndroidKeyStoreBCWorkaround Provider.java

  8. [8]

    androidx.security.crypto

    Android. androidx.security.crypto. https://develo per.android.com/reference/androidx/securit y/crypto/package-summary

Show all 97 references
  1. [9]

    App Security Improvement Program

    Android. App Security Improvement Program. https: //developer.android.com/privacy-and-secur ity/googleplay-asi

  2. [10]

    Android. Cipher. https://developer.android.co m/reference/javax/crypto/Cipher

  3. [11]

    Hardware security module

    Android. Hardware security module. https://develo per.android.com/privacy-and-security/keys tore#HardwareSecurityModule

  4. [12]

    KeyGenParameterSpec

    Android. KeyGenParameterSpec. https://develope r.android.com/reference/android/security/k eystore/KeyGenParameterSpec. 14

  5. [13]

    KeyProtection

    Android. KeyProtection. https://developer.andr oid.com/reference/android/security/keystor e/KeyProtection

  6. [14]

    KeyStore

    Android. KeyStore. https://developer.android. com/reference/java/security/KeyStore

  7. [15]

    MasterKey

    Android. MasterKey. https://developer.android. com/reference/androidx/security/crypto/Mas terKey

  8. [16]

    Remediation for unsafe encryption mode us- age

    Android. Remediation for unsafe encryption mode us- age. https://support.google.com/faqs/answer /10046138

  9. [17]

    Security guidelines

    Android. Security guidelines. https://developer. android.com/privacy-and-security/security -tips

  10. [18]

    setAttestationChallenge

    Android. setAttestationChallenge. https://develope r.android.com/reference/android/security/k eystore/KeyGenParameterSpec.Builder#setAtt estationChallenge(byte[])

  11. [19]

    setRandomizedEncryptionRequired

    Android. setRandomizedEncryptionRequired. https: //developer.android.com/reference/android/ security/keystore/KeyGenParameterSpec.Buil der#setRandomizedEncryptionRequired(boolea n)

  12. [20]

    setUserAuthenticationRequired

    Android. setUserAuthenticationRequired. https://de veloper.android.com/reference/android/secu rity/keystore/KeyGenParameterSpec.Builder# setUserAuthenticationRequired(boolean)

  13. [21]

    SharedPreferences

    Android. SharedPreferences. https://developer.an droid.com/reference/android/content/Shared Preferences

  14. [22]

    Trusty TEE

    Android. Trusty TEE. https://source.android.c om/docs/security/features/trusty

  15. [23]

    Verify hardware-backed key pairs with Key Attestation

    Android. Verify hardware-backed key pairs with Key Attestation. https://developer.android.com/pr ivacy-and-security/security-key-attestati on

  16. [24]

    Android Keystore system

    Android. Android Keystore system. https://develo per.android.com/privacy-and-security/keys tore, 2024

    2024

  17. [25]

    KEY_ALGORITHM_3DES

    Android. KEY_ALGORITHM_3DES. https://deve loper.android.com/reference/android/securi ty/keystore/KeyProperties#KEY_ALGORITHM_3D ES, 2024

    2024

  18. [26]

    KeyProperties

    Android. KeyProperties. https://developer.andr oid.com/reference/android/security/keystor e/KeyProperties, 2024

    2024

  19. [27]

    Conscrypt

    Android Developers. Conscrypt. https://source.a ndroid.com/docs/core/ota/modular-system/co nscrypt

  20. [28]

    Apktool. Apktool. https://apktool.org/, 2024

    2024

  21. [29]

    appten- tive/android/sdk/encryption/resolvers/KeyResolver23.java

    Apptentive. appten- tive/android/sdk/encryption/resolvers/KeyResolver23.java. https://github.com/apptentive/apptentive-a ndroid/blob/91aebf3fa758edddd40924f06aecdf 1be4f12683/apptentive/src/main/java/com/ap ptentive/android/sdk/encryption/resolvers/ KeyResolver23.java#L70

  22. [30]

    HIPAA security rule & risk analysis

    American Medical Association. HIPAA security rule & risk analysis. https://www.ama-assn.org/practi ce-management/hipaa/hipaa-security-rule-r isk-analysis

  23. [31]

    amazon- aws/internal/keyvaluestore/KeyProvider23.java

    AWS-SDK-Android. amazon- aws/internal/keyvaluestore/KeyProvider23.java. https://github.com/aws-amplify/aws-sdk-and roid/blob/8fd69db5e22d13973ddebf6521f5663a e2275c4c/aws-android-sdk-core/src/main/jav a/com/amazonaws/internal/keyvaluestore/Key Provider23.java#L91

  24. [32]

    Broken Fingers: On the Usage of the Fingerprint API in Android

    Antonio Bianchi, Yanick Fratantonio, Aravind Machiry, Christopher Kruegel, Giovanni Vigna, Simon Pak Ho Chung, and Wenke Lee. Broken Fingers: On the Usage of the Fingerprint API in Android. In NDSS, 2018

    2018

  25. [33]

    A Large-Scale Study on the Prevalence and Usage of TEE-based Features on Android

    Davide Bove. A Large-Scale Study on the Prevalence and Usage of TEE-based Features on Android. arXiv preprint arXiv:2311.10511, 2023

    2023 arXiv

  26. [34]

    Generic attacks against cryptographic hardware through long-range deep learning

    Elie Bursztein, Luca Invernizzi, Karel Král, Daniel Moghimi, Jean-Michel Picod, and Marina Zhang. Generic attacks against cryptographic hardware through long-range deep learning. arXiv preprint arXiv:2306.07249, 2023

    2023 arXiv

  27. [35]

    SoK: Understanding the Prevailing Security Vulnerabilities in TrustZone-Assisted TEE Systems

    David Cerdeira, Nuno Santos, Pedro Fonseca, and San- dro Pinto. SoK: Understanding the Prevailing Security Vulnerabilities in TrustZone-Assisted TEE Systems. In 2020 IEEE Symposium on Security and Privacy (SP) , pages 1416–1432. IEEE, 2020

    2020

  28. [36]

    Sgxpectre: Steal- ing intel secrets from sgx enclaves via speculative exe- cution

    Guoxing Chen, Sanchuan Chen, Yuan Xiao, Yinqian Zhang, Zhiqiang Lin, and Ten H Lai. Sgxpectre: Steal- ing intel secrets from sgx enclaves via speculative exe- cution. In 2019 IEEE European Symposium on Security and Privacy (EuroS&P), pages 142–157. IEEE, 2019

    2019

  29. [37]

    Analysis of secure key storage solutions on android

    Tim Cooijmans, Joeri de Ruiter, and Erik Poll. Analysis of secure key storage solutions on android. In Proceed- ings of the 4th ACM Workshop on Security and Privacy in Smartphones & Mobile Devices , pages 11–20, 2014. 15

    2014

  30. [38]

    Jelly Bean

    Android Developers. Jelly Bean. https://develope r.android.com/about/versions/jelly-bean

  31. [39]

    setBlockModes

    Android Developers. setBlockModes. https://deve loper.android.com/reference/android/securi ty/keystore/KeyGenParameterSpec.Builder#se tBlockModes(java.lang.String[])

  32. [40]

    setBlockModes

    Android Developers. setBlockModes. https://deve loper.android.com/reference/android/securi ty/keystore/KeyGenParameterSpec.Builder#se tEncryptionPaddings(java.lang.String[])

  33. [41]

    Cryptography

    Android Developers. Cryptography. https://develo per.android.com/privacy-and-security/cryp tography, Last Accessed September 4 2024

    2024

  34. [42]

    An empirical study of crypto- graphic misuse in android applications

    Manuel Egele, David Brumley, Yanick Fratantonio, and Christopher Kruegel. An empirical study of crypto- graphic misuse in android applications. In Proceedings of the 2013 ACM SIGSAC conference on Computer & communications security, pages 73–84, 2013

    2013

  35. [43]

    Why Eve and Mallory love Android: An analysis of Android SSL (in)security

    Sascha Fahl, Marian Harbach, Thomas Muders, Lars Baumgärtner, Bernd Freisleben, and Matthew Smith. Why Eve and Mallory love Android: An analysis of Android SSL (in)security. In Proceedings of the 2012 ACM conference on Computer and communications se- curity, pages 50–61, 2012

    2012

  36. [44]

    Android permissions demys- tified

    Adrienne Porter Felt, Erika Chin, Steve Hanna, Dawn Song, and David Wagner. Android permissions demys- tified. In Proceedings of the 18th ACM conference on Computer and communications security, pages 627–638, 2011

    2011

  37. [45]

    Mind your keys? a security evaluation of java keystores

    Riccardo Focardi, Francesco Palmarini, Graham Steel, M Squarcina, Mauro Tempesta, et al. Mind your keys? a security evaluation of java keystores. In Proceedings of the Network and Distributed System Security Sympo- sium, pages 1–15. The Internet Society, 2018

    2018

  38. [46]

    Security and privacy failures in popular {2FA} apps

    Conor Gilsenan, Fuzail Shakir, Noura Alomar, and Serge Egelman. Security and privacy failures in popular {2FA} apps. In 32nd USENIX Security Symposium (USENIX Security 23), pages 2079–2096, 2023

    2023

  39. [47]

    GitHub Search Results

    GitHub. GitHub Search Results. https://github.com /search?q=%22setIsStrongBoxBacked%28false% 29%22+language%3AJava&type=code&l=Java&p=1

  40. [48]

    Lest we remember: cold-boot attacks on encryption keys

    J Alex Halderman, Seth D Schoen, Nadia Heninger, William Clarkson, William Paul, Joseph A Calandrino, Ariel J Feldman, Jacob Appelbaum, and Edward W Fel- ten. Lest we remember: cold-boot attacks on encryption keys. Communications of the ACM, 52(5):91–98, 2009

    2009

  41. [49]

    Announcing the Android Ready SE Alliance

    Sudhi Herle and Jason Wong. Announcing the Android Ready SE Alliance. https://security.googleb log.com/2021/03/announcing-android-ready-s e-alliance.html, 2021

    2021

  42. [50]

    Sloth: Key stretching and deni- able encryption using secure elements on smartphones

    Daniel Hugenroth, Alberto Sonnino, Sam Cutler, and Alastair R Beresford. Sloth: Key stretching and deni- able encryption using secure elements on smartphones. Cryptology ePrint Archive, 2023

    2023

  43. [51]

    SARA: Secure Android Remote Authorization

    Abdullah Imran, Habiba Farrukh, Muhammad Ibrahim, Z Berkay Celik, and Antonio Bianchi. SARA: Secure Android Remote Authorization. In 31st USENIX Se- curity Symposium (USENIX Security 22) , pages 1561– 1578, 2022

    2022

  44. [52]

    What Is Virtualization Security? https://www

    Intel. What Is Virtualization Security? https://www. intel.com/content/www/us/en/business/enter prise-computers/resources/virtualization-s ecurity.html

  45. [53]

    Using Cryptography to Store Credentials Safely

    Trevor Johns. Using Cryptography to Store Credentials Safely. https://android-developers.googlebl og.com/2013/02/using-cryptography-to-store -credentials.html

    2013

  46. [54]

    Unpacking privacy labels: A measure- ment and developer perspective on google’s data safety section

    Rishabh Khandelwal, Asmit Nayak, Paul Chung, and Kassem Fawaz. Unpacking privacy labels: A measure- ment and developer perspective on google’s data safety section. arXiv preprint arXiv:2306.08111, 2023

    2023 arXiv

  47. [55]

    Pixel 6: Setting a new standard for mobile security

    Dave Kleidermacher, Jesse Seed, Brandon Barbello, and Stephan Somogyi. Pixel 6: Setting a new standard for mobile security. https://security.googleblog.co m/2021/10/pixel-6-setting-new-standard-for -mobile.html, 2021

    2021

  48. [56]

    Are iphones really better for privacy? comparative study of ios and android apps

    Konrad Kollnig, Anastasia Shuba, Reuben Binns, Max Van Kleek, and Nigel Shadbolt. Are iphones really better for privacy? comparative study of ios and android apps. arXiv preprint arXiv:2109.13722, 2021

    2021 arXiv

  49. [57]

    Static analysis of android apps: A systematic literature review

    Li Li, Tegawendé F Bissyandé, Mike Papadakis, Siegfried Rasthofer, Alexandre Bartel, Damien Octeau, Jacques Klein, and Le Traon. Static analysis of android apps: A systematic literature review. Information and Software Technology, 88:67–95, 2017

    2017

  50. [58]

    Android custom permissions demystified: From privilege escalation to design shortcomings

    Rui Li, Wenrui Diao, Zhou Li, Jianqi Du, and Shanqing Guo. Android custom permissions demystified: From privilege escalation to design shortcomings. In 2021 IEEE Symposium on Security and Privacy (SP) , pages 70–86. IEEE, 2021

    2021

  51. [59]

    Libradar: Fast and accurate detection of third-party li- braries in android apps

    Ziang Ma, Haoyu Wang, Yao Guo, and Xiangqun Chen. Libradar: Fast and accurate detection of third-party li- braries in android apps. In Proceedings of the 38th international conference on software engineering com- panion, pages 653–656, 2016. 16

    2016

  52. [60]

    The persistence of memory: Forensic iden- tification and extraction of cryptographic keys

    Carsten Maartmann-Moe, Steffen E Thorkildsen, and André Årnes. The persistence of memory: Forensic iden- tification and extraction of cryptographic keys. digital investigation, 6:S132–S140, 2009

    2009

  53. [61]

    The Android Platform Security Model

    René Mayrhofer, Jeffrey Vander Stoep, Chad Brubaker, and Nick Kralevich. The Android Platform Security Model. ACM Transactions on Privacy and Security (TOPS), 24(3):1–35, 2021

    2021

  54. [62]

    RNSensitiveInfoModule.java

    mCodex. RNSensitiveInfoModule.java. https://gi thub.com/mCodex/react-native-sensitive-inf o/blob/495dd7f08c077f5744e56803e45f54787df 3dab3/android/src/main/java/dev/mcodex/RNS ensitiveInfoModule.java#L313

  55. [63]

    Strengthening Hardware Security with Galaxy S20’s Secure Processor

    Samsung Newsroom. Strengthening Hardware Security with Galaxy S20’s Secure Processor. https://news.s amsung.com/global/strengthening-hardware-s ecurity-with-galaxy-s20s-secure-processor , May 2020

    2020

  56. [64]

    A Survey of Published Attacks on Intel SGX

    Alexander Nilsson, Pegah Nikbakht Bideh, and Joakim Brorsson. A Survey of Published Attacks on Intel SGX. arXiv preprint arXiv:2006.13598, 2020

    2006 arXiv

  57. [65]

    Department of Health and Human Services

    U.S. Department of Health and Human Services. Guid- ance to render unsecured protected health information unusable, unreadable, or indecipherable to unauthorized individuals. https://www.hhs.gov/hipaa/for-pro fessionals/breach-notification/guidance/i ndex.html

  58. [66]

    Department of Health and Human Services

    U.S. Department of Health and Human Services. The security rule. https://www.hhs.gov/hipaa/for-p rofessionals/security/index.html

  59. [67]

    To pin or not to {Pin—Helping} app developers bullet proof their {TLS} connections

    Marten Oltrogge, Yasemin Acar, Sergej Dechand, Matthew Smith, and Sascha Fahl. To pin or not to {Pin—Helping} app developers bullet proof their {TLS} connections. In 24th USENIX Security Sympo- sium (USENIX Security 15) , pages 239–254, 2015

    2015

  60. [68]

    Demystifying ARM TrustZone: A Comprehensive Survey

    Sandro Pinto and Nuno Santos. Demystifying ARM TrustZone: A Comprehensive Survey. ACM computing surveys (CSUR), 51(6):1–36, 2019

    2019

  61. [69]

    Towards HTTPS everywhere on android: We are not there yet

    Andrea Possemato and Yanick Fratantonio. Towards HTTPS everywhere on android: We are not there yet. In 29th USENIX Security Symposium (USENIX Security 20), pages 343–360, 2020

    2020

  62. [70]

    50 ways to leak your data: An exploration of apps’ circumvention of the android permissions system

    Joel Reardon, Álvaro Feal, Primal Wijesekera, Amit Elazari Bar On, Narseo Vallina-Rodriguez, and Serge Egelman. 50 ways to leak your data: An exploration of apps’ circumvention of the android permissions system. In 28th USENIX security symposium (USENIX security 19), pages 603...

    2019

  63. [71]

    Breaking into the keystore: A practical forgery attack against android key- store

    Mohamed Sabt and Jacques Traoré. Breaking into the keystore: A practical forgery attack against android key- store. In Computer Security–ESORICS 2016: 21st Eu- ropean Symposium on Research in Computer Security, Heraklion, Greece, September 26-30, 2016, Proceedings, Part II 21,...

    2016

  64. [72]

    Commit 4b074b7: Refactoring StrongBox code

    Salesforce. Commit 4b074b7: Refactoring StrongBox code. https://github.com/forcedotcom/Salesfo rceMobileSDK-Android/commit/4b074b7c744f44 129486029a7df6481d0d7c3eb2

  65. [73]

    KeyStoreWrapper.java

    Salesforce. KeyStoreWrapper.java. https://github .com/forcedotcom/SalesforceMobileSDK-Andro id/blob/1a11e225b20968cc88ed08cf3304ede28b 5701af/libs/SalesforceSDK/src/com/salesfor ce/androidsdk/security/KeyStoreWrapper.jav a#L247

  66. [74]

    Trust Dies in Darkness: Shedding Light on Samsung’s Trust- Zone Keymaster Design

    Alon Shakevsky, Eyal Ronen, and Avishai Wool. Trust Dies in Darkness: Shedding Light on Samsung’s Trust- Zone Keymaster Design. In 31st USENIX Security Sym- posium (USENIX Security 22) , pages 251–268, 2022

    2022

  67. [75]

    Provide information for Google Play’s Data safety section

    Google Play Store. Provide information for Google Play’s Data safety section. https://support.goog le.com/googleplay/android-developer/answer/ 10787469?hl=en

  68. [76]

    Signal Private Messenger

    Google Play Store. Signal Private Messenger. https: //play.google.com/store/apps/datasafety?id =org.thoughtcrime.securesms&hl=en&gl=US

  69. [77]

    CleanOS: Limiting Mobile Data Exposure with Idle Eviction

    Yang Tang, Phillip Ames, Sravan Bhamidipati, Ashish Bijlani, Roxana Geambasu, and Nikhil Sarda. CleanOS: Limiting Mobile Data Exposure with Idle Eviction. In 10th USENIX Symposium on Operating Systems Design and Implementation (OSDI 12) , pages 77–91, 2012

    2012

  70. [78]

    Code of practice for app store operators and app developers

    United Kingdom Department for Science, Innovation and Technology. Code of practice for app store operators and app developers. https://www.gov.uk/governm ent/publications/code-of-practice-for-app -store-operators-and-app-developers

  71. [79]

    Foreshadow: Extracting the keys to the Intel SGX king- dom with transient Out-Of-Order execution

    Jo Van Bulck, Marina Minkin, Ofir Weisse, Daniel Genkin, Baris Kasikci, Frank Piessens, Mark Silberstein, Thomas F Wenisch, Yuval Yarom, and Raoul Strackx. Foreshadow: Extracting the keys to the Intel SGX king- dom with transient Out-Of-Order execution. In 27th USENIX Security...

    2018

  72. [80]

    Cacheout: Leaking data on intel cpus via cache evictions

    Stephan Van Schaik, Marina Minkin, Andrew Kwong, Daniel Genkin, and Yuval Yarom. Cacheout: Leaking data on intel cpus via cache evictions. In 2021 IEEE Symposium on Security and Privacy (SP) , pages 339–

    2021

  73. [81]

    Cryptography Changes in Android P

    Adam Vartanian. Cryptography Changes in Android P. https://android-developers.googleblog.com /2018/03/cryptography-changes-in-android-p .html, March 8 2018

    2018

  74. [82]

    Exploring permission- induced risk in android applications for malicious ap- plication detection

    Wei Wang, Xing Wang, Dawei Feng, Jiqiang Liu, Zhen Han, and Xiangliang Zhang. Exploring permission- induced risk in android applications for malicious ap- plication detection. IEEE Transactions on Information F orensics and Security, 9(11):1869–1882, 2014

    2014

  75. [83]

    Program slicing

    Mark Weiser. Program slicing. IEEE Transactions on software engineering, (4):352–357, 1984

    1984

  76. [84]

    When program analysis meets byte- code search: Targeted and efficient inter-procedural anal- ysis of modern android apps in backdroid

    Daoyuan Wu, Debin Gao, Robert H Deng, and Chang Rocky KC. When program analysis meets byte- code search: Targeted and efficient inter-procedural anal- ysis of modern android apps in backdroid. In 2021 51st Annual IEEE/IFIP International Conference on De- pendable Systems and N...

    2021

  77. [85]

    Titan M makes Pixel 3 our most secure phone yet

    Xiaowen Xin. Titan M makes Pixel 3 our most secure phone yet. https://blog.google/products/pixel /titan-m-makes-pixel-3-our-most-secure-pho ne-yet/, 2018

    2018

  78. [86]

    evolving target, and so HIPAA’s security require- ments are not linked to specific technologies or products

    Wu Zhou, Yajin Zhou, Xuxian Jiang, and Peng Ning. Detecting repackaged smartphone applications in third- party android marketplaces. In Proceedings of the sec- ond ACM conference on Data and Application Security and Privacy, pages 317–326, 2012. 18 A Appendix A.1 Trusted Hardw...

    2012

  79. [87]

    Programmer/Developer b

    Which of the following best describes your role? a. Programmer/Developer b. Software Tester/Quality Assurance c. Project Manager d. Software Design/Architecture e. Administration (Non-Technical) f. Other

  80. [88]

    Approximately how many people (including project man- agers, developers, testers, etc.) are involved in developing the app? 20 a. 1 b. 2 - 5 c. 6 - 20 d. 21 - 50 e. 50+

  81. [89]

    How many years of experience do you have working with Android app development? a. None b. Less than 1 year c. 1 - 5 years d. 5 - 10 years e. 10 years or more

  82. [90]

    On a five-point scale, how much do you agree with the following statement: Our development team prioritizes security as part of the development process. a. Strongly agree b. Agree c. Neither agree nor disagree d. Disagree e. Strongly disagree

  83. [91]

    On a five-point scale, how much do you agree with the following statement: Our app collects and processes potentially sensitive user data (e.g., name, other demo- graphic information, health data, financial data, etc.). a. Strongly agree b. Agree c. Neither agree nor disagree ...

  84. [92]

    On a five-point scale, how much do you agree with the following statement: I am familiar with the concept of trusted hardware (e.g., Intel SGX and Arm TrustZone). a. Strongly agree b. Agree c. Neither agree nor disagree d. Disagree e. Strongly disagree

  85. [93]

    On a five-point scale, how much do you agree with the following statement: I am familiar with the Android Key- store trusted hardware API, commonly used in Android development for credential storage (e.g., storing crypto- graphic keys). a. Strongly agree b. Agree c. Neither ag...

  86. [94]

    ] Based on our static analysis as of November 2023, your app was recorded as not using the Android Keystore API

    [If app did not reference Android Keystore API at all. ] Based on our static analysis as of November 2023, your app was recorded as not using the Android Keystore API. Which of the following reasons best describe the main considerations behind this decision? Please select all ...

    2023

  87. [95]

    [If app did not reference Android Keystore API at all. ] To the best of your knowledge, what libraries, if any, does your app use within Android for credential storage (either user login credentials or developer credentials such as cryptographic keys)? [Open text]

  88. [96]

    AndroidKeyStore

    [If app was recorded as disabling StrongBox. ] A secure element (called the StrongBox Keymaster in Android) is a more advanced form of trusted hardware. Based on our static analysis of your app from November 2023, we determined your app used the Android Keystore API but disabl...

    2023

  89. [256]

    These measurements were taken from the TEE and SE in Google’s Pixel 8 device. 24

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.