Now that lets encrypt.org launched public beta, they are only giving away https certificates that last 90 days. Thats for security reasons and they advice the developers to renew their https certificates after 60 days and the best way to do that is to automate that.
However, I am looking to be adding HTTPS to my mobile app. How would you automatically renew a certificate every 90 days? Wouldn't that require a new app build and an update every 60 days to the app/play store?
I would love to see this question answered because I realize HTTPS is much more secure.
Thanks in advance!
Didn't have enough space in comment so I'll post it here
I'm not really sure how encrypt.org is working, so as long as you don't provide some more information about their certificate system I cant help you.
However X509Certificate itself, contains mechanism to certificate renewal, so if it's implemented correctly on ther side you can actually implement it in your app:
According to wiki:
To allow for graceful transition from the old signing key pair to the
new signing key pair, the CA should issue a certificate that contains
the old public key signed by the new private signing key and a
certificate that contains the new public key signed by the old private
signing key. Both of these certificates are self-issued, but neither
is self-signed. Note that these are in addition to the two self-signed
certificates (one old, one new).
Since both cert1 and cert3 contain the same public key (the old one),
there are two valid certificate chains for cert5: "cert5 → cert1" and
"cert5 → cert3 → cert2", and analogously for cert6. This allows that
old user certificates (such as cert5) and new certificates (such as
cert6) can be trusted indifferently by a party having either the new
root CA certificate or the old one as trust anchor during the
transition to the new CA keys
However this still require for you to have CA cert, (which probably you don't).
On the other hand I don't know why you need your own certificate (and why from encrypt.org)? And are you sure, that their certs are not validating in Android default TrustStore? And eventually Isnt's it better to create self signed certificate for you server and use it in app so you can have full control?
Related
I would like to get the list of all revoked certificates list downloaded on an Android device? I know that this class allows you to check if a certificate is revoked or not, but I want to get the whole list of revoked certificates. Is it possible? Does Android store such a list or it uses OCSP to check the certificates?
It would appear that Android does not store a certificate revocation list (or at least if it does then it doesn't use it). There's a reddit thread from a few years ago that brings this up and discusses the pros/cons of it, but the essence of it is that if you go to https://revoked.grc.com/ (which should throw an error if your browser checks for revoked certificates) on mobile Chrome, you'll be notified that your browser doesn't check for revoked certificates.
From the page above (revoked.grc.com, which you shouldn't be able to see unless you're using a browser without a CRL):
The mobile Android platform currently offers no certificate revocation checking of its own, so Android apps (including all users of Google's Chrome browser) are vulnerable to malicious certificate abuse. The only way to use Android securely today is with Firefox, which brings along its own certificate security.
A couple more sources I found (again a few years old, but they still seem to be relevant and accurately describe the current situation):
An issue on the OkHttp (an Android http client) github discussing whether to add certificate revocation checks, where they decide not to
The CommonsBlog, discussing the lack of certificate revocation checks on Android
A Chromium issue about the lack of a CRL, where one of the developers states that it won't be added and presents the justification:
Marking this WontFix for two reasons:
1) Revocation checking is the responsibility of Android and the related SSL APIs. Android itself does not and has never performed revocation checking [...]
2) Revocation checking generally doesn't work (as a security feature), and especially for mobile, greatly affects performance (negatively) and privacy (negatively)
I have a signed APK. What I want to do is, access the private key and sign (encrypt) some message using it.
Is it possible to access this private key through my code in run time?
Any sample code to do the same?
Never, ever place you Keyring for signing playstore apks in your app.
Because everyone can extract the keyring from your app and use it.
Best practice is to create a new keypair inside of your app on first start. So every installation of your app has its own keypair. Otherwise your users could encrypt data from other installations, too.
More secure is it, to ask the user for password. Which you can then use to secure the keystore for the newly generated keypair. This way also a stolen keystore of your app is harder to crack, because it has a password which only your user knows.
Very complex scenarios uses a key exchange system, where your user keys are generated and managed by a server application. Transport can be done with AES encryption etc.
Here is good presentation about basic cryptography on android from a good fried al sutton ;) http://de.slideshare.net/AlSutton/2014-droidcon-nlandroidcryptography?ref=https://www.linkedin.com/in/alsutton
I'm currently looking at the possibilities of storing/using secrets keys in an Android application. I've found Nikolay Elenkov's blog very helpful regarding this topic and I've learnt a lot of things about the Android keystore and some hardware-based implementations.
Still I've got some questions about security and user experience aspects.
Software keystore
For what I understood, in this configuration a masterkey is derived (using PBKDF2) from a user password (plus a salt to prevent rainbow tables attacks) and used to encrypt secrets. As far as I know, the password is the one used for the lock screen.
On a non-rooted phone, only the user 'keystore' is able to read/write the encrypted files and whenever an application want to access a file, it has to call the keystore daemon which checks if its UID is authorized to access this file (the authorizations are stored in a sqlite database).
But there are still some details I couldn't figure out :
Does using the keystore enforce the use of a password-protected lock screen ?
Does the user have to input his/her password every time an access to the encrypted keys is required ?
Given it's a software-only mechanism, I think a secret key will always end up decrypted in RAM whenever it's used for cryptographic operations, right ?
Hardware-based keystore
As for the hardware-based implementation, it seems that SoC manufacturers provide solutions compliant to [Global Platform TEE][2] (Trusted Execution Environment) with embedded Trusted Applications and APIs that enable Google to provide an hardware-backed implementation of its keystore. It's thus possible to store secret keys in the TEE, ask for RSA key pair creation inside the TEE and sign or check data using secret keys stored inside the TEE. This way, one can use secret keys for basic cryptographic operations without them ever leaving the TEE.
If I got it right, access control to those keys is provided by the Google keystore daemon using the same mechanism as in the software implementation. The only difference is that references to the keys stored in the TEE are used instead of the encrypted keys themselves.
If everything stated before is correct, I guess it would be possible on a rooted phone to modify the permissions database so that an application with an arbitrary UID can have data signed with any key stored in the TEE. Am I right ?
Thanks for your time!
Does using the keystore enforce the use of a password-protected lock
screen ?
Yes, user is forced to use lock screen, protected with password, pin, or pattern.
Does the user have to input his/her password every time an access to
the encrypted keys is required ?
No, once the device is unloked, KeyStore becomes unlocked as well and there's no need to enter additional passwords. However, application should check if the KeyStore is unlocked, because user could disable the lock screen protection in Settings. Once key locked is disabled, KeyStore becomes uninitialized and must be unlocked again.Several times I faced a strange behavior, when the KeyStore was locked, but I didn't have lock screen protection set up. I was prompted to enter a password or pin code to enter the KeyStore. However, it was not possible, since I didn't have any passwords. I assume some system apps were locking the KeyStore. I had to reset it to re-initialize.
Given it's a software-only mechanism, I think a secret key will
always end up decrypted in RAM whenever it's used for cryptographic
operations, right ?
Yes, all keys retrieved from the KeyStore will reside in RAM until garbage-collected or deinitialized. But you can obtain the key each time you need it, not keeping it in some long-living variable.
Unfortunately, I'm not familiar with HW-backed KeyStore. Cannot say anything about it.
Your analysis of the TEE-based hardware-backed scenario is correct. The private key bits generated in the TEE (which isn't necessarily compliant with the Global Platform specs) never leave the TEE and private key operations are performed inside it.
You're also correct that the handles to the TEE-based keys are stored in Keystore, so it's possible for root to access and use any of them, or to move them around so any app can use them.
I have a code cert that is going to expire soon and have recently acquired a new cert from the same provider. I need to transition my android app from the older cert to the new cert. However because the certs are different android requires a full uninstall (deleting app data which I would prefer to avoid).
Due to my client specification I'm unable to use a self signed cert.
Is there a way to transfer without losing the local app data?
I am aware at adt -migrate exists but when I use it I get the following error
Migration certificate can only be applied to desktop native installers with native extensions. Target: apk
Extending certificate validity should be your first choice.
Let your CA extend your certificate instead of purchasing a new one.
All certificate information will be preserved and your clients won't need to uninstall the app at all.
Is there a way to transfer without losing the local app data?
No, other than by backing up the data, uninstalling the old app, installing the new app, and restoring the data. If your app does not already have a full backup mechanism, then you are in a world of hurt, if you cannot get the CA to extend the certificate (per flx's answer).
Due to my client specification I'm unable to use a self signed cert.
That does not change the fact that you need a signing key that will live long enough for the lifetime of the app. And, since certificate authorities do go out of business, so your client should buy a suitably-long certificate now, rather than assuming that an extension can be obtained at any point in the future.
Or, your client should come to its senses and use a self-signed certificate.
Our developers will be using both PCs and Macs to create Android apps.
When a KeyStore is generated on a Mac, how do we move it to a PC so that the same app can be edited/built/signed by both Macs and PCs?
I imagine that you can just use a flash drive, no? I'm going to assume you create the keystore using java's keytool, which is cross platform as far as I know. So once you've created your keystore, you just copy it from one computer to the other. When you're ready to sign your app, just navigate to the flashdrive or where ever you copied the keystore from the flashdrive.
Copy/Paste through network or usb memory key ... Keys and Key folder are just folder ...
But your question raise another issue.
Why keys have to be shared accross developpers..
In android development and keys you have 2 roles
1) Publisher
2) Developer/Workers
Publisher will sign final application ready for release to final user/customer
It use development APK files that are unsigned then use publisher key with long validity to sign the package.
Publisher may have several keys but more for business reason.
Developer/Workers will use automatic eclipse generated keys with short validity(1 years) just to be able to test/debug the app on device, these keys should/must not be used for release purposes.
Each worker may have it own keys and can change it when he want
Or each worker should have the ability to sign any final APK they produce, but it can be a security risk.. because any worker may use this final release key (publisher key) anywhere and any application from your command or any other uncontrolled other application ...