Great! Why didn't I think of this!! If I cache the encrypted response data from server then it can't be edited by anyone. Thank you!! Can you please explain your last line though: "That result contains time, device id, and other information that is needed to verify it." The server echos back any extra fields I add to the license query. Is that what you mean - I should add the device id to the query? How will that improve security? What I got from the documentation was that it contains the VT, GT, GR and UT fields.
Now that you have suggested this cool trick of securing my licensing data, I don't see the need to encrypt my preferences file at all. Why do you recommend obfuscating it at all? Why provide AESObfuscator when you can just document your method in the licensing service guide? Am I missing something again? ~rajorshi On Feb 15, 11:22 pm, Dianne Hackborn <hack...@android.com> wrote: > Not if you use this correctly -- you keep the result you got back from the > server, which is signed with the private key. If you don't have that > (verifying the cert) then the app isn't licensed. That result contains > time, device id, and other information that is needed to verify it. > > Sorry I missed that your question was about licensing, because I saw the > part about encrypting stuff which is nothing you need to do for licensing. > As I said, the license result is signed and you can verify that it is a > valid result. There is absolutely no need to encrypt it. > > > > > > On Tue, Feb 15, 2011 at 9:46 AM, rajorshi <groups.rajor...@gmail.com> wrote: > > But, if someone can edit my preferences file to modify the stored > > validity time stamp, grace period and max. retry count to very > > reasonably values, he can prevent my app from ever contacting the > > server after the first attempts or make it retry all the time. This > > effectively removes LVL checks. Also, if bypassing the licensing is > > indeed as easy on rooted phones as I mentioned, doesn't that > > practically negate the advantage of having a licensing scheme which > > works independent of device configuration. After all, that is what > > attracted me to the licensing service in the first place - the thought > > that I would be able to get additional revenue if my apps could be > > legitimately installed on rooted phones. > > > ~rajorshi > > > On Feb 15, 10:21 pm, Dianne Hackborn <hack...@android.com> wrote: > > > 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.com > > >wrote: > > > > > 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. > > > > -- > > > 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 > > -- > 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.- Hide quoted text - > > - Show quoted text - -- 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
