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.
Related
My goal is to write an application for Android (>= 9.0) which basically offers a device-owner-style control like Google's "Android Device Policy".
The following criteria have to be met:
Zero dependency on Google servers or any other 3rd party infrastructure like existing EMM solutions (MobileIron et cetera)
The user should not be able to remove or disable the app
Provisioning methods: QR-Code, NFC, URL, ADB, actually any "local" way ...
Has to work with stock androids on regular consumer devices
In short: I'd like to write an unremovable device manager (including a web-based management UI), put it on a device I own, give that device to someone else, and being able to fully control the device remotely.
Is such a project even possible with the current situation of Android?
No.
Has to work with stock androids on regular consumer devices
Mostly, this is your biggest hurdle to overcome.
What you are asking for is the description of a very powerful MalWare. An app that ca run on any version of Android, that can't be uninstalled, but can do what it wants to "fully control the device".
If you move away from the idea of "stock android on regular consumer device", towards a suite of devices you have some say in distributing:
Here is a list of Google Partners who offer an EMM solution: https://androidenterprisepartners.withgoogle.com/emm/
Here is Samsungs effort at device control:
https://www.samsungknox.com/en
Here is Googles device management:
https://developers.google.com/android/management
You could write your own ROM of Android and be able to control the things you want, but that would require .. building a ROM aka a whole phone OS forked from AOSP.
The user should not be able to remove or disable the app
This is only possible if you have a system app.
Or something extreme (which with any extreme, is always possible to have problems), like having two apps, and they monitor each other for uninstall, and programatically reinstall (vs 1 app that can't do much when it is being uninstalled).
I've always liked cheap smartphones ($ 50) because with little money I can have a powerful system with lots of sensors and things like that. So I wondered if it was possible to use the hardware without using the very limited android APIs, programming it at a low level then, of course with the root. In particular I wanted to see how the LTE module worked and experiment with this having full control, the Android API does not allow it to do much.
UPDATE: I'm using something called libhybris, a wrapper that permit the use of android driver blobs in Linux.
The first layer of software for the phone is the bootloader. It tells the processor what partition to load into memory for executing the kernel. This is the level that is usually blocked by manufacturers because of greedy corporate reasons that are beyond the scope of this site.
The second layer of the phone is the linux kernel. Rooting is the process of gaining root user access to this layer. Root is the main administrator user account that has permission to do anything to the device. Accessing this layer is what most people refer to rooting. A large portion of the kernel is written in C, with other parts in c++. What happens at this level is where all the magic is. For most phone this is where the code for the modem resides. Talking to this can usually be done via at commands of serial. Sensors are also programmed at this level and communicate via drivers. Root access is not normally needed to read sensor data, its just a case of permissions usually.
The next level is the android operating system, the java instance runs on top of that, which in turn executes the android operating system. This is the portion that most users will see and is primarily written in java. In reality you can run any kind of user interface at this level.
A very brief view of android apps.
The android api provides a way for java developers to write "apps" that communicate with the kernel and access different parts of the phone's hardware. These apps can also be written using c++. Only until recently has google integrated c++ into android studio, but the most common and still most effective method of doing so is using the QT framework.
It's a bit problematic.
Hardware manufacturers do that actually.
Take into account that Android is Linux much like other distributions.
The manufacturers develop hardware and then compile a version Android that sits on top of it. Each Android compilation is specifically tailored to the hardware and equipped with drivers that enable the main OS access to the different hardware capabilities.
For example, some tables will tweak the Android OS to not support cellular communication because they decided to cut costs and deliver the tablet without a cellular module.
From here you have 2 options:
To hack a specific hardware and understand how the OS communicates with the hardware.
Find hardware manufacturers that release some/all of their Android OS code. This is a much simpler way as you can both learn and extend the Android OS for that specific device.
An example of the 2nd way is Sony who has AOSP that allows low-level access to some of the Sony devices.
Also, there is always the Android NDK which gives you a more low-level access to Android but you are still constrained by the KIT API so I'm not sure it will help you.
I'm using something called libhybris, a wrapper that permit the use of android driver blobs in Linux.
I am creating a new type of security application that sits at OSI Layer 2/3 and encrypts packets of data flowing between devices. With this proven technology, I can create apps such as Secure Skype, Private Messenger and so forth and I can do things such as blend Triple DES and AES 256 bit encryption (this will eventually be an open source encryption platform) on the same communication channel. We run underneath higher level, more limited, options such as SSL and VPN and we have been working on desktops for years.
The problem is that I cannot figure out how to port my Linux version over to Android due to the need to have admin rights for my app. I do NOT want to try to force people to root their phone and I am looking for some legal option.
In Windows and Apple, you can get your code verified - in Windows it is called Windows Logo verification. In those case, your code is run through a whole series of tests, the source code is signed and that cert is then authorized for admin rights.
Given how Android works, it would seem that a similar option should exist but I cannot find anything.
Can somebody please point me in the right direction?
Thank you very much for your time.
I'm pretty sure the only way to get "admin" rights on Android is through having rooted the phone, unfortunately.
If you decide to go ahead with this despite that (I know that isn't what you wanted), I'd recommend libsuperuser. Just using Runtime.getRuntime().exec("su ...") may not work consistently across all versions of Android and this library provides a way that will work across them (source). You should first check if root exists before running anything, otherwise you may end up just crashing at runtime because the su binary doesn't exist.
This is a security measure in Android. If you have low level access to all the packets like that, you can do incredibly evil stuff. Therefore, the OS deliberately makes that access impossible to user apps.
As far as I can tell, the closest equivalent to the Windows Logo Program is convincing an OEM to sign your app with their key or include it in the system partition.
I am writing an Android 2.1 application that needs to get data from a USB device. The USB device is an embedded system i created. The embedded system has no OS. Also, the android device does not send any data to the embedded system.
How should i go about this, I'm guessing i will need to make a high-level driver to communicate from USB to the application. But, i have never made a Linux driver before.
If creating a high-level driver is the best way to do this, can someone give me some references so i have somewhere to start.
If there are other ways to accomplish this i would also like to hear about it
-Thanks
The Android Open Accessory Development Kit is where you should start looking. Like many of other Google's documents, the tutorial is reasonably complete and should provide you with a good starting point
Good Luck!
I think you will need to recompile Android kernel to add usb device support.
It can be an option if you are working on some dedicated project and only one Android phone should be supported. If you want to support all kinds of Android phones, I can suggest to implement USB host in your embedded system( if it is possible), thus your Android phone can be connected using ADB protocol.
Is there any way to run Android as a webapp? Either by installing an emulator or something like the Android-x86 or Live-Android projects on a web server?
Perhaps you should define what qualifies as a "web app" ?
For example, I'm pretty sure the (linux version of) the android emulator already works over X11, meaning the display and user input can be from a remote machine (running any modern OS) across the network from the one doing the computation. Maybe that doesn't sound like a web app to you since the client isn't a web browser, but hypothetically one could write a crude X server as a java applet to run in the browser, so wouldn't it qualify then?
Ultimately there are many ways to do this - run a bunch of instances of ARM or X86 android on some kind of VM (or how about a cluster of beagleboards?), then come up with a scheme to remote the user interface using something homegrown or based on X or VNC or whatever strikes your fancy.
I believe are also commercial services such as deviceanywhere that let your remotely test your program on a variety of real smartphones exactly matching the configuration an end user would have.
If one brave soul moves the Android Emulator into a Webstart / Applet application you might be lucky.
As of now the requirements are too high and nobody did it.