Apps/WebApplicationReceipt/GenerationService: Difference between revisions

An attacker could capture a signing key and export it from the signing node.  They could make as many nodes as they like.

Countermeasure: The certification of the signing key would expire after a short number of days; from that point onward the attacker could not mint new receipts.  (XXX wait, that's not right, you could mint new receipts for the old time range, but they're still acceptable.)

An attacker could compromise a signing node and create as many receipts as they like.

Countermeasure: Infrasec will correlate the signing activity log with actual requests from the Marketplace.

An attacker could create their own receipt, sign it with their own key, certify that key with their own private key, and attach that.

Countermeasure: The developer must verify that the chain is based on a public key that comes from the store the receipt claims to be from.

An attacker could compromise the public key distribution point of Marketplace, place their own key there, and produce their own receipts rooted in that key.

Or: Attacker could compromise the SSL chain leading to the public key distribution point and MITM their own key.

Countermeasure: Changes to the public key should be accompanied by out-of-band signaling from Marketplace; any other change is an attack.  Geographic tripwiring would be needed to catch the MITM.

An attacker could compromise k-of-n Mozilla employees, and export the private key.

An attacker could compromise the channel through which the public keys are relayed from the root trust nodes to the distribution point, and place their own public key in the list.