Defend against vampires with 10 gbps network encryption
synacktiv.com
synacktiv.com
More seriously, I have wondered if you can detect these kinds of external interference. Auto lock the machine if power/network/wifi/Bluetooth/USB conditions change.
Nabbing an unlocked laptop was how they got the Silk Road guy (though they probably already had sufficient evidence elsewhere).
https://arstechnica.com/tech-policy/2015/05/sunk-how-ross-ul...
> The ADXL362 accelerometer in the PayShield 10K acts as a "Motion Sensor" detecting tilt movements. An alarm triggers an alert if the HSM is moved (for example, slid out of the rack)
You could also monitor the ethernet link. They can move your server but they can't move the entire network, set up an encrypted tunnel between two distant physical servers and self destruct the moment that tunnel gets disrupted.
Some computers come with gyros/accelerometers built in. My old HP laptop had some kind of head crash prevention that used that hardware. I know this, because Gnome thought it was a tablet style sensor and turned my screen upside down if I didn't disable the sensor. Maybe getting a HP server can already get you a whole bunch of movement sensors.
You could probably figure out if the server is being moved by measuring capacitance of the case, measuring accelerometers, maybe add a GPS dongle. Or you could add an LTE connector and measure any signals you may receive that you shouldn't from inside a server room. You can probably measure _something_ in the server room, though, so to make sure your LTE dongle doesn't get interrupted, also measure whatever reliable signal you can find to detect Faraday cages.
Lastly, you could put a video camera in the case on all sides and measure changes. Detecting law enforcement badges probably isn't that hard with opencv if you're dedicated enough.
You have to hide your security measures and never tell anyone, though, or they'll just leave the server as-is and use the classic rubber hose exploit to make you give up the key material.
Incoming Bluetooth Low Energy announcements should have a receive power level associated with them. Stick a beacon (like say a standard ble temperature/humidity sensor) somewhere, and you should be able to tell if the distance to it changes.
Easily. Bolt the machine to the floor in such a way where the case has to be opened and a trip sensor activated to actually move the machine.
You can switch my power source without noticing? Who cares. The attack is taking the machine where it is not supposed to be. That's a problem we've been solving since forever.
So they could just remove the existing UPS?
what is inject a UPS?
Edit: If the machine is plugged into a power bar / power strip / whatever you want to call it, this is much easier still: Plug the vampire UPS into the power bar as well, wait for it to sync up to the grid, and disconnect the bar from the outlet. The UPS continues to feed power into the bar and thus keeps the machine powered.
* In case they are split for whatever reason (switched plug, different circuit) whatever, just take off the faceplate, pull out the outlet, and now you have direct access to the screw terminals and copper wiring on the outlet. You could wire into the plug using the second set of terminals or via the other connection method (one being the screw terminals, the other being the "insert into the hole" depending on which is used) and take the whole outlet with you.
The insulation on plug pins prevents you pulling the plug far enough out of the socket to use a plug pin capture device; if it's far enough out of the socket to expose the uninsulated portion of the pins, it is no longer far enough into the socket to be receiving voltage, and you've just interrupted the power, which is precisely what you don't want.
The design of our wall sockets is such that there is no separate faceplate assembly; you'd have to take the entire socket off of the wall. Excepting some exotic sockets (like the MK Logic Plus Rapid Fix), there is only one recessed insulated screw terminal for line and neutral and no holes to push conductors into [1], and loosening that screw to put another conductor in would also risk interrupting the power.
Furthermore, most sockets are on ring circuits, and removing the socket from the wall creates a dangerous potential for an overcurrent condition on the now-incomplete ring, which the breaker will not respond to, as it can't know that the ring is no longer complete.
In order to safely do socket surgery in this scenario, you'd first have to connect both lines and both neutrals together using something like a scotchlok connector. Then you can cut one of the line and neutral conductors from those to the socket. Finally, you can crimp onto the flying socket line and neutral from the vampire, and then cut the other line and neutral when the UPS is ready to feed the socket. This leaves exposed mains-potential conductors behind the wall which should be capped off by some form of scotchlok or crimp connector for occupant safety, and an exposed mains-potential conductor which should be capped off for officer and technician safety. [2]
I dare say this is more involved and riskier than simply carefully cutting into the equipment power cord. Also, good luck finding enough slack conductor behind a wall socket in order to pull this off.
I guess a more elaborate version of the same idea can be done if the computer plugged directly to an outlet with two sockets too, removing the socket from the wall.
The only time I can forsee vampiring the cable being a thing would be if computer is directly plugged into a single socket outlet on the wall?
You would need to drill holes in the concrete wall to get to the power lines in the wall in order to take the outlet along and hope that there isn't an additional device in the breaker panel.
This is actually a well-trodden area of datacenter interconnect (DCI) devices that do line-rate encryption (to crazy levels like 400G+) to protect those links that may have easily accessible fibers strung along poles, for instance, to prevent just the vampirism described in the post. Packetlight, Ciena, Infinera and others.
Just spit-balling a little, but I wonder if Wireguard is the best tool here given that the author is only using it for a single point-to-point link and they control the devices on both ends. That CPU supports AES-NI and probably does it a lot faster than Wireguard's ChaCha20 (hard to get numbers for their server CPU, but the tiny little x86 mini PC I use as my router does AES XTS at 43Gbps according to `cryptsetup benchmark`).
You might see better performance by tunneling the vxlan connection using a different technology which can use AES-NI? Then again, Wireguard is definitely still a good tool for stuff like this, and maybe the performance penalty isn't a big deal here.
My understanding is that AES has some design warts that make it not ideal (basically, it's easy to both implement and use in ways that leak information if you're not careful) but that it's still essentially perfect symmetric encryption if you're using it as recommended. Is that wrong?
FWIW, the reason I brought up performance was because the OP spends a large chunk of the post talking about it, so I assume it's an important requirement for them.
[1] https://en.wikipedia.org/wiki/Datagram_Transport_Layer_Secur...
Now I admit ChaPoly has some pretty nice advantages if you're implementing it in software. But with the trend of AES-GCM hardware support and the long-lived nature of WireGuard's crypto choices given the lack of ciphersuite negotiation (which I agree was a good decision!), I'm not sure AES-GCM wouldn't have been the best (albeit less cool) choice.
Although maybe on the other hand, ChaPoly can still be made to run pretty fast even just in software and it gives WireGuard the advantage of being more practical on very low-end devices that might lack AES-GCM hardware. Avoiding ciphersuite negotiation means a tradeoff needs to be made somewhere, at least with current algorithms, and I'd bet line-rate hardware encryption is probably the least likely place to see WireGuard for a while at least, so maybe WireGuard did make the best tradeoff at the time.
I agree in advance, Noise already uses counter-based nonces, the extended nonce wouldn't matter to vanilla Noise.
I wanted to push back a little on the notion that Chapoly was "cool" and GCM was "lame" back in 2015-2016. At the time, GCM was coming off a pretty rough run of implementation bugs. It was the tail end of a period of time where a concern was that some mainstream architectures wouldn't be able to run performant constant-time GCM at all; like, the fast software GCMs had a table-driven multiplication? I forget the details.
But you could have done a secure WireGuard instantiated on AES-GCM. It's true that GCM was out of fashion and Chapoly was in fashion. I just want to say, that fashion had (has?) some real technical roots. That's all.
I've never heard that before. Are you referring to a specific mode of operation?
My solution ended up using tc's mirred[0] action for implementing a fully L2-transparent frame relay. I wonder if their setup achieves the same degree of transparency, because afaiui, that's just not possible involving a 802.1Q-compliant (Linux) bridge.
I spent close to a week optimizing my setup looking at kernel flame graphs and perf results, reading adapter-specific tuning guides and driver source, and can say that the only really meaningful performance optimizations (in both the Broadwell- and Zen3/Vermeer-based implementations I tried) were disabling mitigations in the kernel (esp. on Zen3, that boosted performance by more than 20%), and getting CPU frequency scaling/idle states sorted out correctly (which yielded much higher wins on the older Broadwell uarch, because power state transition appears to happen much quicker on Zen3).
As for the solution presented in the (on the whole really great; I love it!) article, I have my doubts about the effectiveness of the cargo-culted "sysctl tuning" mentioned - TCP, for example, is simply not involved at all in the described setup, so "tuning" its buffer allocations cannot have any effect on the workload.
Kudos to the writers for solving their problem in a creative, cost-effective and maintainable way! :)
[0]: https://www.man7.org/linux/man-pages/man8/tc-mirred.8.html
please elaborate
With Zen3, this hardly mattered at all.
I also got to witness that using IPv4 for the wireguard "overlay" network yielded about 30% better performance than when using IPv6 with ULA prefixes.
[0]: https://man.archlinux.org/man/x86_energy_perf_policy.8 [1]: https://linux.die.net/man/1/cpupower
came across the epp thing once or twice but remained in the land of 'echo performance |tee /sys....'
if you can share anything related to your sweetspot
the v6-performance issue reeks of mtu
For Broadwell in particular, it is enough to avoid power states lower than C1E, in my experience.
And no, MTU plays no part in the degraded IPv6 performance. I think it's rooted in a less efficient route lookup mechanism (Linux 6.7 was what I tested with), but I did not take the time to check properly.
Like, by disabling the mitigations does that leave the servers slightly more open to someone nefarious finding a way to use some kind of timing attack to get some knowledge of your wireguard keys?
(Genuine question as someone with very little knowledge on both wireguard and *bleed CPU flaws)
Can you elaborate on what is not transparent about 802.1q bridge in Linux?
I hear you on the system tuning. Whenever I change sysctl variables I always include a comment with what the default was and why the new setting is better. I don't trust sysctl copy pasta w/o decent explanations.
You may already do this, but in general, please include the Year, Month, Kernel Version and your own Name when doing this.
vm.dirty_ratio = 40
vm.dirty_background_ratio = 10
vm.swappiness=10
governor=performance
energy_perf_bias=performance
min_perf_pct=100
I can't believe they were under any memory pressure, so the first three presumably made no difference, but it's also quite surprising to me that the default ondemand cpu governor was responsible for such a dramatic performance hit. Not throttling up quickly enough leading to higher latency maybe? Very interesting anyway.
Quite amusingly it's the load isn't big enough for the default governor to rise the clock up to max.
If they posted the cpu load it would be pretty obvious.
But getting back to the main topic of the paper: why not just S2S IPSec the link?
TFA explains it pretty well. Also every encryption is adding the load and latency, so defaulting to it when it wasn't asked for isn't the best way
> why not just S2S IPSec the link?
Because IPSec is still PITA and also sucks bad performance wise against WG.
"Oh, no, a truck run into the pole carrying the copper/fiber, it must be an accident and no intervention is going on undetected because of the outage."
What we really need is promiscuous connectivity , but fully untrusted connections. It's maddening why it's hard to communicate 2 wireless devices while they are literally sharing the same radio spectrum and multiple radios could be used to talk to each other.
I have a computer setup with a one-way gige connection for reviewing potentially malicious content in an air-gapped manner. The transmit side transceiver needs to see an incoming signal, so I just use one of these to feed its own output back into it:
# setup a 8020 MTU on wg0 interface to account for the 80 bytes wireguard headers overhead
# 20-byte IPv4 header or 40 byte IPv6 header, 8-byte UDP header 4-byte type, 4-byte key index, 8-byte nonce, 16-byte authentication tag)
/sbin/ip li set dev wg0 mtu 8020
Got to use it again to set up a remote telescope for the eclipse.
9.71 Gbps with wg on a 10GBps link with sysctl tunings, custom MTUs,.
I had heard of token ring, but not 10BASE5: https://en.wikipedia.org/wiki/10BASE5
I'd love to see your IT manager's face when you propose it :D
asking because copper is neither cheap nor particularly hard to penetrate.