diff --git a/assets/contributors.csv b/assets/contributors.csv index 333233e95d..caca415e65 100644 --- a/assets/contributors.csv +++ b/assets/contributors.csv @@ -134,6 +134,8 @@ Tirui Wu,Arm,,,, William Watson,Arm,,,, John O'Hara,Arm,JohnOhara-Arm,johnaohara,JohnnyDoItAll, Usamah Zaheer,Arm,usamahz,,, +Kostiantyn Perehuda,Arm,,,, +Yogesh Deshpande,Arm,,,, Roy Jamil,Ac6,RoyAc6,royjamil,,https://www.ac6.fr/en/ Elad Gross,Arm,eladgr,,, Ash Naik,Arm,,,, diff --git a/content/install-guides/c2patool.md b/content/install-guides/c2patool.md new file mode 100644 index 0000000000..ed0989003a --- /dev/null +++ b/content/install-guides/c2patool.md @@ -0,0 +1,127 @@ +--- +title: C2PA Tool +description: Install C2PA Tool on Arm Linux, macOS, or Windows on Arm to work with Content Credentials from the command line. +minutes_to_complete: 20 +official_docs: https://github.com/contentauth/c2patool +author: Kostiantyn Perehuda + +draft: true + +test_maintenance: false + +### FIXED, DO NOT MODIFY +weight: 1 +tool_install: true +multi_install: false +multitool_install_part: false +layout: installtoolsall +--- + +## Overview + +[C2PA Tool](https://github.com/contentauth/c2patool), invoked as `c2patool`, reads, creates, and +validates Content Credentials in supported media files. Content Credentials use the +Coalition for Content Provenance and Authenticity (C2PA) standard to record media provenance. + +You can install C2PA Tool on 64-bit Arm Linux, macOS on Apple silicon, or Windows on Arm. +The Linux instructions cover Ubuntu and Debian. + +Homebrew and Cargo install the version available from their package source. For release +information, see [C2PA Tool releases](https://github.com/contentauth/c2patool/releases). + +## Install on macOS + +Install [Homebrew](https://brew.sh/) if it isn't already available, then install C2PA Tool: + +```console +brew install c2patool +``` + +## Install on Arm Linux + +Prebuilt Linux releases target `x86_64`. Use Cargo to build and install a native `aarch64` +executable. + +Install the build dependencies on Ubuntu or Debian: + +```console +sudo apt update +sudo apt install -y build-essential pkg-config libssl-dev +``` + +Install [Rust](/install-guides/rust/) to obtain Cargo, then install C2PA Tool: + +```console +cargo install c2patool --locked +``` + +Cargo installs `c2patool` in `$HOME/.cargo/bin`. + +## Install on Windows on Arm + +Prebuilt Windows releases target `x86_64`. Use Cargo to build and install a native ARM64 executable. + +Install the Microsoft C++ Build Tools and [Rust](https://www.rust-lang.org/tools/install) with the +MSVC toolchain for ARM64. Open a new PowerShell window and run: + +```console +cargo install c2patool --locked +``` + +Cargo installs `c2patool.exe` in `%USERPROFILE%\.cargo\bin`. + +## Verify the installation + +Print the installed version: + +```console +c2patool --version +``` + +The output reports `c2patool` followed by the installed version number. + +Display the command summary: + +```console +c2patool --help +``` + +The expected output starts with: + +```output +Tool for displaying and creating C2PA manifests. +``` + +## Troubleshooting + +If your shell can't find `c2patool`, open a new terminal. For a Cargo installation, confirm that +`$HOME/.cargo/bin` on Linux or `%USERPROFILE%\.cargo\bin` on Windows is in your `PATH`. + +## Update C2PA Tool + +On macOS, run: + +```console +brew update +brew upgrade c2patool +``` + +For a Cargo installation, run: + +```console +cargo install c2patool --locked --force +``` + +## Uninstall C2PA Tool + +For a Homebrew installation, run: + +```console +brew uninstall c2patool +``` + +For a Cargo installation, run: + +```console +cargo uninstall c2patool +``` diff --git a/content/install-guides/exiftool.md b/content/install-guides/exiftool.md new file mode 100644 index 0000000000..f3a761410c --- /dev/null +++ b/content/install-guides/exiftool.md @@ -0,0 +1,96 @@ +--- +title: ExifTool +description: Install ExifTool on macOS, Linux on Arm, or Windows on Arm to read and write media metadata from the command line. +minutes_to_complete: 10 +official_docs: https://exiftool.org/install.html +author: Kostiantyn Perehuda + +draft: true + +test_maintenance: false + +### FIXED, DO NOT MODIFY +weight: 1 +tool_install: true +multi_install: false +multitool_install_part: false +layout: installtoolsall +--- + +## Overview + +[ExifTool](https://exiftool.org/) reads and writes metadata in image, audio, and video files. +You can install it on macOS on Apple silicon, 64-bit Arm Linux, or Windows 11 on Arm. +On Windows on Arm, you use the Windows x64 executable under emulation. + +Package-manager commands install the version available from your package source. See the +[ExifTool download page](https://exiftool.org/) for current releases. + +## Install on macOS + +Install [Homebrew](https://brew.sh/) if it isn't already available, then install ExifTool: + +```console +brew install exiftool +``` + +## Install on Arm Linux + +On Ubuntu and Debian, install the `libimage-exiftool-perl` package: + +```console +sudo apt update +sudo apt install libimage-exiftool-perl +``` + +On Fedora, install the [perl-Image-ExifTool package](https://packages.fedoraproject.org/pkgs/perl-Image-ExifTool/perl-Image-ExifTool/): + +```console +sudo dnf install perl-Image-ExifTool +``` + +Both packages provide the `exiftool` command and its Perl dependencies. + +## Install on Windows 11 on Arm + +The Windows x64 executable runs through +[x64 application emulation on Windows 11 on Arm](https://learn.microsoft.com/en-us/windows/arm/apps-on-arm-x86-emulation). + +Follow the [official Windows installation instructions](https://exiftool.org/install.html#Windows): + +1. Download the **64-bit Windows Executable** ZIP from the [ExifTool download page](https://exiftool.org/). +2. Extract the archive into a permanent folder in your user directory. +3. Rename `exiftool(-k).exe` to `exiftool.exe`. Keep its accompanying `exiftool_files` folder beside it. +4. Add the folder containing `exiftool.exe` to your user's `Path` environment variable. +5. Open a new PowerShell window so it picks up the change. + +## Verify the installation + +Print the installed version: + +```console +exiftool -ver +``` + +The output is similar to: + +```output +13.55 +``` + +Your version can differ. List the available metadata tags to confirm ExifTool runs: + +```console +exiftool -list +``` + +The output begins with `Available tags:` followed by tag names. + +## Troubleshooting + +If your shell can't find `exiftool`, open a new terminal and confirm that the directory containing +`exiftool` is in your `PATH`. On Windows, also check that the executable is named `exiftool.exe` +and that `exiftool_files` is still beside it. + +If Ubuntu cannot locate the package, check that the `universe` repository is enabled for your Ubuntu +release, then run `sudo apt update` again. diff --git a/content/install-guides/libjpeg-turbo.md b/content/install-guides/libjpeg-turbo.md new file mode 100644 index 0000000000..c2582eab5a --- /dev/null +++ b/content/install-guides/libjpeg-turbo.md @@ -0,0 +1,95 @@ +--- +title: libjpeg-turbo +description: Install libjpeg-turbo on macOS, Linux on Arm, or Windows on Arm to encode, decode, and transform JPEG images. +minutes_to_complete: 10 +official_docs: https://libjpeg-turbo.org/Documentation/Documentation +author: Kostiantyn Perehuda + +draft: true + +test_maintenance: false + +### FIXED, DO NOT MODIFY +weight: 1 +tool_install: true +multi_install: false +multitool_install_part: false +layout: installtoolsall +--- + +## Overview + +[libjpeg-turbo](https://www.libjpeg-turbo.org/) provides JPEG encoding and decoding libraries and +command-line tools. The tools include `cjpeg` for encoding, `djpeg` for decoding, and `jpegtran` +for transforming JPEG images. + +You can install the tools on macOS on Apple silicon, 64-bit Arm Linux, or Windows on Arm. +Package-manager commands on macOS and Linux install the version available from your package source. + +## Install on macOS + +Install [Homebrew](https://brew.sh/) if it isn't already available, then install the +[jpeg-turbo package](https://formulae.brew.sh/formula/jpeg-turbo): + +```console +brew install jpeg-turbo +``` + +## Install on Arm Linux + +On Ubuntu and Debian, install the `libjpeg-turbo-progs` package: + +```console +sudo apt update +sudo apt install libjpeg-turbo-progs +``` + +On Fedora, install the [libjpeg-turbo-utils package](https://packages.fedoraproject.org/pkgs/libjpeg-turbo/libjpeg-turbo-utils/): + +```console +sudo dnf install libjpeg-turbo-utils +``` + +Both packages provide `jpegtran` and the other command-line tools. Installing only the JPEG +runtime library doesn't provide these tools. + +## Install on Windows on Arm + +{{% notice Note %}} +The following steps use libjpeg-turbo version 3.1.4.1. You can use another version that provides +a native ARM64 installer. Replace the installer with the file for your chosen version. +To find the latest version, see [libjpeg-turbo releases](https://github.com/libjpeg-turbo/libjpeg-turbo/releases). +{{% /notice %}} + +1. Download `libjpeg-turbo-3.1.4.1-vc-arm64.exe` from the + [libjpeg-turbo 3.1.4.1 release](https://github.com/libjpeg-turbo/libjpeg-turbo/releases/tag/3.1.4.1). +2. Run the installer and note the installation directory. +3. Add the installation's `bin` directory, containing `jpegtran.exe`, to your user's `Path` + environment variable. +4. Open a new PowerShell window so it picks up the change. + +## Verify the installation + +Print the installed version: + +```console +jpegtran -version +``` + +The output is similar to: + +```output +libjpeg-turbo version 3.1.4.1 (build 20260327) +``` + +Your version and build can differ. A successful version check confirms that your terminal can +find and run `jpegtran`. + +## Troubleshooting + +If your shell can't find `jpegtran`, open a new terminal and confirm that the directory containing the +executable is in your `PATH`. On Windows, check for `jpegtran.exe` in the installation's `bin` +directory. On Linux, check that you installed the command-line tools package for your distribution. + +If Ubuntu cannot locate the package, check that the `universe` repository is enabled for your +release, then run `sudo apt update` again. diff --git a/content/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/1-understand-the-c2pa.md b/content/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/1-understand-the-c2pa.md new file mode 100644 index 0000000000..27b93dd0ea --- /dev/null +++ b/content/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/1-understand-the-c2pa.md @@ -0,0 +1,149 @@ +--- +title: Understand the C2PA Content Credentials +description: Learn how C2PA Content Credentials record provenance and what successful validation does and does not establish. +weight: 2 + +### FIXED, DO NOT MODIFY +layout: learningpathall +--- + +## Synthetic and untraceable media + +Advances in cameras, editing software, and generative AI make digital content easy to create and +modify. Synthetic or manipulated images, video, and audio can be difficult to distinguish from +captured media by appearance alone. + +This ambiguity creates opportunities for misinformation, impersonation, and fraud. It also affects +legitimate content. When origin and edit history are missing, you cannot reliably trace where a file +came from, which tools changed it, or whether it is being presented in its original context. + +The problem is not the existence of synthetic media. The problem is the loss of reliable context as +media moves between people, tools, and services. Media needs provenance information that remains +associated with the digital asset and can be checked for tampering. + +## EU AI Act transparency requirements + +[Article 50 of the EU AI Act](https://digital-strategy.ec.europa.eu/en/policies/guidelines-ai-transparency-obligations) +has applied since 2 August 2026. It requires providers of AI systems in scope to mark synthetic audio, +image, video, and text outputs in a machine-readable format so that they can be detected as +AI-generated or manipulated. + +Separate disclosure rules apply to people and organizations that deploy AI systems. Deepfakes must +be clearly disclosed to the people who encounter them. Certain AI-generated or manipulated text +published to inform the public on matters of public interest must also be disclosed. The Act includes +scope conditions and exceptions, so machine-readable provenance is one part of meeting these +transparency obligations rather than a complete legal solution. + +## C2PA Content Credentials + +The [Coalition for Content Provenance and Authenticity (C2PA)](https://c2pa.org/) defines an open technical standard for +recording provenance information, such as how a digital asset was created and modified, and binding that +information to digital content. The same model can be used across supported media types and +platforms. + +A *Content Credential* is the preferred non-technical term for a [C2PA manifest](https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html#_c2pa_manifest). The manifest packages +statements about a digital asset's origin, the tools used to process it, and the actions performed during its +history. The manifest can travel with the digital asset or remain available separately. + +A verifier can inspect these statements, verify the signature on the claim, and check the +cryptographic binding between the manifest and the digital asset. + +This gives the recipient a tamper-evident record of the digital asset's claimed origin and history. Content +Credentials do not detect fake media or determine whether a claim is true. C2PA can provide the +digitally signed metadata layer described in the +[Article 50 Code of Practice](https://digital-strategy.ec.europa.eu/en/policies/code-practice-ai-generated-content). +For images, signatories following the Code generally combine that layer with imperceptible +watermarking and a detection solution that meets effectiveness, reliability, robustness, and +interoperability requirements. This Learning Path demonstrates only C2PA metadata, so it does not +establish compliance on its own. + +## Understand the C2PA workflow + +[Figure 1](#figure-1) shows how a C2PA workflow connects a digital asset to a signed provenance record. A claim generator records +statements about the digital asset as [*assertions*](https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html#_assertions). These assertions can describe how the digital asset was created, +the actions applied to it, and the information used to bind the manifest to the digital asset. + +The [claim](https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html#_claims) references the assertions and identifies the claim generator. A [claim signature](https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html#claim-signature-definition) signs the +claim with the signer's private key. The claim generator assembles the assertions, claim, and claim +signature into a verifiable unit called a C2PA manifest. + +The [hard binding](https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html#_hard_bindings) +is itself recorded in an assertion. For the JPEG example, a data-hash assertion records a hash of the +asset byte ranges included in the binding. The signed claim references that assertion, making changes +to the recorded binding detectable. + +The digital asset and manifest are distributed together, either in one file or separately. The digital +asset's consumer uses a validator to check the manifest's integrity, its binding to the digital asset, +and the signing credential. The validator checks the manifest's structure and signature and evaluates +the signing credential against its trust policy. + + + +![A C2PA manifest contains assertions, including a hash-based binding to the digital asset, a claim, and its signature. Consumers independently validate the manifest of the distributed digital asset.#center](images/c2pa-manifest-workflow.svg "Figure 1. C2PA manifest structure and workflow") + +[Figure 1](#figure-1) summarizes the model defined by the +[C2PA technical specification](https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html). + +## Understand trust in Content Credentials + +The [C2PA trust model](https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html#_trust_model) distinguishes a *valid manifest* from a *trusted manifest*. A valid manifest is well-formed, has +not changed since it was signed, and passes the required signature, validity-period, and credential +revocation checks. A trusted manifest is valid and its signing credential is also trusted. A validator +can establish credential trust through configured trust anchors, including anchors from the +[C2PA Trust List](https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html#_c2pa_trust_list), or through a credential that the user has explicitly added to a private credential store. + +Trust applies to the signing credential and the signer identity associated with it. It does not prove +that every assertion is factually true. The consumer uses the signer identity, the assertions, and +other trust signals to decide whether to rely on the provenance record. + +## Why stripping provenance does not establish trust + +As digital content ecosystems move toward a future where verified provenance is a requirement for +acceptance, a digital asset must meet all of these conditions to be accepted within such an ecosystem: + +- The manifest passes structural, signature, and credential-validity checks. +- The content binding matches the digital asset, linking the signed provenance record to the received content. +- The signing credential is trusted under the consumer's trust policy. +- The recorded provenance meets the acceptance requirements, such as an approved origin or permitted editing history. + +Together, these checks establish the basis for acceptance. They do not guarantee factual +accuracy, as the [C2PA explainer](https://spec.c2pa.org/specifications/specifications/2.4/explainer/Explainer.html#_goals_and_non_goals) +explains. + +An attacker might modify protected digital asset data, causing the content binding to fail, then +strip the manifest to hide that failure. If no manifest is available for validation, the provenance +is unknown and the content remains untrusted in this ecosystem. Absence alone does not reveal whether +the manifest was stripped or never created; neither case provides the evidence needed for acceptance. + +The attacker therefore cannot turn failed validation into trusted provenance by removing the +manifest. The outcome changes from a failed content-binding check to unavailable provenance, but +the digital asset still fails the acceptance requirements. Stripping the manifest does not bypass +provenance-based trust. Untrusted means that the required evidence has not been established, not +that the content is necessarily false. + +## C2PA Conformance Program + +Verifying a digital asset's provenance depends on whether the products that create and validate its +Content Credentials follow the Content Credentials specification correctly. + +The C2PA Conformance Program evaluates products against the Content Credentials specification and +security requirements. It addresses the need for interoperable implementations that generate and +validate Content Credentials correctly, with a shared basis for certificate trust. + +Production solutions participating in this trusted ecosystem are expected to be conformant. +Approved products appear on the C2PA Conforming Products List. Approved generator products can +obtain claim-signing certificates from certificate authorities on the C2PA Trust List, subject to +their enrollment requirements. + +To prepare your production solution for conformance, start with the +[C2PA Conformance Program](https://c2pa.org/conformance/). It links to the technical and security +requirements, certificate policy, and application process. + +## What you've learned and what's next + +You've learned why digital assets need traceable provenance and how Content Credentials provide a +signed, tamper-evident record of that provenance. C2PA lets you inspect a digital asset's recorded +history, check its integrity, and assess the signing credential to make informed decisions about its +provenance. + +Next, confirm that C2PA Tool is available on your Arm device and prepare the example digital assets. diff --git a/content/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/2-prepare-example-files.md b/content/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/2-prepare-example-files.md new file mode 100644 index 0000000000..67b1f88894 --- /dev/null +++ b/content/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/2-prepare-example-files.md @@ -0,0 +1,69 @@ +--- +title: Check C2PA Tool and prepare the sample image +description: Check C2PA Tool on your Arm device, download the sample JPEG, and confirm that it has no C2PA manifest before signing. +weight: 3 + +### FIXED, DO NOT MODIFY +layout: learningpathall +--- + +## Create a working directory + +Create a folder named `c2pa-demo` wherever you keep your projects, using your file manager or terminal. +Open a terminal in that folder and run the remaining commands there. Keep all files from this +Learning Path in the same folder so the commands can use their filenames without full paths. + +## Confirm C2PA Tool is available + +Run the platform-independent version check: + +```console +c2patool --version +``` + +The version number depends on the current stable release. All subsequent outputs in this Learning +Path were recorded using the following version: + +```output +c2patool 0.27.21 +``` + +If the command is unavailable, follow the [C2PA Tool install guide](/install-guides/c2patool/). + +## Download the sample image + +In a real-world workflow, the software that creates or modifies a digital asset adds Content +Credentials as part of that process. For example, when you take a photograph with a camera that +supports Content Credentials, the camera software signs the image and adds Content Credentials +during capture. + +To focus on signing and validation without setting up a camera, use the +[sample JPEG from the Content Authenticity Initiative's `contentauth/c2patool` repository, pinned to `v0.27.20`](https://github.com/contentauth/c2patool/blob/v0.27.20/sample/image.jpg). +For this exercise, assume the sample represents a digitally captured photograph whose capture +details are available to the camera software when it adds Content Credentials. + +Download the original JPEG from that GitHub page and save it as `image.jpg` in your `c2pa-demo` +working directory. If your browser displays the raw image, use **Save image as**. The file is +61,720 bytes. Keep this unsigned source file for the later steps. + +The upstream sample is provided under the [MIT license, © Copyright 2020 Adobe](https://github.com/contentauth/c2patool/blob/v0.27.20/LICENSE-MIT). +Retain its copyright and permission notice if you redistribute the image. + +## Confirm the starting state + +Use C2PA Tool to confirm that the source image does not already contain a manifest: + +```console +c2patool image.jpg --info +``` + +The expected output includes: + +```output +No C2PA Manifests. (file size = 61720) +``` + +The downloaded sample has no existing C2PA manifest, so you can use it as the unsigned source for the +next step. + +Next, you will add Content Credentials to the image. diff --git a/content/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/3-add-content-credentials.md b/content/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/3-add-content-credentials.md new file mode 100644 index 0000000000..a1eab6fa9b --- /dev/null +++ b/content/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/3-add-content-credentials.md @@ -0,0 +1,162 @@ +--- +title: Add Content Credentials to an image +description: Define provenance assertions and sign a JPEG with C2PA Tool's development credential while preserving the unsigned source image. +weight: 4 + +### FIXED, DO NOT MODIFY +layout: learningpathall +--- + +## Add Content Credentials to an image + +You will add Content Credentials to the image prepared in the previous chapter. You will save the +signed image as a separate file, preserving the unsigned original. + +## Create the manifest definition + +A manifest definition tells C2PA Tool which information to include in the manifest. An [*assertion*](https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html#_assertion) +is a structured statement about an asset. Assertions can describe creation and editing actions, +identify source assets used as ingredients, or record metadata. See the +[C2PA standard assertion summary](https://spec.c2pa.org/specifications/specifications/2.4/specs/ContentCredentials.html#_standard_c2pa_assertion_summary) +for the standard assertion types and links to their definitions. This example uses an actions assertion +to declare how the image was created. + +The [*claim generator*](https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html#claim-generator-definition) is the software that assembles the claim and its references to assertions for +signing. In this exercise, C2PA Tool performs that work using the example identity you supply below. + +In your text editor, create a plain-text file named `manifest.json` in your `c2pa-demo` working directory +with these contents: + +```json +{ + "claim_generator_info": [ + { + "name": "Arm Learning Path C2PA Example", + "version": "1.0.0", + "com.arm.learning_path.tool": { + "name": "c2patool", + "version": "0.27.21" + } + } + ], + "assertions": [ + { + "label": "c2pa.actions.v2", + "data": { + "actions": [ + { + "action": "c2pa.created", + "digitalSourceType": "http://cv.iptc.org/newscodes/digitalsourcetype/digitalCapture" + } + ] + } + } + ] +} +``` + +The manifest definition identifies the signing workflow and records the image's declared origin: + +- **`claim_generator_info`** names your signing workflow `Arm Learning Path C2PA Example`, version + `1.0.0`. This version identifies the tutorial workflow; it is separate from the installed C2PA Tool + version. + +- **`com.arm.learning_path.tool`** records the tool's name and version. Set `version` to the value + reported by `c2patool --version`. The `com.arm` prefix identifies this as a custom field, following + C2PA's [rules for extending claim-generator information](https://spec.c2pa.org/specifications/specifications/2.4/specs/ContentCredentials.html#_generator_info_map). + +- **`assertions`** contains a `c2pa.actions.v2` assertion. Its `data.actions` array records a + `c2pa.created` action, with `digitalSourceType` declaring digital capture as the image's origin. + + You supply this declaration for the exercise. C2PA Tool does not verify how the image was created. + Signing makes changes to the declaration detectable, but does not establish that it is true. + + An action can also include `softwareAgent` to identify the software or hardware that performed it. + You omit that field because the sample's original capture agent is unknown. C2PA Tool generates the + claim, but did not capture the image. + +You supply the provenance fields above. C2PA Tool generates the claim, content-binding data, and signature +when it builds the signed manifest; you do not write those cryptographic structures by hand. + +C2PA Tool also offers a command-line shortcut: with an empty `assertions` array, `--create digitalCapture` +adds the creation action. If you omit `claim_generator_info`, the tool supplies its own name and +version instead of this example label. Keep the explicit claim-generator information to retain the +Learning Path label. You have already defined the creation action in `manifest.json`, so omit `--create` when signing the image. + +## Understand the development credential + +The example uses the private key and signing certificate built into C2PA Tool. These test credentials +let you practise signing, but do not establish a production identity or trust by public validators. +Do not use them to sign production content. Keep the development credential for this exercise so +that your validation results match the following chapters. + +For production, C2PA Tool supports an external signer that supplies the certificate chain and uses +the corresponding private key without exposing it to the tool. Once you have such a signer, +the command takes this form: + +```console +c2patool image.jpg --manifest manifest.json --signer-path /path/to/production-signer --output image-production-signed.jpg +``` + +This is an illustrative alternative, not a step to run in this exercise. +`/path/to/production-signer` is a placeholder for an executable implementing +[C2PA Tool's signer protocol](https://github.com/contentauth/c2patool/blob/main/docs/signing.md), +not a certificate file. The signer supplies its certificate chain and signing algorithm and +manages access to the private key. Do not copy production private keys into the manifest definition. + +For production conformance requirements, see [C2PA Conformance Program](../1-understand-the-c2pa/#c2pa-conformance-program). + +## Sign the image + +Run this command from your `c2pa-demo` directory. The output filename must not already exist. If it +does, move or rename that earlier output before you continue. + +```console +c2patool image.jpg --manifest manifest.json --output image-signed.jpg +``` + +`--manifest manifest.json` supplies your definition. `--output image-signed.jpg` writes the +signed image to a separate file, leaving `image.jpg` unchanged. + +The command exits with status 0 when signing succeeds. The expected development warning is: + +```output +Note: Using default private key and signing certificate. This is only valid for development. +A permanent key and cert should be provided in the manifest definition or in the environment variables. +``` + +The command also prints the generated manifest report. Its generated identifiers differ between runs. +You will inspect that report in the next chapter. + +## Confirm that the signed file contains a manifest + +Inspect the signed image to check that a manifest is present: + +```console +c2patool image-signed.jpg --info +``` + +The expected output includes: + +```output +Validation issues: + signingCredential.untrusted +One manifest +``` + +`One manifest` confirms that the output contains a C2PA manifest. `signingCredential.untrusted` is the +expected trust result for this development certificate; it does not mean that signing failed. +The byte counts and percentages also printed by this command can vary. + +## What you've accomplished and what's next + +You have defined the provenance information, signed the image, and confirmed that the output contains +a manifest. Keep these three files for the remaining chapters: + +| File | Purpose | +| --- | --- | +| `manifest.json` | Your claim-generator information and creation assertion | +| `image.jpg` | The unchanged unsigned source image | +| `image-signed.jpg` | The signed image containing the C2PA manifest | + +Next, inspect the generated manifest and confirm that C2PA Tool reports a valid signature and content binding. diff --git a/content/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/4-inspect-content-credentials.md b/content/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/4-inspect-content-credentials.md new file mode 100644 index 0000000000..375a1d2c3d --- /dev/null +++ b/content/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/4-inspect-content-credentials.md @@ -0,0 +1,191 @@ +--- +title: Inspect Content Credentials +description: Inspect a signed JPEG with C2PA Tool and ExifTool to connect its stored provenance with signature, content-binding, and signer-trust results. +weight: 5 + +### FIXED, DO NOT MODIFY +layout: learningpathall +--- + +## Display the manifest report + +Inspect the signed image to see the recorded provenance and the reported signature, content-binding, +and signer-trust results. Run C2PA Tool to display its JSON manifest report: + +```console +c2patool image-signed.jpg +``` + +C2PA Tool validates the manifest while reading it and includes those results in the report alongside +the recorded provenance fields. + +To save the report as a JSON file that you can open in a text editor, redirect the output: + +```console +c2patool image-signed.jpg > report.json +``` + +This writes the report to `report.json` in your working directory, replacing that file if +it already exists. The signed image remains unchanged. + +## Find the active manifest + +Find `active_manifest`, locate the same label under `manifests`, and inspect +`claim_generator_info`: + +```output +"claim_generator_info": [ + { + "name": "Arm Learning Path C2PA Example", + "version": "1.0.0", + "com.arm.learning_path.tool": { + "name": "c2patool", + "version": "0.27.21" + }, + "org.contentauth.c2pa_rs": "0.90.21" + } +] +``` + +The name and `1.0.0` example version match the values you supplied in `manifest.json`. The custom +`com.arm.learning_path.tool` field records the separate tool name and version you supplied. C2PA Tool adds +`org.contentauth.c2pa_rs` to identify its underlying library; `0.90.21` is the library version in the +tested tool. Manifest labels, instance IDs, and UUIDs differ between runs. + +## Inspect the assertions + +The `assertions` array contains a `c2pa.actions.v2` assertion: + +```output +"actions": [ + { + "action": "c2pa.created", + "digitalSourceType": "http://cv.iptc.org/newscodes/digitalsourcetype/digitalCapture" + } +] +``` + +This is a declaration supplied by the claim generator, not independent proof of how the depicted scene +was produced or whether it is truthful. + +## Inspect the hard binding + +Under `validation_results`, `activeManifest`, and `success`, find: + +```output +{ + "code": "assertion.dataHash.match", + "explanation": "data hash valid" +} +``` + +For this JPEG and tool version, the data-hash assertion provides the hard binding between the manifest +and the image. `assertion.dataHash.match` reports that C2PA Tool successfully checked that binding. + +## Inspect the signature and credential + +```output +"signature_info": { + "alg": "Es256", + "issuer": "C2PA Test Signing Cert", + "common_name": "C2PA Signer" +} +``` + +The validation results also report: + +```output +{ + "code": "signingCredential.untrusted", + "explanation": "signing certificate untrusted" +} +``` + +Keep these checks separate: + +- `claimSignature.validated` says that the cryptographic signature on the claim verifies. +- `assertion.dataHash.match` reports that C2PA Tool successfully checked the hard binding to the image. +- `signingCredential.untrusted` says that the validator's trust policy does not accept the certificate. + +A verifying signature does not, on its own, establish who controlled the corresponding private key. + +## Interpret the result + +For this fixture, C2PA Tool also prints: + +```output +"validation_state": "Valid" +``` + +`Valid` refers to the structural and cryptographic integrity of the C2PA manifest store. C2PA Tool +could read its structure and successfully check the claim signature, referenced assertion hashes, +and binding to the image. It describes the integrity of the provenance record and its connection to +this image, not the truth of the image or the recorded assertions. + +Read this summary together with the individual status codes. Here, `signingCredential.untrusted` +means that the signing certificate is not accepted by the tool's configured trust policy, even though +the integrity checks succeeded. The tool distinguishes `Valid` from `Trusted`, which additionally +requires acceptance of the signing credential under that policy. + +## Locate the C2PA structures inside the JPEG + +The JSON report is a readable interpretation of the embedded data, not its storage format. In this +JPEG, the C2PA manifest store is carried in application metadata segments called **APP11** segments. +A large store can span several segments. Within that store, **JUMBF** (JPEG Universal Metadata Box +Format) organises the data into nested, labelled containers called boxes. Each manifest contains an +assertion store, a claim, and a claim signature. See the +[C2PA JPEG storage specification](https://spec.c2pa.org/specifications/specifications/2.4/specs/ContentCredentials.html#_embedding_manifests_into_jpeg). + +**ExifTool** is a command-line utility for reading and writing file metadata. Use its read-only +inspection commands to connect the fields in `report.json` with the structures actually stored in +`image-signed.jpg`. Start by listing the JUMBF labels: + +```console +exiftool -a -G3 -s -JUMDLabel image-signed.jpg +``` + +`-a` includes repeated labels, `-G3` shows their document hierarchy, and `-s` prints tag names. +Look for these labels: + +| Label | What to identify | +| --- | --- | +| `c2pa` | The manifest store | +| `urn:c2pa:…` | The manifest label matching `active_manifest` in `report.json` | +| `c2pa.assertions` | The assertion store, containing `c2pa.actions.v2` and the `c2pa.hash.data` assertion that provides the hard binding to this JPEG | +| `c2pa.claim.v2` | The claim that references the assertions and signature | +| `c2pa.signature` | The claim-signature container | + +## Trace the stored assertions, hard binding, and claim + +ExifTool's verbose listing lets you trace how the recorded actions, hard-binding parameters, and +claim references connect within the JPEG's nested JUMBF boxes. This view exposes the stored metadata +behind the fields in C2PA Tool's report. You can save it to `metadata.txt` and explore it in a text editor: + +```console +exiftool -v2 image-signed.jpg > metadata.txt +``` + +The following entries help connect the stored metadata with the C2PA Tool report: + +- `JPEG APP11` contains the JUMBF structure whose outer label is `c2pa`, identifying the embedded + manifest store. +- Under `c2pa.actions.v2`, the decoded `c2pa.created` action and `digitalSourceType` correspond to + the declaration in `manifest.json` and the action shown in `report.json`. +- Under `c2pa.hash.data`, `Alg = sha256` identifies the hard-binding hash algorithm. + `ExclusionsStart` and `ExclusionsLength` describe the byte range omitted from hashing. The stored + hash appears as binary data without its value expanded. +- Under `c2pa.claim.v2`, assertion references point into `c2pa.assertions`, and the `signature` + reference ends in `c2pa.signature`, the label of the claim-signature container. + +The claim and action values are stored in CBOR, a compact binary encoding that ExifTool decodes for +this listing. This view reveals the stored structures and their connections; it does not verify the +C2PA signature or content binding. The image remains unchanged. + +## What you've accomplished and what's next + +You have inspected the recorded provenance, distinguished signature and content-binding results from +signer trust, and traced the report's fields to the structures inside the JPEG. The development +credential remains untrusted; reading these records does not establish that their assertions are true. + +Keep `image-signed.jpg` unchanged, along with `report.json` and `metadata.txt`. Next, use an external +validator to examine the same signed image and interpret its results under that validator's trust policy. diff --git a/content/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/5-validate-content-credentials.md b/content/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/5-validate-content-credentials.md new file mode 100644 index 0000000000..61873b5c06 --- /dev/null +++ b/content/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/5-validate-content-credentials.md @@ -0,0 +1,102 @@ +--- +title: Validate Content Credentials with a web validator +description: Validate the signed JPEG with the CAI web validator and compare its provenance display and issuer warning with the C2PA Tool report. +weight: 6 + +### FIXED, DO NOT MODIFY +layout: learningpathall +--- + +## Validate the signed image with the CAI web validator + +You will open `image-signed.jpg` from chapter 3 in the +[Content Authenticity Initiative (CAI) web validator](https://verify.contentauthenticity.org/), +a browser-based tool for inspecting and validating C2PA Content Credentials. The site calls this +tool *Verify*. You will read the recorded provenance and compare the validation results with your +C2PA Tool report from chapter 4. + +According to its [open-source project](https://github.com/contentauth/verify-site), the validator uses +WebAssembly to read and validate C2PA data in your browser. The website can still make network +requests, so this does not mean that it operates entirely offline. + +## Open the CAI web validator and select the signed asset + +1. Open the [CAI web validator](https://verify.contentauthenticity.org/) in your browser. The start page says + **Inspect content to dig deeper** and lists JPEG among its supported formats. +2. Select **Select a file from your device**, as shown in [Figure 1](#figure-1). +3. Choose `image-signed.jpg` from your `c2pa-demo` directory and open it. You can also drag the file + onto the page. +4. Wait for the image and its Content Credentials panel to appear. + +If you use another computer, copy `image-signed.jpg` without modifying or recompressing it. + + + +![CAI web validator start page with Select a file from your device and JPEG in the supported formats. Use this control to open image-signed.jpg.#center](images/verify-select-file.jpg "Figure 1. Select the signed JPEG in the CAI web validator") + +## Inspect the validation result + +In the Content Credentials panel, look for **Unrecognized** beside `image-signed.jpg`, as shown in +[Figure 2](#figure-2). The orange notice indicates that the CAI web validator does not recognize the credential's issuer under its +trust policy. As explained in [chapter 3](/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/3-add-content-credentials/#understand-the-development-credential), +the built-in signing certificate is for development and does not establish a production identity. + + + +![The CAI web validator shows image-signed.jpg with an Unrecognized status and an orange notice about its issuer.#center](images/verify-unrecognized.jpg "Figure 2. Expected result for the development credential") + +{{% notice Note %}} +If no Content Credentials appear, check that you selected `image-signed.jpg`, not `image.jpg`. +If you transferred the file, retry with a copy of the original signed output. +{{% /notice %}} + +## Read the recorded provenance + +Scroll through the Content Credentials panel. Read **Content summary**, then expand **Process** +for the recorded action and app or device name. Expand **About this Content Credential** to find +**Issued by**, as shown in [Figure 3](#figure-3). + + + +![The CAI web validator's details panel shows captured media, the Created action, C2PA Signer, and issuer C2PA Test Signing Cert. Locate the creation and issuer fields in this panel.#center](images/verify-credential-details.jpg "Figure 3. Recorded provenance and test-certificate issuer") + +## Compare with your C2PA Tool report + +Open `report.json` and locate the active manifest as described in +[chapter 4](/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/4-inspect-content-credentials/#find-the-active-manifest). +Use its `assertions` and `signature_info` fields for the provenance comparison, and +`validation_results` for signer trust: + +| Information | C2PA Tool report | CAI web validator view | +| --- | --- | --- | +| Declared origin | `digitalSourceType` ending in `/digitalCapture` | Content summary: This is captured media. | +| Creation action | `action: "c2pa.created"` | Process → Actions: Created | +| Signing certificate's common name | `signature_info.common_name: "C2PA Signer"` | Process → App or device used: C2PA Signer | +| Signing certificate's issuer | `signature_info.issuer: "C2PA Test Signing Cert"` | About this Content Credential → Issued by: C2PA Test Signing Cert | +| Signer trust | `signingCredential.untrusted` | Unrecognized issuer | + +The captured-media summary and **Created** action reflect the declaration you supplied in +[chapter 3](/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/3-add-content-credentials/#create-the-manifest-definition). +**App or device used** shows `C2PA Signer`, matching the development signing certificate's common name, +rather than your custom `Arm Learning Path C2PA Example` label. As that chapter explains, C2PA Tool generated the +claim; it did not capture the photograph. + +The web panel displays the image's provenance without separate signature or binding status codes. +As confirmed in [chapter 4](/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/4-inspect-content-credentials/#interpret-the-result), +both checks pass for this image; **Unrecognized** refers to signer trust. In the next chapter, you +will modify a copy of the image to see how a content-binding failure changes the validation result. + +As discussed in [chapter 1](/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/1-understand-the-c2pa/#understand-trust-in-content-credentials), +validating Content Credentials on its own does not establish that the depicted scene or the recorded +assertions are true. Successful signature and binding checks show that the signed provenance record +is intact and bound to this image. Establishing credential trust also requires the validator to accept +the signing credential under its trust policy. To decide whether to believe the content, consider +the signer's identity and reliability, the recorded history, and any corroborating evidence. + +## What you've accomplished and what's next + +You can now read the web validator's provenance summary and interpret its issuer warning alongside +the detailed C2PA Tool results. + +Keep `image-signed.jpg` unchanged. In the next chapter, you will modify a separate copy and inspect +the resulting content-binding failure. diff --git a/content/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/6-detect-an-unauthorized-change.md b/content/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/6-detect-an-unauthorized-change.md new file mode 100644 index 0000000000..452abf7e87 --- /dev/null +++ b/content/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/6-detect-an-unauthorized-change.md @@ -0,0 +1,147 @@ +--- +title: Detect an unauthorized change to the asset +description: Use jpegtran to create a grayscale copy that retains its C2PA manifest, then identify the content-binding failure with local and web validators. +weight: 7 + +### FIXED, DO NOT MODIFY +layout: learningpathall +--- + +## Confirm jpegtran is available + +Run the platform-independent version check: + +```console +jpegtran -version +``` + +The version and build depend on your installed release. The output is similar to: + +```output +libjpeg-turbo version 3.1.4.1 (build 20260327) +``` + +If the command is unavailable, follow the [libjpeg-turbo install guide](/install-guides/libjpeg-turbo/). + +## Modify the signed asset + +Continue in your `c2pa-demo` directory. Create a grayscale copy of `image-signed.jpg` while keeping +its embedded manifest unchanged: + +```console +jpegtran -copy all -grayscale -outfile image-modified.jpg image-signed.jpg +``` + +- `-grayscale` removes the image's color. +- `-copy all` preserves the metadata, including the embedded C2PA manifest. +- `-outfile` writes the changed image to a separate file without re-signing it. + +The command normally prints no output. Open `image-modified.jpg` in an image viewer: the image +should appear in grayscale. Keep `image-signed.jpg` unchanged for comparison. + +{{% notice Note %}} +Keep the input and output filenames different. The command overwrites `image-modified.jpg` if +it already exists. Preserve the manifest with `-copy all`; otherwise, you would be testing +missing metadata instead of a change to the image. Removing the manifest cannot turn a failed +binding check into trusted provenance. See +[Why stripping provenance does not establish trust](/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/1-understand-the-c2pa/#why-stripping-provenance-does-not-establish-trust). +{{% /notice %}} + +## Inspect the modified image in the web validator + +1. Open the [CAI web validator](https://verify.contentauthenticity.org/). +2. Choose **Select a file from your device**, or **Select another file from your device** if + chapter 5's result is still open. +3. Select `image-modified.jpg` and wait for validation to finish. +4. Open the image's result or **Content Credentials** panel if needed. + +Look for the grayscale preview, the **Invalid** status, and the red tampering warning. Compare +this with the **Unrecognized** issuer warning you saw for the original image in chapter 5: + +![CAI Verify displays the grayscale image-modified.jpg with an Invalid status and a red warning that its Content Credentials cannot be verified or viewed. Look for both the visible edit and the new validation warning.#center](images/verify-grayscale-invalid.jpg "Grayscale asset: invalid Content Credentials") + +The red warning tells you that the credentials cannot be verified or viewed. Use C2PA Tool next +to identify the failed check. + +{{% notice Note %}} +`jpegtran` preserves stored thumbnails, so some viewers may still show a color thumbnail. +Check the full image to see the grayscale edit. +{{% /notice %}} + +## Find the content-binding failure + +Save a report for the modified image: + +```console +c2patool image-modified.jpg > report-modified.json +``` + +Open `report-modified.json` and find `validation_state`. The expected output is: + +```output +"validation_state": "Invalid" +``` + +Under `validation_results.activeManifest.failure`, find: + +```output +"code": "assertion.dataHash.mismatch" +``` + +This means the image's hash no longer matches the hard-binding assertion. The unchanged manifest +is still present, but it no longer matches the grayscale image. + +Under `validation_results.activeManifest.success`, find `claimSignature.validated`. The claim's +signature still verifies because you changed the image rather than the signed claim. + +## Compare the original and modified assets + +Compare `report-modified.json` with `report.json` from chapter 4 and the web result from chapter 5: + +| Check | Original signed image | Modified copy | +| --- | --- | --- | +| Image appearance | Color | Grayscale | +| Embedded manifest | Present | Present; unchanged | +| Claim signature | `claimSignature.validated` | `claimSignature.validated` | +| Asset binding | `assertion.dataHash.match` | `assertion.dataHash.mismatch` | +| Development credential | `signingCredential.untrusted` | `signingCredential.untrusted` | +| Local validation state | `Valid` | `Invalid` | +| Verify status | Unrecognized | Invalid | + +The issuer-trust result stays the same. The new failure concerns the binding between the signed +record and the changed image. + +## Why replacing the hashes does not restore validity + +An attacker might try to alter an image and reuse its Content Credential to present it as the +unchanged original. Replacing the recorded hashes cannot hide the edit: the data-hash assertion, its +reference in the claim, and the claim signature form a chain of integrity checks: + +- **Changing the data-hash assertion** can make its stored image hash match the edited asset, + but changes the assertion itself. The claim still references the original assertion hash, + so the assertion-reference check fails (`assertion.hashedURI.mismatch`). +- **Changing the assertion reference in the claim** can make that reference match the modified + assertion, but changes the signed claim. The original signature no longer verifies + (`claimSignature.mismatch`). + +Hashes can be recalculated without a secret. A replacement signature that verifies under the +original signing certificate requires the corresponding private key. Without that key, patching +the assertion and claim cannot make the altered content pass these checks under the original +credential. The protection comes from the signature, not from preventing access to the manifest. + +See the [C2PA validation rules](https://spec.c2pa.org/specifications/specifications/2.4/specs/ContentCredentials.html#_validation) +for these checks. + +C2PA also supports legitimate edits: a new signed manifest can reference the earlier asset as +an ingredient, linking its signer and provenance record to the edited version. This provenance +chain records the modification rather than concealing it. + +## What you've accomplished + +You have added Content Credentials to an image on Arm, inspected its embedded provenance with +C2PA Tool and ExifTool, and validated it with the CAI web validator. You then modified the image +while preserving its manifest and traced the resulting warning to a content-binding mismatch. + +You can now distinguish asset integrity, claim-signature validity, and signer trust, and explain +how signed provenance makes changes detectable. Content Credentials give you verifiable provenance +signals to help you assess an asset's recorded origin and history. diff --git a/content/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/_index.md b/content/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/_index.md new file mode 100644 index 0000000000..645b1437e7 --- /dev/null +++ b/content/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/_index.md @@ -0,0 +1,65 @@ +--- +title: Create and verify C2PA Content Credentials on Arm + +draft: true +cascade: + draft: true + +description: Understand why digital media needs verifiable provenance. Add Content Credentials to an image on an Arm device. Inspect its C2PA manifest. Validate it with an external validator. Observe a content-binding validation failure after a controlled change to the image. + +minutes_to_complete: 55 + +who_is_this_for: This is an introductory topic for developers who want to add and validate C2PA Content Credentials on Arm devices. + +learning_objectives: + - Explain what C2PA is, the content provenance problem it addresses, and why provenance matters. + - Add Content Credentials to a sample image on an Arm device. + - Inspect the manifest and interpret the content-binding, signature, and trust results. + - Validate Content Credentials with an external validator. + - Demonstrate a content-binding failure after a controlled change to the image. + +prerequisites: + - "The current stable release of [C2PA Tool](/install-guides/c2patool/) installed on your Arm device" + - "[ExifTool](/install-guides/exiftool/) installed on your Arm device" + - "[libjpeg-turbo](/install-guides/libjpeg-turbo/) installed on your Arm device" + - Familiarity with running command-line tools + +author: + - Kostiantyn Perehuda + - Yogesh Deshpande + +generate_summary_faq: true +rerun_summary: false +rerun_faqs: false + +### Tags +skilllevels: Introductory +subjects: Security +armips: + - Cortex-A +tools_software_languages: + - Content Credentials + - C2PA Tool + - ExifTool + - libjpeg-turbo +operatingsystems: + - Linux + - macOS + - Windows + +further_reading: + - resource: + title: C2PA technical specification + link: https://c2pa.org/specifications/ + type: documentation + - resource: + title: C2PA Tool source repository + link: https://github.com/contentauth/c2patool + type: repository + +### FIXED, DO NOT MODIFY +# ================================================================================ +weight: 1 +layout: "learningpathall" +learning_path_main_page: "yes" +--- diff --git a/content/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/_next-steps.md b/content/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/_next-steps.md new file mode 100644 index 0000000000..727b395ddd --- /dev/null +++ b/content/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/_next-steps.md @@ -0,0 +1,8 @@ +--- +# ================================================================================ +# FIXED, DO NOT MODIFY THIS FILE +# ================================================================================ +weight: 21 # The weight controls the order of the pages. _index.md always has weight 1. +title: "Next Steps" # Always the same, html page title. +layout: "learningpathall" # All files under learning paths have this same wrapper for Hugo processing. +--- diff --git a/content/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/images/c2pa-manifest-workflow.svg b/content/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/images/c2pa-manifest-workflow.svg new file mode 100644 index 0000000000..4467568b59 --- /dev/null +++ b/content/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/images/c2pa-manifest-workflow.svg @@ -0,0 +1,106 @@ + + + C2PA manifest structure and workflow + A C2PA manifest contains an assertion store, a claim, and a claim signature. The assertion store includes a hard-binding assertion recording a hash of the included digital asset data. The claim references the assertions and is signed with the signer's private key to create the claim signature. Three arrows lead from distribution of the digital asset and manifest to separate consumers, who each independently validate the manifest. + + + + + + + + + + + + Digital asset + created + + Assertions + recorded + + Claim + assembled + + Claim + signature + created + + Manifest + assembled + + Digital asset + and manifest + distributed + + + Consumer 1 + validates the manifest + + Consumer 2 + validates the manifest + + Consumer 3 + validates the manifest + + + + + + + + + + + + + + Digital asset + Image, audio, video, + or document + + + + + + C2PA manifest + + + Assertion store + + Hard-binding assertion + Hash of included + digital asset data + + + Other assertions + Actions, metadata, + ingredients + + + Claim + References the assertions + and identifies the + claim generator + + + Claim signature + Signs the claim with + the signer's + private key + + + + + + + Hash + + The digital asset and its manifest can be distributed in one file or stored separately. + diff --git a/content/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/images/c2pa-sample-image-license.txt b/content/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/images/c2pa-sample-image-license.txt new file mode 100644 index 0000000000..c38edb6cda --- /dev/null +++ b/content/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/images/c2pa-sample-image-license.txt @@ -0,0 +1,31 @@ +Third-party sample image: c2pa-sample-image.jpg + +Source: https://github.com/contentauth/c2pa-rs/blob/712f03b72cbc1b00fc41adee5835fc92be2758d1/cli/sample/image.jpg +SHA-256: f999fd78bfe8a83c96e468a078830ba94485bc1bc6fd086fb94a43bd29dd0f23 +The JPEG is unchanged; only its filename differs from upstream. + +Redistributed under the upstream MIT license. This notice applies to the +sample JPEG; it does not change the Learning Path's documentation license. +Retain this notice with redistributed copies of the sample. + +MIT License + +© Copyright 2020 Adobe. All rights reserved. + +Permission is hereby granted, free of charge, to any person obtaining a copy +of this software and associated documentation files (the "Software"), to deal +in the Software without restriction, including without limitation the rights +to use, copy, modify, merge, publish, distribute, sublicense, and/or sell +copies of the Software, and to permit persons to whom the Software is +furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice shall be included in all +copies or substantial portions of the Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE +AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, +OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE +SOFTWARE. diff --git a/content/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/images/verify-credential-details.jpg b/content/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/images/verify-credential-details.jpg new file mode 100644 index 0000000000..e17d8bcbb9 Binary files /dev/null and b/content/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/images/verify-credential-details.jpg differ diff --git a/content/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/images/verify-grayscale-invalid.jpg b/content/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/images/verify-grayscale-invalid.jpg new file mode 100644 index 0000000000..d4cc3f5185 Binary files /dev/null and b/content/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/images/verify-grayscale-invalid.jpg differ diff --git a/content/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/images/verify-select-file.jpg b/content/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/images/verify-select-file.jpg new file mode 100644 index 0000000000..53a18a324b Binary files /dev/null and b/content/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/images/verify-select-file.jpg differ diff --git a/content/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/images/verify-unrecognized.jpg b/content/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/images/verify-unrecognized.jpg new file mode 100644 index 0000000000..b62a076bd4 Binary files /dev/null and b/content/learning-paths/embedded-and-microcontrollers/c2pa-on-arm/images/verify-unrecognized.jpg differ