StrongBox 3000
Electronic safe with multi-level authentication.
CESI · Embedded systems · Team project
- Client
- MI7 agency, simulated brief
- Target
- Arduino, 8-bit microcontroller
- Deliveries
- 4 milestones, from circuit to full prototype
- Factors
- Recognised card + physical combination
Key points
- Two independent factors: neither the card nor the combination is enough alone
- Circuit designed before the code: the wiring decides what the program can read
- Multi-level authentication algorithm with distinct access rights
- Four deliverables, from first circuit to assembled safe
How it works
- 1
The circuit first
Before any code, the wiring: the switches forming the combination, the card-reading contacts, the feedback LEDs, and the resistors that go with them. In embedded work this order is not a preference: the number of available pins decides what the program can read, not the other way round.
- 2
The breadboard build
The schematic becomes a real breadboard build wired around the Arduino. This is where paper meets reality: one miscalculated resistor and the LED burns out, one misplaced wire and the input floats instead of reading zero.
- 3
The authentication algorithm
The security logic proper: recognise the presented card, read the switch combination, and open only if both agree. Several levels of rights were defined, since not every agent opens the same compartments.
- 4
The assembled safe
The previous pieces brought together into a complete prototype, presented to the client. A system that works on the bench and one that works once closed inside its box are not quite the same object.
Try it yourself
Present a card, set the four switches. Neither is enough on its own: that is the whole point of the build.
Factor 1: the card presented
Factor 2: the combination
Present a card, set the switches.
The safe never says which of the two factors is wrong: saying so would let an attacker search for them separately, turning two locks back into one. The expected combination is deliberately short here, four switches.
Context
A simulated brief: the MI7 agency needs a safe for its sensitive documents. The first embedded systems project of the course, and the first time a program I wrote drove something physical rather than printing a result to a screen.
Why two factors, and why independent
A card alone gets stolen. A combination alone gets watched over a shoulder. Requiring both is not about stacking two protections but about forcing an attacker to succeed at two attacks of different kinds: steal an object, and observe a gesture. That is the reasoning behind two-factor authentication, and seeing it on a twenty-component build makes it far more concrete than any lecture diagram.
- The two factors are read on separate inputs: compromising one reveals nothing about the other
- The safe does not say which of the two is wrong, otherwise it helps the attacker search separately
- Rights levels open different compartments rather than giving everything to whoever gets in
What I took away
- An embedded program is designed with the circuit, not after it
- The reasoning behind two-factor authentication, seen from the inside
- Running a project end to end, from requirements to a presented prototype
- What an over-talkative error message hands to an attacker