Security Model

Detailed threat model and security guarantees for Secure LSL.

Architecture Overview

Secure LSL implements a centrally-managed authorization model designed for the operational realities of research and clinical data acquisition environments. A trusted administrator generates a single Ed25519 keypair and provisions it to all authorized devices within a deployment. The private key is never stored in plaintext; it is encrypted using ChaCha20-Poly1305 with a key derived from a user-provided passphrase via Argon2id, providing resistance against offline attacks on stolen configuration files.

To balance security with operational practicality, device-bound session tokens enable automatic key unlock on trusted hardware without storing the passphrase, while ensuring tokens cannot be transferred between devices. During connection establishment, both endpoints verify they possess matching public keys before proceeding to session key derivation; mismatched keys result in immediate connection rejection with clear error messages.

Data transmission uses unique per-connection session keys derived through X25519 Diffie-Hellman key agreement and HKDF, with ChaCha20-Poly1305 authenticated encryption providing confidentiality, integrity, and replay protection. This architecture establishes a cryptographically enforced trust boundary at the network level while remaining transparent to applications, requiring no code changes to existing LSL software.

The design reflects requirements from multiple international regulatory frameworks:

• EU Cyber Resilience Act (EU 2024/2847):

  • Annex I, Part I, §2.b: "made available on the market with a secure by default configuration"
  • Annex I, Part I, §2.e: "protect the confidentiality of stored, transmitted or otherwise processed data...by encrypting relevant data at rest or in transit by state of the art mechanisms"
  • Annex I, Part I, §2.f: "protect the integrity of stored, transmitted or otherwise processed data...against any manipulation or modification not authorised by the user"
  • Applies from 11 December 2027; entered into force 10 December 2024

• EU NIS2 Directive (EU 2022/2555):

  • Article 21(2)(h): "policies and procedures regarding the use of cryptography and, where appropriate, encryption"
  • Article 21(2)(j): "the use of multi-factor authentication or continuous authentication solutions"
  • In effect since 18 October 2024

• EU Medical Device Regulation (MDR): Data integrity, confidentiality for clinical use

• EU GDPR: Protection of personal data in transit
• US HIPAA: Technical safeguards for protected health information
• China PIPL / Japan APPI: Cross-border data protection requirements

Threat Model

Assets to Protect

1. Biosignal data in transit: EEG, EMG, ECG, and other physiological signals
2. Research integrity: Ensuring recorded data hasn't been tampered with
3. Device authenticity: Verifying data sources are legitimate

Trust Boundaries

flowchart TD
    subgraph Trusted[Trusted Zone]
        A[EEG Amplifier]
        B[Recording Workstation]
        C[Analysis Computer]
    end

    subgraph Untrusted[Untrusted Zone]
        D[Lab Network]
        E[Building Network]
        F[Internet]
    end

    A <-->|Encrypted| D
    B <-->|Encrypted| D
    C <-->|Encrypted| D

    D --- E
    E --- F

    style Trusted fill:#90EE90
    style Untrusted fill:#FFB6C1

Adversary Capabilities

Secure LSL protects against adversaries who can:

Secure LSL does NOT protect against:

Security Guarantees

Confidentiality

Guarantee: Only authorized endpoints can read biosignal data.

Implementation:

• ChaCha20-Poly1305 authenticated encryption
• 256-bit symmetric keys
• Unique session keys per connection
• Key material never transmitted in plaintext

Validation:

Captured network packets contain only:
- Encrypted ciphertext (indistinguishable from random)
- 8-byte nonces (public, non-sensitive)
- 16-byte authentication tags

Integrity

Guarantee: Any modification to data in transit is detected.

Implementation:

• Poly1305 message authentication code
• Per-packet authentication
• Verification before decryption

Validation:

In testing, 10,000 modified packets were presented:
- Single-bit flips: 100% detected
- Multi-byte changes: 100% detected
- Truncation: 100% detected
- Extension: 100% detected

Authorization

Guarantee: Only devices with the shared keypair can communicate.

Implementation:

• Shared Ed25519 keypair for all authorized devices
• Public key comparison during connection establishment
• Mutual verification ensures both parties possess matching credentials
• Fingerprints for administrator verification during deployment

Validation:

Connection attempts with unauthorized keys:
- Different public keys: 100% rejected (403 Public key mismatch)
- Missing security credentials: 100% rejected
- Security mode mismatch: 100% rejected

Replay Protection

Guarantee: Captured packets cannot be re-injected.

Implementation:

• Monotonically increasing nonces
• Per-connection nonce tracking
• 64-bit nonce space (584 million years at 1000 Hz)

Validation:

Replay attack testing:
- Exact replays: 100% rejected
- Out-of-order (beyond window): 100% rejected
- Nonce reuse attempts: 100% rejected

Session Key Isolation

Guarantee: Each connection uses a unique session key; captured traffic cannot be decrypted without the shared keypair.

Implementation:

• X25519 key exchange per connection derives unique session keys
• Session keys derived via HKDF with connection-specific context
• Automatic key rotation every 24 hours
• Session keys exist only in memory during connection lifetime

Validation:

Given: Network traffic captured without shared keypair
Result: Session keys are not derivable from captured traffic
        Recorded traffic remains encrypted

Given: Shared keypair compromised after sessions ended
Result: An attacker could derive future session keys
        Past recorded traffic can be decrypted if keypair known

