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 > > > > > >
