C2PA Security Considerations

Attacks against hardware implementations of C2PA would attempt to leverage the trust of the hardware manufacturer. For example, a camera lens sends digital information to the camera’s CPU to sign what was captured. A hardware attacker might inject their own data between the lens and the camera’s CPU to convince the camera to sign fake images.

Attacks against a PKI infrastructure might leverage several techniques. A simple example of this attack would be creating a self-signed certificate that spoofs a legitimate certificate in an attempt to exploit a flaw in the validator’s implementation of trust list verification. Another example attack would be to socially engineer a certificate authority to sign content with another user’s credentials. These attacks could also include attacking the cryptographic algorithms used in the signature. Lastly, the attacker could attempt to steal a signing key either through compromising a signing service, compromising a user’s credentials to the signing service, or stealing the hardware used by the image creator. In addition to the guidance described below for specific threats, further cryptography recommendations are provided in the Trust section of the Guidance for Implementers.

Attackers targeting the user interface would create malicious manifest data that targets the user interface in which the user views the rendered content credentials. In this scenario, the attackers would embed malicious data into the C2PA metadata. When an end-user uses a user interface to view the C2PA metadata, the malicious data would be extraced from the asset and presented to the end user. This data could attempt to confuse the end-user directly. For instance, the attacker might try to use homoglyph attacks to confuse the end-user regarding the text that they are reading. Alternatively, the attacker might attempt to inject malicious data that could take control of the user interface and interfere with what is presented to the end-user. As an example, a flaw in a web-based user interface might allow the malicious manifest data to be interpreted as code by the web browser which would result in cross-site scripting. If the attacker’s malicious payload is interpeted as JavaScript by the web browser, then the attacker could manipulate the trusted user interface into presenting false information to the end-user.

Consumer attacks would focus on victimizing the human users of C2PA implementations. For instance, they might leverage how the C2PA specification allows remote manifests and references to other remote data to track and identify viewers of the content. When a person views Content Credentials, their client may make requests to these resources. If the remote resources are hosted by the attacker, the attacker could track which IP addresses have viewed specific assets. In countries where viewing certain types of content is prosecuted, this could result in the viewer’s life being put at risk. In addition, it may be possible to frame someone for viewing banned content. An attacker could take a safe image and embed a banned image containing remote C2PA metadata as an ingredient. While the user would only see the safe image, they would be flagged for looking at banned content when the manifests for the embedded ingredient are resolved.

These attacks would focus on exploiting the software or hardware involved in C2PA Manifest processing. An example of this type of attack would be generating a C2PA Manifest with a sufficiently large payload to perform a buffer overflow. An attacker might also include malicious manifests that result in an image being misclassified by implementations that correlates C2PA information.

These attackers would have a thorough understanding in the C2PA specification and look for potential flaws in the C2PA guidance. While every effort is made to ensure that C2PA guidance is secure, a threat model would not be complete without taking into account the possibility for a mistake in the guidance or a change in the threat landscape that undermines the core tenets of the specification. Similar specifications have improved with each new version as a result of issues identified in the previous version. The threat model must take into account the possibility that the C2PA specification will have an unforeseen issue requiring an update to the specification and potential action by the C2PA community.

One method for attacking the specification is to undermine people’s trust in the technology. For instance, frequent attacks spoofing information from C2PA Manifests, while not the direct fault of the specification, could wear on the community’s patience and trust of the technology. If these attacks result in frequent efforts on the part of the end-user to verify that the content is not a spoofing attack, then they will lose patience from the extra required effort and abandon the technology. Once the community abandons the technology, attackers can revert to their original techniques for creating disinformation. The community needs be aware of malicious disruptors in the community and work to minimize their impact.

These types of attacks are focused on human assumptions rather than technical attacks. For instance, one attack might be to take a photo of an image rendered by a high-definition television. The image captured by the device would be technically valid and realistic. However, without proper contextual information, a viewer of the image would assume that it was taken of a real event rather than a manufactured TV image. Similarly, there are also techniques for creating optical illusions for cameras. In these instances, the capture device correctly records and signs what came through the camera lens. However, the resulting image leads the viewer to a false conclusion about the event.

Description

An attacker removes C2PA Manifests from an asset delivered with hard bindings. For example, by downloading C2PA-enabled media from a social media site, stripping the C2PA Manifest(s), and re-posting it.

Prerequisites

Technical ability to strip provenance data from published or stored assets and deliver the stripped assets targeted users or systems. For example, via republishing to social media or on-path attacks.

Impact analysis

