Sqlite encyption

[marksmithhfx]

We tested on another computer using iExplorer and were not able to export or open a sqlite database or other files inside of the "engine" folder on an iPad running iOS6, but were able to export on another iPad running iOS5.
-Todd and Jim

Hi Todd, I should have asked, were you able to open/export files from the documents folder in iOS 6? If you are on "another computer" one would hope this couldn't happen, but perhaps iExplorer lets you do that?

Thanks

-- Mark

[James Little]

Hey Mark,

We got decrypting on iOS to work with mergAES. Basically, the premise was to decrypt as we copy.

Code: Select all

  put specialfolderpath("engine") & "/secret.sqlite" into t_db_path
         if there is a file t_db_path then
          put URL ("binfile:" & t_db_path) into tData -- copy the encrypted  file into a variable
               put "secretcode" into encryption_key
               put mergAESOpenSSLDecrypt(tData,encryption_key) into temp
               put specialfolderpath("documents") & "/secret.sqlite" into next_db_path
               put temp into URL ("binfile:" & next_db_path) -- copy the decrytped file back over the orginal
   end if    

In iOS6, we are able to export files from the documents folder on a different computer with iExplorer. So our current strategy is to:
1) encrypt sqlite file in LCdesktop
2) copy and decrypt to the "documents" folder
3) encrypt the documents sqlite
4) sandwich our calls to the database with a decrypt/encrypt

[marksmithhfx]

In iOS6, we are able to export files from the documents folder on a different computer with iExplorer. So our current strategy is to:
1) encrypt sqlite file in LCdesktop
2) copy and decrypt to the "documents" folder
3) encrypt the documents sqlite
4) sandwich our calls to the database with a decrypt/encrypt

That's terrific. Glad to hear you have it working. Don't forget to iphoneSetFileDataProtection to complete on the file. This will give you added protection when the device is locked, and may also provide additional protection when a user is browsing your "sandbox" with a program like iExplorer. I plan to run some tests on this over the holidays when I have access to a second computer.

-- Mark

[marksmithhfx]

A quick update on iOS security. Over the holiday I had the opportunity to test my iPad against a computer that had never seen it before. The good news: the iPad passcode seems to be the key to associating your iPad with another device. Without my passcode neither iTunes nor iExplorer could read anything on the device. Thats the good news. Now the bad. A passcode, unless it is carefully chosen, provides little real protection. While I've not actually tried it I am told that you can easily obtain a piece of software that can "discover" a simple 4 digit numeric passcode in 20 mins or less (using brute force attempts). So, at the very least, if you are interested in securing data on your iDevice, choose a complex passcode.

So, pretending that the potential thief had discovered my simple 4 digit numeric passcode, I entered it into iTunes when prompted. At this point it was possible to backup my device onto the new device and it became possible for iExplorer to "browse" many of the files and directories. I'm storing (fake) patient data in the documents directory of my applications sandbox. Without anything more than my passcode, iExplorer was easily able to copy the sql file to the desktop, where it would have been readable (except I had taken the extra precaution of encrypting the file using Monte Goldings mergAES add-on).

In short, if your passcode is secure your data should be. If your passcode is compromised somehow, you will need additional levels of protection in order to secure data you think is valuable and important.

Cheers, and Happy New Year

-- Mark

[marksmithhfx]

Or, read this summary...

http://www.runrev.com/newsletter/januar ... etter3.php

Thanks for all the great advice and discussion we had here.

-- Mark