Loading...
xail Patent Portfolio / Application 3
Sign out ← Back
PATENT PORTFOLIO · APPLICATION 3

Threshold Cryptographic Authentication via Push-Delivered Session-Bound Digital Signatures with Distributed Signing Key Custody

Push-based authentication eliminating shared secrets, preventing push bombing, and providing non-repudiable authorization through Ed25519 session-bound signatures and threshold key distribution.

20 Claims Filed 11 Independent 9 Dependent 32 Method 6 System
20
claims filed
11
independent
9
dependent
16
figures
Ed25519
signature scheme
0
shared secrets
Filing Strategy: Claims are organized into filing groups. Group A (20 claims) files now. Group B (18 claims) is reserved for a continuation application using the same specification. All claims are supported by the current specification.
GROUP A · FILING NOW
20 claims · 11 independent · 9 dependent
Claim 1 · Method

Push-Based Session-Bound Authentication

Generate random session ID, deliver challenge via push gateway to user device with session ID + relying party DID + timestamp. User computes Ed25519 signature over session ID + relying party DID + user DID + timestamp. Fraudulent relying party structurally cannot obtain valid approval.

CLAIM 1 Method Push-based session-bound authentication with Ed25519 signatures Session ID + relying party DID + timestamp binding eliminates phishing structurally USE CASE: A bank sends a push notification asking "Approve login?" — the user taps approve, their phone signs the exact session ID. A phishing site can't reuse this signature. C2 Out-of-band delivery, transport independence C4 Zero server-side secret — only public keys stored C5 Split-channel challenge with auth.challenge scope C13 Dual binding: session ID + relying party DID
Claim 3 · Method

Push Bombing Resistance

Each challenge has unique session ID + relying party DID + timestamp. Approval signature bound to specific session ID. Push flooding eliminated — each approval mathematically non-transferable.

CLAIM 3 Method Standalone Push bombing resistance via session-bound non-transferable signatures Each approval is mathematically bound to a specific session — flooding produces no value USE CASE: An attacker sends 100 fake push notifications. Accidental approval only works for the attacker's fake session, not the real bank's session. Zero damage.
Claim 6 · Method

Threshold Multi-Device Authentication

Register n devices (n>=2), each with distinct Ed25519 keypair + DID. Deliver challenge to all n. Grant auth when k distinct devices return valid signatures. Fault tolerance + compromise resistance.

CLAIM 6 Method Threshold multi-device authentication with k-of-n Ed25519 signatures Fault tolerance (n-k offline) + compromise resistance (fewer than k = zero auth) USE CASE: A CEO has Xlock on phone, tablet, and laptop. Even if the phone is stolen, the attacker can't authenticate — they need 2 of 3 devices. C7 Threshold key splitting alternative — single signature output from distributed key shares C8 Progressive security enrollment with visual tier indicators (add devices to increase threshold)
Claim 10 · System

Cross-Provider M2M Authentication System

n nodes across at least 2 independent cloud providers, each storing one share. Threshold signing requires k nodes. Compromise of all infrastructure from any single provider = insufficient.

CLAIM 10 System Standalone Cross-provider M2M authentication with multi-cloud share distribution Compromise of all infrastructure from any single cloud provider = insufficient for signing USE CASE: A medical records system distributes signing key shares across AWS, Azure, and GCP. A complete AWS breach reveals nothing — need shares from at least 2 providers.
Claim 23 · System

Zero Server-Side Secret Authentication System

Trust registry stores only public keys + DIDs. No shared secrets, TOTP secrets, or symmetric keys. Challenge generator produces 128+ bit random session IDs. Complete credential store breach = only public keys revealed.

CLAIM 23 System Standalone Zero server-side secret authentication — only public keys stored Complete credential store breach reveals only public keys — no re-enrollment needed USE CASE: A company's auth server is hacked. With traditional MFA, every employee must re-enroll. With Xlock, the breach reveals only public keys — useless to attackers.
Claim 24 · Method

Relay Transparency — E2E Encrypted Gateway

Challenge encrypted with AES-256-GCM, signed with relying party's Ed25519. Gateway relays without ability to decrypt or forge. User decrypts, signs response. Relying party verifies independently of gateway.

