Hi Dianne, > I appreciate this discussion, but would like to make clear that we have no > plan to introduce a CA-based permission model in Android. [...]
Fair enough. CA is off the table as far as Google's involvement in developing Android code is concerned. I acknowledge it is a model that gives a lot of people angst for all sorts of real past experiences as well as perceived future lockdowns. By transition, I'd also suggest that pure reliance on Google's removing bad applications from Android Marketplace might also be off the table given that if the Android team philosophically resists having an entity deciding what people can install, it should follow that they the Android team would also resist Google being that deciding entity. So let's explore the trusted authorities model danfuzz proposes. > 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. I think danfuzz's model is elegant for installation of new applications, if there is a defined standard for how such a trusted authority can be established, added onto the device or removed by the end user, updated over the air, etc, it could be a very effective way of preventing new distributions of bad applications. So it could be a good vaccination mechanism. How could we add a cure mechanism to that? If an application is discovered to be noxious or part of a noxious web and is already installed on a device, a trusted authority model could be enhanced to allow for a push type of deinstall notification coming from that trusted source. So it's something like a centrally managed CRL without requiring a signature under the CA's root cert. Reasonable compromise? Side note: > It wouldn't be based on certificates, but rather > the particular .apk binary. I assume that there is no way that an application can modify its own binary or that one application can update another binary, thus invalidating binary signatures. Is that correct? Regards, -jfr On May 5, 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.
