I would like to create an android application. In this application I would like to create a PKCS file system (like in Java Card applet) (not involving secure element) and perform cryptographic operations through APDU commands. Is it possible? Any valuable suggestions?
Thanks in advance.
Yes, although APDU's are meant to be send over a T=0 or T=1 transmission protocol. You may map those on the internet protocol, but some mapping may be required.
You could start with JCardSim which implements the Java Card specifications (in part) on the JRE. It will likely also run on Android, although you may have to make some modifications.
Related
Assume we have a process that may dlopen() some third-party library. This library may perform open("write_only_logfile", O_WRONLY) on some file to which user has only write access. We need to have an ability to be notified if this library attempts to open a file, so later we may dup() returned descriptor and redirect output.
There are few restrictions that make interception harder:
LD_PRELOAD is forbidden - no way to hook open()
inotify(7) doesn't help because user has no read permissions on "write_only_logfile" and it is owned by admin
we have no access to library sources and therefore cannot modify it
"write_only_logfile" is hardcoded inside the library, so we cannot pass another name to perform redirecting
I'm wondering if Linux has an efficient way to help in such situation.
Especially taking in account the fact that process may open() miscellaneous files pretty often.
P.S. To avoid confusion and understand better - it is a regular Android application with loaded JVM. If app hangs (so called ANR) - system sends SIGQUIT to it. Signal is received via dedicated thread that open()s /data/anr/traces.txt and writes JVM state to it. These data extremely useful for debugging. But app cannot read that file directly because of security reasons (All applications write to it, so there may be somewhat sensitive). Anyway I believe that it is absolutely fair to intercept content that my process would write to it.
P.S.S. In the worst case it is possible to find JVM library image (libart.so) and manually patch jump slot for open(). But it doesn't sound well.
Sounds like you are in troublesome situation. Most solutions briefly mentioned below are guaranteed to interfere with SELinux, so don't take my word for any of that.
Debugging your own process with strace to intercept open is one of usual solutions on normal Linux. I am not sure if it would work in Android; it certainly might become off-limit for non-debuggable apps starting in some new versions (if it is has not been banned yet).
seccomp-bpf is another possibility. Might not be available on older Android versions, but since Android O seccomp is going to be a guaranteed part of Android security getup. Intercept open in warn-only mode and give control back to yourself when something interesting happen (via debugging or signals).
If /data/anr/traces.txt is opened on-demand, you should be able to observe that by watching contents of /proc/self/fd/ with inotify or via polling. You might be able to reduce impact of races by setting io niceness of the opening thread…
All of above are only partial solutions, you still might need to decode actual open syscall that happened (strace source code might be helpful there for strace/seccomp solutions, readlink for /proc/self/fd/) and act upon it (dup2, as you already mentioned).
"write_only_logfile" is hardcoded inside the library
Is it possible to modify the memory of data segment of the library/executable? Afaik mprotect and PROTECT_EXEC in particular have been heavily restricted, but at least mmap is certainly permitted (to support JIT compilers etc). It might be possible to cook something up to edit the string constant in place (as long as doing so is possible and allowed, I am not sure myself about that).
If this is just about redirecting writes (and reads) to a single file, you could run the application in a mount namespace with a suitable bind mount for that particular file. Setting things up in this way probably requires a small SUID binary.
A more general solution quickly approaches a union file system, and getting it right is quite hard. Even the in-kernel union file system, overlayfs, does not manage to provide full POSIX semantics.
You need LD_PRELOAD to hook an application. To hook a third-party library, just load your hook normally before the library (or have it in your executable).
Assuming the library calls open from libc and not the corresponding syscall directly, and that it is linked in a normal way, you just have a function named open somewhere in your code. Make it call open from libc (RTLD_NEXT or whatever). The third-party library (and all other libraries of course) will resolve its open symbol to your function.
Hy... I'm trying to find a source code that implementing android HCE with secure element. I have read these two articles right here :
http://developer.android.com/samples/CardEmulation/index.html
http://blog.opendatalab.de/hack/2013/11/07/android-host-card-emulation-with-acr122/
But those just shows an Android HCE without secure element. I have read another blogs too, but none of them shows me the source code example. Just some explanations about Secure elements or else....
Can someone help me with this...?? I need an android source code example with secure element included...And ooowh.. I dont need third party librari, for example from SEEK FOR ANDROID/SIM ALLIANCE or usmile project...
Thanks in adnvace.... :-)
Your question doesn't make sense. You can't have HCE (Host Based Card Emulation) using a secure element. The sole purpose of HCE is, that you don't have to access the secure element.
What you'll probably want is to put a card emulation application into the secure element.
Bad news first: You will very likely not be able to do this because you need to authenticate with the secure element to install any applications. It is highly unlikely that you'll ever get the keys.
Anyway:
To get access to the secure element you have to use a non public API. The relevant files are available in the android source tree at:
<android-sdk-base>frameworks/base/nfc-extras
With a bit of luck you can access the classes provided using java reflection. Once you have access to the classes you'll need an instance of the class NfcExecutionEnvironment. This class provides the function:
byte[] transceive(byte[] in)
This is the communication channel to the secure element. The function expects ISO7816-4 commands, and you can expect it to behave like a JavaCard SmartCard with NFC extensions. Given that you have the keys to authenticate to the SE you should be able to upload and install ordinary JavaCard .cap files directly to the SE.
Using the SEEK API is probably easier and more flexible as it may allow you to install applets to a NFC-SIM card as well.
How can we make Android assets secure so that no one can read them after app deployment?
There is nothing you can do that will stop a determined attacker from reading them.
Using your own application level encryption would at least make the problem unique to your application, but someone could still do code analysis of your app to figure out how to decrypt them.
The platform's limited copy protection mechanisms are weaker, because they only have to be defeated once for all applications (such as by rooting the phone).
Assets utilized by platform functionality would also vulnerable to a modified platform configured to dump out copies of them.
Do what is easy to stop casual copying by unsophisticated users if you like, but then save your time and energy for battles you can actually win, such as the quality of your application.
As the title says - is there something in iOS that lets you say 'this file is allowed to be accessed by other apps' - preferably only readable, but read/write would be good enough.
Basically I am trying to place a file outside the sandbox so other apps can read it - preferably via the openURL that points to a local file rather than an http address.
Thanks
Edit:
I just received an answer from Apple Tech support and they told me that this is currently impossible (just after iOS 6 released)
I don't think it's possible to do it the way you describe. Last I checked, apps can only write inside their sandbox dir and cannot read inside other apps' sandboxes (though IIRC there used to be a few other writable directories).
What, exactly, is the end result you are trying to achieve?
If you know the app you want to read the data, you can use a custom URL scheme.
If you have a file of a certain type (extension/content-type, I think), you can use UIDocumentInteractionController to let the user pick an app to open it in.
If you just want to share some data with any app, the closest I can think of is a custom UIPasteboard. OpenUDID does this for a slightly dubious purpose.
I would like to write application (as background service) which will encrypt whole file system totally. The questions are:
Is it possible, such that all Android services will work smoothly? Like, say Microsoft's BitLocker?
If so - can someone point me to some sources/docs?
No this is not possible thought the API.
You'd have to get the source code of Android and try to implement that yourself baking your own custom system image.
However I don't think it is possible at all.
Encrypted file system would be possible only via kernel-mode driver, which means a custom ROM for a device.
Its not clear if you are doing this to be secure, or only in order for a trojan to claim payment for restoring the files ;)
Encrypting files after they have been written in plaintext will leave the plaintext spread around your Flash (or disk) until that space is later reclaimed for new files. Its basically not secure. You have to encrypt before bytes get written to disk.
Android runs on Linux, and device drivers for storage, whilst modular, are compiled into the kernel. So unless you are distributing a custom Android image, you cannot post-install install a driver on someone's device.
There has been discussion like this on the mailing list here.