ELECTRO-MECHANICAL LOCK DESIGN
At the door, the lock makes its access decision without waiting for a server. I built the path that gets it there: a management portal, policy compiler, signed credentials, smart keys, and embedded firmware. A valid cryptographic exchange is only the start. The lock also checks stored policy, credential scope and freshness, time, and actuator safety. If a required check is uncertain, it stays locked.
Why Mechanical Locks?
Pin tumbler locks have used similar mechanical principles for thousands of years. My interest led me through dimple, wafer, disc-detainer, and lever tumbler designs, then to Medeco’s biaxial pin system. Its pins must reach the correct height and rotate to the correct angle, making both picking and unauthorized duplication more difficult.
What fascinated me also exposed a limitation: the lock physically stores information about the key needed to operate it. Physical access to one lock could expose shared mechanical credentials and put other openings on the same keying system at risk. That possibility led me to question whether mechanical security alone was enough.
Electronic access adds credential management and audit trails, but wired installations can require power and data at every door, alongside server infrastructure. I wanted to explore a system that could make the final access decision locally without that dependence.
Investigating CyberLock
CyberLock’s key-powered design interested me because it brought electronic access control to existing doors without wiring power to each lock. Administrators could limit a key’s active period, deactivate a lost key, and review access attempts. Earlier implementations also exposed an important lesson: digital credentials are only as secure as the hardware and logic protecting them. IOActive published an advisory in 2015.
I purchased several CyberLock cores and CyberKeys to investigate them myself. The older chips in the units I examined used non-constant-time algorithms, and I demonstrated the resulting timing side channels in my own experiments. I also investigated crowbar fault injection: brief disturbances to the power supply that can make normally protected information accessible. My experiments demonstrated this behavior. These findings concern the legacy units I tested.
The design lesson was concrete: a lock or key must protect its stored credentials even under unexpected electrical conditions. Successful communication alone cannot establish that the hardware is secure.
A lock circuit board beside its corresponding key, set up for debugging and communication analysis.
My Raspberry Pi Pico test setup for crowbar fault injection and observing data exposed during the attempts.
After repeated attempts, my program recovered the secure key. The value in this recorded run was all zeros; the attack method was not specific to that value. This was an implementation weakness rather than an exhaustive search of the possible key combinations. It showed why a large keyspace alone cannot protect a credential if the device exposes it during an attack.
From Access Plan to Physical Action
The management portal turns an access plan into signed permissions. The key and lock authenticate each other at the door; the lock then applies its own policy before it can request actuation.
The lock owns the final decision. An authenticated session proves who is communicating; it does not grant entry. The lock separately verifies credential identity and freshness, applies local conditions with deny precedence, and records the result before any permitted actuator request.
1. Begin with deny.
2. Reject invalid, stale, revoked, or out-of-scope credentials.
3. Evaluate the policy; a matching denial overrides a matching grant.
4. Record the result, then request actuation only when access and safety checks both pass.
Embedded credentials have limited space. My compiler searches for a compact representation and checks it against every opening in the provisioned set. It compares the access decision, whether a policy value exists, and that value with the planned result. Any mismatch or oversized candidate is rejected before issuance.
Applied Cryptography
I chose each primitive for a specific job. Ed25519 signatures authenticate credentials and updates. A hybrid key exchange establishes session secrets, and authenticated encryption protects messages. A successful exchange never bypasses the lock’s policy check. I also built a server signing adapter for nonexportable hardware key handles and exercised it with test doubles.
As a separate research exercise, I built an experimental substitution–permutation cipher and reproducible analysis tools. Python, C, and GPU experiments investigate diffusion and differential and linear behavior. This research remains outside the access system, which uses established cryptographic primitives.
Verification and Board Design
My tests compare policy results across C, Python, and Go; mutate and truncate inputs; replay and alter protected messages; and simulate interrupted flash writes. A recorded sanitizer-backed host run completed 103,228 checks with zero failures. The management interface distinguishes a queued update from one acknowledged by a device, keeping planned work separate from applied state.
I designed separate lock and key PCBs, both specifying an NXP SE051C2 secure element for protected credentials and cryptographic operations. NXP reports Common Criteria EAL6+ certification for the SE051 hardware and operating system. The lock board also includes actuator inhibition and power monitoring. Schematic and layout checks are complete; fabrication and bench testing are the next gate for timing, power interruption, clock trust, and mechanical actuation.
Lock and key board designs · 3D CAD views. Fabrication and bench testing are the next stage.
One Unlock Request
A valid session is a starting point. Signed profiles and binding, the current epoch, revocation, trusted time, local policy, lockdown, and tamper checks can each stop an unlock request. The audit write and final authorization recheck happen before the actuator request.
Lock decision · C-style pseudocode. Begin with deny; record the event and recheck authorization before requesting actuation.
Compact-policy exactness · C-style pseudocode. Reject oversized candidates and any mismatch in access decisions or policy values before issuance.
Two nRF52840 microcontrollers simulate communication between the lock and key. The black wire is common ground; the yellow wire carries data. I use a one-wire protocol to test authentication and communication while checking the software for attacks, bugs, and regressions before the custom boards are manufactured.
The hardest part was making the boundary between a valid credential and permission to unlock unambiguous. I traced that decision through the compiler, cryptography, flash storage, firmware, and actuator path, then tested failures at each boundary.