CLAIM 24 Method Relay transparency — E2E encrypted challenge delivery via gateway Gateway cannot decrypt or forge — relying party verifies independently of relay USE CASE: A password manager uses Xlock for vault access. The push relay (even if compromised) can't read what's being approved or forge a fake approval — it's E2E. C34 Recipient-specific encryption via Ed25519-to-X25519 birational mapping — only the intended device can decrypt the challenge
Claim 25 · Method

Asymmetric Registration — xlock:// URI

Registration code contains relying party DID + gateway URL + optional callback. No shared secret at any point. User scans QR, registers RP in local trust store, sends public key to RP.

CLAIM 25 Method Asymmetric registration via xlock:// URI — zero shared secrets QR code scan creates no shared secret — only user's public key is stored at RP USE CASE: A user scans a QR code at their bank's website. Unlike TOTP setup (shared secret), xlock:// registration creates zero shared secrets — only the public key is stored. C35 Dual-mode migration period — TOTP + push-based coexistence for gradual enterprise rollout without service disruption
Claim 26 · Method

Multi-Party Transaction Approval

Transaction requires K-of-N approvers. Challenge sent to all N via push. Each approver signs with their Ed25519 key. Execute only upon K valid signatures from K distinct DIDs.

CLAIM 26 Method Standalone Multi-party K-of-N transaction approval with push-delivered challenges Each approver signs independently — no single member can authorize alone USE CASE: A $10M wire transfer requires 3 of 5 board members to approve via push notification. Each signs independently — no single member can authorize it alone.
Claim 27 · Method

Three-Layer Anti-Push-Bombing Defense

Layer 1: rate limit (max pending challenges per recipient per window). Layer 2: challenge-bound Ed25519 signature (non-replayable). Layer 3: E2E encrypted context display. Three layers operate independently.

CLAIM 27 Method Standalone Three-layer anti-push-bombing: rate limit + signature binding + E2E context Three independent defense layers — each eliminates a different attack vector USE CASE: An attacker push-bombs a CEO. Layer 1 blocks after 3/min. Layer 2 ensures accidental approval = one session only. Layer 3 shows the request came from unknown IP.
Claim 28 · Method

Scope-Gated Authorization via Trust Registry

Third-party apps register challenge scope in trust registry. Gateway verifies requesting app's DID has valid scope before delivering. Users implicitly authorized to respond to challenges directed to their DID.

CLAIM 28 Method Standalone Scope-gated authorization — trust registry validates challenge scope Gateway rejects challenges from apps without valid registered scope USE CASE: A rogue app tries to send Xlock challenges to random users. The gateway rejects them — the app never registered an 'auth.challenge' scope in the trust registry.
Claim 33 · System

Comprehensive Push-Based Authentication System

Client device + gateway relay + trust registry + rate limiter + asymmetric registration + challenge lifecycle manager. Eliminates shared secrets, prevents push bombing, provides non-repudiable authorization.

CLAIM 33 System Comprehensive Xlock system: registration + gateway + trust + rate limiting Full authentication stack eliminating shared secrets with non-repudiable authorization USE CASE: A government agency deploys the complete Xlock stack: asymmetric registration, relay transparency, rate limiting, and threshold gating for classified operations. C37 Challenge history store — encrypted, local-only database for audit and forensic review of all authentication events
GROUP B · CONTINUATION 1
18 claims · 7 independent · 11 dependent
Claim 9 · Method CONTINUATION 1

Threshold M2M Authentication

Distribute agent's signing key across n nodes via threshold IDA. Signing ceremony reconstructs key transiently from k shares, signs, discards. Key never exists complete except during signing.

CLAIM 9 Method Threshold M2M authentication with transient key reconstruction Signing key split across n nodes — reconstructed only during signing, then discarded USE CASE: A Kubernetes cluster's API signing key is split across 3 nodes in different AZs. Even if us-east-1 goes down, the other 2 nodes can still sign. C11 Cross-organizational bilateral consent (HIPAA, attorney- client, SEC) C12 Cryptographic compliance audit trail via DID document C22 Threshold signature protocol (no key reconstruction variant)
Claim 14 · Method CONTINUATION 1

