Have a look to this previous thread. As far as I know and understood, it is not in the strategy of Google to support a CA in the base android platform.
http://groups.google.com/group/android-security-discuss/browse_thread/thread/f1b877ca7053d79f/ba00c3980bbbc7f9#ba00c3980bbbc7f9 jfr wrote: > Is there philosophical resistance to a central or series of central > certificate authorities? If so, does this come from the Android team > in Googleland or from other groups? > > - jfr > > On May 4, 10:13 am, "guillaume leterrier (Teleca Germany)" > <[email protected]> wrote: > > You are correct. I used the wrong terminology. A trojan is a more > > appropriate term. > > > > Anyway, I do not understand why you are stating that it is not > > possible to resign an existing application with a new key ? > > > > I do not see any difficulty for a hacker to re-sign any application > > with its owned private key and then distribute it on the web. He can > > modify the binary before re-signing, or he may simply have access to > > the source code, or even re-create the source code to fake the > > original application. > > > > By the way, he doesn t even need to reverse engineer any code. He just > > need to create and distribute any useful application and include a > > sleeping trojan into it. > > > > The only thing, a hacker can not do, is to gain access to the private > > signing key of other developer. Basically, it can not resign with the > > same private key ( it doesn t have it ), but it can resign with any > > new one. > > > > If there would be a certificate authority controlling the developer > > private key, then the user would safe from installing an application > > signed with an unknown/invalid developer private key. But that is not > > the security concept of the android platform. > > > > > > > > Disconnect wrote: > > > That is called a trojan. > > > > > And lack of upstream verification does not mean lack of verification. You > > > cannot upgrade an existing application with a new key. > > > > > On Mon, May 4, 2009 at 9:46 AM, guillaume leterrier (Teleca Germany) < > > > [email protected]> wrote: > > > > > > Well, I m simply relying on user application download to spread a > > > > sleeping virus ! > > > > > > Imagine, a small application that is so nice and useful that many > > > > users install it. > > > > > > This nice application may perform (permission granted by the user) > > > > useful functions and perform them in a proper way during a long time. > > > > > > Unfortunately, this application could contain a sleeping virus. Yes, > > > > this application could have been designed or modified by a malicious > > > > developer. The modified version could also be available on the web and > > > > downloaded by end-user. End-user have no way to distinguish between an > > > > original signed application and a malicious one. > > > > We assume there is no Certificate authority that track applications , > > > > the signature keys and developer ID. > > > > > > After couple of months, the virus may become active and take advantage > > > > of the user granted permissions to perform money costly operations or > > > > simply drain the battery. > > > > For example, low standby-time of the mobile may trigger many complain > > > > calls to after-services and generate unexpected cost for the mobile > > > > manufacturers and the operators. > > > > > > Disconnect wrote: > > > > > A virus, by definition, spreads. How do you expect an android virus to > > > > > spread? > > > > > > > Also, what can it damage? (Leaving aside gaping holes like 'su' in > > > > 1.0/1.1 > > > > > dev phones and full access to sd card data) "Oh no, the virus hidden > > > > > in > > > > > TwitterFooler deleted all the data from .. um.. twitterfooler. Ha, > > > > > take > > > > > that.. me..." > > > > > > > On Mon, May 4, 2009 at 8:54 AM, guillaume leterrier (Teleca Germany) < > > > > > [email protected]> wrote: > > > > > > > > Unfortunatly, that is also my understanding of the current Android > > > > > > security model. > > > > > > > > There is no certificate authority scheme that check application > > > > > > content and ID/rights of the developer. > > > > > > > > All developers and all applications are treated as equal by the > > > > > > android security model. > > > > > > > > The end-user is mainly in charge of assessing the trustworthiness of > > > > > > an application and its installation consequences, based on its > > > > > > requested permission. ( an exception to be noticed is the shared ID. > > > > > > see related discussion thread....) > > > > > > > > It is also assumed that the end-user is responsible enough to get > > > > > > application from a known market place and not from any unknown web- > > > > > > site source. > > > > > > > > The end-user could still un-install the application if not > > > > > > satisfied, > > > > > > it could also rate the application on the market place. Ok, this is > > > > > > a > > > > > > reactive approach, after damages could be done. > > > > > > > > Next end-users could use the application rating to assess the > > > > > > quality > > > > > > of the application provided by previous user, before taking any > > > > > > installation decision. > > > > > > > > However, the malicious developer could still regenerate the same > > > > > > malware with a different key, and potentially continue the damages > > > > > > under an other identity. > > > > > > > > The market place could implement an automatic scheme that scan > > > > > > applications to limit such cloning behavior by comparing binary > > > > > > signed > > > > > > with different keys and reject black listed malware application. > > > > > > > > Moreover, if there is a virus embedded in the application source > > > > > > code, > > > > > > and such virus could still become active after a sleeping period. An > > > > > > anti-virus could also scan ( at installation time ) the application > > > > > > binary and compare it against an updated list of unknown malware. > > > > > > The > > > > > > anti-virus check could also be performed by the market place itself. > > > > > > > > Android wrote: > > > > > > > The silence in the thread scares me. Does anyone knowledgeable > > > > > > > have > > > > an > > > > > > > answer to Tote's question? > > > > > > > > > Is the totality of Android API protection based solely on the idea > > > > that > > > > > > > self-signing out of self-generated certificates is trustworthy? No > > > > chain > > > > > > of > > > > > > > trust? No identity escrow? No skin in the game of any sort > > > > > > > whatsoever > > > > to > > > > > > be > > > > > > > able to track down the originator of a rogue app? No validation > > > > > > > that > > > > > > someone > > > > > > > with bad intentions isn't self-signing an innocuous-looking > > > > application > > > > > > that > > > > > > > gets on marketplace but that triggers bad behavior after it's been > > > > widely > > > > > > > installed? > > > > > > > > > Please tell me that the effectiveness of Android's API security > > > > > > > model > > > > > > isn't > > > > > > > purely based on crowdsourcing and user-generated feedback... > > > > > > > > > -jfr > > > > > > > > > Dave, > > > > > > > Thanks for the exhaustive answer and I naturally appreciate > > > > > > > Google's > > > > > > > decision on working out this security model. Nevertheless, you > > > > > > > seemed > > > > > > > not to answer one of the important questions I also asked: > > > > > > > > > "Another question is that if any developers can sign their apps > > > > > > > freely > > > > > > > without any consequences (I mean there's no accountability on > > > > > > > self- > > > > > > > signed certificates) what will really prevent malware from > > > > > > > spreading? > > > > > > > " > > > > > > > > > That is, if I were a malware author it wouldn't give me too much > > > > head- > > > > > > > ache to change my self-signed certificates frequently - and I > > > > > > > don't > > > > > > > want to update my previous app, either. What is Google's approach > > > > > > > to > > > > > > > this problem? > > > > > > > > > Thanks, > > > > > > > > > Tote > > > > > > > > > On Feb 5, 3:02 am, Dave Bort <[email protected]> wrote: > > > > > > > > > ________________________________________________ > > > > > > > Message sent using UebiMiau 2.7.10
