Responding to Issue #48 #59
Conversation
I wrote a response to Issue #48 for this page. @JustinCappos offered to do a write-up on the other two questions on the page. The text above is basically taken from the text @JustinCappos and @tkfu already had shared on the discussion thread. I blended those comments and then @patrickvacek looked over my draft and made some suggestions.
| @@ -5,4 +5,30 @@ css_id: faq | |||
|
|
|||
| # Frequently asked questions | |||
|
|
|||
| ### **What makes Uptane different from other SOTA security mechanisms?** | |||
|
|
|||
There was a problem hiding this comment.
| Security problems occur due to accidental disclosures, malicious attacks, disgruntled insiders. It is not | |
| a matter of whether a successful attack will occur, but when. One key feature of a security system is the | |
| ability to securely recover from an attack. This means that an update system must have a way to securely | |
| recover from a key loss or compromise. | |
| For example, suppose a nation-state actor steals a signing key and wants to use it to distribute software (as has | |
| happened before) [cite Iran, etc.]. The update system must provide a way to revoke the current trusted | |
| information even if the adversary is able to be a man-in-the-middle for future communications. Uptane | |
| is designed to provide strong security in cases like these and is designed so that failures are | |
| compartmentalized and limited in scope. | |
| No other automotive update system has been designed to work in such rigorous situations or has | |
| received the public scrutiny of Uptane. We follow best practice in the security community by having | |
| wide-scale, public review. This has been proven to be essential time and time again to ensure a | |
| design will hold up against attackers, especially those as strong as nation-state actors. Furthermore, | |
| Uptane's design is heavily influenced by the design of TUF, a widely used software update system | |
| with a strong track record of usability and security across millions of devices. As a free and open | |
| standard, with no cost to use or adopt, Uptane stands alone in the automotive update space. | |
There was a problem hiding this comment.
Might be easier to review this if it were a separate PR. The linebreaks aren't helping, either.
|
|
||
| ### **How does Uptane work with other systems and protocols?** | ||
|
|
||
|
|
There was a problem hiding this comment.
Other mechanisms for performing update such as XXX, YYY, ZZZ, are compatible with Uptane. Uptane can use
any mechanism for data transport and is designed to provide strong security guarantees even if the
underlying network or transport mechanism is compromised. If an automaker wants to move to a secure
update system, keeping their existing update system as a transport for Uptane is an effective way to do so.
Co-authored-by: Patrick Vacek <patrickvacek@gmail.com>
Co-authored-by: Patrick Vacek <patrickvacek@gmail.com>
Co-authored-by: Patrick Vacek <patrickvacek@gmail.com>
Co-authored-by: Patrick Vacek <patrickvacek@gmail.com>
|
Can we merge the Pull Request as is, and them open a new one to review and comment on @JustinCappos new text? It might become a bit unwieldy if we keep adding commits. |
There was a problem hiding this comment.
Can we merge the Pull Request as is, and them open a new one to review and comment on @JustinCappos new text? It might become a bit unwieldy if we keep adding commits.
Agreed, I think that'd be easier to work with. This can be merged now as far as I'm concerned.
|
I'm merging this branch now, which closes Issue #48. I will open a new pull request for suggested comments/changes on the newer copy on this thread. |
I wrote a response to Issue #48 for this page. @JustinCappos offered to do a write-up on the other two questions on the page.
The text above is basically taken from the text @JustinCappos and @tkfu already had shared on the discussion thread. I blended those comments and then @patrickvacek looked over my draft and made some suggestions.