Security Model

A comprehensive overview of GhostPay Mesh’s security architecture, cryptographic foundations, and privacy guarantees.

1. Threat Model

GhostPay Mesh is designed to operate securely in adversarial environments where devices may be compromised, communication channels may be monitored, and parties may be malicious. The security model addresses the following threat categories:

🔒 Double Spending

An attacker attempts to redeem the same PLC multiple times, either through chain forking or parallel settlement requests.

🔒 Replay Attacks

An attacker captures a valid transfer and re-broadcasts it to steal funds or confuse the transaction history.

🔒 Man-in-the-Middle

An attacker intercepts BLE/NFC communication between devices during an offline transfer to modify or steal PLC data.

🔒 Key Extraction

An attacker with physical access to a device attempts to extract the private key from secure storage.

🔒 Forgery

An attacker attempts to create counterfeit PLCs or forge transfer signatures without possessing the correct private key.

🔒 Timing Attacks

An attacker manipulates device clocks to extend expired PLCs or bypass time-based security constraints.

Trust Assumptions

The device’s secure enclave (TEE/Secure Element) is trusted for key storage and signing operations.
The Ed25519 signature scheme is computationally infeasible to forge.
SHA-256 is collision-resistant for the purposes of commitment hashing.
The settlement backend is honest-but-curious: it will follow the protocol but may attempt to learn information.

2. Cryptographic Primitives

GhostPay Mesh uses a carefully selected set of modern, well-audited cryptographic primitives. No custom or novel cryptography is employed.

Primitive	Algorithm	Purpose	Security Level
Digital Signatures	`Ed25519`	PLC signing, transfer authorization, identity verification	~128-bit
Symmetric Encryption	`XChaCha20-Poly1305`	Encrypting PLC payloads during BLE/NFC transport	256-bit
Hashing	`SHA-256`	Commitment hashes, transfer chain integrity	128-bit collision
Key Derivation	`Argon2id`	Deriving encryption keys from user PINs for local key protection	Memory-hard
Random Generation	`CSPRNG`	Nonces, UUIDs, key generation	OS-level entropy

Why Ed25519?

Ed25519 was chosen for digital signatures for several reasons critical to the offline-first use case:

Small signatures (64 bytes) — essential for QR code transport where payload size is limited to ~3KB.
Small keys (32 bytes public key) — reduces PLC payload size for BLE transfers.
Fast verification — critical for validating transfer chains on resource-constrained mobile devices.
Deterministic — no dependency on a random number generator during signing, eliminating a class of implementation vulnerabilities.
Widely audited — used in TLS 1.3, SSH, Signal Protocol, and Solana.

Why XChaCha20-Poly1305?

XChaCha20-Poly1305 provides authenticated encryption for PLC payloads during transport:

24-byte nonce — virtually eliminates nonce collision risk, critical when nonces are generated independently on offline devices.
Software-friendly — does not require AES hardware acceleration, ensuring consistent performance across all Android/iOS devices.
AEAD — authenticated encryption with associated data prevents both tampering and information leakage.

3. Device-Bound Keys

Every GhostPay Mesh device generates a unique Ed25519 keypair during initial setup. This keypair is the device’s identity and is never transmitted, exported, or backed up.

Key Generation

Key Generation Flow

// 1. Generate 32 bytes of entropy from OS CSPRNG

seed = CSPRNG(32)

// 2. Derive Ed25519 keypair

(private_key, public_key) = Ed25519.generate(seed)

// 3. User sets a 6-digit PIN

pin_hash = Argon2id(pin, salt, t=3, m=65536, p=4)

// 4. Encrypt private key with PIN-derived key

encrypted_key = XChaCha20Poly1305.encrypt(

  key: pin_hash,

  nonce: CSPRNG(24),

  plaintext: private_key

)

// 5. Store encrypted_key in device Secure Enclave / Keystore

SecureStorage.store("ghostpay_key", encrypted_key)

Key Storage

iOS: Keys stored in the Secure Enclave via SecKeyCreateRandomKey with kSecAttrTokenIDSecureEnclave.
Android: Keys stored in the Android Keystore with setIsStrongBoxBacked(true) where available, falling back to TEE-backed storage.
Private keys are never exported from the device’s secure hardware.
All signing operations happen within the secure enclave — the raw private key never enters application memory.

Key Loss: If a device is lost or destroyed, the associated keys are irrecoverable. Any PLCs issued by or held by that device must be settled through the dispute resolution process. This is by design — key recovery mechanisms would introduce an attack vector.

4. Transfer Security

Offline PLC transfers are protected by a multi-layer security architecture that ensures integrity, authenticity, and confidentiality during transmission.

