<-Data Types       Go to ToC    Verification Pipeline ->

1 Threat Model

The PTF Trust Framework assumes a Full‑Trust environment in which no Process Instance (PI), no credential, and no communication channel is trusted by default.
The threat model includes:

1.1 Identity Threats

  • Impersonation of a Process Instance
  • Use of forged or stolen cryptographic keys
  • Replay of previously valid identities or credentials

1.2 Credential Threats

  • Forged InstanceCredentials or ProcessLifecycleCredentials
  • Tampering with credential contents
  • Use of expired or revoked credentials

1.3 Evidence Threats

  • Injection of fabricated attestation evidence
  • Replay of stale evidence
  • Manipulation of evidence hashes or signatures

1.4 Policy Threats

  • Bypassing policy evaluation
  • Using incorrect or outdated policies
  • Manipulating PolicyBinding objects

1.5 Communication Threats

  • Man‑in‑the‑middle attacks
  • Message tampering
  • Replay of TrustRequests or TrustResponses

1.6 Data Exchange Threats

  • Unauthorized access to exchanged data
  • Violation of legal or security constraints
  • Loss of provenance or annotation integrity

2 Security Objectives

PTF aims to ensure:

2.1 Authenticity

All identities, credentials, evidence, and messages must be verifiably authentic using SAT algorithms.

2.2 Integrity

All PTF objects must be protected against tampering through signatures and hashes.

2.3 Freshness

Evidence and credentials must be validated against timestamps and validity intervals.

2.4 Authorization

Only authorized PIs and AIMs may access or process data, as defined in DEM.

2.5 Non‑repudiation

TrustOperations and TrustResponses must be signed to provide auditability.

2.6 Least Privilege

VerificationProfiles and PolicyBindings ensure PIs only receive the trust level required for their function.

3 Security Considerations

3.1 Cryptographic Algorithms

All cryptographic operations must use algorithms defined in the Security Algorithm Taxonomy (SAT).
Deprecated or weak algorithms must be rejected.

3.2 Trust Anchors

Trust anchors must be validated using the TrustAnchor data type and must be securely distributed.

3.3 Credential Chains

If credential chains are used, each link must be validated for:

  • signature
  • issuer
  • validity interval
  • role consistency

3.4 Evidence Freshness

AttestationEvidence must include timestamps or freshness indicators and random unpredictable elements. Replay attacks must be mitigated by rejecting stale evidence.

3.5 Policy Enforcement

Policies must be:

  • authenticated
  • bound to the correct target
  • evaluated deterministically

Policy bypass must not be possible.

3.6 Message Security

TrustMessage objects must be:

  • signed
  • timestamped
  • non‑replayable

3.7 Data Exchange Metadata (DEM)

After trust is established, DEM ensures:

  • authorized access
  • legal compliance
  • security constraints
  • provenance
  • annotation integrity

3.8 Logging and Auditability

Each verification step must produce a TrustOperation entry.
Logs must be protected against tampering.

4 Assumptions and Limitations

PTF assumes:

  • Cryptographic keys are generated and stored securely by PIs.
  • Time sources used for validity and freshness checks are to be synchronised and trustworthy.
  • Underlying transport channels may be untrusted, but signatures protect integrity.
  • PTF does not define runtime sandboxing or execution isolation for PIs.
  • PTF does not define key management protocols (only key usage and identity binding).

5 Security Properties Table

PTF Object Security Protections Threats Mitigated
Cryptographic Instance Identity SAT signature, key binding, role taxonomy Impersonation, key misuse, identity spoofing
InstanceCredential SAT signature, issuer validation, validity interval Forged credentials, tampering, expired credentials
ProcessLifecycleCredential SAT signature, lifecycle state binding Fake lifecycle states, replay of old states
AttestationEvidence SET type validation, hash verification, signature verification, freshness Fake evidence, replay attacks, tampering
PolicyBinding Signature, binding to target, profile‑driven rules Policy bypass, incorrect policy use
VerificationProfile Deterministic rule evaluation Inconsistent trust decisions, privilege escalation
TrustMessage (Request/Response) Security Algorithm Taxonomy signature, timestamps, temporal unicity MITM, tampering, replay of requests/responses
TrustOperation Signed audit log entries Non‑repudiation, audit tampering
TrustAnchor Root‑of‑trust validation Fake issuers, rogue CAs
DataExchangeMetadata (DEM) Traceability, authorisations, legality, security metadata, provenance Unauthorised access, legal violations, data misuse

6 Threats → Mitigations → PTF Data Types → Pipeline Steps

Threat Mitigation Mechanism PTF Data Types Involved Verification Pipeline Step
Identity Impersonation Out-of-band authentication, signature verification, key binding, role validation CII, SAT, CryptographicInstanceRoleTaxonomy Identity Verification
Use of forged or stolen keys Signature verification, trust anchor validation CII, TrustAnchor, SAT Identity Verification
Replay of old identities Temporal unicity, timestamp checks, validity intervals CII, InstanceCredential Identity Verification
Forged credentials Signature verification, issuer validation InstanceCredential, PLC, SAT Credential Verification
Tampered credentials Hash/signature verification InstanceCredential, PLC, SAT Credential Verification
Expired or revoked credentials Validity interval checks InstanceCredential, PLC Credential Verification
Fake evidence Evidence type validation (SET), signature verification AttestationEvidence, SET, SAT Evidence Verification
Tampered evidence Hash verification, signature verification AttestationEvidence, SAT Evidence Verification
Replay of stale evidence Freshness checks (timestamps, nonces) AttestationEvidence Evidence Verification
Incomplete evidence Completeness checks AttestationEvidence, VerificationProfile Evidence Verification
Policy bypass PolicyBinding authentication, profile enforcement PolicyBinding, VerificationProfile Policy Evaluation
Use of wrong or outdated policies Signature verification, version checks PolicyBinding Policy Evaluation
Privilege escalation Deterministic rule evaluation VerificationProfile Policy Evaluation
Message tampering Signed TrustMessages TrustMessage, SAT Request Intake / Response Generation
Replay of TrustRequests/Responses Timestamps, nonces TrustMessage Request Intake
Man‑in‑the‑middle attacks Sender network address obfuscation, end‑to‑end signatures TrustMessage, SAT Request Intake / Response Generation
Audit tampering Signed TrustOperations, Data Exchange Metadata TrustOperation, SAT Operation Logging
Unauthorized data access (post‑trust acquisition) DEM authorisations DataExchangeMetadata Post‑Trust Data Exchange
Violation of security  DEM security metadata DataExchangeMetadata Post‑Trust Data Exchange

7 Verification Pipeline

<-Data Types       Go to ToC    Verification Pipeline ->