Loading
Loading
GFAE makes location, hardware, and time part of the key derivation condition. The result is not just access denial. It is inability to re-derive the same decryption context outside authorised constraints.
Design Principle
The GFAE architecture combines a post-quantum shared secret with physical signal-quality context, hardware attestation, and time-window constraints into a single HKDF-based key derivation pipeline. Each factor is an entropy input. All factors must be concurrently valid. The output key material is bounded to the authorised condition set, it cannot be reproduced outside it.
Each stage is a mandatory gate. Failure at any point prevents key material from being produced.
Derivation gate sequence
Gate 1/4
Physical Location Context
The active GNSS constellation set contributes evaluated physical signal context, not a browser location assertion.
Hardware Attestation
The enrolled TPM 2.0 device provides a hardware-rooted prerequisite for working key material.
Time-Window Constraint
The configured access epoch must be valid at derivation time, restricting replay outside the approved window.
Entropy Fusion and Key Derivation
Accepted inputs and the post-quantum secret flow through HKDF-SHA-512 to create AES-256-GCM key material.
Entropy fusion engine
Illustrative view
Illustrative pipeline. Exact derivation internals, entropy thresholds, and test vectors are NDA-only.
GFAE evaluates physical signal-quality context from GNSS receivers, not OS-reported coordinates, browser geolocation APIs, or IP-based location lookups. The distinction is architectural: reported coordinates are trivially spoofable at the software layer; signal-quality context requires physical presence near transmitting satellites.
A multi-constellation GNSS approach is used for higher reliability across different operational environments. Geofencing supports both polygon-based and radius-based boundary definition, enabling precise or approximate geographic constraint depending on deployment requirements.
Authorisation signal context
GPS | Active
Global Positioning System
United States
GAL | Active
Galileo
European Union
GLO | Active
Global Navigation Satellite System (GLONASS)
Russian Federation
Navigation with Indian Constellation (NavIC): Receiver-dependent support; availability depends on hardware configuration.
Known Limitations
Indoor environments, urban canyons, and signal obstruction reduce GNSS signal quality and reliability. Deployments in such environments require supplementary positioning input or alternative validation approaches.
Only hardware devices pre-enrolled in the GFAE system can contribute to key derivation. TPM 2.0 provides a hardware-rooted trust anchor: attestation keys are bound to the physical chip and cannot be exported or replicated in software.
Software credential stores, including private keys stored on disk, in environment variables, or in software keystores, can be cloned and transferred. Hardware attestation raises the bar by requiring the physical device to be present. The enrolled device becomes a necessary prerequisite for key derivation, not just authentication.
Trust Anchor
TPM 2.0. Hardware-rooted attestation. Platform attestation is part of the trust evaluation, not just device identity.
Enrolment
Devices must be explicitly enrolled before they can participate in key derivation. Ad-hoc device use is not possible without prior registration.
Residual Risk
Physical extraction of the enrolled hardware by a sophisticated adversary, compromising the TPM directly, remains a residual risk. Physical security of enrolled hardware is a required operational control.
Authorised access windows are configured per deployment. Key re-derivation is cryptographically impossible outside the configured window. This is not a session timeout or a policy check, it is a hard constraint on the entropy inputs to key derivation.
Time-window enforcement provides replay resistance at the key derivation level. Captured key material or intercepted session context cannot be replayed into a new derivation attempt outside the valid window. Expiring cryptographic context is a design property, not a policy overlay.
Enforcement Type
Cryptographic, time-window epoch is an input to HKDF derivation. Not a session policy or API check.
Configuration
Windows are configured per deployment. Shift patterns, maintenance windows, and operational schedules can be encoded directly into access constraints.
Replay Resistance
Captured derivation inputs from a valid window cannot be replayed in a later epoch to reproduce the key.
GFAE uses ML-KEM-1024, the NIST FIPS 203 final standard for post-quantum key encapsulation. This addresses the harvest-now, decrypt-later threat: data encrypted today remains protected against future quantum-capable adversaries attempting to decrypt previously collected ciphertext.
The post-quantum shared secret is one entropy input to the HKDF derivation pipeline, combined with the physical and temporal factors. GFAE can operate alongside classical infrastructure while preparing for the quantum transition.
Standard
ML-KEM-1024, NIST FIPS 203 final standard. Addresses Harvest-Now, Decrypt-Later for GFAE-protected data.
Honest Language
“Post-quantum resistant”, not “quantum-proof”. Resistance is relative to known algorithmic attacks against the current standard. Future cryptanalysis may affect any standard.
Coexistence
Designed to work with classical infrastructure. Migration agility is a design intent, not a current certified capability.
A brief availability interruption is an acceptable cost for regulated deployments. An insecure fallback, where an alternative code path produces key material under degraded conditions, is not. GFAE is designed so that missing, invalid, or unverifiable inputs produce no output.
Missing or invalid location context
Key not derivable. Access denied.
Hardware attestation fails or device is unregistered
Key not derivable. Access denied.
Request falls outside configured time window
Key not derivable. Access denied.
Any factor input is absent, degraded, or unverifiable
System fails closed. No insecure fallback.
High-Assurance Mode
High-assurance mode requires a physical TPM 2.0 device and validated GNSS signal context. Software-only deployments provide a reduced assurance level and are intended for evaluation and integration development only, not regulated production deployment.
Responsible disclosure of limitations is part of the GFAE evaluation posture. Security evaluators should understand the boundaries of the current technology before assessing fit for purpose.
GNSS Indoor Limitations
GNSS signals are attenuated or blocked indoors and in dense urban environments. GFAE cannot rely solely on GNSS-based geofencing in environments where satellite signals are unreliable. Deployments in such environments require supplementary positioning mechanisms or alternative validation approaches.
Hardware Dependency
High-assurance mode requires a physical TPM 2.0 device or equivalent hardware security module. Software-only deployments provide a reduced assurance level. Proper physical security controls for the enrolled device are required.
Operational Complexity
Deploying GFAE correctly requires careful geofence definition, hardware enrolment, key management procedures, time synchronisation, and operational resilience planning. GFAE does not remove the need for operational security procedures.
External Validation Status
GFAE is patent pending and represents independent research. External independent security validation, certification, and formal penetration testing are part of the roadmap and have not yet been completed. GFAE should be treated as a promising early-stage technology, not a certified product.
Not a Replacement for IAM or Legal Compliance
GFAE addresses a specific layer of cryptographic access control. It does not replace identity and access management, network security, monitoring, incident response, or legal and regulatory compliance processes.
Emergency Access
In safety-critical deployments such as healthcare, emergency break-glass procedures require explicit policy design. GFAE's fail-closed design must be carefully considered against operational availability requirements.
Public Disclosure
Safe to share without restriction:
NDA-Only
Available only under executed NDA:
Technical briefings under NDA are available for qualified defence innovation reviewers, CISOs, and verified institutional evaluators. Briefings cover exact derivation details, entropy architecture, and implementation evidence. Contact to initiate the NDA process.
The illustrative demo shows concept-level pipeline simulation. The full technical briefing, under NDA, covers exact derivation internals, implementation evidence, and fit-for-purpose assessment for your deployment context.
NDA process initiated on request. No commercial obligation. Suitable for defence, healthcare, and critical infrastructure evaluators.