How attackers and defenders think about whole systems, from the memory of one process to the trust model of the web. Each topic came as an attack and the defence it led to, so you learn why a mechanism exists by seeing what it stops.
Main ideas
- Memory safety, and what stack canaries, non-executable memory and address randomisation protect against.
- The web’s public key infrastructure, and where certificate trust breaks.
- Network and DNS security. I read the SAD DNS line of work alongside (SAD DNS, its follow-up, SCAD), and its lesson carries over to robots: rejecting a forged message isn’t enough if the rejection changes shared state an attacker can read back.
- Authentication, anonymity and privacy.
- Side channels, where a secret leaks through timing or shared hardware with no bug in the data path.
- Threat modelling: list the assets, the attackers and what each can reach before fixing anything.
Project
In a team of four, a project on robot security with two parts. The first was a survey of how robots get attacked and defended, sorted by layer: firmware, middleware, sensor data, planning and the cloud. The second was a demonstration in simulation, which was my part. Tampering with one sensor feed on the robot’s own middleware biased its fused position estimate and walked its navigation off course, and a monitor that compared the fused estimate with each sensor’s own account caught the growing gap.
A small, slow bias at the bottom of the stack becomes a wrong decision two layers up, and it is much harder to catch than a sudden jump. The defence that worked used a second, independent account of the same quantity. The code and the survey are on GitHub as Humanoid Robot Security.
Relevance to my research
Telling a tampered sensor from a faulty one, from inside the robot, is a large part of robust robotics, and it leans on robust estimation and runtime monitoring. In a team, a compromised robot looks like a Byzantine one.