Apps/WebApplicationReceipt/GenerationService: Difference between revisions

* [kang 2012-05-11] In Appendix B, the public key which is the root of the trust is stored on a HTTPS webserver. This means if the webserver is compromised, the key can be replaced by any key and the applications will trust it (which may be what you meant by "compromise SSL"). A possible recommendation (note: this is *only* a possible recommendation) would be to generate 2 keys in the HSM, lets call them master key and sub key. The master key sign the sub pub key, and we place it on the HTTPS webserver. All apps verify up to the master key, enforcing that, any key must be signed by the HSM master key in order to be trusted (so if someone replace the key on the HTTPS webserver it won't work. he would have to also compromise the HSM). It also means the trust is established at the first fetch of the master pub key (and that the same threat still exists at this level, but once trusted you would keep it, while the sub key can be replaced. This also means devices such as B2G devices could ship with it, and that also means the master key can be on a different server (so you would have to compromise 2, to compromise the first fetch). Yet another possibility is to simply have a warning on the application side prompting to accept the key when the master/root key changes (which should only occur when something really wrong happened, aka server or key has been compromised)