The reason that this question was born is that I am totally lost, so please forgive the trivial and senseless parts.
I have an Android app, a web-service, a MicroSD smart card (mobile security card). I need to know how can I use the card with ssl to securely communicate with the web-service. Rebuilding and flashing the OS is not an option.
What I know:
The API used to communicate with the MSC
How to write/deploy applets to the MSC
How to call a web-service
What I don't know:
SSL
Too much about certificates and cryptography (only shady academic stuff from the university)
How things come together and what should I use to accomplish this
seek-for-android has an OpenSC tutorial and library, but the OS needs to be patched for that. Is there a way to avoid that and still use the solution?
I know I could be much further into this with a little research, but my deadline is quite close (a few days), so I need help, much help, and very soon.. Thank you in advance!
EDIT:
More specifically:
I have a Smart Card SD card from Giesecke & Devrient, with Java Card OS and fine applets and dev tools. I also recieved an android service to communicate with the card (the applets) with APDUs. This is quite low-level, it acceps byte codes as commands and data.
I need to call a web-service via SSL authentication. Now I know that SSL uses (can use) hardware tokens with PKCS#11 interfaces.
There is a project called seek-for-android with a guide to patch the OS and have a standard PKCS#11 interface over the smart card (I believe this would be OpenSC). I CAN'T patch the OS.
So the questions again:
Can the Android SSL implementation use (custom) PKCS#11 interfaces in some way, if yes, how? (e.g. possibly with some security providers)
Can I use OpenSC (and other stuff mentioned in the linked guide) without patching the OS (e.g. extract the libs and include it in my application)?
Overall, how should I link the gap between the low-level smart card and the high level SSL? I kindly ask you for any material regarding this.
As this is a special form of a Smart-Card encapsulated inside a microSD-card I assume that the API bases on special SD-Card read and write operations. Such operation may or may not be usable on Android without root access.
That depends on the certain implementation of the API. Usually such a microSD card already comes with Android libraries (as it is the most open relevant mobile platform) from the vendor. You should ask there for getting more information.
Use Bouncycastle (Spongycastle is the fork for Android) and implement your own Security Provider which uses the SmartCard instead of a file for stored certificates.
If you can access your card without patching the ROM, you can roll your own (requires knowledge of cryptography) SSL implementation on top of it.
If not, then AFAIK you need to patch Android to get access to the extra hardware. And the built-in SSL library has no support whatsoever for client-side "hardware tokens" AFAIK.
Related
I intend to port a Qt desktop application to Android. It uses QSerialPort to communicate with an external device (which has a built-in CP210x)
The application, although written purely in Qt and C++, runs fine on Android, but it doesn't see the device. The CP210x official driver download page recommends to compile the kernel on Android from source, which is not feasible to expect from the average customer. Other recommendations I found online recommend jailbraking the phone, which also isn't something we could expect end users to do.
There are scant few questions in this topic on the Qt forums, most saying that QSerialPort's Android support is quite limited. However, these topics are often at least 6-7 years old.
An Android developer forum/wiki/tutorial? recommends to use "Android Things", whatever it is. I couldn't find any apps fitting that description.
I know that it's physically possible to use serial-usb on an non-jailbroken Android, as I tried out a serial console app and it worked, I could successfully exchange data with my device.
Does this mean that the only was is to develop my own wrapper in Java, and use JNIEXPORT? That would break the easy multi-platform compilation I used before (just selecting a different kit from Qt Creator) Are there any simpler ways to accomplish this? Is USB OTG usage so low that no one else thought to implement anything in this regard?
QSerialPort has only a non-official partial Android Support (see https://wiki.qt.io/Qt_Serial_Port).
(... Use on own risk, only for rooted devices, in which is it possible to get/set a permissions to the /dev/ttyXYZ nodes)
You can use JNI to get a FileDescriptor with permission and then use the libusb library in C++ to communicate with device.
But yes, it would break the easy multi-platform compilation.
The new Android Pixel 3 contains a secure element called Titan M.
First, I am wondering if it is possible to interact with this secure element by using the Open Mobile API (package android.se.omapi) now available on Android 9.
Secondly, I looked at this OMAPI and found that it allows to send APDU messages to applications using ISO 7816 protocol for smart cards. So I would like to know what kind of applications I can interact with.
If it is possible, my aim would be to insert a JavaCard applet into the Titan M secure element and to use OMAPI to send APDU to this applet. Has anybody tried to do that ? I would be happy to get any feedback on what it is possible to do with this API and Pixel 3.
Thanks.
Franck
First, I am wondering if it is possible to interact with this secure element by using the Open Mobile API (package android.se.omapi) now available on Android 9.
At first glance and doing some limited research (mainly because there is limited information available) it doesn't look like this would be the case. That API is mainly intended for SIM cards, and I sincerely doubt with a high level of confidence that a SIM API or functionality is present in the Titan M System-on-a-Chip (with ARM SC300 core, in all likelihood).
Secondly, I looked at this OMAPI and found that it allows to send APDU messages to applications using ISO 7816 protocol for smart cards. So I would like to know what kind of applications I can interact with.
SIM cards and embedded Secure Elements that support an APDU interface on devices that support OMAPI. However, although I would say that Titan M is an embedded Secure element, I would wage that it doesn't use OMAPI and because of that, it won't be available through the API. Actually, I would be surprised if it uses APDU's at all. ISO/IEC 7816-4 is a pain that you can do without if you're able to specify the transport layer yourself.
If it is possible, my aim would be to insert a JavaCard applet into the Titan M secure element and to use OMAPI to send APDU to this applet. Has anybody tried to do that ? I would be happy to get any feedback on what it is possible to do with this API and Pixel 3.
I would find it entirely unlikely that Google is willing to pay license costs to Oracle to be able to implement Java Card. I certainly don't see Google listed in the JCF, which you would expect if you would implement a native Java Card solution yourself.
Finally, there have been many posts that said that the Titan M "firmware" would be released as Open Source by Google. However, that promise never materialized. Note that it is extremely tricky to release such code for secure processors. If a security issue is found that requires a software fix then that fix might have to be applied all over the place, and details of the fix may help adversaries.
So, all said, you will have to do with the high level interfaces that Android offers - as far as I am able to find out.
I am working on a RSS reader application. And I need to find a backend database. I want the database be embedded because I don't want the users to install a database server.
I know SQLite is a good choice, but I am wondering if there are any other nosql choices?
(I don't yet have 50 rep points to comment on, and build upon, the accepted answer; otherwise I would, sorry!)
You can embed MongoDB in your OEM solution but there are two things to consider:
It is written in C++, so if you are coding in a different language you might need to write a wrapper that launchers the database process separately.
MongoDB is licensed under Gnu AGPL-3.0 which is a copy left server license. The accepted answer, and the Google group quote, both correctly state that this would normally force you to also be AGPL licensed. However, they MongoDb states that the intention of the license is to allow refinements to their code to be submitted back, and that your product will remain separate. This makes me think that the normal copy left rules don't apply.
The goal of the server license is to require that enhancements to MongoDB be released to the community. Traditional GPL often does not achieve this anymore as a huge amount of software runs in the cloud. For example, Google has no obligation to release their improvements to the MySQL kernel – if they do they are being nice.
To make the above practical, we promise that your client application which uses the database is a separate work. To facilitate this, the mongodb.org supported drivers (the part you link with your application) are released under Apache license, which is copyleft free. Note: if you would like a signed letter asserting the above promise please request via email.
Source: http://www.mongodb.org/display/DOCS/Licensing
According to the Google Group, yes it can, but it doesn't cover how exactly.
Yes, but it isn't pretty and will
force your app to be AGPL licensed. If
you are interested take a look at how
the tools handle the --dbpath option.
Source: http://groups.google.com/group/mongodb-user/browse_thread/thread/463956a93d3fb734?pli=1
If you're using .NET, one option might be RavenDB, which is a document database, and can be embedded.
Please checkout https://github.com/Softmotions/ejdb
This project being developed to resolve this issue.
How about Couchbase Lite? It's an open source, embeddable document database. While it can function as a standalone document database, its real value is in its ability to synchronize with remote document databases. It may be aimed at iOS / Android, but it can run on anything with a JVM.
https://github.com/couchbase/couchbase-lite-java
There is no straight forwarding way to use MongoDB as an embedded library in terms of a well-reusable library. Eliot - head of 10gen - spoke of "it would be nice to have one" - but there is nothing available that could be reused in a sane way.
Looks like a lot of OEMs are trying to get Mongo on to their hardware and devices for real-time processing. A link from MongoDBs website
I usually use Buildroot to create a cross-compiled Embedded Linux root file-system along with all the user space packages.
I noticed that MongoDB is one of the packages that's already integrated as one of the Buildroot builtin packages.
You may check out MongoDB make file for some hints regarding how to built it for Embedded Linux.
Is it possible to get the network packets / stream prior to encryption? I mean if you are locally root and could compile pretty much everything yourself, even the kernel. Where would be the best place to do it, if it's even possible?
Somewhere inside the android framework might be a good point, where the encryption is actually done.
I know about all the mitm ways to attack, but it would be great if there would be a way without using a "proxy" or any other default gateway.
It would be used for debugging purposes on a special developer device.
Does anyone know if an app can be hacked to manipulate anything else beside the actual app or the host phone itself? A web service server perhaps? Is that even possible? So the real question is, if an app is hacked, can the information it might possess or has access to be used for negative purposes?
(I'm looking to secure an app, not hack anyone.) :)
Web services are always vulnerable to being hacked. This is why you use a secure connection such as SSL to transfer any sensitive information.
As far as directly hacking Android applications, I imagine a hacker would have to do something along the lines of decompiling an application to assembly, much as they do for traditional applications.
Any kind of storage on the device in non-compiled format (some XML, text files, preferences) is more vulnerable to being hacked than natively compiled .apk's.
I think everything is hackable...
It is quite easy to get access to all your application's data on a rooted device. Things like your database or your private files are accessible on a rooted device.