PaperlayerView exact revision on arXiv

Source-linked AI summary

Secure Aggregate Encryption with Identity-Based Authentication for Multi-Vendor FPGA Cloud Deployment

Mukta Debnath, Krishnendu Guha, Debasri Saha, Amlan Chakrabarti, Susmita Sur-Kolay

arXiv:2610.11873v1cs.CR

TL;DR

Heterogeneous FPGA cloud deployment requires scalable authorization, authenticated device access, and bitstream protection, while prior approaches leave these functions separated. SAEID integrates aggregate authorization, identity-based authentication, and identity-bound verification; reported timings include approximately 4.35 ms for authentication and 4.95–5.09 μs for device addition.

  • Problem

    Heterogeneous FPGA deployment requires device authentication, device-bound bitstream verification, scalable authorization, and secure management of changing device groups.

    Source: §1 · p. 1

  • Method

    SAEID extends AgEID to heterogeneous multi-vendor clouds by combining aggregate authorization with authenticated deployment sessions and device-bound bitstream protection.

    Source: §1 · p. 2

  • Results

    Identity-based authentication completes in approximately 4.35 ms, and device addition requires 4.95–5.09 μs.

    Source: §1 · p. 3

  • Takeaways & Limitations

    SAEID retains constant-size aggregate ciphertexts within each vendor domain while providing individual decryption and dynamic membership.

    Source: §1 · p. 2

    AgEID, which SAEID extends, assumed a homogeneous single-vendor environment and primarily addressed confidentiality.

    Source: §1 · p. 2

Abstract

from arXiv · show

Secure deployment of FPGA bitstreams in heterogeneous multi-vendor cloud infrastructures requires scalable authorization, authenticated device access, and bitstream protection throughout the deployment lifecycle. Existing approaches typically address these functions through separate mechanisms, increasing coordination and key management requirements. This paper presents SAEID, a secure FPGA deployment framework that integrates aggregate authorization, certificate-free identity-based device authentication, and identity bound bitstream verification within a pairing based cryptographic framework, with symmetric cryptography used for session binding and AES 256 GCM based bitstream protection. Building on AgEID, an aggregate encryption scheme that enables individual decryption for authorized FPGA devices, SAEID extends the underlying framework to heterogeneous multi vendor deployments by supporting multiple FPGA vendors and IP providers, capability-aware authorization, and dynamic device membership. SAEID provides protection against unauthorized access to future deployments after device revocation and to prior deployments by newly enrolled devices, while retaining constant-size aggregate ciphertexts within each vendor domain and individual decryption. Experimental results demonstrate the practical performance of SAEID, with identity-based device authentication completing in approximately 4.35 ms and device membership updates requiring 4.95 to 5.09 micro seconds for device addition. The aggregate-encryption component exhibits scalable behavior with increasing device-set size. The complete SAEID software decryption path was also validated on a physical ZC702 Cortex A9 platform, requiring 191.126 ms. These results demonstrate scalable aggregate authorization with bounded authentication and dynamic-membership overhead for secure multi-vendor FPGA deployment.

1 Introduction

Heterogeneous FPGA cloud deployment calls for scalable authorization, device authentication, device-bound bitstream verification, and secure management of changing device groups. SAEID extends AgEID with multi-vendor authorization, dynamic membership, and authenticated, device-bound deployment while retaining individual decryption and constant-size aggregate ciphertexts within each vendor domain.