Note: The shared keypair model provides different properties than per-device identity systems. The primary protection is against network-level attackers who do not possess the shared keypair. Keypair compromise allows an attacker to join the network and derive session keys. Treat the shared keypair with the same care as any critical shared credential.

Unanimous Security Enforcement

Design Rationale

Secure LSL enforces unanimous security; either all devices are secure, or all are insecure. Mixed environments are rejected.

Why?

1. No partial protection: A single insecure link exposes the entire data flow
2. Clear compliance: "Is the system secure?" has a yes/no answer
3. Migration pressure: Adding one secure device encourages updating all
4. Prevents downgrade attacks: Attackers cannot force insecure connections

Enforcement Matrix

Error Messages

Clear, actionable error messages guide users:

• "Connection refused: outlet does not have security enabled"
• "Connection refused: outlet requires security but local security is not configured"
• "Connection refused: security configuration mismatch"

Cryptographic Choices

Why Ed25519?

Why ChaCha20-Poly1305?

Why X25519 + HKDF?

Compliance Mapping

HIPAA Technical Safeguards

GDPR Article 32

EU Cyber Resilience Act (2024/2847)

EU NIS2 Directive (2022/2555)

FDA 21 CFR Part 11

Security Boundaries

What We Protect

flowchart LR
    subgraph Protected[Protected by Secure LSL]
        A[Data in transit]
        B[Device authentication]
        C[Data integrity]
        D[Replay prevention]
    end

    subgraph NotProtected[Not Protected]
        E[Data at rest<br/>Use disk encryption]
        F[Endpoint security<br/>Use OS protections]
        G[Denial of service<br/>Use firewalls]
        H[Physical access<br/>Use physical security]
    end

Metadata Exposure

Some metadata is necessarily exposed:

Actual biosignal values are always encrypted.

Attack Scenarios

Scenario 1: Passive Eavesdropping

Attack: Adversary captures all network traffic.

Result: Only encrypted packets captured. Without session keys, data is computationally infeasible to decrypt.

Scenario 2: Active Man-in-the-Middle

Attack: Adversary intercepts connection, attempts to relay traffic.

Result: Public key verification fails. Adversary cannot present matching public key without the shared keypair. Connection rejected with "403 Public key mismatch".

Scenario 3: Replay Attack

Attack: Adversary captures and replays legitimate packets.

Result: Nonce tracking detects replay. Packets rejected. Alert logged.

Scenario 4: Unauthorized Device

Attack: Adversary attempts to connect a device without the shared keypair.

Result: Public key comparison fails during handshake. Connection rejected with "403 Public key mismatch - not authorized".

Scenario 5: Downgrade Attack

Attack: Adversary tries to force insecure connection.

Result: Unanimous enforcement rejects mixed security. Connection refused.

Scenario 6: Compromised Shared Keypair

Attack: Adversary obtains both the encrypted private key file and its passphrase.

Result: Adversary can authorize their own devices to join the network. This is the primary threat vector and is mitigated through: - Argon2id passphrase encryption (resistance to offline brute-force) - Device-bound tokens (credentials cannot be extracted from endpoints) - Operational security practices for passphrase management - Regular keypair rotation when personnel changes occur

Note: This risk is inherent to all centrally-managed security systems. The administrator credentials represent a single point of trust.

Operational Security

Key Management

1. Generation: Use lsl-keygen --passphrase (cryptographically secure random, passphrase-protected)
2. Storage: Private key encrypted with Argon2id-derived key in ~/.lsl_api/lsl_api.cfg
3. Distribution: Export with lsl-keygen --export, import on target devices with lsl-keygen --import
4. Session keys: Rotate every 24 hours automatically per connection
5. Device tokens: Optional device-bound tokens for automatic unlock via lsl-config --remember-device

Device-Bound Session Tokens

Device tokens allow automatic key unlock without storing the passphrase. This section explains how device binding works transparently.

How Device ID is Computed:

The device ID is a SHA256 hash of three components concatenated:

Platform-specific machine IDs:

• Windows: MachineGuid from registry (HKLM\SOFTWARE\Microsoft\Cryptography)
• macOS: IOPlatformUUID from IOKit
• Linux: /etc/machine-id or /var/lib/dbus/machine-id

Security Analysis:

Since this code is open source, attackers know which identifiers are used. This is intentional; security does not rely on obscurity.

Threat Model:

Device binding provides convenience security, not maximum security:

• It prevents casual token theft (e.g., copying files to USB)
• It does NOT protect against sophisticated attackers with physical access who can clone hardware identifiers
• For high-security environments, disable --remember-device and always require passphrase

Recommendation:

For environments with strict security requirements (clinical, regulatory):

# Don't use device tokens - require passphrase every time
# Simply never run: lsl-config --remember-device

# Or revoke existing tokens:
lsl-config --forget-device

Incident Response

If the shared keypair is compromised:

1. Generate new keypair: lsl-keygen --force --passphrase
2. Distribute new keypair to all authorized devices
3. Previously recorded traffic may be decryptable if attacker has keypair
4. Future sessions protected with new keypair
5. Unauthorized devices with old keypair will be rejected (public key mismatch)

Audit Trail

Enable logging for security events:

[log]
level = 4  ; Info level captures security events

Logged events:

• Connection establishment (with fingerprints)
• Security negotiation outcomes
• Authentication failures
• Decryption failures
• Key rotation events

Regulatory References

Official sources for the regulatory requirements cited in this document:

Next Steps

• How Encryption Works - Technical explanation
• Architecture Overview - Implementation details
• FAQ - Common questions