It is possible for an attacker to remove metadata as described. Depending on the context, this could cause a user agent not to display provenance information associated with the asset.

Security guidance

The impact of this threat scenario could be mitigated through use of manifest repositories, e.g., by making C2PA Manifests available to user agents when embedded manifests are missing.

Use of manifest repositories can introduce security and privacy issues. See the Content binding security section for more information.

Description

An attacker removes metadata from within C2PA Manifests(s) stored in a asset delivered with hard bindings, such as the assertion store, individual assertions, claims, claim signatures, etc. For example, by downloading C2PA-enabled media from a social media site, stripping the target C2PA metadata, and re-posting it.

Prerequisites

Technical ability to strip provenance data from published or stored assets and deliver the stripped assets targeted users or systems. For example, via republishing to social media or on-path attacks.

Impact analysis

It is possible for an attacker to remove information from inside of a C2PA Manifest as described. However, validation checks as implemented by a C2PA validator will detect any complete or partial removal of data stored within C2PA Manifests due to the use of cryptographic hashes in the hash-uri-map structures stored within the claim. The data within the claim is protected by the claim signature. The hashed-uri-map structures within the Manifest Store are not a security protection which is why removal of an entire C2PA Manifest is possible, and described as a distinct threat scenario.

This is similar to the case of stripping all C2PA metadata. However, in this scenario there is an added benefit that user agents can explicitly detect the attempt to remove metadata as part of the validation process.

Security guidance

The impact of this threat scenario is mitigated through explicit detection of missing metadata through the standard C2PA validation process and factoring this into system behaviour. For example, a user agent would display the affected asset differently than a non-modified asset. (For more information about the user experience aspects, see C2PA’s UX Guidance)

The impact of this threat scenario could be also mitigated through use of manifest repositories, e.g., by making decoupled C2PA Manifests available to user agents when embedded metadata is missing.

Use of manifest repositories can introduce security and privacy issues. See the Content binding security section for more information.

Description

An attacker copies valid, hard-bound C2PA metadata, such as assertions, claims, or entire C2PA Manifests, from one C2PA-enabled asset to another.

Prerequisites

Technical ability to strip provenance data from published or stored assets and deliver the stripped assets targeted users or systems. For example, via republishing to social media or on-path attacks.

Impact analysis

An attacker is able to perform the copying as described. However, C2PA hard bindings provide a cryptographic binding between assets and C2PA Manifests via claim signatures. Thus, validation checks (e.g., as implemented by a user agent) will detect the replaced C2PA Manifests.

This is similar to the case of stripping all C2PA metadata. However, in this scenario there is an added benefit that user agents can explicitly detect the attempt to remove metadata as part of the validation process.

Security guidance

The impact of this threat scenario could be mitigated through explicit detection of incorrect metadata as described here, and factoring this into system behaviour. For example, a user agent would display the affected asset differently than a non-modified asset. (For more information about the user experience aspects, see C2PA’s UX Guidance).

The impact of this threat scenario could be also mitigated through use of manifest repositories, e.g., by making decoupled C2PA Manifests available to user agents when embedded metadata is missing.

Use of manifest repositories can introduce security and privacy issues. See the Content binding security section for more information.

Description

An attacker compromises the confidentiality of a claim signing key and uses it to attach valid, malicious provenance to a asset.

Prerequisites

Ability to read and use a valid C2PA claim signing key. For example by stealing it from a claim generation and signing system. Ability to copy, modify, or generate assets, add desired (valid) C2PA provenance metadata to them, and deliver them to targeted users or systems. For example, via republishing to social media or on-path attacks.

Impact analysis

An attacker that is able to steal a signing key can spoof valid C2PA Manifests on arbitrary assets. This applies to both hard and soft bindings. Valid claim signatures will be limited to the exposed key; an attacker cannot impersonate other signers in this scenario. These manifests will pass validation checks. Further, an attacker will be able to continue to generate assets with spoofed provenance until the compromised credential is revoked, and revocation status is propagated to the targeted users/systems.

If the signer’s credential type does not support or provide a means for revocation, it may be necessary to remove the trust anchor associated with the signer’s credential from the respective C2PA trust list to effectively revoke the malicious manifests. In this case, all manifests associated with the trust anchor will be invalidated.

Revocation of the signing key associated with the malicious manifests may invalidate other manifests if signing keys are reused between claim generation / claim signing system users.

Security guidance

