so, essentially, you're trying to create a "key continuity" system rather than a "trusted certification" system. As you point out, the initial bootstrapping is outside the realm of what can be dealt with.
A public/private key pair could just as easily have a certificate created for it (self-signed certificate), and the add-on should be able to initiate adding the self-signed certificate to the certificate store. [The user should be prompted 'this is to allow X addon to automatically and securely update itself'.] This would allow for a standardized certificate revocation process (add-on author sends the certificate to a "revokeaddoncert" or such mailing address, perhaps signed using the private key to the certificate, stating that it is administratively revoked?) to be included in Mozilla suite updates. I would propose that a critical certificate extension be included in those self-signed certificates: 'name of Mozilla add-on'. This would allow the certificate's scope to be limited appropriately. It should also allow for the add-on's name to be blacklisted through the authorization mechanism [remember, certificates are designed to solve the authentication, not authorization, problem] even if the key is never manipulated in the user's certificate store to be 'untrusted'. The security of this system relies on two things: good key management practices at the developer side, and appropriate limitations implemented in the Mozilla software side as well. It allows for the re-use of the existing code and model in a way that does not require third-party intervention, while maintaining editorial control over badware. [For those not in the know: A 'critical extension' is a piece of information stuck in an X.509v3 certificate that is specified as 'if you don't know what this extension is, stop processing this certificate and return a certificate validation error'. When properly implemented, this would allow for the add-on update process to verify the signature of the add-on with a critically-marked certificate, without allowing that certificate to inadvertently be used for website authentication. If the critical extension includes the name of the add-on, then there comes a two-fold benefit: 1) it's cryptographically authenticated, and 2) An add-on that uses one key cannot be overwritten by any other -- for example, the 'firebug' add-on could not be overwritten by an add-on signed with a key that belongs to a 'firebad' add-on.] I will need to do some analysis to be able to describe/define the threat model against this type of system. I should point out that this is not a unique concept -- the One Laptop Per Child project insists on a key continuity management system rather than a certification authority system, though I have not looked at their threat model and analysis. Preliminarily, I like this proposal. I don't know how doable it will be, given the politics involved in the MoFo, but I think that it certainly bears looking into. (I'm suspending my own comments on the weaknesses involved until I analyze it -- but I've mentioned at least some of the already-existing pieces which can be re-used to reduce implementation time and effort.) -Kyle H On 6/14/07, Dave Townsend <[EMAIL PROTECTED]> wrote: > Hi all, I am looking for some feedback on a proposal I'm working on to > improve the security of add-on updates in Mozilla products. Let me give > an overview of the problem I wish to solve and then what I have come up > with so far as a potential solution. > > In the Mozilla applications we have an add-ons installed. I'm ignoring > how the add-ons are installed but let's assume that once there we have > some faith in them. The application periodically checks for available > updates to an add-on by downloading an update file from a url specified > by the installed add-on. > > What I want is to be able to be able to establish some trust that the > update file retrieved is correct, and has not been tampered with, > intercepted and is as it was originally written by the add-on author. > > The key problem is that I wish to do this in a way that does not cost > the add-on author any money (or at least a very small amount of money), > so getting a certificate signed by one of the root CA's is not an option > nor is serving the file from an ssl server. > > The potential solution that I am considering is by using a digital > signature. The add-on author, when he first writes the add-on creates a > public and private key. The public key is included in the add-on on > initial install. After that the private key is used to sign the update > file. In this way the application has the author's public key and can > use it to verify the signature of the update file. > > There are a few problems already pointed out: > > This all assumes that the initial add-on was not tampered with in the > first place. This is true however that is really a different problem for > the future, right now I have to concentrate on the update mechanism alone. > > If the add-on author has their private key compromised then of course we > lose all security. I don't see a real way around this but we have > certain possibilities in place (add-on blacklisting for example) that > could be called into play in such an event. > > Finally the public key for the add-on on the users machine could be > changed however in the event that someone has gained access to the users > machine I think ensuring the security of updates is a moot point. > > Now I am not an expert on cryptography so I would appreciate any > comments you have on other weaknesses in the proposal or any other > solutions or problems you think I might have missed. > > Cheers > > Dave > _______________________________________________ > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto > _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
