P100 � AIEP � Multi-Chip Governance Co-Attestation Architecture
Field of the Invention
[0001] The present invention relates to hardware security architectures for governed artificial intelligence systems.
[0002] More particularly, the invention relates to a co-attestation mechanism between an AIEP governance chip operating in accordance with GB2519826.8 and one or more existing hardware security enclaves present in a host device � including processor secure enclaves, trusted execution environments, and device security processors � wherein neither component can unilaterally override the other’s governance constraints, and wherein the co-attestation record is cryptographically verifiable by external parties.
Background
[0003] Mobile and embedded computing devices commonly incorporate hardware security architectures including processor-embedded secure enclaves, trusted execution environments (TEE), and dedicated security processors. Examples include Apple Secure Enclave, ARM TrustZone, and Qualcomm Secure Processing Unit (SPU).
[0004] These existing security architectures enforce device security policies including secure key storage, biometric authentication, and payment credential protection. They operate as trusted hardware components with defined interfaces to the application processor.
[0005] An AIEP governance chip as defined in GB2519826.8 enforces AI reasoning governance constraints � canonical arbitration, hash-binding, fail-closed execution gating, and GoalVector generation � at the silicon level. A device incorporating both an AIEP governance chip and an existing hardware security architecture requires a mechanism for the two components to operate together without either being able to override the other’s governance domain.
[0006] Without a co-attestation mechanism, two failure modes arise. First, the existing security processor may be able to suppress or bypass AIEP governance chip operations by issuing privileged instructions within its security domain. Second, the AIEP governance chip may be able to operate outside the device’s established security policy by claiming a domain that the existing security architecture does not recognise.
[0007] Existing systems do not provide:
(a) a mutual attestation protocol between an AIEP governance chip and an existing device security enclave establishing independent governance domains that neither can override; (b) a co-attestation record cryptographically binding the outputs of both components for each governed execution cycle; (c) fail-closed execution gating when co-attestation between the components cannot be established; (d) a CoAttestationHash enabling external parties to verify that both the AIEP governance chip and the existing security enclave attested to the execution; or (e) governance domain boundary enforcement preventing the existing security processor from issuing instructions that would alter canonical AIEP arbitration outcomes.
[0008] There exists a need for a co-attestation architecture that enables AIEP governance chips to integrate with existing device security architectures in a manner that preserves both governance domains without either being able to override the other.
Summary of the Invention
[0009] The invention provides a multi-chip governance co-attestation architecture for a device incorporating an AIEP governance chip and one or more existing hardware security components.
[0010] The co-attestation architecture establishes a GovernanceDomainBoundary between the AIEP governance chip domain and the existing security component domain. The GovernanceDomainBoundary defines which operations belong to each domain and specifies that neither component may issue instructions that cross into the other’s domain.
[0011] At each governed execution cycle, both components independently produce attestation values for the operations within their respective domains.
[0012] The AIEP governance chip produces an AIEPAttestationValue comprising a hash over its canonical arbitration outputs, execution state, and a cycle counter.
[0013] The existing security component produces a SecurityEnclaveAttestationValue comprising a hash over its security policy enforcement outputs and the same cycle counter.
[0014] A CoAttestationRecord is produced by combining the AIEPAttestationValue and SecurityEnclaveAttestationValue under a schema-defined combination function producing a CoAttestationHash.
[0015] Execution of outputs from the governed cycle is gated on the successful production of the CoAttestationRecord. If either component fails to produce its attestation value within the defined cycle window, execution is blocked fail-closed.
[0016] CoAttestationHash is included in the output record, enabling external parties to verify that both components attested to the execution.
[0017] The technical effect is a governed integration architecture enabling AIEP governance chips to operate within devices that already have hardware security architectures, without requiring replacement of the existing security component and without either component gaining the ability to override the other.
Definitions
[0018] GovernanceDomainBoundary: A hardware-enforced specification defining the operations belonging to the AIEP governance chip domain and the existing security component domain respectively, preventing cross-domain instruction issuance.
[0019] AIEPAttestationValue: A hardware-produced cryptographic value from the AIEP governance chip over its canonical arbitration outputs and execution state for a specific cycle, incorporating a cycle counter for synchronisation.
[0020] SecurityEnclaveAttestationValue: A hardware-produced cryptographic value from the existing security component over its security policy enforcement outputs for the same cycle, incorporating the same cycle counter.
[0021] CoAttestationRecord: A combined record produced from AIEPAttestationValue and SecurityEnclaveAttestationValue under a schema-defined combination function, containing the CoAttestationHash.
[0022] CoAttestationHash: A cryptographic hash computed under a schema-defined combination function over AIEPAttestationValue and SecurityEnclaveAttestationValue, enabling external verification that both components attested to the execution.
[0023] Cycle Counter: A shared monotonic counter maintained in tamper-resistant hardware, incremented at each governed execution cycle, used to synchronise attestation values from both components.
Detailed Description of Preferred Embodiments
1. GovernanceDomainBoundary Establishment
[0024] The GovernanceDomainBoundary is established at device initialisation via a mutual recognition protocol executed between the AIEP governance chip and the existing security component.
[0025] The mutual recognition protocol establishes: the operation classes belonging to the AIEP governance chip domain; the operation classes belonging to the existing security component domain; and the interface through which cycle counter synchronisation and attestation value exchange occur.
[0026] The GovernanceDomainBoundary specification is loaded into hardware-resident registers in both components via their respective authenticated configuration interfaces.
[0027] Once established, the GovernanceDomainBoundary cannot be modified by software instruction from any layer.
[0028] The AIEP governance chip will not accept instructions for operations within its domain from the existing security component, and will not issue instructions that alter operations within the existing security component’s domain.
2. Cycle Counter Synchronisation
[0029] A shared cycle counter is maintained in tamper-resistant hardware accessible to both components.
[0030] The cycle counter is incremented at each governed execution cycle.
[0031] Both components read the current cycle counter value at the start of each cycle and incorporate it into their respective attestation values.
[0032] Cycle counter synchronisation ensures that AIEPAttestationValue and SecurityEnclaveAttestationValue produced in the same cycle can be deterministically combined.
3. Attestation Value Production
[0033] AIEPAttestationValue is computed within the AIEP governance chip hardware isolation enclave as:
AIEPAttestationValue = H(CanonicalArbitrationOutput || ExecutionStateHash || CycleCounter || AIEPChipId)
[0034] SecurityEnclaveAttestationValue is computed within the existing security component as:
SecurityEnclaveAttestationValue = H(SecurityPolicyEnforcementOutput || CycleCounter || SecurityComponentId)
[0035] Both components produce their attestation values independently within the same cycle window.
4. CoAttestationRecord Production
[0036] CoAttestationHash is computed as:
CoAttestationHash = H(AIEPAttestationValue || SecurityEnclaveAttestationValue || CycleCounter || SchemaVersionId)
[0037] CoAttestationRecord comprises CoAttestationHash, AIEPAttestationValue, SecurityEnclaveAttestationValue, CycleCounter, and a timestamp recorded as data.
[0038] CoAttestationRecord is appended to the governance chip’s append-only execution record.
5. Fail-Closed Execution Gating
[0039] Execution of outputs from the governed cycle is gated on the presence of a valid CoAttestationRecord.
[0040] If either component fails to produce its attestation value within the defined cycle window � due to component failure, security policy violation, or governance domain breach � the CoAttestationRecord cannot be produced.
[0041] Execution is blocked fail-closed and a CoAttestationFailureRecord is appended identifying which component failed to produce its attestation value.
6. External Verification
[0042] External parties � including device manufacturers, regulatory auditors, and counterparties � can verify a CoAttestationHash by obtaining the stored AIEPAttestationValue and SecurityEnclaveAttestationValue from the CoAttestationRecord and recomputing the hash.
[0043] A matching CoAttestationHash confirms that both components independently attested to their respective governance outputs in the same cycle.
[0044] External verification does not require access to either component’s internal state beyond the stored attestation values.
7. Integration with Device Manufacturer Security Architecture
[0045] The co-attestation architecture is designed to be implementable without modification to the existing security component’s core architecture.
[0046] In one embodiment, the existing security component’s contribution to the co-attestation is provided via a new attestation extension � an additional computation the existing security component performs in each cycle alongside its existing operations, producing SecurityEnclaveAttestationValue without altering its existing security functions.
[0047] This design enables AIEP governance chip integration with Apple Secure Enclave, ARM TrustZone, and Qualcomm SPU architectures through attestation extension rather than architectural replacement.
Claims
-
A multi-chip governance co-attestation architecture for a device comprising an AIEP governance chip and an existing hardware security component, the architecture configured to: establish a GovernanceDomainBoundary preventing either component from issuing instructions that alter operations within the other’s domain; maintain a shared cycle counter in tamper-resistant hardware incremented at each governed execution cycle; produce an AIEPAttestationValue from the AIEP governance chip and a SecurityEnclaveAttestationValue from the existing security component incorporating the same cycle counter; compute a CoAttestationHash over both attestation values and the cycle counter; gate execution of cycle outputs on successful CoAttestationRecord production; and block execution fail-closed when either component fails to produce its attestation value within the cycle window.
-
The architecture of claim 1 wherein the GovernanceDomainBoundary is established at device initialisation via a mutual recognition protocol and cannot be modified by software instruction from any layer.
-
The architecture of claim 1 wherein CoAttestationHash is computed as a cryptographic hash over AIEPAttestationValue, SecurityEnclaveAttestationValue, the cycle counter, and a schema version identifier.
-
The architecture of claim 1 wherein CoAttestationRecord is appended to the governance chip’s append-only execution record comprising CoAttestationHash, both attestation values, cycle counter, and a timestamp.
-
The architecture of claim 1 wherein external verification of CoAttestationHash is performed by obtaining stored attestation values from the CoAttestationRecord and recomputing the hash without access to either component’s internal state.
-
The architecture of claim 1 wherein the existing security component’s contribution to co-attestation is provided via an attestation extension producing SecurityEnclaveAttestationValue without altering the existing security component’s core security functions.
-
A method for multi-chip governance co-attestation comprising: establishing a GovernanceDomainBoundary at device initialisation; synchronising a shared cycle counter between governance chip and security component; producing independent attestation values from each component incorporating the cycle counter; computing CoAttestationHash over both values; and gating execution fail-closed on CoAttestationRecord production.
-
A non-transitory computer-readable medium storing instructions which, when executed by a hardware attestation controller, perform the method of claim 7.
Drawings
Figure 1 � GovernanceDomainBoundary Architecture
Device hardware:
+---------------------------+ +------------------------------+
| AIEP Governance Chip | | Existing Security Component |
| (AIEP domain) | | (Apple Secure Enclave / |
| | | ARM TrustZone / Qualcomm) |
| GoalVector | | Key storage |
| ConstitutionalPolicy | | Biometric auth |
| FlexibilityContract | | Secure boot |
| FoundingTensionHash | | |
+---------------------------+ +------------------------------+
? GovernanceDomainBoundary ?
Neither component can issue instructions altering
operations within the other's domain.
Established at device initialisation; not modifiable by software.
Figure 2 � Dual Attestation with Shared Cycle Counter
Tamper-resistant shared cycle counter: C = 42
|
+---------------------------+---------------------------+
| |
v v
AIEP Governance Chip Security Component
AIEPAttestationValue = SecurityEnclaveAttestationValue =
sha256(aiep_state ? C) sha256(security_state ? C)
|
+---------------------------+
|
v
CoAttestationHash = sha256(
AIEPAttestationValue
? SecurityEnclaveAttestationValue
? cycle_counter (C=42)
? schema_version_id
)
Figure 3 � CoAttestationRecord Structure
CoAttestationRecord (appended per cycle, append-only):
{
co_attestation_hash,
aiep_attestation_value,
security_enclave_attestation_value,
cycle_counter: 42,
timestamp_iso: "2026-03-08T...",
schema_version: "2.0.0"
}
External verification:
obtain record from governance chip's append-only log
co_attestation_hash inputs are all stored in the record
recompute co_attestation_hash ? compare
no access to either component's internal state needed.
Figure 4 � Fail-Closed Execution Gate
+----------------------------------------------------------+ | CO-ATTESTATION EXECUTION GATE | | | | Cycle C begins | | Both components must produce attestation value | | within cycle window T_max | | | | Both received in T_max? | | | | +--- YES ---> CoAttestationRecord produced | | | CoAttestationHash computed | | | cycle output EXECUTED | | | | | +--- NO ---> EXECUTION BLOCKED (fail-closed) | | missing component identified | | AttestationFailureRecord appended | +----------------------------------------------------------+
Abstract
A multi-chip governance co-attestation architecture for devices incorporating an AIEP governance chip and an existing hardware security component is disclosed. A GovernanceDomainBoundary established at device initialisation prevents either component from issuing instructions into the other’s domain. A shared tamper-resistant cycle counter synchronises attestation production. The AIEP governance chip produces an AIEPAttestationValue and the existing security component produces a SecurityEnclaveAttestationValue for each governed execution cycle. A CoAttestationHash is computed over both values and the cycle counter, forming a CoAttestationRecord appended to the governance chip’s append-only execution record. Execution is gated on successful CoAttestationRecord production, blocked fail-closed when either component fails to produce its attestation value. External parties verify CoAttestationHash from stored records without access to component internals. The architecture integrates AIEP governance chips with existing security architectures � including Apple Secure Enclave, ARM TrustZone, and Qualcomm SPU � through attestation extension rather than architectural replacement.