Encryption strength

[ukimiku]

When B4A developers encrypt information using the B4A libraries, do these libraries encrypt according to the standard java jre security policies (as stated in the files inside the jre/lib/security directory (on Windows with JDK installed))? I have replaced the custom-installed policy files for "local_policy" and "US_export_policy" that only offered "strong" encryption with the files from Sun for "unlimited strength" encryption, as I don't want to mislead the users of my App into believing the encryption was actually really secure when it isn't.

For Java 6:
Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 6

For Java 7:
Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 7 Download

Now I would like to know how I can test in an B4A app that the new, unrestricted, policies are in effect.

Thank you.

Regards,

 

[Erel]

Which library do you refer to?

Note that Android is based on a port of Java 7.

 

[ukimiku]

I am referring to the RandomAccessFile library, SQLCipher library, and Encryption library.

When I launched B4A the first time, I was asked to point to javac. Does it matter whether I choose javac from a 1.6 version of Java or does it have to be javac from the 1.7 edition? I have both versions here and can choose. At the moment, the 1.7 javac is chosen. Will this in any way influence which encryption security protocols are chosen to honor during compilation of the app?

Thanks.

Regards,

 

[agraham]

I know enough about Java security to know that I don't really understand it! and know enough about encryption in general to realise that I am not an expert and my advice should be disregarded.

However my understanding is that those policy files are checked at runtime, that's why they are part of the JRE and not the JDK. As such they are of no relevance to Basic4android as Android does not use the Oracle JRE to execute compiled code.

Under the Oracle JVM I believe you get an ""Illegal key size or default parameters" exception if you exceed the encryption strengths permitted by the policy files but it would not be safe to assume that Android will do the same.

I do not know, and some cursory Googling has not shown up anything, if the Android runtime libraries do in fact have a similar mechanism but I have found some web forum posts that seem to indicate that other JVMs, particularly the HotSpot JVM and runtime libraries used in OpenJDK, may have no such limitations so Android may (or may not) also be unlimited.

As I indicated above you should now disregard this entire post and do your own investigation to satisfy yourself!

 

[Erel]

It doesn't matter which javac you use for compilation.

 

[ukimiku]

agraham,

thanks for your careful reply. I will do some more in-depth searching. Thank you for your googling as well.

Your conceptual remarks on the policy files being part of the JRE and not the JDK make sense to me. I had mistakenly thought they were being checked at compile time. So now two things need to be checked out:

1) How can I test the strength of the encrytion algorithm used by the JRE on the device? Will there be execeptions thrown when the app tries to exceed these limitations, or will the attempt to do so just die silently, or will the strength be reduced to the maximally allowed strength?

As Android devices are sold in the U.S. (with their restrictive policies on encrytion strength) and, for instance, in Germany (with a government that rather liberally encourages people to use encryption schemes that are as strong as possible), I can hardly imagine that vendors will go the extra mile of adjusting the policy files for each country invidually. Which would mean that they, in order to be allowed to sell their software in the U.S., probably settle for the greatest common divisor, so to speak: the weaker version of the encrption algorithms.

Different encryption strength policies that vary with the respective country would pose issues for App vendors as well, as then "unlimited strength"
Apps that are legal in Germany would have to either (illegally) maintain their encryption strength or have it reduced (supposedly silently, which is potentially dangerous) by the Android system down to the level allowed overseas.

2) I think since the advent of Android 2.2 or 2.3, just-in-time compilation of the Dalvik jars is being performed, and so it would have to be the JIT compiler that checks the JRE policy files. Where to find these files on the device? That will be one venue for investigation. Is there any security policy check being performed by the JIT or the JRE bytecode interpreter on Android 1.5/1.6/2.0?

More input from the forum members will be greatly appreciated.

Thank you.

Regards,

 

[ukimiku]

Erel, thanks, good to know.

 

[Erel]

As far as I know this policy mechanism is not available in Android.

 

[ukimiku]

Thanks. In my web research, I haven't come across a single reference to these security policy files being used by Android.

What I have found so far (I am not at all versed in this matter, so please read the following thoughts with caution):

The encryption on Android is based on "Bouncy Castle", a set of encryption APIs (for JAVA and C#). Homepage: bouncycastle.org
According to Wikipedia, Bouncy Castle is Australian in origin, so U.S. export policies do not apply Bouncy Castle (cryptography) - Wikipedia, the free encyclopedia , as these algorithms are imported into the U.S., not exported from them. Of course, this says nothing about other countries and their policies, while my stance is that the governments of these countries are responsible for controlling what can be imported into their country.

The app backup utility (via USB) of Android ICS is based on Bouncy Castle and uses 256-bit AES keys, as one reverse-engineering programmer has found out: Android Explorations: Unpacking Android backups . Mr. Nelenkov has managed to read and decrypt the app backup archives as created by the Android backup service on the Windows OS. This last site contains a lot of additional in-depth research about security on Android.

Android sometimes packaged older versions of "Bouncy Castle" so that some algorithsm (i.e. AES) may not be available on a given phone. If you want to import recent Bouncy Castles libs into your JAVA or C# development for Android and force Android to use the new libs, you must do some extra work, as is detailed here: Encryption on Android & BouncyCastle - un|we|sen

My 2 cents for now.

Thank you.

Regards,