Claim generators must adhere to best practices for securing keys in their respective operating environments. This includes using platform-specific best practices for key storage and management (e.g., hardware security modules, key management services), minimizing key reuse, and revoking keys when compromise is suspected. For more information on key management, see the NIST Key Management Guidelines.

Signing keys should not be used for multiple purposes. For instance, the claim signing key should not be used for anything other than signing the claim itself. They also should not be used across multiple claim generation tools. This can reduce the harm caused by a leaked or compromised key. It is also highly recommended that all signing credentials include revocation information.

Description

An attacker misuses a legitimate claim generator (e.g., photo editing service) to add misleading provenance to a C2PA-enabled asset.

Prerequisites

Ability to access and exploit or misuse a claim generator system. For example, misuse of a claim generator may result in malicious additions of C2PA Manifests, Assertions, or Claims to assets; exploitation of vulnerabilities in claim generators may lead to modification or tampering with existing C2PA Manifest data added with the target claim generator’s signing key(s). Ability to deliver assets to targeted users. For example, via publishing to social media or on-path attacks.

Impact analysis

An attacker may be able to misuse or exploit a claim signing system to create malicious C2PA Manifests that can then be delivered to targeted users/systems. For instance, assume that a camera manufacturer creates C2PA manifests for photos taken with their cameras. The goal of the camera’s implementation is only to support assertions related to the camera hardware and information collected by the camera at the time of capture. The camera manufacturer does not support adding any other assertions to their claims. An attacker may try to inject their own assertions into the camera’s claim signing process to make it appear as though their malicious assertions also originated from the camera manufacturer. For instance, if the camera manufacturer did not support identity-related assertions, then the attacker might try to inject an identity assertion with the hopes that consumers of the image would assume that the camera manufacturer validated that identity. The list of possible assertions that would be useful for an attacker to attempt to inject would be contextual to the specific service or device.

Note that valid claim signatures will be limited to credentials used by the targeted claim signing system; an attacker cannot impersonate other signers in this scenario.

If the signer’s credential type does not support or provide a means for revocation, it may be necessary to remove the trust anchor associated with the signer’s credential from the respective C2PA trust list to effectively revoke the malicious manifests. In this case, all manifests associated with the trust anchor will be invalidated.

Revocation of the signing key associated with the malicious manifests may invalidate other manifests if signing keys are reused between claim generation / claim signing system users.

Security guidance

Claim generators must adhere to industry best practices for information security and anti-abuse practices, including leveraging available platform-specific features for deployment (e.g. Android Play Integrity, Apple DeviceCheck). Likewise, claim generators should use platform-specific best practices for key storage and management. For example, usage of hardware security modules, key management services), minimizing key reuse, and revoking keys when compromise is suspected. For more information on key management, see the NIST Key Management Guidelines.

Signing keys should not be used for multiple purposes. For instance, the claim signing key should not be used to also sign the values of assertions or actions. They also should not be used across multiple claim generation tools. This can reduce the harm caused by a leaked or compromised key. It is also highly recommended that all signing credentials include revocation information.

Whenever technically possible, the claim signing service should validate that the request originated from a trusted source. In addition, claim generators should add data validation logic that confirms that the supplied data does not include any unexpected or unsupported assertions. All supplied assertion types should match the allow list of supported types for that claim generator and there should only be the expected number of assertions for each assertion type. The allow list for a specific claim generator may be more specific than the validation checks specified within the C2PA specification.

A claim signing service can optionally consider checking the values within the assertions when data validation is possible. These checks would not be intended to increase the public perception of the validity of the data. Instead, the data validation checks would help the claim generator to detect and limit abuse of their system by bad actors.

Description

An attacker causes a C2PA claim signing key issuer to issue a valid signing key to them. They then use this signing key to add misleading provenance to a C2PA-enabled media asset.

Prerequisites

Ability to bypass unspecified processes for obtaining a claim signing key.

Impact analysis

An attacker that is able to obtain a legitimate claim signing key can spoof valid C2PA Manifests on arbitrary media assets. These manifests will pass validation checks. Further, an attacker will be able to continue to generate media assets with spoofed provenance until the compromised credential is revoked, and revocation status is propagated to the targeted users/systems.

It may be necessary to remove the trust anchor associated with the signer’s credential from the respective C2PA trust list to effectively revoke malicious manifests. In this case, all manifests associated with the trust anchor will be invalidated.

Security guidance

The C2PA does not currently specify requirements regarding issuance of claim signing keys. It is recommended that these processes be robust against exploitation and misuse. The CAB Forum Baseline Requirements provide a working example of security requirements for signing credential issuers.

Description

