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]
