Hello David - I agree that signage doesn't prevent malware. But it does allow for people to assert that a particular package/app has been approved by both the developer and the issuer/store. How they go about assuring there isn't malware is up to them and may involve a variety of mechanisms (contracts, people, automated tools, etc.) I suspect that B2G won't want to accept self-signed certificates. It would not lead to a robust eco-system and I also expect that the carriers would not accept that (or maybe require it to be removed if they don't notice it right away). It has been asserted that app stores would have some kind of relationship with Mozilla, so we may not want this either. And beyond that, signing allows for distinguishing versions. Related to that, I, as a consumer, would like to know when an app has changed. I don't want may apps changing on me willy nilly. There are definitely apps that I have purchased for my iPhone that I specifically did not upgrade when an upgrade became available, as I was concerned that functionality had been removed. It did turn out that in later upgrades the functionality came back, but I would want to allow the user to control that, not the developer unilaterally.
Just for fun, see http://www.youtube.com/watch?feature=player_embedded&v=k4EbCkotKPU It is has some relevance to the discussion. -Jim Straus On Mar 11, 2012, at 9:11 PM, David Barrera wrote: > I've been following this mailing list and thought I should chime in on > the topic of digital signatures for apps. > > On Sun, Mar 11, 2012 at 8:20 PM, lkcl luke <luke.leigh...@gmail.com> wrote: >> jonas. i'm a bit shocked and taken aback that you're saying this. >> do you understand why the debian project has the infrastructure that >> it has? >> >> this is *important*, jonas. >> >> if you do not understand what jim is referring to, and you are going >> to be the person in charge of implementing the security of B2G please >> for god's sake do some research into why debian digitally-signs all >> packages. >> >> you've come up with some absolutely fantastic ideas on the issue of >> B2G security but if you are, as you say, "not a big believer in code >> signing" this is a really big alarm bell. >> >> the simple version is: the reason why debian digitally signs each >> individual package is to ensure that malicious packages cannot be >> installed [on an uncompromised unmodified system]. >> > > Debian signs packages so that they can use mirrors to distribute > updates. Some mirrors might use http, some mirrors may be malicious, > some mirrors may be defective and exhibit file corruption. Digitally > signing each file allows client software to verify that the packages > originated from Debian, and that they haven't been modified in > transit. If Debian decides to package up malware (intentionally or > not), digital signatures will still verify. Signing is used for > authentication, not malware prevention. > >> if you do *not* have such a system in place it is incredibly easy for >> a malicious user to take any arbitrary package, wrap it with malicious >> code and release it under the exact same name. > > It is trivial to remove a signature from a package and re-sign it with > a different key. If the system is set up to only trust certain > certificates, this attack can be detected. If you are using, for > example, self-signed certificates and a trust on first use model (a la > Android), signatures don't help too much. You would need to check that > the first time you install a package, you got it from the right > source. > >> how do you prevent this from happening? jim has described the >> problem space, very very well. it turns out that there already exists >> a near-perfect solution to that problem (debian packaging). SSL is >> like... waayyyy down at the bottom of the infrastructure that is >> *used* by those solutions. > > SSL works well for authentication and as Jonas points out, it is well > understood by developers and the community. If B2G apps will *only* be > distributed through a single store, then SSL can provide the > authentication you need without the overhead of a signing/verifying > infrastructure. If there is going to be more than one app store, or > developers can distribute apps on their own, then I think it is > sensible to think about digital signatures. > >> l. >> _______________________________________________ >> dev-b2g mailing list >> dev-...@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-b2g > > > > -- > David Barrera > Carleton Computer Security Lab > Carleton University, Ottawa, ON. Canada _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