An attacker finds a media asset with a C2PA Manifest Store that includes an ingredient manifest with a signature from valid, non-public, credentials. They replace the ingredient manifest with a malicious manifest.

Prerequisites

Ability to discover media with susceptible ingredient manifest and generate a malicious replacement. And deliver the media asset to the target users/systems.

Impact analysis

Validation of ingredients is optional, however, validation of the hash of the ingredient’s manifest at the time it was added to the active manifest as an ingredient is not. See the Validation section of the C2PA specification for details.

While a C2PA validator is not expected to have access to the original, non-public, signing credential nor to the original ingredient asset, it can differentiate between the original and compromised provenance by checking the hashed_uri present in the ingredient assertion. Since the malicious manifest will not match the original, the validator is able to detect the attack.

Security guidance

Claim generators should add review ratings to their assertion metadata to propagate their assessment of ingredients to downstream consumers. When this validation is performed on both media assets described in this scenario, downstream consumers will be able to differentiate between them.

Description

An attacker generates a malicious media asset whose soft binding matches the soft binding of a legitimate, target media asset. The attacker creates a decoupled, soft-bound manifest for the malicious media asset and injects it into a manifest repository. The malicious media asset is then delivered to the target/system user, which retrieves the legitimate C2PA Manifest via the common soft binding.

Prerequisites

Ability to generate a colliding soft binding for a target media asset and publish the resulting manifest such that it will be retrieved by the target user/system for the target media asset. Also requires that access to be able to add manifests to a manifest repository.

Impact analysis

Malicious media bound to legitimate C2PA provenance data is validated and presented to the target system/user.

Security guidance

C2PA provides guidance on applying soft bindings, which may include algorithms for mitigating this type of attack. See the content binding documentation for details.

Description

An attacker generates a dummy media asset whose soft binding matches the soft binding of another media asset. They then use a claim generator to create a valid, malicious C2PA claim(s), and a C2PA Manifest. They then publish the C2PA Manifest to a manifest repository. When the target media asset is validated, the malicious C2PA Manifest is retrieved via the common soft binding.

Prerequisites

Ability to generate a colliding soft binding for a target media asset and publish the resulting manifest such that it will be retrieved by the target user/system for the target media asset.

Impact analysis

Malicious provenance data bound to a legitimate media asset is validated and presented to the target system/user.

Security guidance

C2PA provides guidance on applying soft bindings, which may include algorithms for mitigating this type of attack. See the content binding documentation for details.

Description

Each manifest has a digital signature that includes a hash of the original content. An assertion is redacted by using zeroes to overwrite the relevant section of the manifest. However, the original hash remains a part of the image via the signature. The redaction information includes information on the type of data that was redacted from the original manifest. An attacker may try to guess what was originally contained within the assertion by brute-forcing the potential values until they find a value that matches the original hash. While many bytes will have been replaced with zeroes, the standardization of the formatting means that many of those bytes will be predictable. In addition, brute forcing of all possible values may not be necessary for certain situations. For instance, an attacker may just want to confirm whether the image was created using a short list of individuals that they are interested in. Therefore, they would only need to test whether author assertions with those values match the hash. Some data types, such as geolocation, have a finite set of overall values and even smaller set of likely values if you can make certain assumptions about where the photo might have been taken. Therefore, without mitigations, it might be possible to brute force the original values of certain redacted data types.

Prerequisites

The attacker needs to have access to a compute resource capable of brute-forcing the expected space of the redacted field that they are targeting. If a unique, cryptographically random C2PA salt was included with the assertion, then brute-forcing the original value should not be feasible.

Impact analysis

The ability to recover redacted data would jeopardize any safety and security provided by the redaction.

Security guidance

A C2PA salt must be included with each assertion. The salt must be cryptographically random, unique for each assertion, and either 16 or 32 bytes in length. This approach results in the attacker having to brute force both the combination of original value and the randomized salt corresponding to that value. The inclusion of randomized salt should make this technique infeasible.

Description For some workflows, a claim generator will have assertions that it creates within its own trusted environment, referred to as "created assertions." The claim generator may also accept assertions from clients outside of its environment, called "gathered assertions." An attacker may try to cause parsing errors or confusion in parsers by injecting gathered assertions that overlap with the created assertions. As an example, an untrusted client might try to send their own "claim_generator" assertion with the intent that their gathered assertion value will override the created assertion value from the claim generator within a UI. An attacker may also try to confuse the claim generator parser by sending created assertion types within their gathered assertions.