Transport Encryption

All PLC data transmitted via BLE or NFC is encrypted using XChaCha20-Poly1305 with an ephemeral shared key established through X25519 Diffie-Hellman key exchange.

Ephemeral Key Exchange

// Sender and Receiver perform X25519 ECDH

sender_ephemeral = X25519.generate()

receiver_ephemeral = X25519.generate()

shared_secret = X25519.exchange(

  sender_ephemeral.private,

  receiver_ephemeral.public

)

// Derive transport key via HKDF

transport_key = HKDF-SHA256(

  ikm: shared_secret,

  salt: "ghostpay-transfer-v2",

  info: sender_pubkey || receiver_pubkey,

  len: 32

)

Signature Chain Verification

Each transfer in the chain is cryptographically linked to the previous transfer, creating an auditable, tamper-proof history:

The sender creates a transfer record containing: to_pubkey, timestamp, nonce, and previous_hash.
The sender signs this record with their private key.
The receiver verifies the signature using the sender’s public key.
The receiver verifies previous_hash matches the hash of the last entry in transfer_chain.
If verification passes, the new transfer record is appended to the chain.

5. Anti-Fraud

While the protocol provides strong cryptographic guarantees, the settlement layer adds behavioral analysis and heuristic checks to detect fraud patterns that cryptography alone cannot prevent.

Backend Monitoring

Anomaly Detection: Machine learning models analyze settlement patterns to detect unusual activity (e.g., a device suddenly settling many high-value PLCs).
Graph Analysis: Transfer chain graphs are analyzed to detect circular transfers (potential money laundering) or suspicious mesh topologies.
Reputation Scoring: Devices accumulate a reputation score based on settlement history. New or low-reputation devices face stricter limits.

Velocity Checks

Check	Limit	Window
Max PLC value	R$ 1,000.00	Per PLC
Max daily issuance	R$ 5,000.00	24 hours
Max daily settlements	R$ 10,000.00	24 hours
Max transfer hops	10	Per PLC
Max concurrent PLCs	50	Per device

Amount Limits

PLC amounts are bounded to reduce systemic risk. Limits are tiered based on device reputation:

Tier 1 (New device): Max R$ 200 per PLC, R$ 500/day
Tier 2 (Established): Max R$ 500 per PLC, R$ 2,000/day
Tier 3 (Trusted): Max R$ 1,000 per PLC, R$ 5,000/day

6. Privacy by Design

GhostPay Mesh is architected with privacy as a foundational principle, not an afterthought. The protocol minimizes data collection to the absolute minimum required for operation.

Zero Personal Data

No names, emails, or phone numbers are collected or stored by the protocol.
No KYC required for PLC creation, transfer, or settlement below regulatory thresholds.
Device identity is based solely on public keys — which are pseudonymous and unlinkable without additional information.
No IP logging during settlement. TLS connections are anonymized through a mix network.

Data Minimization

The settlement backend stores only the minimum data required to prevent double-spending:

PLC ID and commitment hash (for deduplication)
Settlement timestamp and rail used
Settlement transaction ID (for dispute resolution)

The backend does not store:

Full PLC payloads (only hashes)
Transfer chain details (only the final settlement proof)
Device metadata, location, or behavioral data

Right to Erasure: Since the backend stores only cryptographic hashes and transaction IDs, there is no personal data to erase. The protocol is GDPR-compatible by architecture.

7. Compliance

GhostPay Mesh is designed to be compatible with existing financial regulations while preserving privacy and decentralization.

BACEN Compatibility

The protocol is compatible with the Brazilian Central Bank (BACEN) regulatory framework:

Pix Integration: Settlement via Pix follows all BACEN instant payment standards including the DICT (Directory of Transaction Identifiers).
SPB Compliance: Settlement transactions are processed through BACEN’s Brazilian Payment System (SPB).
Reporting: Aggregate settlement data (non-PII) is reportable to BACEN under existing electronic payment regulations.

AML Integration

Anti-Money Laundering (AML) measures are integrated at the settlement layer:

Transaction Monitoring: All settlements above R$ 2,000 trigger enhanced monitoring.
Suspicious Activity Reports (SARs): The system automatically generates SARs for pattern-based anomalies.
Chain Analysis: Transfer chain depth and topology are analyzed for structuring attempts.
Regulatory Thresholds: PLCs above R$ 5,000 require additional verification at settlement time.

Regulatory Approach

GhostPay Mesh follows a “compliance at the edges” approach: the core protocol remains privacy-preserving and decentralized, while settlement providers (the “edges” where value enters and exits the system) implement regulatory requirements. This allows the protocol to adapt to different jurisdictions without modifying the core PLC specification.