tags:

views:

63

answers:

2

I m designing a big android application, where there are XMLs to store temporary data, images captured by camera and other details. Which is the best way to protect them from outer access from phone or from PC. XMLs can be encrypted. And images too, however there are times when they need to be accessed very often and encrypting-decrypting is very heavy operation. XML encryption is manageable but images cause memory problems. Is there any alternative way, something at folder level ?

A: 

There is not such a secure thing to do with assets.

  • If you store stuff on res/raw it can be read by other applications on a normal phone but yes on a rooted one.
  • If you encrypt data, the decryption key will be available in your code. Easy to get it having the apk and apktool.

Perhaps you can do some of that but also obfuscating the code (Android developer guides recommend ProGuard).

Macarse
+1  A: 

Ok, so the "enemy" is the malicious user? If that's the case, there is very little you can do, especially on a root-ed phone. Essentially, since your application is the guest here, you can't really prevent your host from kicking you out.

However, there are a few things you can do to deter them from doing so. You can encrypt the XML and image, but as Macarse raised, the decryption key would have to be on the apk itself or if you contact a server to get decryption key, it is possible for an advanced attacker to spoof a request which your server wouldn't be able to distinguish with real key requests. I'd go against asking the server, it's too much hassle with little gain.

Another you can do is to devise a proprietary image format, then no standard image editing tools can edit the image. However, an advanced attacker could still reverse engineer your image format, and write a converter to a standard image format.

The third thing and most realistic you can do is to just not store the image on the phone. When you take a snap, then immediately send it to the server, so you wouldn't need to mess with securely saving the image. An attacker can still intercept the network traffic as it is being sent or they can tamper your apk(!) such that the program would save a copy of the image to the phone. You can probably do some self-authenticating apk, but that's usually much more hassle than it's worth.

In short, there is little you can do against your host. It all depends on how valuable is the data you're securing, and how likely someone would spend that much time on trying to break your security, to get to the prize.

I'd say, just encrypt the image using a locally stored decryption key, unless you have a real reason to suspect that someone would spend their time to reverse engineer your code.

Lie Ryan
+1 Rep. Thanks for the reply. I m not targeting a pro hacker. I m targeting someone with little or no knowledge in hacking. I have done what you said currently. But issue is not with form-details.xml, problem is with images. Encrypting and decrypting them so often is very heavy. Also, what if I encode images to Base64 and append into the form-details.xml I m encrypting. Will it make XML parsing more heavy ?
Prabhat
@Prabhat: Depends on the XML parser type you're using. An XML parser that creates the full XML tree on load would definitely become slightly slower; while XML parsers that loads the XML file as a stream, would be less affected. I'd say put the image as a separate file, and encrypt them separately. Alternatively, you can `tar` them and encrypt them together.
Lie Ryan
@Lie Ryan. Thanks for the update. Putting images separately and encrypting them is the current scenario which is heavy. I m using SAX Parser btw. Tar-ing them and encrypting also causes issues. Coz every time I have to decrypt and scan through for right file.
Prabhat
@Prabhat: I can assure you that Base64-decoding the image is going to be even heavier and also the encrypt(xml+b64(image)) size is going to be much bigger (wastes precious mobile bandwidth) than either encrypt(xml+image) or encrypt(xml)+encrypt(image). Base64 is inefficient container, it should only be used when you have to send binaries through printable ASCII pipeline.
Lie Ryan
SAX parser is a stream parser, so if used correctly, you can delay reading the image data until the end, i.e. you should put the image data near the end of the XML file. I would still recommend tarring them as a separate file though; tar is an uncompressed archive format and accessing a single file in it should be almost as fast as filesystem operation.
Lie Ryan