Prerequisites The attacker must be able to send customized assertions to a claim generator. The claim generator needs to have a flaw where created assertions and gathered assertions are not properly separated. Alternatively, a Content Credentials UI must have a flaw where the gathered assertion values override the created assertion values or appear to have precdent over the created assertions values.

Impact analysis An attacker may be able to override the values within the created assertions with their own values. This can undermine the trust that the claim generator has with the community. End-users viewing C2PA data may be confused as to which values are correct.

Security guidance Claim generators should ensure that gathered assertions can never be inserted into the map of created assertions. Claim generators may choose to have a deny list blocking claim signing requests where it is clear that an attacker is sending assertions that conflict with their created assertions in order to prevent abuse within their environments. C2PA UI implementations should clearly seperate gathered assertions from created assertions within the UI so that end-users can distinguish between the two sources.

Description

A common attack for this category would be cross-site scripting. An attacker could inject malicious JavaScript into a claim. When a web user interface renders the claim details for an end-user, the malicious JavaScript within the claim may get executed by the web browser. This could result in manipulating the behaviour of the trusted user interface and misleading the end-user. Another attack in this category might be the injection of special characters that prevent the UI from displaying the full data included in the claim such as nulls or carriage returns. UI rendering attacks could also include the use of homoglyph attacks to confuse the end-user regarding the text that they are reading. Lastly, the attacker could try visual attacks where an image within the asset, such as a thumbnail or icon, is designed to confuse the end-user. For instance, the image could contain text such as, "Verified by …​" or a lock icon.

Prerequisites

The attacker needs to have access to a claim signing mechanism that will allow for arbitrary text within signed claims. This could be a self-signing mechanism if the targeted implementation does not limit content based on the certificate authority.

Impact analysis

The viewer of the claim metadata will be misled with regards to the validity of the image. As an example, if the malicious payload contained attacker controlled JavaScript that was interpreted by the web page displaying the C2PA metadata to the end-user, then the attacker could manipulate the UI so that the viewer would see fake signing information or incomplete claim information.

Security guidance

Prior to claim signing, signers can verify that the fields provided contain the expected characters, length, and format for the given field. When displaying Content Credentials, implementations can leverage output encoding to prevent special characters from being interpreted as code. In addition, attacker controlled data should be displayed in text fields that do support code execution and that can correctly handle data of unexpected lengths. For web applications, a Content Security Policy (CSP) can help mitigate certain types of attacks.

As an example, one of the potential vectors for this class of attack would an SVG file that contains malicious JavaScript. The C2PA specification currently supports SVG images as the primary asset or ingredient. In additon, the C2PA specification supports SVG files as the icon within the generator-info-map. Therefore, it is necessary to be cautious when rendering SVG files either directly or as part of supporting claim generator icons. Implementations should apply best practices to prevent the execution of JavaScript such as ensuring that the image is loaded from a separate domain from the UI, loading the file through the use of HTML img tags, and applying a Content Security Policy to prevent the execution of JavaScript within the SVG image.

Description

Many organizations may try to index and store C2PA data for the purposes of search, data analytics, or similar functionality. An attacker may want to prioritize their image in the result by interfering with the classification of this image. A likely attack for this scenario would be SQL injection in order to manipulate the database of stored information.

Prerequisites

The attacker needs to have access to a claim signing mechanism that will allow for arbitrary text within signed claims. This could be a self-signing mechanism if the targeted implementation does not limit content based on the certificate authority.

Impact analysis

The implementation attempting to store and organize the data may become controlled by the attacker.

Security guidance

Implementations storing data within a database should follow the security best practices for their database solution. As an example, common best practices for SQL database include prepared statements and stored procedures. The implementation may also choose to implement data validation prior to storing the metadata and reject any images that have potentially malicious data.

Description

Applications written in memory unsafe languages, such as C and C++, may be vulnerable to techniques such as buffer overflow, heap overflow, and use-after-free attacks. These vulnerabilities could be present in the main application or within the third-party libraries supporting the application. All applications, regardless of language, need to maintain any third-party libraries in use to ensure that they are fully patched. The malicious file may be the primary asset, a sub-asset such as a thumbnail, or a remote asset that is loaded after the intial asset is parsed. An attacker may try to confuse the parser by including remote or child assets that are of an unexpected data type. In addition, all applications may be vulnerable to flaws in the application logic resulting in attacker-controlled conditions.

Prerequisites

