Why Encryption Matters for Biosignal Research

You might wonder: "I'm just streaming EEG in my lab. Why do I need encryption?"

This page explains why security matters even in research settings, and why Secure LSL was designed the way it is.

The Current State of LSL Security

LSL's official documentation states clearly:

"The SessionID is not a security feature... you are still able to intercept packets involved in a session that is not yours."

This means:

• All biosignal data travels in plaintext over your network
• Anyone on your network can read your data with basic tools like Wireshark
• No authentication prevents unauthorized devices from connecting
• No integrity checking detects if data has been tampered with

In our review of 150+ LSL applications across Python, MATLAB, C++, and other languages, we found zero existing security implementations.

Why This Matters

1. Regulatory Compliance

If your research involves human subjects, you likely need to comply with data protection regulations:

2. Multi-Institution Collaborations

Modern neuroscience increasingly involves collaboration across institutions:

flowchart TD
    subgraph Before["Without Encryption"]
        A1[University A] -->|"Plain EEG data<br/>visible to ISP, network admins"| B1[Internet]
        B1 -->|"Plain data"| C1[University B]
    end

When data crosses network boundaries:

• Network administrators at each institution can see your data
• ISPs can inspect the traffic
• Any compromised router along the path exposes everything

3. Protect Your Research

Even in a "closed" lab network:

• Shared WiFi: Other researchers, visitors, or students on the same network can sniff traffic
• Compromised devices: A malware-infected laptop can capture all network traffic
• Data integrity: Without authentication, how do you know your recorded data wasn't modified?

4. Clinical Applications

Brain-computer interfaces (BCIs) and neurofeedback are moving toward clinical deployment:

• Patient neural data requires protection
• Real-time control systems must verify data authenticity
• Regulatory approval requires documented security measures

The LSL Security Gap in Numbers

Anyone on your network with Wireshark can see all of this in seconds.

Common Objections (and Responses)

"My lab network is isolated"

"We use a VPN for sensitive work"

"Our IT department handles security"

"Performance will suffer"

"It's too complicated"

# One command per device
./lsl-keygen

# That's it. Your existing code works unchanged.

The Unified Security Model

We designed Secure LSL with a "secure by default with unanimous opt-out" model:

flowchart TD
    subgraph Network["Your Lab Network"]
        A[EEG Amplifier]
        B[Eye Tracker]
        C[LabRecorder]
        D[Analysis Workstation]
    end

    subgraph Valid["Valid: All devices agree"]
        V1["All have keys → Encrypted"]
        V2["All insecure → Plain (legacy)"]
    end

    subgraph Invalid["Invalid: Mixed environment"]
        I1["Some secure + Some insecure → Rejected"]
    end

    Network --> Valid
    Network --> Invalid

    style V1 fill:#90EE90
    style V2 fill:#FFE4B5
    style I1 fill:#FFB6C1

Why this design?

1. No accidental gaps: You can't accidentally leave one stream unprotected
2. Clear status: Either everything is encrypted, or you get a clear error
3. Migration pressure: Adding one secure device encourages updating all devices
4. Simple auditing: "Is security enabled?" is a yes/no answer, not a per-stream matrix

What Secure LSL Protects Against

What Secure LSL Does NOT Protect

Being clear about scope:

Getting Started

Ready to secure your lab?

Quick Start Guide →

Or learn more about how the encryption works →