1 Introduction

  • SAEID extends AgEID beyond its homogeneous, single-vendor model, which primarily addressed confidentiality, to heterogeneous multi-vendor cloud infrastructures.Device authentication, bitstream integrity and device binding, and dynamic device membership were outside AgEID’s security model.Source: §1 · p. 2
  • SAEID supports multiple FPGA vendors and IP providers, capability-aware authorization, and dynamic membership while retaining constant-size aggregate ciphertexts per vendor domain and individual decryption.Its aggregate-encryption design extends to heterogeneous FPGA clouds using vendor-specific authorization domains and capability-aware device selection.Source: §1 · p. 2
  • The framework combines aggregate authorization, authenticated deployment sessions, and device-bound bitstream protection while keeping cryptographic domains separate.Pairing-based device authentication and identity-bound bitstream verification use a common bilinear-group foundation, with separate identity and authorization secrets.Source: §1 · p. 2
  • Device addition and revocation use constant-cost updates to the affected vendor-specific authorization component and provide forward and backward security across membership epochs.The contribution describes dynamic membership with forward and backward security across epochs.Source: §1 · p. 2
  • The security analysis covers confidentiality, device impersonation and replay resistance, bitstream integrity and device binding, dynamic membership, and multi-vendor isolation.The evaluation also validates the complete SAEID software path on physical ZC702 ARM hardware.Source: §1 · p. 3
  • Approximately 4.35 ms for identity-based authentication, 4.95–5.09 μs for device addition, and 4.49–5.46 μs for revocation; the software path was validated on physical ZC702 ARM hardware.The passage also reports the complete SAEID software path was validated on a physical ZC702 ARM platform.Source: §1 · p. 3

2 Background and Related Work

Prior FPGA security work addresses bitstream protection, cloud deployment, and multi-device authorization, while authentication and bitstream verification have often remained separate from aggregate encryption. SAEID responds to the gap with a framework spanning heterogeneous vendors, multiple IP providers, and dynamic device membership.

2.1 FPGA Bitstream Security and Cloud Deployment

  • Earlier work spans device-level configuration security, cloud-FPGA protection, and IP protection, but often focuses on individual configurations or IP distribution.Related mechanisms include secure configuration, bitstream authentication, tamper protection, and IP licensing.Source: §2.1 · p. 3

2.2 Aggregate Encryption and Dynamic Authorization

  • Aggregate encryption lets an IP provider encrypt an AES key once for an authorized FPGA cluster while preserving individual device decryption.Broadcast encryption and key-aggregate cryptography provide related foundations; AgEID adapts aggregation to FPGA bitstream deployment.Source: §2.2 · p. 4
  • Cloud FPGA authorization must evolve as devices are added or revoked, and dynamic key-aggregate schemes address membership changes and secure key updates.Source: §2.2 · p. 4

2.3 Device Authentication and Bitstream Authenticity

  • Device authentication establishes FPGA legitimacy, while bitstream authenticity checks authorized-provider origin and whether configuration data was modified; prior mechanisms remained separate from aggregate authorization.Identity-based cryptography offers a certificate-free approach, including pairing-based encryption and signature constructions.Source: §2.3 · p. 4

2.4 Research Gap

  • Existing mechanisms did not jointly address heterogeneous cloud deployment, motivating SAEID’s combination of scalable authorization, certificate-free authentication, identity-bound verification, and dynamic membership.The stated scope also includes multiple FPGA vendors and IP providers.Source: §2.4 · pp. 4–5

3 System Model and Threat Model

SAEID models a cloud FPGA deployment with vendor-operated identity authorities, IP providers, a partially trusted cloud service provider, and heterogeneous devices. Its capability-aware and vendor-separated authorization model defines security objectives and explicit boundaries for device membership and adversarial threats.

3.1 System Entities

  • Vendors provision FPGA devices with individual decryption and identity keys, while providers prepare accelerator designs and the CSP manages shared resources and relays messages.Each vendor operates its own identity authority and cryptographic domain.Source: §3.1 · pp. 5–6

3.2 Capability-Aware Deployment Model

  • Capability classes capture deployment requirements such as FPGA-family compatibility, accelerator features, available logic, memory, DSP resources, and bitstream compatibility.A capability cluster can span vendors, but eligibility does not replace vendor- and provider-specific cryptographic authorization.Source: §3.2 · p. 6

3.3 Multi-Vendor and Multi-Provider Deployment

  • A capability cluster may include devices from multiple vendors, with a separate provisioning context and authorization component maintained for each vendor.Cross-vendor pooling does not require sharing device private keys or merging cryptographic domains.Source: §3.3 · p. 6
  • Each IP-provider deployment has its own authorization state, session context, and protected bitstream, so state for one provider does not itself grant access to another’s deployment.Vendor-issued device credentials remain unchanged across provider deployments.Source: §3.3 · p. 6

