Agree. The problems we get (security wise) with the freedom we currenrly have in android are a necessary evil.
On May 5, 2009, at 10:34 PM, Disconnect <[email protected]> wrote: I'd hate to see t-mobile in particular get a hold of that capability. Based on their past behaviour, it would destroy the android series on their network. Unless this has changed in the past year or so, you can still try it yourself. Go down and buy any basic j2me-supporting subsidized phone from your local tmob store. Free is good. You'll discover that gmail, gmaps, etc etc don't work because tmob ships them with security checking enabled, and the only signed apps are the ones from their store. So local apps work, network ones don't.. (The good news is, you get 72 hours to give it back in disgust and - with only about 8 phone calls and 6 hours on hold - you can get the contract extension revoked.) On Tue, May 5, 2009 at 8:31 PM, Dianne Hackborn <[email protected]> wrote: Hi all, I appreciate this discussion, but would like to make clear that we have no plan to introduce a CA-based permission model in Android. For certain we are not going to do such a thing for any of the existing permissions (breaking all existing apps), and I think there are other better solutions for providing other more dangerous permissions as I described in my recent post to another thread. There are many problems with CAs, as other people have well outlined in this thread, and at a fundamental level they are just intrinsically incompatible with Android's "all applications are created equals" philosophy (which we want to make -more- true, not less). Android was designed from the start to not rely on the crutch of CAs, and this is baked into its approach to security. I think that comparing Android-without-CAs to Windows-without-CAs significantly glosses over what a lot of Android's approach to security is about (placing each application into its own uid sandbox, explicit permissions and trust to reach out of that sandbox, etc), and I would be interested to hear from people who think these are the same why it is they believe this. That said, I do think there is an area where we can improve the security experience for most users. One thing we'd like to introduce an idea danfuzz has for "trusted authorities." This would be a list of servers that, prior to installing an application, the system would consult to determine whether or not that application is okay. The server may either do this as a white-list or black-list. It wouldn't be based on certificates, but rather the particular .apk binary. For example, T-Mobile may pre-configure their devices to consult their own trusted authority to black-list the occasional application they find trouble with; the user could add another entry for McAfee who would be maintaining its own list of bad applications based on its own analysis and monitoring. On Tue, May 5, 2009 at 2:05 PM, William Enck <[email protected]> wrote: JFR (and others), I think we are in agreement on many of these points. I wanted to bring some balance to the dialog. There is an opportunity to use a number of techniques to curtail the potential for repeating the PC's failures (hopefully we are not too late). A CA-based model is one part of the larger picture. Putting aside the discussion of why Android doesn't currently use a CA-based model, let's discuss hypothetically how such an architecture might be constructed. Here's some food for thought: 1) Should end-users be allowed to override settings that restrict applications to a specific set of CAs? and how should this be allowed (hopefully not on demand)? Many end-users jail-break Symbian and iPhone handsets in order to run applications that are not officially supported. To my knowledge, Android has been primarily jail-broken by hobbyists looking to experiment. However, there are specific instances (e.g., tethering) that are similar iPhone jail-breaking motivations. Basically, this is a question of the security mechanism's psychological acceptability. (Note, I believe some providers allow SymbianSigned to be turned off for this reason). 2) Should the user be able to add more CAs manually (e.g., to allow other application stores)? How do we know the malware isn't adding new CAs? Should this be hierarchical with an official Android certificate at the root? 3) Should the CA signatures be per-application or per-developer? or should this vary based on CA? 4) Should the developer pay a large or small fee to have applications signed (directly or indirectly) by the CA? 5) How should certificate revocation occur? Push or pull? Should it affect only newly installed applications? or help the user remove malware? I'm sure this list could go on. Thanks, -Will On May 4, 2009, at 12:19 PM, jfr wrote: Hil Will, Your points are valid that PKI is not a panacea. Code signing has limitations -- I agree. Without extensive code review, code signing of any sort is not a guarantee that the application isn't doing something malicious - agreed. Signing under a CA's certificate, likewise, is not a guarantee of any kind of verification that the application isn't misbehaving - again, agreed. But that's not ultimately the point. What code signing under someone else's umbrella of trust does is give you the _possibility_ of setting up a system where trust can be systematically revoked in automated fashion when malicious activity is performed under false pretenses within an application that has a signature. I think that malicious activity can be clearly and cleanly defined (e.g. your information is released without your knowledge, or you are subject to monetary costs or other damages that you did not agree to). I'm not talking about curtailing "distasteful" content. I'm talking about mechanisms for controlling clearly dangerous applications. I also agree with you that this is not just an Android issue, but of every general purpose computing system. When it comes to smartphones, however, other platforms have come up with some way of mitigating the potential impact of rogue applications. We can argue the merits and drawbacks of each all day, but the point is that they have something that has made a reasonably large number of intelligent people comfortable. The fact that Android is operating as a smartphone platform but doesn't have an answer to this other than crowdsourcing is basically saying to handset manufacturers, network operators and end consumers that they're on their own and it's their own damn fault if something awful happens to their information, phone bill, or the networks on which they run. Signing + CA is not the complete solution, by any stretch of the imagination, I agree, but something like it could be a start. On the desktop side, relying on end users' knowledge has given us lovely things like ILOVEYOU and botnet DDoS attacks on Estonia. Why repeat that joy on a promising platform by not coming up with an alternative? -jfr -- William Enck PhD Candidate Department of Computer Science and Engineering The Pennsylvania State University [email protected] -- Dianne Hackborn Android framework engineer [email protected] 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.
