MACsec (IEEE_802.1AE) is Layer2 encryption for your local LAN. It encrypts all traffic and authenticates hosts at medium access control layer. I've been playing with it in my local environments and implemented some out of band keying and this page gives some notes about MACsec.

You can check my Github for 'nk-macsec' which uses Nitrokeys to key MACsec enabled hosts. I use this in my home LAN where my main development workstation is isolated from rest of the family provided segment with MACsec encrypted Layer2 access. I have also made available buildroot image for 'macsec router' which allows me to use RaspberryPi4 as router between MACsec segment and public network.

• Github

Following picture illustrates typical home LAN environment, where China produced router provides isolation between Internet but inside of your LAN segment, everything moves laterally with no restrictions.

Imagine if you have some valuable corporate data, access tokens for corporate infrastructure or even better, VPN routing your computer (in LAN) traffic to corporate restricted VPN segments. Information security peoples often have sensitive research, code samples and other possibly harmful data at their workstations.

Do you think that China router is enough and your hosts are safe on local LAN?

My solution to prevent lateral movement is to use MACsec. I implemented small buildroot firmware image to RaspberryPi4 which acts as out-of-band 'keying device' and 'macsec router'.

→ This results that my main development workstation is not present at LAN segment in Layer3 (IP).

Bellow is detailed information how this implementation works.

This implementation works only with Linux. No Mac's or Windows are supported.

Typically in local LAN everyone can 'see' everyone. If you are required to isolate hosts on LAN, you need to implement aircap, some routing firewall between segment or VLAN's.

You find MACsec enabled switches and systems from many vendors. I found them to be too expensive and overkill for my simple needs. And it seems that most of those are only encrypting layer2 traffic between host and switch, leaving plain text traffic visible inside switch.

I implemented small C program (nk-macsec) to read and write keying material to external security module (Nitrokey PRO or Storage) and udev rules to do this keying automatically when Nitrokey is inserted. Additionally I did small embedded Linux firmware image for RaspberryPi4 which does routing between my MACsec segment and public network behind it.

You can deploy solution with 'macsec router' or just with Nitrokey as out-of-band keying device. With this approach your MACsec layer2 keying is delivered always physically and not over the wire. And with given approach MACsec is always 'host-to-host' which allows you to use any Layer2 switch vendor.

I bet you find interesting use cases after you get what MACsec actually is. My initial start was to segment my high value development workstation(s) from home network, but equally I've seen needs to isolate DFIR teams from target networks or use MACsec router as traffic blocking device in case of emergency.

→ It's actually pretty impressive to piggyback existing networks and leave no trace on Layer3 monitoring.

You can implement some opsec with given solution. By default 'MACsec router' has only Console access through serial port and does not have SSH or other services exposed to any interfaces. As you can implement your Layer2 encryption on any network, I believe it's nice OPSEC increase anyway!

Basically all configuration on 'MACsec router' happens through one file where MAC addresses are just listed. First MAC address is your RaspberryPi4 'MACsec router' and rest are hosts you'd like to use with solution.

So how I use this solution? I can decide when I want to re-key my MACsec segment by inserting my Nitrokey first in RaspberryPi4. By doing this, RaspberryPi4 as MACsec router creates new keys and writes them to Nitrokey. After this, RaspberryPi4 re-keys it's internal state and rest of the MACsec enabled hosts are 'cut off' and unable to communicate with RaspberryPi4 (because they contain old keys). When I take Nitrokey to my workstation and insert it, after few seconds - workstation completes re-keying (via udev rules) and connection resumes. MACsec segment rekeyed!

So the magic happens with 'nk-macsec' and udev rules that launch 'nk-macsec' based on Nitrokey insert. Keep it simple.

You can test 'nk-macsec' manually with following steps: