Supply Chain Integrity, Transparency, and Trust (SCITT)
bofreq-birkholz-supply-chain-integrity-transparency-and-trust-scitt-04

The information below is for an older version of this BOF request.
Document Type Proposed BOF request Snapshot
Title Supply Chain Integrity, Transparency, and Trust (SCITT)
Last updated 2022-05-20
State Proposed
Editor Henk Birkholz
Responsible leadership
Send notices to (None)
bofreq-birkholz-supply-chain-integrity-transparency-and-trust-scitt-04

BoF Name: Supply Chain Integrity, Transparency, and Trust (SCITT)

Description

Concerns about the security of supply chains, including those for physical goods, services, and digital products, have been around for a long time. This work aims to improve supply chain security by making the actions of entities in that supply chain transparent and thereby accountable. Statements made about supply chain elements, such as software and hardware components, must be identifiable, authentic, verifiable, and non-repudiable (enabling third-party verification and auditing).

This virtual interim non-WG-forming BoF will reduce agenda stress and save cycles in the already compressed IETF hybrid-meeting agenda.

The SCITT discussion at the IETF 113 SECDISPATCH session yielded several topics as its output, of which some will be topics of this interim BoF. The primary output of this BoF is intended to be building blocks of preliminary decisions on how to scope an upcoming chartering effort.

The planned outputs include:

  • Goals and non-goals for an initial charter based on An Architecture for Trustworthy and Transparent Digital Supply Chains and participant input
  • Initial core terminology on the topics of: ledger, receipt, identity, revocation, basic operation, and trustworthiness
  • Initial requirement sets, including: iot-applicable, crypto-agile, and identity-agile
  • Minimal/conceptual charter building blocks

Goals to be discussed:

  • Globally uniform/interoperable (counter-)signing format for "Statements made about supply chain elements"
  • Offline/air-gap validation
  • Claim-lifetime & identity-lifetime

Success factors:

  • Establishing a shared understanding of the problem statement
  • Bringing relevant stakeholders into the room
  • Stimulating list/discussion activity

Required Details

  • Status: Non-WG-Forming BoF
  • Responsible AD: Roman Danyliw
  • BOF chairs: TBD
  • BOF proponents:
  • Number of people expected to attend: 50
  • Length of session (1 or 2 hours): 2 hours
  • Conflicts (whole Areas and/or WGs): No conflicts as this is a virtual interim.
  • Chair Conflicts: No conflicts as this is a virtual interim.
  • Technology Overlap: COSE, RATS -> No conflicts as this is a virtual interim.
  • Key Participant Conflict: TBD

Information for IAB/IESG

  • Any protocols or practices that already exist in this space:
    • Notary/ORAS
    • Sigstore
    • SBOM
      • SPDX
      • CycloneDX
    • Endorsements
      • In-Toto
      • SLSA
    • IETF SBOM Access
    • COSE
  • Which (if any) modifications to existing protocols or practices are required: session output?
    • COSE secure Receipt Representation (Read/Write)
    • Standardization of Claims/Endorsements
    • DiD backbone with extensions
    • Protocol extensions for Indexing (are there fundamental Indexing implementations or is it per vendor so that things such as Rego can be used). This could mean that specific types of content are explicitly known, allowing for efficient consumer uses cases.
    • Audit Proofs
  • Which (if any) entirely new protocols or practices are required:
    • Interoperable envelope format, signing, and countersigning for transparent claim.
    • Registration policies for inclusion in transparent logs.
    • Receipts for verifying inclusion in transparent logs (based e.g. on Merkle Trees)
  • Open source projects (if any) implementing this work:
    • Under Cloud Native Computing Foundation (CNCF) are both NotaryProject and ORAS
    • Building blocks
      • GlueCose
      • go-cose
      • .Net COSE
  • Traceability Interoperability work at W3C Credentials Community Group

Proposed Agenda

Problem Statement (10 min)

What problem needs to be solved?

