Create a CAWG Identity threat model

[puhley]

Before the 1.0 release, a threat model should be created to ensure that the specification is robust against any potential attacks. While some of the issues can only be addressed at the implementation level, it is also possible for the specification to give flawed or incomplete guidance. In addition, a threat model will be a useful starting place for implementors to allow them to understand which threats are addressed by the specification and which threats are their responsibility to handle within the implementation.

Some expected attack vectors would include:

Replay attacks:

• Can an attacker extract the identity assertion out of one piece of content and embed it in another piece of content?
• Is there anything that makes the identity assertion unique to that piece of content?
• Does the C2PA validator need to do any checks to make sure that a replay attack is not occurring?

Name collisions (both intentional and coincidental). This is both a technical differentiation and UI differentiation.

• How do we differentiate between two John Doe's registered to the same identity provider?
• How do we differentiate between two John Doe's each registered to a different identity provider?
• How do we differentiate between anonymous reporters who need to remain anonymous at a technical level?
• How do we differentiate between anonymous reporters in the UI? If we allow them to specify what gets displayed for their ID, then that opens the door for impersonation attacks. E.g. I am "anonymous" but please display "Barack Obama" to the end-user.
• Is the end-user required to memorize serial numbers, cert chains, etc.? Do end-users need to keep a "phone book" of serial numbers that they trust?

Parsing and validation errors: The spec needs to be further along to really dig into these but it will need to be in the specification. However, here are a few common attack themes:

• Injection of code (HTML, JavaScript, etc.) into a text field so that the attacker can attempt to control what is displayed to the end-user. Does the specification support markup in the text fields? Should all fields be considered unicode strings?
• Text fields of excessive length: These can cause buffer overflows or could be an attempt to "push" trusted UI indicators out of the rendered view of the user. Should the specification place an upper bound of the length of given fields?
• Injection of special characters: These can be truncation attacks. For instance, if the UI parser is written in C, then an attacker might try to inject a null byte to cause discrepancies in the code about what should be displayed. Are they any special characters necessitated by the specification that need to be escaped before being placed into the text field of an assertion?

Homoglyph and typo-squatting attacks:

• These are common in phishing and impersonation attacks conducted on domain names and social media.

Response:

• If a bad actor makes it into the system, then how does that ID get blocked? Is there an OCSP/CRL/bad actor database/etc.?
• Does the C2PA validator need to do real time checks to ensure that the ID is still considered valid?
• What if the bad actor is in an ingredient and not the primary piece of content?

• What is displayed to the end-user in both the primary content and ingredient scenarios?

  This is a rough first draft to start the conversation. We can expand this list as we work. Once we get a fairly complete list, we can begin the process of converting this to an official document. For now, let's use the issue to start collecting ideas.

---

• [X] I have read the CLA Document and I hereby sign the CLA.

---

[paulengland]

Thanks for starting this -

There’s also a set of worries that originate from the fact that we have more than one signature. I’ve tried to mitigate (although not fix) these concerns in This issue documents security fixes to the identity map · Issue #95 · creator-assertions/identity-assertion (github.com) (and the related PR.)

Here's some explanatory text from the PR:

Identity Assertions primarily allow a credential holder to form a non-repudiable, tamper-evident binding between the credential subject and the list of referenced assertions. In some cases, the identity assertion provides an additional trust signal over the information provided by the C2PA Claim Signature, and in other cases, the Identity Assertion is of primary interest, and the Claim Signature provides supplemental information.

The Identity Assertion straightforwardly supports the former (trust-signal) case, because the Claim Signature integrity protects the identity assertion from stripping or replacement. This means that the identity assertion cannot be tampered without invalidating the Claim Signature.

However, the converse is not true. Without additional protections, the identity assertion does not guard against the Claim Signature being stripped and replaced. The mechanisms described in this section provide protections against this attack.

The Claim Signature protects against stripping or modification of an identity assertion because the hash of the identity assertion is included in the Claim Signature. Unfortunately, it is not possible for the identity assertion to include the hash of the Claim Signature because it is not known when the identity assertion is created. This specification provides a weaker binding that allows the identity assertion creator to specify the key/certificate that is authorized to sign the Claim. This does not prevent a Claim Signature being stripped and replaced by the same Claim Signer, but it does prevent the Claim Signature from being replaced by a different Claim Signer. To enable this protection, the identity assertion creator can optionally include the hash of the Claim Signer credential/certificate authorized to (subsequently) sign the Claim. If these protections are not needed (for example, if the identity assertion is expected to be a supplemental trust signal), then the claim_certificate_hash field can be omitted.

Similar security considerations apply in the case of multiple identity assertions. If more than one identity assertion is present, then earlier-created identity assertions that are referenced by hash by later-created identity assertions are protected from modification. However, later-created identity assertions are not protected from being stripped and replaced. This attack can be mitigated by each identity assertion stating the hash of the credentials/certificates that are authorized for use by other identity assertions, in a very similar way to how the claim_certificate_hash field is used.

Finally, note that referenced_assertions field MUST include the JUMBF URI of all of the assertions in this Claim, although the assertion hashes may be omitted (apart from for one hard-binding assertion). This guards against additional assertions being added that were not authorized by the identity assertion creator.

[puhley]

Adding notes for future reference: Replay attacks are, at least partially, being addressed by adding a hard binding reference in a to-be-signed map: https://github.com/creator-assertions/identity-assertion/pull/75

[puhley]

Note: The C2PA signer should not be considered to be trusted in this threat model. We have to consider the possibility that the the C2PA signing system gets compromised since we are dealing with nation state actors. The identity assertion and identity credential should not be able to be compromised by a malicious/compromised C2PA signing system. For instance, all signatures should be created within the signer's environment and the payload provided to the C2PA signing system must be what is to appear in the final image. In addition, the identity assertion should contain a hard binding within the signature provided to the C2PA signing system so that the C2PA signing system can not embed the identity assertion into other images.

[christianpaquin]

Note: The C2PA signer should not be considered to be trusted in this threat model.

Right. That's one of the motivations behind PR #96.

[scouten-adobe]

Closed by #99.