Context
NB: This is a writeup of something I explored years ago. It’s not really structured, and it may not be 100% accurate, but I find it interesting to share nonetheless. Hope you enjoy it!
Some big buildings (hospitals, big companies, universities, etc.) still use traditional physical locks. On big facilities, people may need to open (or close) 3 or 4 doors between the outside and their desk.
The problem arises in not giving more rights than needed. Alice’s key should only open the front door, Alice’s floor, and her cubicle, but it shouldn’t open Bob’s desk. The naive solution would be to give each user a specific key for each door, but this becomes a usability nightmare.
I was intrigued in analysing how such systems work. In my case, the master key system implemented in KESO keys (manufactured by Assa Abloy).
Description of the keys
In my case, I focused on KESO 2000 keys. At first glace, the system seems reasonably secure. The keys cannot be legally copied by a blacksmith. Even more so, the key blanks cannot be easily accessible.
These keys have a springy pin at their tip. Without it, the lock doesn’t engage:
It turns out that this pin is patented1, and thus nobody that I could find sells blanks.
(One solution if you want to cut your own key is to obtain a really low privileged key of the same building.)
Getting information
In order to discover how the MSK worked, I had to get hold of some keys. By photographing them and annotating which doors they could open, I hoped that I’d by able to see the schema transcend.
Funnily enough, getting hold of keys proved to be difficult. Turns out social engineering is not that easy when you are an introvert ;-). At the end of the day, I was able to photograph 18 different keys. For each one, I’d also write which doors I thought it would open.
Getting the key cuts into a usabel format was done using a small python script. First, a homograph projection had to be done in order to have the same reference space when annotating the cuts:
Then, it asked the user to click on all the holes of the key.
The keys of the building I studied appeared to have 3 different types of cut, which I called:
- simple depth
- double depth
- Marker
Interestingly enough, the “marker” (the weird groove in the pictue above) cut looks like US patent US4553452A. However, on these keys it always stayed at the same position regardless of the “powers” of the key.
The list of clicked coordinates would look like so:
# Cut type;X pos;Y pos
M;483;390
S;198;678
S;198;816
S;195;1557
S;195;1707
S;582;2004
S;576;1251
S;582;1107
B;579;819
B;579;1545
B;192;2010
B;204;1260
B;198;1116
They were then fed to a simple nearest neighbours (k=1) script in order to get the nearest “logical” cut of key:
Master Key System
Once all the key cuts were identified, it was just a matter of trying to decorelate the single cut→lock from a list of locks for exach key.
That is, my assumption was that if a key $A$ with cuts $C1$, $C2$ would open locks $L1$ and $L2$, and a key $B$ with cuts $C2$, $C3$ would open locks $L2$ and $L3$, then cut $C2$ was associated with lock $L2$2.
Furthermore, all the rooms are hierarchical: to open the room X, you need to open the main building, and X. But to open cubicle A inside room X, you need to open the 3 locks. By comparing keys with themselves, and comparing the set of cuts with the set of rooms, we could find really interesting data:
At this point, I assumed that in the valid “lock-cut space”, cuts would only be additive. I.e. if two keys $K_1$, $K_2$ with a set of cuts $S_1$,$S_2$ would open a respective set of locks $SL_1$, $SL_2$ then the resulting key $K_\omega$ made by superposing both keys ($K_1$, $K_2$) would open the joined set of locks $SL_1 + SL_2$.
As far as I’m aware, this assumption is true.
By adding more keys and removing common cuts for nested locks, we start getting the schema. Here, you can see that the D4B
cut which was previously given to the building code was removed, and associated with the 6C
floor, as it is not present on keys that open other floors but note 6C
:
Conclusion
In conclusion, once we had access to some keys, the keying scheme seemed rather straight forward. In my opinion, most of the security appears to rely on two main assumptions:
- keys are hard to obtain
- the “building marker3 is specific to each building, and hard to “cut”
Concerning the embedded locks (i.e. room A1
, inside room A
), it turns out that there are no specific bits allocated to them. I.e. it seems like it was not possible to cut keys that would open subroom 4A1
(inside 4A
) and room 6B
, but not room 6B1
(inside 6B
), as the bit indicating subroom XX1
was the same on all keys.
Indeed, once you have a valid key, it’s basically just a game of adding more holes into specific parts of the key to gain access to more rooms.
Funnily enough, this was confirmed when I gained access to the cleaning lady’s key, which had plenty of cuts in some areas of the key only4:
I wanted to joke about patenting something making it more secure, but in this case I’d agree a bit. It was a real pain finding blanks on the internet. ↩︎
Some “formalism” always makes it more professional ↩︎
Sadly I could not compare with another unrelated building using the same key system ↩︎
Social engineering worked out in the end ;-) ↩︎