Signed packets. Known senders.

In 30 seconds

Identity on every protected packet, and a valid-or-invalid verdict wherever you check it.

01 / The problem

The network moves packets. It never checks who sent them.

The Open Systems Interconnection (OSI) stack was designed to deliver traffic from physical connections (Layer 1) to the application layer (Layer 7). The OSI stack was not built to prove where traffic came from. Identity was added at the application layer: API tokens, RPC frameworks, etc. Everything below layer 7 is trusted by position. A stolen API token works from wherever it's sent. Once inside the gateway, packets will look the same and pass as legitimate traffic.

Gaps security teams live with

1. Visibility isn't validationYour tools see every connection. They can't tell you whether it should have been allowed.
2. Authentication isn't verificationA login proves someone had the credential, not who is using it now. Stolen credentials, malware on a signed-in device and hijacked sessions all look legitimate.
3. Automation trusts its inputsAttackers can shape what automation sees: enough to slip past detection, or to disrupt your services through alert fatigue.

The question

"Was this packet sent by the authorized signer, for this exact session?"

Channel Lock answers it for every protected packet.

02 / Where it fits

What changes for your security team

• Detection with less noise

  Traffic from enrolled users and devices is signed and known. What's left to investigate is the invalid traffic: no signature, the wrong key, or fields changed on the way.

• Input your automation can trust

  Automated response is only as good as its input. Every threat Channel Lock logs is a packet that failed a check that an attacker couldn't bypass.

• An audit trail at the packet level

  Signed packets that fail are logged with the reason. Our Metrics view shows what was verified and what wasn't.

Adds to the zero trust you already run

• Segmentation

  Group critical assets by who may reach them, not by subnet, and keep internal firewall rules simple.

• Identity and access

  Your IAM checks the sign-in. Channel Lock carries that identity on every protected packet, so usage traces back to a user or device. The packet carries a signature, not a name.

• VPN and remote access

  A stolen VPN credential gets someone onto the network, but it doesn't sign their packets. Channel Lock checks identity behind the VPN; the VPN keeps doing the encryption.

03 / See it working

Watch a server say no.

$ curl -s \
  -H "PRIVATE-TOKEN: $GITLAB_TOKEN" \
  https://gitlab.example/api/v4/projects \
  | jq -r '.[].name'
agentic

$ curl -s \
  -H "PRIVATE-TOKEN: $GITLAB_TOKEN" \
  https://gitlab.example/api/v4/projects \
  | jq -r '.[].name'
agentic

$ curl -s \
  -H "PRIVATE-TOKEN: $GITLAB_TOKEN" \
  https://gitlab.example/api/v4/projects \
  | jq -r '.[].name'
^C  # no answer

$ ssh jdemo@gitlab.example
jdemo@gitlab:~$

$ ssh jdemo@gitlab.example
jdemo@gitlab:~$

$ ssh jdemo@gitlab.example
Permission denied
(publickey,keyboard-interactive).

04 / How it works

Three roles. Keys never touch the packet path.

The Channel Signing Key Authority (CSKA) holds the key relationships and hands out session material. The Signer and Validator do the packet work. Keys move on a separate control plane. The packet path carries only signed data.

1. EnrollA user proves who they are to the identity provider, with an email PIN and a passkey, and downloads a one-time enrollment file. Imported on the device within 15 minutes, it becomes a device credential only that user's account can read.
2. SignFor each session, the signer combines its signing key with the session ID and channel ID to derive a session key. It hashes the configured packet fields with that key and appends the result as a trailer.
3. FetchThe validator asks the CSKA for that session's key, naming the signer and the user. The CSKA checks the request, releases the key once, and returns the user's identity, signed by the identity provider, so the validator knows who is sending.
4. CheckThe validator recomputes and verifies each protected packet. Valid traffic continues. Failed validation is blocked and recorded as a threat.

05 / The packet

Up to 34 bytes, at the end of the packet.

Channel Lock appends a signature trailer to the tail of the IPv4 packet, then fixes up length and checksums so the packet stays valid on the wire. Fields that legitimately change in transit, such as TTL and checksums, are normalized before hashing, so routers don't break the signature.

• What's in it

  A 4-byte header with the digest mode, the layers covered and a flag for a new session; a 14-byte session block when a session starts or the key rotates; then 4 bytes per hashed layer.

• Symmetric session keys

  Each check is a keyed hash, not public-key math.

• Two digest modes

  SHA-512, rolled up to 4 bytes per hashed layer, or XOR for lightweight tagging. XOR is not a cryptographic signature.

• Configurable coverage

  Choose which of L3, L4 and payload are protected. Behind a NAT, hash the payload only.

• Extensible options

  The trailer ends with a compact, fixed control field. Its version identifies the trailer format, allowing future formats to be introduced with matching signer and validator support.

06 / The verdict

Valid packets pass. Invalid packets stop.

The validator answers one question per packet, and blocks every packet that fails.

For each protected packet, the validator checks one thing: did the authorized signer send it, for this session, with the protected fields unchanged? Valid packets carry on as normal. Invalid packets are blocked before they reach the service.