3.4 Threat Model and Security Objectives

  • The model excludes availability and denial-of-service attacks, provider-credential revocation, physical extraction, and compromise of protected master secrets or provider credentials.Provider credentials are assumed valid for their registration lifetime unless the vendor identity domain is re-provisioned.Source: §3.4 · pp. 7–8
  • Only authorized devices can recover the AES key, while revocation blocks later ciphertexts and newly enrolled devices cannot decrypt ciphertexts generated before enrollment.Membership changes affect only the corresponding vendor-specific authorization component and do not require re-provisioning unaffected devices.Source: §3.4 · p. 7
  • Fresh authentication challenges resist transcript reuse, and authenticated session binding detects ciphertexts or authorization messages from a different deployment context before AES-key recovery.The provider–device exchange binds aggregate ciphertexts to authenticated identities and freshness values.Source: §3.4 · p. 8
  • Identity-bound provider signatures and AES-256-GCM protect provider authenticity, intended-device binding, and bitstream payload integrity before FPGA configuration.Source: §3.4 · p. 8

4 Proposed SAEID Framework

The proposed SAEID framework extends aggregate encryption and individual decryption to heterogeneous multi-vendor, multi-provider deployments, combining capability-aware authorization and dynamic membership with certificate-free identity-based device authentication and identity-bound bitstream verification. Its workflow separates session binding, aggregate key recovery, provider/device verification, and bitstream integrity checks.

4 Proposed SAEID Framework

  • SAEID retains AgEID’s aggregate-encryption and individual-decryption properties while adding capability-aware selection, vendor-specific authorization, dynamic membership, certificate-free authentication, and identity-bound bitstream verification.Its extensions primarily address deployment and security layers rather than changing the underlying aggregate-encryption primitive.Source: §4 · p. 8

4.1 From AgEID to SAEID: A Deployment Scenario

  • The same vendor-specific aggregate ciphertext serves all authorized devices, its size is independent of the authorized-device count, and devices in other vendor domains use separate encryption operations.Membership epochs prevent revoked devices from recovering later deployments and newly enrolled devices from recovering earlier ciphertexts; unaffected devices’ identity credentials remain unchanged.Source: §4.1 · pp. 9–10

4.2 Capability-Aware Clustering and Heterogeneous Bitstream Deployment

  • Capability determines deployment eligibility, while vendor identity defines independent cryptographic authorization domains; bitstream preparation scales with architecture classes rather than device count.Devices may share a capability cluster across vendors, but architectural compatibility determines which compiled bitstream variant each device can execute.Source: §4.2 · pp. 11–12

4.3 Multi-Vendor, Multi-Provider Deployment and Dynamic Membership

  • Devices from different vendors can participate in one deployment without sharing vendor secrets or device keys, and SAEID supports deployments from multiple IP providers.Each provider’s deployment has its own authorization state, session context, and key; adding or revoking a device does not require reconstructing the complete multi-vendor authorization structure.Source: §4.3 · pp. 12–13, Figure 3 · p. 12
  • Membership updates change only the affected vendor aggregate component at O(1) cost, while epoch changes block newly enrolled devices from prior ciphertexts and revoked devices from future ciphertexts.Previously issued ciphertexts are not retroactively re-encrypted, unaffected devices need not be re-provisioned or have identity keys modified, and the update-cost measurement assumes the added device is already provisioned with its keys.Source: §4.3 · p. 13

4.4 Aggregate Encryption and Secure Bitstream Execution

  • AES-256-GCM protects each architecture-specific bitstream variant, while a separate session key binds the authenticated provider-device exchange to deployment metadata and the vendor aggregate ciphertext.At the FPGA, the session-binding tag is checked before key recovery, followed by identity-bound signature and AES-GCM tag verification before decryption and configuration.Source: §4.4 · pp. 14–15, Figure 4 · p. 14
  • SAEID performs one aggregate-encryption operation per participating vendor domain, enabling individual decryption by authorized devices while excluding devices outside the authorized subset.The aggregate ciphertext protects a group-valued deployment secret from which the symmetric bitstream key is derived.Source: §4.4 · pp. 13–15