The traceability of physical and digital artifacts in supply chains is a long-standing but increasingly severe security concern. The problem to be solved is to define a generic and scalable architecture to enable transparency across any supply chain with minimum adoption barriers for producers and enough flexibility to allow different implementations of transparency services with diverse auditing and compliance requirements. The architecture should support the ongoing verification of goods and services where one may assure the authenticity of entities, evidence, policy, and artifacts, and where the actions of entities can be guaranteed to be authorized, non-repudiable, immutable, and auditable.

Is the timing right?

The end-to-end supply chain for a given good or service is highly complex due to globalization, third-party dependencies, varying customer requirements, legal and regulatory compliance, and many other factors. Supply chain complexity manifests quality, sustainability, reliability, safety, and security risks. Governments and companies worldwide have experienced numerous supply chain attacks by criminals targeting weaknesses in these complex supply chains. In response, global entities have initiated compliance mandates, developed novel solutions, or are still actively pursuing emergent technologies to reduce supply chain risks. The use cases presented below highlight the acute market signals driving the urgency to define globally interoperable supply chain transparency services.

How does it relate to other IETF work?

Core technologies from the IETF can act as building blocks in this area ranging from digital signing technologies to distributed identity efforts. The intention is to add to these technologies in a way that many of the additions are also building blocks that are applicable beyond the specific objectives of SCITT.

A Notional Complex Supply Chain

Stages within the supply chain are connected upstream and downstream and may include one-to-one, many-to-one, and one-to-many relationships through the lifecycle of the product. We assume that the suppliers, consumers, and/or standards bodies have defined the following:

  • Generalized process layout for the product output(s)
  • Process threat models
  • Mitigations and best practices
  • Artifacts recommended to mitigate threats and acceptable residual risks
  • Data storage and retention
  • Auditing and compliance requirements

For a complex supply chain, we consider four personas: the supplier, the consumer, the auditor, and the notary.

  • Supplier

    • Receives a production request
    • Inherits BOM(s) and product output(s) associated with the upstream processes
    • Creates a signed process layout based on supplier-specific implementation of standards and downstream requirements
    • Process steps
    • Required artifacts
    • Artifact metadata
    • Claims
    • Sublayout integration (upstream)
    • Sources required materials and tools, and verifies and records provenance
    • Executes process steps, sign and store artifacts, metadata, and claims in accordance with the process layout
    • Tags each product output with a unique identifier
    • Generates and signs a Bill of materials (BOM) for each product output
    • Submits signed content to the notary
    • Ships product output(s) to the next supplier(s) or consumer(s) in the supply chain
    • Applies continuous supply chain security monitoring to provide robust security analytics and actionable intelligence for product output(s), including updates and/or revocation as appropriate

  • Consumer

    • Receives finished product output(s) and BOMs associated with the upstream processes
    • Validates the:
    • Finished product output(s) have one or more endorsements from trusted auditors that are notarized
    • Absence of non-compliance endorsements and at least one compliance endorsement
    • Creates a signed layout for provisioning, deployment, operation, and end-of-life
    • Process steps
    • Required artifacts
    • Artifact metadata
    • Claims
    • Sublayout integration (upstream)
    • Executes process steps, signs and stores artifacts, metadata, and claims in accordance with the process layout throughout the lifecycle
    • Tags each product output with a unique identifier
    • Generates and signs a Bill of materials (BOM) for each product output
    • Submits signed content to the notary
    • Applies continuous supply chain security monitoring to provide robust security analytics and actionable intelligence in the deployed system

  • Auditor

    • Performs auditing at any time given a product output identifier and BOM, to:
    • Verify what is recorded by the notary and leverage additional audit trail data as needed
    • Go back to the supplier(s) to gather evidence captured during production
    • Establishes data sharing agreements, as necessary
    • Audits receipts, claims and replays ledger for supplier(s) based on audit scope
    • Confirms compliance against standards and customer requirements
    • Provides analytical insights as needed
    • Produces signed endorsements of compliance or non-compliance
    • Submits endorsements to the notary

  • Notary

    • Validates identity and countersigns content received from the supplier, consumer, or auditor
    • Stamps epoch marker and issues receipt

Use Cases (10 min)

Software Bill of Materials (SBOM)

