java – Making Android Keyboard Resilient against KeyLogger attacks-ThrowExceptions

Exception or error:

Being a victim of a Key Logger attack on android, I want to develop a solution for KeyLogger attacks for android. I know basic java and a little about android and very little about Information Security. I am also aware that whatever knowledge I have is not enough to figure out and to develop a solution. I just like to discuss my idea and to see if it is feasible.

Here is what I have:

  1. An android application, which wants to secure user input, must provide a secret key(which can be obtained from server, for a specific user or session) when invoking the android keyboard.
  2. Android keyboard will receive the secret key and use it to encrypt user input and broadcast KEYPRESS event(or whatever event android keyboard broadcasts) with encrypted value.
  3. When an application receives KEYPRESS event, it decrypt’s the value in KEYPRESS even to get the actual user input.

I just came to realize that, screenshot can be used to get what user types with latest image-2-text software’s. But that is completely a different domain, IMHO.

So, what do you think about it? Is it possible to do it?

Update

I was completely wrong about my phone got owned. Actually, it was never got hacked. But, what really got hacked was me. Yes, I have something in my body, which just copies everything that my brain can receive. And it also capable of receiving and making my brain to do it. I still dont know, why I am able to write this update. May be, who ever put that thing in my body using me as a marketing material. Thanks for answers for my dumb question.

How to solve:

Not realistically.

Few programmers are dealing with low-level input themselves. That is usually handled by other things. Web developers, for example, rarely get involved on a keystroke-by-keystroke basis, even for finding out when those events occur (e.g., for real-time validation), let alone for manually processing that input (e.g., putting the next character typed after the cursor of the field and advancing the cursor by one position).

Moreover, users are not in the habit of changing their input methods frequently. I do not plug in a different USB keyboard when I am visiting Stack Overflow versus when I am visiting Tweetdeck, for example. In the world of Android, this means that the user is going to expect their input method editor to work on all apps and not have to keep changing input method editors just to make some people happy.

Furthermore, you cannot magically change the protocol between input method editor (a.k.a., soft keyboard) and the Android OS. Your keyboard will raise key events. You are welcome to say that your keyboard offers up substitutions for those events as an “encryption” mechanism, but that would be more of a crude substitution cipher (e.g., “whenever the user types A, send over ;“), as you cannot unilaterally decide to expand the key event space.

As a result, not only will you need to write your input method editor, but you will need to write your own custom ROM with a custom Android framework that can handle the “decryption”. Or, you would have to force all the worlds’ developers to rewrite their apps. And in either case, a keylogger could trivially detect that yours is the input method editor and note that fact, so whoever is using the logs can do some trivial decryption to convert ; back into A.

Now, if you are writing some app where you want to avoid a rogue input method editor, you are welcome to bake in your own data entry keyboard into that app. Then, you will merely anger many of the users of your app, as your in-app keyboard is not the one that they want to use, or lacks features that they are used to (e.g., support for blind users, support for their particular language).

###

Here is what I would do to implement a secure input method paradigm – as expressed in the question – for Android:

First of all, I am assuming that you have read and understood the “Security” section for InputMethodManager here:
InputMethodManager

So, what we need to develop is an Input Method (IME) which is an Android service, which, along wth the custom keypad view, implements two interfaces:

  1. InputMethod
  2. InputMethodSession

As per the security section in the documentation referred to above, the user need to willingly accept your IME as the system IME. Also, Android will make sure that only system will bind to your service and use the InputMethod interface which is used to show/hide the keyboard etc. So, here things are pretty secure for you and all apps that uses your keyboard.

Now, coming to the security framework that you want to implement:

Lets call it as Secure Input Method – SIM – and lets define our security domain as your IME and the applications that wishes to use your SIM. Here is the significance of the second Interface InputMethodSession

The most important – and often ignored method of this interface is the key of this solution and it is called: appPrivateCommand. This interface allows a private command sent from the application to the IME. As per the documentation, this method can be used to provide domain-specific features that are only known between IME and their clients – and this is exactly what you need for your SIM.

So, using this interface, the apps in your security domain can pass any security information (say, some form of credentials) they want to hand over to your IME. It is up to you to define a method where your service can communicate with a authentication server which processes the client app submitted credentials and approves it. Now if the encryption keys are derived by both your IME and the client, you have established a secure channel of communication between your SIM and its client app (say, via encryption using a derived key from these credentialsd).

You can even customize this whole mechanism by defining some key sequences (like Control+Alt+Del in Windows) which initiates the whole thing by user himself and you can even provide a visual indication (say, a shining green icon) on your keyboard that the input channel is secured… Possibilities are many 🙂

Hope this helps.

###

You can do this only if you are developing your own keypad and configure Android to use it. It is not that hard with some experience in Android programming.

Just search in Google for “custom keypad for android” for more inputs.

Leave a Reply

Your email address will not be published. Required fields are marked *