Mark, > "Temporary package attribute assigning a signature to the package. This > will be removed once real support for package signing is implemented. " > > So, I wouldn't count on that specific attribute being around.
Hmmm. That's the price I have to pay, playing with beta software. > same caller as a previous one. And, if you *are* passing some sort of > caller token with each call, impersonation is merely a matter of > intercepting and reusing said token. Even if you check the digital > signature on each call, assuming the signature is of some packaging of > the call's parameters, you are still subject to a replay attack. Now, My idea here is to tie the pid of the calling process to the verified digsig. That way subsequent calls do not require re-verification. I suspect it is quite hard to impersonate a pid! I'm not sure it can be done in Linux e.g. ask the OS to run your executable under a specific pid. I suspect NOT. At this stage, I am not worried about "replay" attacks. Regarding decompilation; I wonder if it is possible to obsfuscate bytecode. Java ME has that facility. > So the question you need to ask yourself is: will the amount of security > gained from going through this be worth the effort? Even if it comes to nought; it's still a good intellectual exercise and I've got lots of spare time. Regards, Gavin --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] Announcing the new M5 SDK! http://android-developers.blogspot.com/2008/02/android-sdk-m5-rc14-now-available.html For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---