2

I have an Android application that communicates with another java application. For the data encryption i use the javax.crypto library to encrypt and decrypt the data with a pre-shared key.

According to this question it's possible to get the source code from an APK file. So if somebody is able to read the source code of my application, he's also able to read/manipulate the encrypted data.

It's probably true, so is there a way to prevent this (additional measures, other security method)? Don't know if it have extra value but here is my encryption code:

private static String   IV              = "AAAAAAAAAAAAAAAA";
private static String   ENCRYPTION_KEY  = "0123456789abcdef";

Cipher cipher = Cipher.getInstance("AES/CBC/NoPadding");
SecretKeySpec key = new SecretKeySpec(ENCRYPTION_KEY.getBytes("UTF-8"), "AES");
cipher.init(Cipher.ENCRYPT_MODE, key,new IvParameterSpec(IV.getBytes("UTF-8")));
return cipher.doFinal(input.getBytes("UTF-8"));

EDIT: Communication is send and recieving by NFC. My main issue is, if someone has the key he's able to read and write (abused) information to the other side (the NFC reader)

Community
  • 1
  • 1
S.Pols
  • 3,414
  • 2
  • 21
  • 42
  • The communication is happening locally on one device or over internet? That's important to know before making security considerations. – castor Sep 17 '14 at 13:17
  • Actually it's neither. It's over NFC. So if someone reads the pre-shared key he will be able to create his own Android app and use the pre-shared key to abuse the system. – S.Pols Sep 17 '14 at 13:19
  • Define safe. Against what scenarios are you trying to protect? If you question is 'can anyone extract the key compiled into my app?' the answer is: YES, *very easily*. – Durandal Sep 17 '14 at 13:25
  • My main issue is, if someone has the key he's able to read and write (abused) information to the NFC reader.. – S.Pols Sep 17 '14 at 13:28
  • Are we talking inter-device NFC communication or device-to-mifare-card communication ? – castor Sep 17 '14 at 13:41
  • Inter-device communication. Phone is reader/writer mode. The reader is card-emulation mode. They have bi-directional communication using APDU's. – S.Pols Sep 17 '14 at 13:47
  • Purpose is important. If you need to ensure secure communication between two devices, this isn't a way to do this. But if we are talking 2 devices which have no possibility of knowing some pre-shared device pair communication key, it's is as secure as possible. There would be another ways of dynamically rotating the key. But I don't think it's necessary. – castor Sep 17 '14 at 13:50
  • 1
    What do you mean with not necessary? A random person can read my pre-shared key, create an Android application, touch the phone to the reader, read everything the reader will send, decrypt the data and send encrypted data (which the reader will accept). – S.Pols Sep 17 '14 at 13:56
  • If you want this to be secure you would need to at least do the key exchange externally (eg. through your own server, which would setup the pre-shared key for the communication and send these keys to the devices). Or you could use asymmetric encryption, but again knowledge of private key is a must, therefore. Option A is something I see as secure and easier to do. – castor Sep 17 '14 at 14:27

1 Answers1

3

The pre-shared key is not safe!

For someone with just little java reverse engineering skills it is a job of five minutes to decompile your APK file and extracting the key. Once this has been done your crypto is effectively useless.

The standard approach to fix this is to use a key agreement algorithm. You can for example use the Diffie-Hellman key exchange to quickly and secure generate a common secret between two devices: Wikipedia on Diffie-Hellman

Build a hash from the generated common secret and use this as your AES encryption key for this session is a lot more secure and doesn't take much work.

If NFC is your transport layer you need bidirectional data exchanges for Diffie-Hellman to work. Therefore Android Beam will not be usable for you. You can however do bidirectinal data-transfer using host based card emulation on one phone and reader/writer mode on the other.

Using encryption when transmitting data over NFC is a good idea by the way, also the communication range is limited to some few centimeters, you can still sniff the communication from a few meters distance. NFC doesn't do any encryption for you.

A last word of warning: Cryptography is hard to do in practice. Before you send out anything of value over a cryptographic link please make sure that you have a good understanding of what you do. I recommend reading this book which is a good and practical introduction of cryptography: Bruce Schneider - Cryptography Engineering

Nils Pipenbrinck
  • 83,631
  • 31
  • 151
  • 221
  • Thanks, that was the information i was looking for! I am going read the book! – S.Pols Sep 18 '14 at 11:15
  • 2
    As a clarification, the easiest and most secure way to establish one is to use a well-maintained SSL/TLS library. No need to reinvent the wheel, particularly in such a hard field as cryptography. – luis_pmb Sep 18 '14 at 11:36
  • I thought SSL can only be used in combination with the HTTP protocol. Can you also make an own implementation with SSL and combine that with a random wireless technology, like NFC? – S.Pols Sep 18 '14 at 13:02
  • 1
    @S.Pols There is probably a way to bypass TCP/HTTP and roll your own data transport mechanism. In the end the bits don't care if they get transmitted over ethernet or NFC. – Nils Pipenbrinck Sep 18 '14 at 13:40
  • 1
    Yeah, it's possible. SSL is used on top of many other protocols, such as IMAP or FTP. @Nils is right, as what SSL does is cyphering/deciphering whatever stream of bits you are sending. It's fully transparent to whatever application layer protocol it wraps around. Individual libraries and implementations are another story though, and I'm not very familiar with Android's library ecosystem, but in theory it's possible. – luis_pmb Sep 18 '14 at 13:52