348
edits
Apps/WebApplicationReceipt/GenerationService: Difference between revisions
Jump to navigation
Jump to search
Apps/WebApplicationReceipt/GenerationService (view source)
Revision as of 21:53, 29 March 2012
, 29 March 2012→Threat Model
| Line 43: | Line 43: | ||
# '''Threat:''' An attacker could capture a signing key and export it from the signing node. They could make as many receipts as they like. | # '''Threat:''' An attacker could capture a signing key and export it from the signing node. They could make as many receipts as they like. | ||
## ''' | ## '''Countermeasures:''' | ||
## | ### The attacker needs to attach the certification for the key for it to be accepted, and the certification contains a not-after date. The attacker would not be able to produce certificates that would be acceptable past that date. That said, we might want the not-after date to be substantially in the future, so we take additional steps if the theft is detected. | ||
### If we detect the theft of the signing key, we revoke it internally and begin a root key reset and reissuance as described in Appendix C. | |||
### If we do not know that a signing key has escaped into the wild, the only clue we would receive is when the verify_url is invoked with a receipt that passes cryptographic verification but does not match the transaction log. This condition would be indistinguishable from database corruption but should trigger immediate warnings. | |||
# '''Threat:''' An attacker could compromise a signing node and create as many receipts as they like. | # '''Threat:''' 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. | #* '''Countermeasure:''' Infrasec will correlate the signing activity log with actual requests from the Marketplace. | ||