<- End‑to‑End Examples Go to ToC
1 General
The MPAI-PTF Reference Software implements Technical Specification: Process Instance Trust Framework (MPAI-PTF) V1.0 in the AI Framework specified by Technical Specification: AI Framework (MPAI-AIF) V3.0. With it, an AIF Controller establishes trust in every AI Module it runs – on its own machine or on a remote AIM host – before the Module is allowed to start, and two Controllers establish trust in each other before they exchange data.
It is written in C# for .NET 10 and is part of the software that implements MPAI-AIF V3.0, MPAI-MAS V1.0 and CAV-TEC V2.0. The same trust mechanisms protect the AI Modules of MPAI-MAS and the messages exchanged by Connected Autonomous Vehicles.
2 Components
| Component | Function |
| Trust library | The PTF Data Types, their canonical form and signatures; the issuing and checking of Cryptographic Instance Identities, Instance Credentials and Process Lifecycle Credentials; the Verification Pipeline; the Trust Establishment Protocol; Attestation Evidence; the Trace of Trust Operations; the signing of Data Exchange Metadata. |
| AIF Controller | Acts as Trust Anchor, Policy Authority and Verifier for the AI Modules it runs: it issues their credentials, binds their policy, verifies them before a Module starts, and records each Trust Operation. |
| AIM host | A program that runs AI Modules on another machine for a Controller. Each AIM’s key is made on the host and never leaves it; the host presents the AIM’s identity and evidence, and receives its credentials. |
| Root of trust | A Trust Anchor’s key may be held in a TPM 2.0, where it cannot be exported, and the code the party runs is measured into it. The software uses the TPM 2.0 command set against Microsoft’s reference TPM simulator. |
| MPAI Store | Approves AIM Implementations by recording the fingerprints of their binaries; the evidence of what an AIM runs is compared with them. |
| City Trust Authority | Admits Connected Autonomous Vehicles to a city by issuing them credentials, so that CAVs that do not know each other can establish trust through it. |
3 The Actors
| MPAI-PTF Actor | In the Reference Software |
| Process Instance | An AI Module Instance, local or on an AIM host. |
| Trust Anchor | An AIF Controller, an AIM host, a City Trust Authority. A CAV is a Controller. |
| Verifier, Policy Authority | The AIF Controller, for the AI Modules it runs; each end of a link between two Trust Anchors, for the other end. |
| Data Producer / Consumer | CAVs exchanging messages through their External Ports. |
4 Data Types
The JSON Schemas of all the Data Types are compiled and checked by the tests; the objects the software produces are validated against them.
| Data Type | Use |
| Cryptographic Instance Identity | Produced and verified: an ECDSA P-256 public key, its fingerprint, and a signature proving possession of the private key. |
| Instance Credential | Issued and verified, also as a chain of credentials (e.g. a package issuing credentials to the AI Modules it contains). |
| Process Lifecycle Credential | Issued at each change of state of a Module: Created, Running, Suspended, Terminated. |
| Attestation Evidence | Produced and verified: the hashes of the AIM’s binary and models, or a TPM quote. |
| Policy Binding | Produced by the Controller from the AIM’s Metadata – its Ports and their Data Types, the Storage it may use – and enforced on every Channel of the Module. |
| Trust Anchor | Produced and verified. |
| Trust Message | TrustRequest and TrustResponse of the Trust Establishment Protocol. |
| Trust Operation | Produced and signed for each step of verification, issuing and policy binding; kept in the Trace. |
| Data Exchange Metadata, Security | Produced and verified on the messages CAVs exchange. |
| Security Algorithm, Security Evidence and Trust Operation Taxonomies | Their identifiers are used. |
| Cryptographic Instance Role Taxonomy, Security Technology Taxonomy, Profile, Process Instance, Error Code | Not used yet (see 11). |
5 Verification Pipeline
Before a Module starts, the Controller verifies each of its AI Modules with the Verification Pipeline. The steps are executed in order, the first failure stops the pipeline, and each step is recorded as a signed Trust Operation:
- Identity: the Cryptographic Instance Identity is well formed, its fingerprint matches its key, its signature proves possession of the key, and it is that of the expected instance.
- Credential: the Instance Credential – or its chain – leads to a trusted Trust Anchor, is signed by its issuer, names this identity, and is within its validity.
- Lifecycle: the Process Lifecycle Credential is signed by a trusted issuer, current, and in the expected state.
- Evidence: the Attestation Evidence is signed, and what it says the AIM runs is what the MPAI Store approved.
- Policy: the Policy Binding is the Verifier’s own, is for this instance, and its constraints are those of the AIM’s Metadata.
An AI Module that fails is not started; the Module reports NOT_TRUSTED.
6 Trust Establishment Protocol
Two Trust Anchors – a Controller and an AIM host, or two CAVs – establish trust with the Trust Establishment Protocol when their link is opened, over TLS:
- Each end sends a signed TrustRequest or TrustResponse and verifies the other’s: its Trust Anchor is trusted – or, for CAVs, credited by a Trust Authority the receiver trusts – valid, and its signature correct. Trust is mutual.
- Freshness: a message more than 5 minutes old or ahead is refused.
- Replay: each message names the certificate of the TLS link it is sent on, so it cannot be replayed or relayed on another link.
- An AIM host may require the Controller to present TPM-attested evidence of the code it runs, and vice versa.
7 Attestation Evidence
- The Controller measures each AIM Implementation – its binary and its models – before building it, and compares the measurements with the fingerprints approved by the MPAI Store.
- A party whose key is in a TPM measures its own code and each Implementation into TPM registers and proves them with a quote, signed by a key the TPM manufacturer certified, over a nonce bound to the link. The Verifier replays the measurement log against the quote and checks each measurement against the approved values.
8 Data Exchange Metadata
Each message a CAV sends to another CAV carries Data Exchange Metadata with its Security: the Trust Authority and the credential of the sender, and the hash of the message signed with the sender’s key. The receiver drops a message that is unsigned, altered, or signed by another party than the one it claims to come from.
9 Cryptography
- Signatures: ECDSA P-256 with SHA-256 (
PTF-ALGO-SIG-ECDSA-P256-SHA256). Hashes: SHA-256 (PTF-ALGO-HASH-SHA256). - An object is signed in canonical form: members sorted at every level, no whitespace, minimal escaping, numbers in their shortest form, UTF-8.
- Credentials are valid for 24 hours, Process Lifecycle Credentials for 1 hour, Trust Anchors for 1 year.
10 Trust Operations and the Trace
Every Trust Operation – issuing, verifying, binding a policy, changing a lifecycle state, admitting a link – is signed and appended to a Trace in which each record carries the hash of the previous one and the Controller’s signature. The Controller verifies its Trace when it starts and refuses to run if the Trace was altered, truncated or reordered.
11 Not yet implemented
- Roles in the Cryptographic Instance Identity and the Cryptographic Instance Role Taxonomy.
- Profile (VerificationProfile), Process Instance and Error Code objects: a failure is reported with a reason, not with the Error Codes of MPAI-PTF.
- Revocation of credentials; an allow-list of evidence types; the age of evidence.
- The usage rules of Data Exchange Metadata (retention, onward sharing), and Data Exchange Metadata on the data exchanged inside a Controller or with an AIM host.
- A Verifier distinct from the parties: the Controller verifies the AI Modules it runs, and two Trust Anchors verify each other.
- The Conformance Testing suite (ID-xx, CR-xx, EV-xx, …) as such.
- A hardware TPM: the software uses the TPM 2.0 reference simulator.
12 Verification
The Reference Software is verified by automated tests, among them:
- The schemas, the canonical form, and signatures altered, reordered or missing.
- Identities, credentials and credential chains, valid and refused: not possessed, expired, not yet valid, wrongly signed, from an unknown issuer, for another identity, in the wrong state.
- Each failure of the Verification Pipeline and where it stops; Modules refused as
NOT_TRUSTED. - Binaries and models other than those approved by the Store.
- The Trust Establishment Protocol with foreign, expired, forged, stale and relayed messages.
- TPM-held keys that cannot be exported; quotes from another manufacturer, with an old nonce, with a missing log item, or over altered code.
- The Trace altered, truncated, reordered and continued after a restart.
- An MPAI-MAS Service under Zero Trust with an attested AIM host; two CAVs admitted by a city, and messages refused when altered or sent by another party.
13 Access to the code
Please send an email to the MPAI Secretariat to access the code.