4.5 Integrated Identity-Based Authentication and Bitstream Integrity

  • SAEID integrates certificate-free identity-based authentication of FPGA devices and registered IP providers with aggregate authorization as separate mechanisms.Vendor-scoped device and provider identities use distinct namespaces, avoiding a separate certificate-management infrastructure while preserving the separation between authentication and authorization.Source: §4.5 · pp. 16–17
  • Provider signatures bind each encrypted variant to its registered provider, intended FPGA, and release metadata, and deployment is accepted only after signature and AES-GCM integrity verification.The device verifies the signature and the AES-GCM authentication tag using the recovered AES key.Source: §4.5 · p. 18

5 Security Analysis

SAEID’s security analysis considers a cloud provider that may manipulate deployment messages and an adversary that may compromise some FPGA devices. It separates aggregate-encryption secrets from identity secrets and uses fresh deployment and session keys.

Threat model

  • The adversary may control the CSP, manipulate deployment messages, and compromise a subset of devices, exposing their locally stored decryption and identity keys.The stated threat model also includes attempts at key recovery, impersonation, bitstream substitution, cross-domain privilege escalation, and exploitation of membership changes; vendor and identity-authority secrets and uncompromised-device secrets remain outside its capabilities.Source: §5 · p. 18

Key separation

  • SAEID separates aggregate encryption, protected by vendor-specific secret γ_v, from device authentication and provider signatures, which use identity secret s_v.The AES-GCM key m is freshly generated per deployment, while the session key is derived from the authenticated device–provider exchange.Source: §5 · p. 18

Proof scope

  • Security proof sketches and the corresponding advantage bound are provided for the stated adversarial model.Source: §5 · p. 18

Appendix A.

The appendix analyzes confidentiality, dynamic membership, authentication, bitstream integrity, and isolation under stated cryptographic and freshness assumptions. It also specifies boundaries on what membership updates revoke and on the trusted state required for replay resistance.

AES-key confidentiality

  • Only devices satisfying the vendor-specific aggregate-decryption relation can recover the group deployment secret and derive the AES-256 key; unauthorized devices and collusions lacking that relation cannot recover it.The aggregate-encryption algebra is retained from AgEID, while SAEID changes device selection, vendor organization, authentication, and deployment authorization.Source: Appendix A · pp. 18–19

Dynamic membership

  • Membership changes update only the affected vendor component in O(1) aggregate-key time, providing forward and backward security for newly generated ciphertexts.The update bound excludes provisioning and installing long-term credentials; revocation does not erase plaintext keys or bitstreams already legitimately obtained, and provider-credential revocation is outside the model.Source: Appendix A · pp. 19–20

Authentication and replay resistance

  • Fresh nonces and timestamps, plus rejection of previously accepted freshness values, prevent reuse of recorded authentication transcripts under the stated identity-based Fiat–Shamir assumptions.The guarantee depends on trusted per-device freshness state being preserved across power cycles and reconfiguration; loss or rollback is outside the threat model.Source: Appendix A · p. 20

Bitstream integrity and device binding

  • An identity-bound provider signature and AES-GCM tag bind acceptance to the provider, encrypted payload, target device, and release metadata.Under signature-unforgeability and AES-GCM-authenticity assumptions, modified, substituted, forged, or incorrectly targeted bitstreams are rejected except with negligible probability.Source: Appendix A · p. 20

Multi-vendor and multi-provider isolation

  • Vendor-specific aggregate-encryption and identity domains prevent one vendor’s credential or authorization component from directly satisfying another vendor’s conditions.Compromise of one provider deployment alone does not provide the material needed to access another independent deployment, assuming vendor and provider credentials remain protected.Source: Appendix A · p. 20

Partially trusted CSP

  • The CSP relays deployment artifacts but does not receive the master, identity-authority, device-private, AES, or session keys.Under the stated cryptographic and freshness assumptions, it cannot recover the AES key or make a modified deployment artifact pass device-side checks except with negligible probability.Source: Appendix A · pp. 20–21

End-to-end security

  • End-to-end security relies on key separation, domain separation, cryptographic security, and freshness; a violation must correspond to failure of an underlying mechanism.The detailed game-based reductions and advantage bounds are provided in Appendix A.Source: Appendix A · p. 21

6 Scalability Analysis

SAEID separates deployment scaling across selected devices, vendor domains, providers, and target architectures. Its evaluation reports fixed-size per-vendor aggregate ciphertexts and scaling patterns that vary by deployment stage.

6.1 Complexity of Core Operations

  • Aggregate-authorization preparation requires O(|S_c,v|) operations, device addition and revocation require O(1) aggregate-key update work, and device recovery is O(1) when its authorization-dependent term is precomputed.Computing that term from the deployment set at runtime requires O(|S_c,v|) group additions.Source: §6.1 · p. 21
  • Aggregate-key extraction increases with authorized device-set size, online AES-key encryption remains approximately independent of that size, and membership-update costs remain approximately constant in evaluated configurations.Bitstream preparation depends on the number of distinct target architectures.Source: §6.1 · pp. 21–22, §6 · p. 21

6.2 Multi-Vendor and Multi-Provider Scaling

  • Cumulative aggregate AES-key encryption workload becomes O(PV) when every provider deploys across all V vendor domains; this is workload scaling, not concurrent wall-clock latency.The evaluation reports workload increasing approximately linearly with participating vendor domains while provider deployments maintain separate authorization state.Source: §6.2 · p. 22

6.3 Communication and Deployment Scaling

  • Aggregate ciphertexts remain fixed-size within each vendor domain regardless of selected-device count, while online AES-key encryption operations increase only when more vendor domains participate.Capability-aware clustering limits aggregate-authorization processing to selected devices.Source: §6.3 · p. 23

7 Experimental Evaluation

The evaluation examines SAEID’s aggregate-encryption scaling, deployment overheads, authorization metadata, and rejection of tested invalid cases. It also validates the software decryption path on a physical ZC702 and tests an ECC scalar-multiplication RTL component, noting limitations in the current hardware implementation.

7.1 Experimental Setup

  • All 23 functional checks passed, covering authorized and unauthorized decryption, membership behavior, authentication, and bitstream-integrity verification.The evaluation also ran the complete software deployment path on a physical ZC702 ARM Cortex-A9 platform.Source: §7.1 · p. 23

7.2 Cryptographic Performance and Scalability

  • For authorization sets of 10–10,000 devices, SAEID.Extract increased almost linearly, reaching 45.02 ms at 10,000; SAEID.Encrypt remained between 3.73 and 3.74 ms, approximately independent of authorized-device count within a vendor domain.Source: §7.2 · p. 24
  • 5.901 ms online SAEID.Decrypt time fell to 1.400 ms with precomputation for a 1000-device set, making online decryption approximately independent of set size.At |S_v| = 1000, SAEID.Extract required 4.477 ms and SAEID.Encrypt required 3.729 ms; with the authorization-dependent term precomputed, SAEID.Decrypt required 1.400 ms.Source: §7.2 · p. 24

7.3 Deployment, Security, Communication, and Storage Evaluation

  • 4.95–5.09 μs per device addition and 4.49–5.46 μs per revocation were measured, with update times approximately constant across evaluated deployment sizes.Updates modify only the affected vendor-specific aggregate-authorization component; unaffected devices need no credential regeneration, and existing ciphertexts are not re-encrypted solely because of an update.Source: §7.3 · p. 25
  • Authorization metadata grows with participating vendor domains and authenticated sessions but is independent of the devices represented in each vendor-specific aggregate ciphertext.Each FPGA device stores one individual decryption key and one identity-based private key, so device-resident cryptographic state is constant with deployment size; provisioning records scale with enrolled devices and provider credentials with registered provider–vendor domains.Source: §7.3 · p. 26
  • The measured IBA device response was 1.968 ms and provider-side verification 2.382 ms; negative tests of incorrect identities, modified proof components or challenges, replayed responses, and all seven bitstream-integrity cases were rejected.Source: §7.3 · p. 26