Structural Prompt Injection Defense

Split instruction payload into n shares via GF(2) IDA. Transmit to n independent endpoints. Recipient validates timestamp + nonce + signature + scope per share. Reconstruct from k verified shares. Attacker controlling <k endpoints = cannot inject.

CLAIM 14 Method Structural prompt injection defense via threshold instruction splitting Defense independent of content filtering — controlling <k endpoints = only random noise USE CASE: An AI agent receives instructions split across 3 cloud providers. A prompt injection attack on one endpoint gives the attacker random noise — can't influence the instruction. C15 Configurable threshold k per agent (k>=3) C16 Reconstruction failure as injection detection signal C18 Source-agnostic: human, AI, orch- estration, tool C20 Heterogeneous endpoints: HTTP + email + MQ C21 Forensic record on reconstruction failure
Claim 17 · Method CONTINUATION 1

Three-Layer Instruction Integrity Verification

Three layers: (1) per-share HMAC verification, (2) threshold reconstruction, (3) digital signature over reconstructed payload. Compliance record without content.

CLAIM 17 Method Three-layer instruction integrity: HMAC + reconstruction + Ed25519 Compliance record (sender, recipient, share count, channels, timestamp) without content USE CASE: A financial trading bot receives "sell 10,000 shares" — each of the 3 layers independently confirms the instruction is genuine. HMAC, reconstruction, Ed25519 signature. C19 Compliance record with pre-decryption hash — proves instruction integrity without revealing content
Claim 29 · Method CONTINUATION 1

Gateway-Relayed Authorization of Threshold Operations

Threshold operations (split, reconstruct, transfer) require push-authenticated human approval. Ed25519-signed approval covers operation ID + type + timestamp. Non-repudiable audit record.

Divided Infringement Note

All steps — generating the challenge, delivering via push gateway, verifying the Ed25519 signature, and gating the threshold operation — are performed by or attributable to a single platform operator. No third-party action is required to practice this claim.

CLAIM 29 Method Gateway-relayed authorization of threshold secret-sharing operations Push-authenticated Ed25519 approval with non-repudiable audit record USE CASE: Before a backup service splits a user's seed phrase into threshold shares, the user must approve via push notification. The Ed25519 signature proves consent. C36 Both split and reconstruct operations require separate push-based authorization — prevents unauthorized reconstruction of threshold data
Claim 30 · System CONTINUATION 1

Unified ACI Authorization Layer

Push auth module + plurality of ACIs (message splitting, file vault, key ceremony, code deployment, cross-border transfer) + authorization gate requiring Ed25519-signed approval. Single DID identity across all ACIs.

CLAIM 30 System Unified ACI authorization layer — one DID across all platform services Single Ed25519-signed push approval authorizes operations across all ACIs USE CASE: A developer uses one Xlock identity to authorize code deployment (Xboot), sign messages (Xlink), and back up files (VaultDrop) — same DID, same push approval. C38 Specific ACI types: message splitting + file vault — push gate required before any threshold cryptographic operation
Claim 31 · Method CONTINUATION 1

Non-Repudiable Chain of Custody

Each custody operation on threshold-shared data requires push-authenticated Ed25519 signature. Chain of custody links: authorizer DID + operation + data ID + timestamp + signature. Cryptographically verifiable, non-forgeable.

CLAIM 31 Method Standalone Non-repudiable chain of custody via push-authenticated Ed25519 signatures Every custody operation cryptographically signed — verifiable, non-forgeable chain USE CASE: Evidence in a legal case is threshold-shared. Every access or transfer requires push-approval. The chain of custody is cryptographic proof — admissible in court.
Claim 32 · Method CONTINUATION 1

Cross-Border Transfer with Compliance Proof

Detect jurisdictional boundary crossing. Push challenge with compliance metadata (source/destination jurisdiction, regulation, classification). Execute only after Ed25519-signed approval. Compliance proof = signed approval + metadata.

CLAIM 32 Method Standalone Cross-border transfer with cryptographic compliance proof Ed25519-signed approval + compliance metadata = verifiable informed consent USE CASE: A European company transfers patient data to a US partner. The compliance officer must push-approve with full GDPR context — the signature proves informed consent.