The growing complexity of large software projects requires additional management of modularity and abstractions, and keeping track of their complete Trusted Computing Base (TCB) is becoming increasingly challenging. Each component may have its own set of dependencies and libraries. Some of these dependencies are binaries, which means their TCB depends on their source and their build environment (e.g., compilers, tool-chains). Further, potentially untrusted channels and repositories may distribute source and binary packages.

An SBOM coupled with transparency services allows software developers, packagers, distributors, auditors, and users to assure the authenticity of entities, evidence, policy, and artifacts and receive guarantees that the entities can be authorized, non-repudiable, immutable, and auditable. This approach facilitates moving the software supply chain from a largely invisible part of the cybersecurity landscape into a visible, transparent, accountable, and highly observable component across its lifecycle.

Safe Movement of Physical Goods Across Geographical Borders

Current customs entry processes and environment results in limited supply chain data visibility, and fragmented or lacking data submissions create an information gap. This creates a risk for goods entering the geographical borders. In addition, restricted usage of trusted data inhibits the collaboration between trade and partnering government agencies to validate and speed the entry clearance and targeting process, resulting in congestion in the supply chain processes, inefficiencies prior to entry of goods within geographical borders, delays in the abilities of regulatory bodies ability to apply appropriate custom releases and ability of regulatory bodies (e.g., U.S. Customs and Border Protection [CBP]) to apply timely consequences creating business risk for importers.

The use of technical standards which have been vetted through standards organizations like GS1 and W3C (in particular verified credentials and decentralized identifiers) allow regulatory bodies to understand clearly:

  • Who is in control of the products being shipped

  • What are the contents of a particular shipment

  • Where are the parties associated with the shipment located

Understanding the who, what, and where about the goods entering and leaving the geographical borders help the regulatory bodies to:
* Gather critical supply and trade data without divulging proprietary information
* Receive data at the creation of the data from the original source
* Retrieve missing data for better quality information for earlier decisions regarding the shipments
* Improve data quality to make informed decisions about a shipment
* Assert verifications of the parties involved with a shipment

Securing Software Supply Chains

Software supply chain attacks are becoming more prevalent. Such attacks happen when a cyber threat actor infiltrates a software vendor’s network and employs malicious code to compromise the software before the vendor sends it to their customers. The compromised software then compromises the customer’s data or system. These types of attacks affect all users of the compromised software and can have widespread consequences for government, critical infrastructure, and private sector software customers, often resulting in crippling companies and bringing global operations to a halt. The software supply chain is becoming so critical that in May 2021, the president of the United States issued an Executive Order targeted at improving the nation’s cybersecurity.

The use of verified credentials and decentralized identifiers provides the necessary technical infrastructure to address critical software supply chain issues. Decentralized identifiers define a standard way to discover keys for issuers and subjects. Verified credentials define a standard way to discover semantics for private claims. These attributes of decentralized identifiers and verified credentials enable defense against powerful threat actors.

Confidential Computing

Confidential Computing can leverage hardware-protected trusted execution environments (TEEs) to operate cloud services that protect the confidentiality of data that they process. It relies on remote attestation, which allows the service to prove to remote users what is the hash of its software, as measured and signed by the hardware.

For instance, consider a speech recognition service that implements machine learning inference using a deep neural network model. The operator of the service wants to prove to its users that the service preserves the user's privacy, that is, the submitted recordings can only be used to detect voice commands but no other purpose (such as storing the recordings or detecting mentions of brand names for advertisement purposes). When the user connects to the TEE implementing the service, the TEE presents attestation evidence that includes a hardware certificate and a software measurement for their task; the user verifies this evidence before sending its recording.

But how can users verify the software measurement for their task? And how can operators update their service (e.g., to mitigate security vulnerabilities, to improve accuracy) without first convincing all users to update the measurements they trust?

A supply chain that maintains a transparent record of the successive software releases for machine-learning models and runtimes, recording both their software measurements and their provenance (e.g., source code, build reports, audit reports) can provide users with the information they need to authorize these tasks, while holding the service operator accountable for the software they release for them.

Microelectronics