The attacker needs to have access to a claim signing mechanism that will allow for arbitrary text or the ability to manipulate the binary structures within signed claims. This could be a self-signing mechanism if the targeted implementation does not limit content based on the certificate authority. For web-based applications, this could also include the ability for the attacker to control the parameters sent within a web request.

Impact analysis

These types of attacks frequently lead to system compromise of the environment in which the application is running, such as an end-user’s desktop or mobile device. If the attacker controls the system, then the system can no longer be trusted for any function.

Security guidance

The implementation should consider using memory safe languages for its implementation. Data validation should be performed to ensure that inputs are of the proper length and format. An implementation may also choose to perform fuzzing to validate the software can robustly handle unexpected input. Have a process to ensure that third-party dependencies are kept up to date. Perform regular security testing of the software to identify any potential logic flaws in the implementation. If possible, conduct active monitoring of the environment to detect attack attempts. Additional information can be found in the Validation section of the Guidance for Implementers .

Description

An attacker may choose to target the infrastructure of the C2PA implementation. These attacks could include exploitation of misconfigurations within the hosting environment, exploitation of hosting provider, or network security vulnerabilities.

Prerequisites

The attacker needs to be able to identify a flaw in the implementation’s services or configuration that can be remotely exploited.

Impact analysis

The attacker could gain control of the hosting environment for the C2PA implementation making the C2PA implementation untrustworthy.

Security guidance

Implementations should ensure that they follow all hosting provider’s security best practices. Server software and hardware should be kept up to date. Conduct regular network penetration testing against the environment to ensure that no known vulnerabilities are present. In addition, ensure that there is active monitoring of the environment to detect any attacks. Mobile applications can verify the integrity of the host environment by using the operating system’s verified integrity APIs such as Android Play Integrity and Apple DeviceCheck

Description

An attacker may try to intercept and/or modify traffic between two trusted components. These types of attacks are known as "adversary-in-the-middle" (AitM) attacks. An attacker can try to position themselves between two nodes on a network, such as a desktop application and a server. Alternatively, an attacker could try to insert themselves between two trusted processes or two trusted hardware components on the same device. If they are successful, then the attacker could monitor communication traffic between the two nodes searching for any secrets that are in transit. In some scenarios, an attacker may be able to modify the request before it reaches the final destination. These types of attacks could allow an attacker to inject malicious content or modify trusted data within the C2PA metadata. Lastly, they may be able to replay requests between the two endpoints in order to cause sensitive actions to be repeated at their discretion.

Prerequisites

The attacker needs to have the ability to insert themselves along the path of communication between two endpoints. This may involve impersonating the destination, controlling a relay device such as a network router, or having the capability to monitor the path along which the request is sent. For some types of impersonation attacks, the attacker may need to have a malicious certificate or certificate authority added to the trust list of the device.

Impact analysis

The attacker could capture secret or sensitive data being sent between the two endpoints. If the attacker can modify the request or response before it reaches its destination, then the attacker could try to modify the victim’s asset or the included assertions before signing. Alternatively, the attacker could use the technique to get their own malicious content signed by the trusted claim signer. In the case of a replay attack, the attacker could cause the same sensitive action to be repeated multiple times. The goal of a replay attack will depend on the specifics of the system architecture. Possible goals could include the unintended re-use of a unique identifier, the leakage of sensitive information or system state over multiple requests, or the signing and time-stamping of additional, attacker-controlled content.

Security guidance

There are several different techniques to protect data in transit depending on the situation. Ensure that all communication between two nodes is encrypted whenever possible. When using TLS, verify the entire certificate chain to ensure that the attacker is not impersonating a certificate authority. Leverage protected channels that an attacker cannot access when available. Another possible technique is to ensure that each communication includes a unique identifier. The receiving system can check that the unique identifier has not already been processed in order to prevent the same action from being repeated multiple times by a replay attack.

Description

The C2PA specification is an evolving standard. As new versions of the specification are released, the older versions may contain vulnerabilities that have been fixed in the newer versions. An attacker may try to exploit these vulnerabilities in implementations based on the older versions of the specification. In addition, the newer versions of the specification may contain important security enhancements that provide defense-in-depth against possible future attacks.

Prerequisites

The attacker needs to have the ability to identify the version of the C2PA specification that is being used by the target. The attacker also needs to have the ability to exploit the known vulnerabilities in the older version of the specification.

Impact analysis

The attacker could gain control of the C2PA implementation by exploiting the known vulnerabilities in the older version of the specification. The specific impact would depend on the version of the specification and the vulnerability. Theoretically, these types of vulernabilities might include the ability to bypass the validation checks, the ability to inject malicious content into the C2PA metadata, or the ability to impersonate a trusted signer.

