JFR,
There are advantages and disadvantages to relying on such a series of
central CAs. This thread has spent a lot of time on the advantages, so
I'll focus on the disadvantages.
1) Public Key Infrastructures (PKIs) carry their own baggage and
inherent problems. For a general discussion of the associated risks,
see Ellison and Schneier's "Ten Risks of PKI" (http://www.schneier.com/paper-pki.pdf
).
2) Relying on code signing has many limitations. Do you remember
Microsoft's Authenticode? Where is it now? What does it mean when a CA
signs code (or a developer key)? Are they manually inspecting source
code? Does this strategy scale? Malware authors have successfully
socially engineered SymbianSigned (e.g., http://www.f-secure.com/weblog/archives/00001190.html)
.
3) Who decides what CA root keys to install in an Android phone? (a)
why should we trust them, and (b) what gives them the right to dictate
content (e.g., to say an application is not socially acceptable).
The answer to malware on mobile phones is not as simple as code
signing + a CA. While I agree there are situations where it can help
mitigate the problem; it is not a complete solution. This isn't just
an Android security problem. It is a "smart phone" security problem.
-Will
On May 4, 2009, at 10:54 AM, 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
--
William Enck
PhD Candidate
Department of Computer Science and Engineering
The Pennsylvania State University
[email protected]