What can make a packet invalid

An invalid verdict means the packet can't be trusted, whatever the cause. It's blocked, and the dashboard records it.

No quiet way to take a key. The CSKA releases each session key only once. If an attacker retrieves it first, the legitimate validator's request is denied. Every packet in that session then fails validation, flagging the affected session for investigation. Once the legitimate validator has retrieved the key, an attacker cannot obtain it through another request: the CSKA refuses any repeat release.

07 / Security model

One key per session, released once.

Session keys move on the control plane, never with the packets. Each key is scoped to one session, and the CSKA releases it one time. That keeps any exposure small, and it means nobody can get a key from the CSKA quietly: if the wrong party asks first, the real validator finds out.

1. A key per sessionThe signer derives a fresh key for every session. A session key is good for that session and nothing else.
2. Released onceThe CSKA hands each session key out once and records who took it. A second request for the same key is refused.
3. No quiet way to take oneIf the wrong party gets a session key from the CSKA first, the real validator can't. Every packet in that session fails, and the session shows up as a threat.
4. One secret, three places to guard itA forged packet needs the session key. The signer's key can derive it, the validator holds it while it checks, and the CSKA releases it once. Protect all three; this isn't a design where an attacker needs two of them.

Channel Lock is a packet-integrity and validation layer. It works alongside endpoint, key and access controls, not instead of them.

08 / Deployment

Goes in where your traffic already flows.

• Linux and Windows

  On Linux, the signer and validator run as eBPF programs. On Windows, they install as a driver on the Windows Filtering Platform (WFP).

• One service, any role

  The same Channel Lock service runs on every device. The dashboard sets each one as a signer, a validator, or both.

• Anywhere on the path

  The validator can sit at a gateway, on a router, or on the server it protects. In the demo, it runs on the GitLab server. A VyOS router running as an egress gateway is another option.

• A dashboard on the CSKA

  Overview, Devices, Threats and Metrics, plus profiles, trust groups and tags for configuration, and a topology view of every CSKA, signer and validator.

• Blocks where it checks

  The validator blocks invalid packets itself, and the dashboard records them.

• Control plane on NATS

  Key requests use NATS request and reply. Requests are fast, and they are rate-limited so nobody can flood the CSKA.

• Fast after the first packet

  The CSKA is asked when a session starts and when the signer rotates its key. In between, each packet costs one keyed hash.

• More than one CSKA

  Run one per site, tenant or partner. Group their IDs into named trust groups, and a rule can require that a packet's signer belongs to a CSKA in a given group.

09 / FAQ

Frequently asked questions.

Does the validator block traffic?

Yes. Packets that fail validation are blocked, and the dashboard records them. Valid packets carry on as normal.

Do unsigned packets show up as threats?

Not by default. A packet with no trailer at all is dropped and counted, but not listed as a threat, so a host that isn't configured yet doesn't flood the dashboard. Signed packets that fail are listed, with the reason and the rule that caught them.

What if someone steals an API token?

It only works from the account it belongs to. The application checks the token; Channel Lock checks who sent the packets. Use a user's token from another account on the same machine, such as a coding agent's, and that account's packets come back invalid.

How does a user get an identity?

They sign in to the identity provider with a passkey and download a one-time enrollment file. Imported on their device within 15 minutes, it becomes a device credential that only their account can read.

Is this IPsec or a VPN?

No. Nothing is encrypted or tunneled. Channel Lock proves which sender signed each packet and that the protected fields didn't change. Pair it with encryption if you need confidentiality.

Does it add latency?

Per packet: one keyed hash and a trailer of up to 34 bytes. The CSKA is consulted when a session starts and when the signer rotates its key.

What stops someone forging a trailer?

Without the session key, a forged digest is a one-in-four-billion guess per hashed layer, and every miss is dropped and logged. A lucky guess reveals nothing about the key. Hash more layers and the odds multiply: L3, L4 and payload together are 96 bits to match.

What happens at a NAT?

NAT rewrites addresses and ports, which would break a digest over L3 or L4. Behind a NAT, set the rule to hash the payload only (L5 to L7), as the demo does.

What about MTU?

Nothing to change. The trailer adds up to 34 bytes, and normal fragmentation handling applies.

IPv6?

Not yet. Channel Lock covers IPv4 today; IPv6 is on the roadmap.

Do my applications change?

No. Channel Lock works at the packet level, below your applications.

What if the CSKA goes down?

Validation fails closed: a session the validator has no key for is blocked. Sessions already keyed keep validating until their signer next rotates its key.

Who is it for?

Teams that run services other machines call, and need to know which user, device or agent is behind each call. Developer and platform teams give each service and agent its own identity. Enterprise security teams screen traffic at gateways and borders. SOC teams get threats that are failed checks, not guesses.

Can threats go to our ticketing or monitoring tools?

Not yet. Today threats are in the Channel Lock dashboard: the Threats view lists each one with its reason and the rule that caught it, and the Metrics view counts what was signed, dropped and flagged.