I am devlopeing some application wherein i have to store the keys in secure manner and do some cryptographic operation on it.
You can't use it directly. You need to develop (or buy) a trusted application and then have your app talk to it through the secure API it provides. This may or may not be usable on all devices, so unless you control the device and/or firmware, it is not guaranteed that you can use it all.
The system keystore on some devices already uses hardware-backed storage for RSA keys (Nexus 7 for example), but it is not standard and some devices only have a software implementation.
If you are targeting the Western World, where Samsung is by far the dominant player, you can make use of their API for Trust Zone:
https://developer.samsung.com/teegris
2019 update:
You still can't use it directly. You should use Google APIs for Android security, some of which may or may not use TrustZone. It is a security tech aimed at device and OS manufacturers, not app developers.
You can read more on the topic here:
ARM TrustZone on Android
Related
I am new to Trusty TEE OS. Is there any way to find out if an Android Device uses such an OS without rooting the device ?
AFAIK there, DRM (Digital Rights Management) is the most widely used application of Trusty OS. Some examples for DRM frameworks are Widevine/PlayReady/ClearKey.
Does it mean that if any of these frameworks are present in the Android device, it is safe to assume that there is an underlying Trusty TEE OS in use ?
Thanks
Both Widevine and PlayReady support multiple security levels - the most secure level for each is tied to the TEE but lower levels are typically not.
Hence, a simple check for DRM will not tell you if the device has TEE.
On older versions of Widevine you would determine the security level fairly easily which would give you a guide - I don't think you could take it as absolute:
https://support.google.com/widevine/answer/6072714?hl=en
The same approach does not work for the current version of Widevine.
I don't believe there is a simple 'TEE supported' API - there are some tricks to try to determine - see the discussion in this answer: https://stackoverflow.com/a/64422042/334402
I am actually studying mobile security and I am focusing on hardware protection, so, I wonder, if is it possible an app can access to mobile hardware resources, and dominate on them, so, no access to any hardware resource by other apps only if permission was given by the dominating app? (as a second level of hardware security).
At least for camera, I'm aware of using Android Device Administration with a policy to Disable camera: https://developer.android.com/guide/topics/admin/device-admin.html Typically using a Mobile Device Manager would be used on authorized devices by corporations/governments in sensitive locations. Other restrictions are probably available as the Device Manager software would be accessing Device Manufacturer APIs.
Another method to achieve your goal of 'wrapping' the hardware is to not let the Android app actually talk to Android framework methods. Basically the client app would be running a virtual container with the container mocking Android framework APIs.
See: How to execute APKs on a customized data directory?
And Commonsware's blog post for additional details: https://commonsware.com/blog/2017/01/17/droidception.html
This would allow you to add additional restrictions at the cost of having all of the apps go through the virtual container. Enforcing the user to always use the container isn't really possible unless you are building a custom ROM or perhaps rooted.
And if you are doing a custom ROM or rooted you might as well add any additional hardware restrictions through those methods.
I am interested in developing trusted applications using TEE.
I have a Nexus 5 that has Android 5.1.1 (LMY48M) on it. I want to create a very basic hello world app to understand TEE logic running on a real device. Nexus 5 supports QSEE (Qualcomm Secure Execution Environment) but I couldn't found any documentation about how to include QSEE communication libraries on a regular Android application.
In an adb root shell,
cat /d/tzdbg/log
cat /d/tzdbg/qsee_log
commands displays empty result.
Is there any one who had try to develop an application like this before?
Any help will be appreciated.
First, for TEE one APP contains two parts, TA(Trust APP, runs in TEE) and CA(Client APP, runs in REE).
QSEE has implement GlobalPlatform(GP) API(not all the GP API), so you should read the GP API white paper and use them to develop CA and TA.
But, you cannot install CA and TA by yourself, because CA and TA should dispatch by TSM.
I am afraid there is currently no straightforward way to do this.
If you want to learn to use a TEE right now, I would suggest that you use a VM running OP-TEE or Open-TEE (as I read you have in your response to #Cobain above), as the GlobalPlatform APIs are widely supported on different devices.
Unfortunately you essentially need to be a device OEM or an established software supplier to do what you want right now, but that is something which may get easier in the future - this is the downside of working with a relatively new technology.
A TSM is a Trusted Services Manager, which is a technology used by some GlobalPlatform TEE implementations to load a TA on a TEE. It is not applicable to QSEE.
Trusty is a Google proprietary TEE, and I'm not aware of any available device which exposes this to users. QSEE is the Qualcomm TEE. Unfortunately I am not able to comment on exactly what it may or may not do.
I wanted to do the same but ended up using sequiturlabs framework for developing Trusted applications on OP-TEE on Raspberry Pi 3. It enabled a hello world TA on a hardware but I am still looking for something that would allow TA development for a secure OS with Android as REE.
https://www.sequiturlabs.com/media_portfolio/sequitur-labs-collaborates-with-linaro-to-lower-barriers-to-iot-security-education-for-raspberry-pi-maker-community/
If you found this: http://source.android.com/security/trusty/index.html
I believe this is the relevant section:
Currently all Trusty applications are developed by a single party and
packaged with the Trusty kernel image. The entire image is signed and
verified by the bootloader during boot. Third-party application
development is not supported in this version of Trusty.
So unless you are creating your own Custom ROM, I don't think you can do anything with Trusty.
In newer versions of Android (I guess since 4.2) there is an option called "hardware-backed" and "software only".
As Google supposes:
Android also now supports hardware-backed storage for your KeyChain
credentials, providing more security by making the keys unavailable
for extraction. That is, once keys are in a hardware-backed key store
(Secure Element, TPM, or TrustZone), they can be used for
cryptographic operations but the private key material cannot be
exported. Even the OS kernel cannot access this key material. While
not all Android-powered devices support storage on hardware, you can
check at runtime if hardware-backed storage is available
ephasis is mine
What I can't understand is: the GalaxyNexus as well as the Nexus 7 have an NFC-Chip with Secure Element, but its storage-type is "software only". The Nexus 4 has an NFC Secure Element, and is "hardware-backed", while the Nexus 7 (2013) and the Nexus 5 don't have a NFC-Secure-Element but are still "hardware backed". I can check this manually inside the Settings-App, but Is there a way to check this inside my App?
As CommonsWare mentioned, I should provide links:
First info that Secure Element is related to the storage-type is mentioned here:
another useful source of info was Nelenkov's blog
Did you actually read the blog? :) Currently 'hardware-backed' means TrustZone (TEE)-backed for all released devices. Using the embedded secure element for this is rather tricky for political reasons, and no current Android devices have a TMP. This leaves TrustZone-based TEE implementations. BTW, Galaxy Nexus also has one, but the driver is disabled in release builds. It has been there since 4.1.
To check from an app use KeyChain.isBoundKeyAlgorithm(String algorithm).
I am looking forward to develop a secure mobile application.
I find my needs getting full-filled with PGP.
Since pgp includes full data encryption (symmetric-key).
So, is PGP a viable solution for mobile applications? (Computation power wise)
I plan to secure only my API responses (String only) with PGP.
Can a mobile processor stand PGP while providing seamless communication?
Or will it be an over-kill for a mobile device to use PGP?
My platforms of development (If that matters):
iPhone
Android
Under PGP I will use: [Since, PGP uses an Asym and a Sym encryption]
RSA [Asym]
Blowfish [Sym]
It should be noted that mobile devices perform asymmetric cryptography negotiations on a regular basis. After all that is the power behind SSL. Maybe at some point 20 years ago resource usage with cryptography was a concern, but today they are very light weight functions by comparison. Blowfish is very old, it was replaced by two-fish about a decade ago and three-fish is aviable but hasn't been finalized so it shouldn't be used. Use AES-256, perferably with GCM mode, because it is more diffcult to botch that implamentation. You should read up on modes of operation because even a very strong cipher can be very weak if you use the wrong mode (such as ECB).
In any case you should be performing useability testing on your own. Really this question is a symptom of a much more serious problem, and that is software testing and useability testing in general. If you tested the speed of this function you would know it wasn't a problem. If you are not testing your applications you will be producing very low quality software.
Yes mobile hardware can handle it or else we couldn't use SSL in the web browser if it couldn't. SSL uses asymmetric encryption just like PGP.