13

What would be the most appropriate way to store private keys for barcode signing in the Android app? Probably most experts here would say - just don't do it, cause it's insecure...

But I would like to understand the level of "insecurity" and risks to proposed solutions.

P.S. Commodity Smartphones to assume.

P.S. we can exchange keys not too often. App Backend API can be designed as needed. But permanent internet connection and variants of signing on the server-side is not possible.

Soufiane Tahiri
  • 2,667
  • 12
  • 27
aholbreich
  • 239
  • 2
  • 8
  • 3
    Does the private key belong to the user (one per user who will want to protect it) or to you (one key, shared by all users of the app some of whom will want to steal it) – Richard Tingle Dec 21 '20 at 22:27
  • Can you clarify whether the key is indeed specific to each phone (generated locally on the phone, and never leaves it), or is a key that is common to all devices, sent by a server? The latter would most probably be a very bad idea. – jcaron Dec 22 '20 at 10:58
  • @RichardTingle unfortunately it has to be shared key... – aholbreich Dec 23 '20 at 15:38
  • @jcaron no the key need to be stored to the keystore provider let's say when the app starts for the first time. – aholbreich Dec 23 '20 at 15:39
  • 1
    Distributing a private key seems like a very bad idea. Are you sure you can’t do otherwise? For instance generate a private key and CSR locally, send the CSR to a server to have it signed with a root certificate, get the certificate back? Intercepting data on a device you control is often trivial. Of course embedding a certificate in a QR code may be a challenge. – jcaron Dec 23 '20 at 16:24
  • @aholbreich The phone's loyalty is to its user, not to you. That is basically a terrible idea. You can probably make it "a pain" to get hold of, but making it impossible (especially if money is involved) will be impossible – Richard Tingle Dec 23 '20 at 16:29
  • 1
    If you are sharing the private key then no need to use keystore as someone can intercept and leak it and then you have to revoke it from every device. Instead, generate unique private key in keystore for every user and certify their public key using your self signed certificate. – defalt Dec 23 '20 at 19:20
  • @defalt let's say https is used and we are the builders of the app. So it can be only intercepted buy "debugging the app", seems not very easy.. How ever not impossible. I understand my self that this is shitty requirenment, but there is a possibility to exchange that key kinde once a week and it's protects barcodes from being copied. So also risk if it's stollen is manageble – aholbreich Dec 24 '20 at 19:50
  • @RichardTingle "making it impossible" in not required and as far i know never the case in security it's allways about the good enough level of security and understood surface of the risk. I would like to understand how to secure that model given and how big is the"pain" for attacker. Of course shared key is bad idea. But i cannot avoid it in a current state of my discussion and i need holistic understanding of the risks and mitigations – aholbreich Dec 24 '20 at 19:56
  • @aholbreich A user can intercept https by MITM. Someone will leak your private key, that's not really hard. What is the relation of private key with bar codes? You should add to your question why do you want to send private key to your users. – defalt Dec 25 '20 at 09:39

1 Answers1

31

All android 7+ devices are equipped with Trusted Execution Environment (TEE) as a mandatory requirement for Google apps licensing. It's a hardware backed keystore which provides isolated storage and data processing for cryptographic blobs. In Qualcomm Snapdragon and Samsung Exynos SoCs, TEE is based on ARM Trustzone. Some devices like in Pixel and iPhone have their own discrete TEE (Google's Titan M and Apple's T2 chip) which is called strongbox. Discrete TEEs are more isolated than ARM Trustzone and independent of the SoC used.

You can use android keystore provider APIs to

Every key stored within the keystore can have the following parameters set:

  • alias - used to identify the key.
  • key size (API 23).
  • purpose – encrypt/decrypt (API 23).
  • encryption mode, algorithm and padding (API 23).
  • should the key be authenticated with the keystore before usage? (API 23).
  • the time duration for which the key can be used after a successful authentication (API 23).
  • should a key be invalidated on new fingerprint enrolment? (API 24)
  • should a keystore require the screen to be unlocked before performing cryptographic operations? (API 28)
  • should a key be protected by a StrongBox hardware security module? (API 28)

You can also use it to encrypt authentication tokens for login, store passwords and encrypt the key which encrypts your app's large sensitive data.

"should a key be protected by a StrongBox hardware security module? (API 28)" seem to be very important in terms of overal security level.

For android 9+, apps can set preference to store keys in strongbox by calling setIsStrongBoxBacked(true). If it throws StrongBoxUnavailableException then apps should fallback to hardware backed keystore. Strongbox is immune from critical side channel vulnerabilities in SoC's CPU which may affect hardware backed keystore. The security of hardware backed keystore falls on the chipmaker of SoC: Gaping 'hole' in Qualcomm’s Secure World mobile vault leaked sensitive data.

Hardware Security Best Practices recommend StrongBox Keymaster. The module contains the following:

  • Its own CPU
  • Secure storage
  • A true random-number generator.
  • Additional mechanisms to resist package tampering and unauthorized sideloading of apps.

Android keystore system

How Secure is your Android Keystore Authentication? (Outdated, published before android 10 release)

defalt
  • 6,231
  • 2
  • 22
  • 37
  • Thank you very much. So if if i got you corect Hardware support for TEE is mandatory for all Android since (Let say API level 26). This is good news! Also the use of Android Keystore is what should be used. Thanks! – aholbreich Dec 21 '20 at 20:28
  • And i guess this would be IOS way? https://developer.apple.com/documentation/security/certificate_key_and_trust_services/keys/storing_keys_in_the_keychain ? – aholbreich Dec 21 '20 at 20:32
  • 1
    @aholbreich yes, or https://developer.apple.com/documentation/security/certificate_key_and_trust_services/keys/storing_keys_in_the_secure_enclave to make sure that absolutely no software can read the private key—storing in the keychain means that the key is encrypted, but you can still decrypt and access it in software – lights0123 Dec 21 '20 at 21:05
  • @default the last point "should a key be protected by a StrongBox hardware security module? (API 28)" seem to be very important in terms of overal security level. Do you agree? Can you give your opinion on that? – aholbreich Dec 23 '20 at 13:46