Security guidance

C2PA implementations should have the operational infrastructure to keep their implementations updated to the latest version of the specification. This includes having a testing infrastructure that can validate that the changes will not cause any new issues for their environment. For implementations that are delivered to third-parties, the implementation should have a process to notify their customers of any updates and have an easy path for their customers to apply the update. Implementors also need to have a plan for when prior versions of the specification become deprecated.

Description

In several places within the C2PA specification, there is support for loading remote content. These features include the ability to load remote C2PA manifests, remote ingredients, and remote claim generator icons. An attacker could use these features to track the viewer of the content when the remote content is retrieved by the C2PA user interface. This could violate the consumer’s right to privacy depending on the applicable laws. In addition, viewing certain types of content may be illegal in certain countries. An attacker could use this tracking to identify individuals who are viewing the content and then use that information to prosecute them. In addition, a person could be framed for viewing banned content by an attacker who embeds banned content as a hidden ingredient within what appears to be a safe image. The viewer would only see the safe image, but the attacker would be able to track the viewer based on the remote content that was retrieved when the ingredient data was processed. Another possible attack would be to use the remote content references to try to dynamically load malware onto the viewer’s system.

Prerequisites

The attacker needs the ability to generate signed, valid C2PA assets that includes remote references to content that they control. The attacker also needs to be able to monitor the requests made to the remote content.

Impact analysis

The privacy and anonymity of the consumer could be compromised. In addition, the consumer could be framed for viewing banned content.

Security guidance

When rendering C2PA metadata, clearly state whether remote content will be automatically loaded. If possible, provide the user with the ability to approve loading remote content each time it becomes necessary to access the data. This will allow the user to know when network requests related to the content are being made and to approve those network requests. If remote content is loaded, then consider using a trusted server to fetch the content for the end-user and then passing the data to end-user’s device. This would result in the trusted server’s IP address being shared with the remote site instead of the end-user’s IP address. For end-users, they would need to consent to the trusted server being aware of what content they are viewing and agree to how that data is handled by the trusted server. If the remote content is not necessary for the user to view the content, then it may be best to have a model where the remote content is not loaded at all or not loaded until the end-user explicity requests it.

Description

An attacker tries to leverage the trust in a known entity by obtaining a certificate with the same, or similar, name. One method for this attack is for the attacker using a different certificate authority than the identity that they are trying to impersonate. For instance, assume that example.org’s identity is provided by Alice’s Trusted Certificate Authority. An attacker may try to request an example.org certificate from Bob’s Trusted Certificate Authority. Since Alice and Bob are two different certificate authorities, the collision goes unnoticed. The consumer of the C2PA manifest may be unaware of whether example.org uses Alice or Bob’s trusted CA for their certificates. Name collisions can also occur without malicious intent when dealing with human identity since many people have the same name. Lastly, an attacker may try to conduct a homoglyph attack where they use characters that look similar to the target’s name.

Prerequisites

The attacker needs to have the ability to request a certificate from a trusted certificate authority using the identity of the target. The attacker may also try to obtain a certificate that is visually similar to the target’s certificate using homoglyphs.

Impact analysis

The viewer of the claim metadata will be misled with regards to the author of the C2PA content. This can result in the viewer mistakenly assigning trust to something that they would consider untrusted.

Security guidance

When providing identity information to manifest consumers, provide the details of the full certificate chain. If possible, leverage the certificate hash or other available unique identifiers to verify that the certificate represents the expected identity. If possible, leverage certificate transparency logs to monitor for potential certificate collisions.

Description

C2PA content can have multiple identities associated with it. However, those identities may not have a trust relationship. Assume that the base of the content is signed by a major, trusted news organization. Changes are then made to the content and those changes are signed by a malicious individual. The consumer of the content may assume that the malicious individual is associated with the trusted news organization, and therefore trust the content based on the news organization’s association with the content. The certificate used by the malicious individual may or may not include a common name that tries to assist in confusing the user regarding their relationship to the news organization.

Prerequisites

The attacker needs to have a valid certificate that is included in a trust list used by the platform presenting the C2PA metadata.

Impact analysis

The viewer of the claim metadata will be misled with regards to the association between the two groups and assign trust based on the more recognizable entity.

Security guidance

When architecting your organization’s signing workflow, consider making the brand signature the final signature over the entire content. If possible, ensure that the certificates used by employees of an organization share the same certificate authority. Another approach is to create an assertion that links the two identities. A user interface needs to clearly present all identities present within C2PA content, and the order in which those identities modified the content.