7.4 Embedded FPGA Evaluation and Resource Utilization

  • Authorized devices recovered the protected AES key, whereas unauthorized devices failed the recovery operation.The complete software path was cross-compiled for ARM and run on the physical Cortex-A9 processor.Source: §7.4 · p. 27
  • 191.126 ms was required for the complete SAEID software Decrypt() operation on the ZC702 Cortex-A9, including two bilinear pairings.The AgEID study’s 401 ms Cortex-A9 result is only a reference because build configurations differ; the current ARM build uses GMP without ARM assembly optimization.Source: §7.4 · p. 27
  • Eight 160-bit scalar-multiplication tests matched PBC bit-for-bit, and modular multiplication and inversion regression tests passed 10/10 cases.The RTL implements ECC arithmetic used in SAEID key generation and aggregate-key computation; arithmetic operations were verified against the PBC software implementation.Source: §7.4 · p. 27
  • The RTL uses a 512-bit modular-arithmetic datapath without DSP blocks, but implements only the ECC component, not a complete SAEID hardware accelerator.Reported power is a Vivado vectorless estimate; the bilinear pairing engine was not synthesized.Source: §7.4 · pp. 27–28
  • −38.046 ns of worst negative slack was measured against the 100-MHz constraint, associated with wide, unpipelined modular-arithmetic paths.The correctness-oriented design could gain timing improvements from further pipelining and architectural optimization, with resource impact depending on the architecture.Source: §7.4 · pp. 27–28
  • AgEID reports 2–17% LUT, 1–13% register, and 1–4% slice overhead with approximately 0.1–0.2 W power, but these figures are not directly comparable.The paper retains them only as references because AgEID’s architectural details and measurement conditions are insufficiently specified for direct resource comparison.Source: §7.4 · p. 28

8 Discussion

SAEID retains scalable aggregate authorization while extending it to heterogeneous multi-vendor deployment, with bounded authentication and bitstream-integrity overhead. The discussion also limits what the software and hardware evaluations establish.

8 Discussion

  • Aggregate-key preparation grows with authorized-set size, online AES-key encryption remains approximately independent of device count within a vendor domain, and workload grows with participating vendor domains.Dynamic membership updates remain effectively constant-cost.Source: §8 · p. 28
  • The complete authentication exchange requires approximately 4.35 ms, while identity-bound signature generation and verification require approximately 1.98 ms and 2.40 ms, respectively.Communication overhead scales separately with vendor domains, authenticated sessions, and target architecture.Source: §8 · p. 28
  • The embedded evaluation confirms that aggregate-encryption software executes on the ZC702 Cortex-A9, while RTL validates only the implemented ECC scalar-multiplication component, not a complete bilinear-pairing accelerator.The 10,000-device scalability result is a software evaluation with a large logical authorization set, not a physical deployment of 10,000 FPGAs.Source: §8 · p. 28
  • Direct quantitative comparison with prior FPGA-security implementations is limited by differences in cryptographic primitives, platforms, and measurement conditions.The AgEID Cortex-A9 result is retained only as a reference baseline.Source: §8 · p. 28
  • Continuous runtime integrity and hardware-rooted attestation are outside the scope of the present work.The discussion identifies these as remaining limitations.Source: §8 · p. 28

9 Conclusion

SAEID extends AgEID for secure FPGA bitstream deployment across heterogeneous multi-vendor environments. Its evaluation reports scaling behavior and validates software decryption on a ZC702 Cortex-A9 platform, while the hardware evaluation remains limited in scope.

9 Conclusion

  • SAEID extends aggregate authorization with capability-aware deployment, multiple IP providers, and dynamic device membership for heterogeneous multi-vendor FPGA clouds.Source: §9 · p. 28
  • The framework adds certificate-free identity-based device authentication and device-bound bitstream verification while retaining individual device recovery within each vendor domain.Source: §9 · p. 28
  • The software, embedded, and RTL experiments confirm expected scaling behavior, and the complete software decryption path was validated on a ZC702 Cortex-A9 platform.The RTL evaluation validates the ECC scalar-multiplication component; the hardware evaluation does not include a complete bilinear pairing engine.Source: §9 · p. 28
  • The current hardware evaluation covers ECC scalar multiplication only and does not include a complete bilinear pairing engine.Source: §9 · p. 28

A Correctness and Security Proof Sketches

The appendix provides correctness derivations and security proof sketches for SAEID. It inherits the aggregate-encryption construction from AgEID and derives the properties affected by SAEID’s multi-vendor extensions.

A Correctness and Security Proof Sketches

A.1 Correctness of Aggregate Decryption

The aggregate-decryption correctness sketch shows how an authorized device recovers the intended result. Its derivation cancels aggregate-authorization terms through bilinearity and a telescoping argument inherited from AgEID.