The structures of microelectronics include composite features across numerous elements (e.g., hardware, firmware, software), each with unique lifecycle stages. The decentralized and generally proprietary supplier records contain diverse data sources. Supply chain insights and lifecycle data transparency for upstream processes are opaque when one assembles components to form a system or system of systems. Ultimately, the end customer must conduct a cybersecurity risk analysis and determine the boundaries of where to apply blind trust, typically driven by the lack of understanding at some level in the system.

The market requires an automated and cloud-scale supply chain security service to address the full-stack analysis of microelectronic systems at any moment throughout the lifecycle while maintaining supplier protection of intellectual property. A proposed solution is to apply a Zero-Trust philosophy using transparency services to support data-driven, quantitative risk assessments and management techniques to assure microelectronics meet confidentiality and integrity requirements and inform the end customer of residual risks.

Digital Product Passport

A circular economy aids in reducing waste by keeping products or their components in the loop through reuse, repair, refurbishment, and recycling. As a first step, many products which have reached end-of-life are now being remanufactured or recycled. Unfortunately, product data such as identification, technical records, lifecycle, materials, and hazards are often unknown or not shared by the industrial manufacturers. Customers lack data on a product's environmental footprint and recyclability, and manufacturers lack insights on how their products are reused or recycled through their lifecycle. A digital product passport, supported by transparency services, allows traceability of supply chain artifacts, auditable claims and compliance, and measurement and management of lifecycle data to promote a sustainable circular economy.

Proposed Standardization Scope (40 min)

  • Overview of current architecture draft (10 min)
  • State-of-the-art overview (brief to avoid getting lost in the details) (5 min)
    • X.509 CA based certification validation works for situations where either the identity does not matter, or it is the current valid certificate.
    • Claim\Endorsement signing, signature formats
      • sigstore, COSE/JOSE, ...
    • transparency systems
      • CT, CONIKS, rekor, Google Oak, ...
    • identity
      • credentials vs identity, PKIX vs DID, ...
    • SBOM formats
      • SPDX, SWID, RIMs, SLSA, CycloneDX...
    • Authenticode (proprietary)
  • Specification to enable global supply chain - software and physical goods. (overview of the work done to date + areas that need future development) (5 min)
    • Signature formats and identifier formats that work both physical and software supply chains.
    • A vocabulary, mechanism and data sets to help determine the legitimacy of organizations participating in global trade and the status of the products and materials described therein. A preliminary version (https://w3c-ccg.github.io/traceability-vocab/#abstract) for the physical supply chain goods has been incubated as part of W3C Credentials Community Group. Inputs are required from other parties to evolve these specifications. At IETF, we would continue and mature these standards and extend them to software chains as well.
    • Discovery and exchange mechanisms, particularly as they relate to both physical and software supply chain use cases. A preliminary version (https://w3c-ccg.github.io/traceability-interop/) has been incubated as part of W3C Credentials Community Group. Inputs are required from other parties to evolve these specifications. At IETF, we would like to continue and mature these standards.
  • Motivation for standardization (5 min)
    • Harder to secure when there is no standarization. Full fidelity interoperability is desired across each market space, as it simplifies attempts by producers to hit as broad a space as possible.
  • Describe architectural aspects, if needed (15 min)
    • Need for a digitial Notary system. One which can
      • Limit fraud
      • Verify and record the identification of participants
      • Maintaining an audit journal fit for Legal discovery
      • Produce a notarial receipt for all documents
    • Programatic Generic Auditing
    • Supply Chain Document Storage. End points where endorsements, SBOMs, etc. documents can be recorded to, allowing for
      • Nesting from product to product,
      • Place to retrieve them when the shipping product cannot (think IOT type devices)
    • Third-party Endorsements. Move to a system where others can generate endorsements of conformance. This is not RATS.
      • Demonstrate that this is more than a spec exercise.
      • What is not envisioned to be standardized

Discussion (60 min)

  • Is the IETF the right place to do this work?
  • Which organizations need to be involved/collaborated with?
    • W3C Verifiable Credentials WG (Orie to liason)
    • W3C Decentralized Identifiers WG (Orie to liason)
  • What are expected technical challenges?
  • Is there interest in implementing the specifications?
  • Is the technology likely to get deployed?
  • Is there enough interest in helping with the work (spec editing, reviewing, implementing, deploying)?