[android-developers] Securing the SharedPreferences file using AESObfuscator in LVL
I have no experience in cryptography, hence this basic question about the AESObfuscator in Android LVL. The AESObfuscator uses app specific info (say package id), device specific info (say android.provider.Settings.Secure.ANDROID_ID) and a salt to generate a key to encrypt the SharedPreference file where the ServerManagedPolicy stores my license information. Now, the app id and the device id are well known. It will be a simple matter to decompile my app to obtain the salt even if I obfuscate my code. Won't somebody be able to generate the key using the three values and edit the SharedPreferences file easily on a rooted phone? On a non-rooted phone I guess I can just make the file private and nobody else will be able to access it, but, what do I do on rooted phones? I can't help feeling I am missing something here. Why else would the documentation on LVL put so much emphasis on refactoring and obfuscating LVL to prevent others from patching the library when a much simpler way would be to just get the salt and edit the preferences file? Can someone enlighten me on this? ~rajorshi -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Securing the SharedPreferences file using AESObfuscator in LVL
Oh and the documentation on LVL obfuscation is to prevent people from easily *modifying* the app to *remove* its LVL checks. This is in many ways a very different issue than trying to protect data that is being stored on the device. The LVL design has the server holding the private key that it uses to sign its results, and the app has a public key it uses to verify results from the server. That way you can't spoof the result without knowing the private key (which is only on the server), so LVL will work without needing to trust the local device or Market app. On Tue, Feb 15, 2011 at 9:18 AM, Dianne Hackborn hack...@android.comwrote: If someone has root, there is little you can do to really protect yourself from them. On Tue, Feb 15, 2011 at 9:10 AM, rajorshi groups.rajor...@gmail.comwrote: I have no experience in cryptography, hence this basic question about the AESObfuscator in Android LVL. The AESObfuscator uses app specific info (say package id), device specific info (say android.provider.Settings.Secure.ANDROID_ID) and a salt to generate a key to encrypt the SharedPreference file where the ServerManagedPolicy stores my license information. Now, the app id and the device id are well known. It will be a simple matter to decompile my app to obtain the salt even if I obfuscate my code. Won't somebody be able to generate the key using the three values and edit the SharedPreferences file easily on a rooted phone? On a non-rooted phone I guess I can just make the file private and nobody else will be able to access it, but, what do I do on rooted phones? I can't help feeling I am missing something here. Why else would the documentation on LVL put so much emphasis on refactoring and obfuscating LVL to prevent others from patching the library when a much simpler way would be to just get the salt and edit the preferences file? Can someone enlighten me on this? ~rajorshi -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Securing the SharedPreferences file using AESObfuscator in LVL
If someone has root, there is little you can do to really protect yourself from them. On Tue, Feb 15, 2011 at 9:10 AM, rajorshi groups.rajor...@gmail.com wrote: I have no experience in cryptography, hence this basic question about the AESObfuscator in Android LVL. The AESObfuscator uses app specific info (say package id), device specific info (say android.provider.Settings.Secure.ANDROID_ID) and a salt to generate a key to encrypt the SharedPreference file where the ServerManagedPolicy stores my license information. Now, the app id and the device id are well known. It will be a simple matter to decompile my app to obtain the salt even if I obfuscate my code. Won't somebody be able to generate the key using the three values and edit the SharedPreferences file easily on a rooted phone? On a non-rooted phone I guess I can just make the file private and nobody else will be able to access it, but, what do I do on rooted phones? I can't help feeling I am missing something here. Why else would the documentation on LVL put so much emphasis on refactoring and obfuscating LVL to prevent others from patching the library when a much simpler way would be to just get the salt and edit the preferences file? Can someone enlighten me on this? ~rajorshi -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