A.1 Correctness of Aggregate Decryption

  • The correctness statement applies to every device in the authorized set associated with its vendor.Source: §A.1 · p. 30
  • For an authorized device, aggregate-authorization terms cancel through bilinearity and the telescoping argument used in AgEID’s construction.The remaining pairing factor cancels in the derivation.Source: §A.1 · p. 30

A.2 Deployment-Secret Confidentiality

The security analysis establishes confidentiality of deployment secrets and protections across authentication, sessions, bitstreams, dynamic membership, and independent domains, and composes the underlying mechanisms’ security under stated assumptions. It also identifies trusted freshness-state persistence as necessary for replay resistance, limits membership guarantees to corresponding ciphertext epochs, and states that the CSP need not be trusted.

A.2 Deployment-Secret Confidentiality

  • Under the BDHE assumption, an adversary lacking target-deployment authorization cannot distinguish the protected group-valued secret m_G from a random element of G_T except with negligible probability.Only an entity that recovers authorized m_G can derive the AES-256 deployment key; protected variants are confidential under AES-256-GCM assuming unique IVs for encryptions under the same key.Source: §A.2 · p. 31

A.3 Authentication Soundness and Replay Resistance

  • Except with negligible probability, a party without the target device’s identity private key cannot prove a fresh authentication challenge, and a prior transcript cannot be replayed in a fresh session.Replay resistance assumes freshness state for N and τ remains in trusted persistent storage across power cycles and FPGA reconfiguration; loss or rollback is outside the guarantee.Source: §A.3 · p. 32

A.4 Authenticated Session Binding

  • Without the authenticated session key, an adversary can produce a valid tag for a modified, redirected, or cross-session aggregate ciphertext only with negligible probability.The result assumes security of H3 and the underlying MAC.Source: §A.4 · p. 32

A.5 Bitstream Integrity and Device Binding

  • Assuming provider-proof unforgeability and AES-GCM authenticity, an adversary cannot modify, substitute, or redirect a protected bitstream to another target device and have it accepted except with negligible probability.The provider identity, intended device, encrypted payload, and release metadata must pass identity-bound verification and authenticated-encryption checks before decryption and FPGA configuration.Source: §A.5 · pp. 33–34

A.6 Dynamic-Membership Security

  • Under the aggregate-encryption security assumption, revoked devices cannot decrypt ciphertexts generated after revocation, and newly enrolled devices cannot decrypt ciphertexts generated before enrollment, except with negligible probability.These guarantees apply to the corresponding membership epochs and do not revoke plaintext, secrets, or bitstreams an authorized device obtained before revocation.Source: §A.6 · p. 34

A.7 Multi-Vendor, Multi-Provider, and CSP Isolation

  • Under SAEID’s key-separation model, compromising one vendor or provider domain does not directly enable decryption or forgery in another, while a CSP-only adversary cannot recover protected AES keys, forge authenticated sessions, or cause modified bitstreams to be accepted except with negligible probability.The CSP adversary observes ciphertexts, deployment metadata, and protocol messages but lacks vendor master secrets, identity-authority secrets, and device private keys.Source: §A.7 · p. 34

A.8 Composition of Security Properties

  • The composition of SAEID’s security properties relies on distinct cryptographic mechanisms and assumptions, including aggregate encryption protecting deployment AES key m under vendor-specific secret γ_v.The supplied passage begins a composition summary but provides no further mechanism or assumption details in this part.Source: §A.8 · p. 35
  • Under the stated security assumptions, an end-to-end violation requires failure of an underlying mechanism, so overall failure probability is bounded by the mechanisms’ individual failure probabilities.The assumptions include key separation, freshness, aggregate encryption, identity proof, MAC, and AES-GCM security.Source: §A.8 · p. 35
  • The composition does not require a trusted CSP, which lacks the vendor master secrets, identity private keys, provider credentials, session keys, and deployment AES key.Source: §A.8 · p. 35
  • The appendix’s security arguments cover AES-key confidentiality, device authentication and replay resistance, session binding, bitstream integrity and device binding, dynamic-membership security, and multi-vendor, multi-provider deployment.Source: §A.8 · p. 35

A.9 Summary of Security Guarantees

Loading 2610.11873v1…