Description Some organizations may choose to sign all images on their website. This may cause issues if images such as 1x1 tracking pixels or image-not-found icons are signed. An attacker may try to mislead the viewer by using those images as ingredients of a malicious image. Assume that an attacker wants end-users to believe that their malicious image is only a slight modification of a trusted image from the organization. When the human consumer looks at the provenance history in a UI, they will see the attacker’s image and the provenance will chain down to the organization’s image. The human consumer may not be able to see a 1x1 pixel in the UI. If the organization’s signed image was an image-not-found icon, then the human viewer would see a broken image icon. In either case, the consumer may assume that the provenance UI is having issues, and that the organization’s original image is not rendering correctly. If so, then the end-user may assume that the attacker’s image is the same as the original image if there are no assertions that indicate that the attacker made any changes.

Prerequisites The organization will need to have created signed images such as tracking pixels, transparent images, or image-not-found icons. The attacker will need to have located copies of those images. The attacker will need to have created a malicious image that they want to attribuge to the trusted organization. The attacker will also need a claim signer that will allow the embedding of an ingredient and the ability to control the assertions on their malicious image to imply that the attacker did not make any relevant changes to the original image.

Impact analysis Some end-users will be confused as to the origin of the attacker’s image resulting in their assumption that is the same, or nearly the same, as the organization’s image. This could result in the end-user being mislead into believing the original source of the image was the trusted organization. The final, malicious image will still have the attacker’s signature. However, the end-user may not know anything about the malicious actor and examining the history for additional context.

Security guidance Organizations should consider the types of images that they sign and the context in which an attacker might be able to use those images as ingredients in a malicious image. C2PA user interfaces displaying provenance information should have a plan for displaying small, transparent, or misleading images so that it is clear to the viewer that the image is present.

Description

The core provenance mechanism in C2PA is that of the claim signature, where a private key associated with a certificate signs the contents of the claim within a manifest. In situations where a human is using a claim generator to sign a creation or modification activity on some digital content, it is possible that the claim generator signs with a certificate that is unique or rare within the overall C2PA ecosystem. Where the instance of that certificate or key used for signing is reasonably rare, malicious actors may be able to use that certificate as a method to uniquely identify the human along with correlating data, or at least the device itself. This can be a serious issue for individuals who need to maintain their anonymity for safety reasons.

This attack could occur in two possible directions. The first is the attacker using a collection of images created by the claim generator’s certificate, and cross-referencing the data to narrow down the list of possible humans who could have created those images. The other attack method would be for the attacker to gain access to the device with that certificate and confirm that the device’s certificates was used to create a given set of images. If they are able to confirm the device was involved, then they can correlate the device to the device’s owner.

Prerequisites

The certificate or key used for signing is only used by a reasonably small content production population in the context of the attack.

The attacker either needs access to: * existing assets signed by the certificate being used to identify a human, where those assets, together, provide enough information to identify a human (e.g. a collection of images taken inside a particular neighbourhood, or of family members), or, * access to the device being used to sign assets

Impact analysis

The privacy and anonymity of the consumer is compromised. In some contexts, this can lead to extreme human harm.

Security guidance

When designing certificate provisioning models and certificate policies, care should be taken to avoid the pre-requisites being available to attackers. Mitigations could include:

One potential use case for C2PA is anonymous journalists who are at risk of physical harm if they are caught. Supporting this use case would involve protections outside of what is detailed in the C2PA specification such as legal response plans and specialized logging. If the solution is not designed to support the anonymous journalist use case, then those types of users should be able to easily discern that the solution is not appropriate for their needs.

Customers will need to know how to control the generation of C2PA metadata in their content. Accidental or unintentional inclusion of metadata could cause harm to at risk groups. For instance, children are often a specialized use case due to additional legal protections and potential threats. In addition, there may be abuse victims who need to control their ability to be tracked by those who could cause them harm. Providing transparency about how to disable C2PA tracking can help protect these users.

Remote C2PA content credential references could be used to track viewers of a piece of content against their will. A malicious author might intentionally use remote references to track anyone who views the image to identify their perceived enemy. One protection option is to warn the user that the content has remote credentials and obtain confirmation as to whether they want that information retrieved. If consent is granted, consider proxying the fetching of that information for the end-user. This action would prevent the end-user’s IP address from being disclosed to the remote site. Regardless of implementation, it is encouraged to inform content consumers how data will be fetched. No data should ever be fetched over an insecure channel.