scary new lock design

[yanksfan]

Are you guys forgetting that we can just revert to the ol' hit it with another piece of metal, preferably a sledge hammer or a crowbar, until it falls off?

It actually does look pick-able, only different methods will have to be applied (as the fore mentioned =P)

[sevedus]

Greetings Yanksfan! Thanks for playing!
Our ability to publicly disclose details right now is limited to the front end (key/cam interaction), and we are very grateful for the peer review thus far. Your assumption that you will have productive recourse to the “destructive entry” techniques mentioned is thus understandable. The (partial-section) side view shows the installed cylinder and front mounting boss, (which is the cylinder housing), on a door of 2.0 inches thickness.
The assembled components protrude from the door surface only 0.525 inches, and rather than the typical “right-cylindrical” configuration with which you are familiar, take the form of a spherical-segment having a 1.75 inch radius. The major diameter of the segment is 2.5 inches.

DoorMtgFrnt1..jpeg

You will note that the components, rather than being mounted ON THE DOOR, are mounted IN THE DOOR. For the device to be “struck” from the door, as you suggest, will require the failure of the door. We have calculated that the front boss might be driven THROUGH the door (assuming the existence of a door which will not yield first), but we believe that to do so will require sound, heat and light sufficient to make this entry a very public event.

Let me be clear about our design intentions. This lock is intended to provide such obstacles to unauthorized entry that ONLY destructive means may succeed, and that those means should be so odiously obvious that someone wishing to enter without detection will move away from the lock and focus on another point of entry. What more could be asked of any lock?

All I can add to previous posts about the “pick-ability” is that the techniques will be VERY DIFFERENT indeed, considering that even the correct key will not operate the lock unless it is inserted above a minimum speed (4 inches/second), because there is no overlap between the serial interactions of pin and permutation. It’s sort of like crossing a stream on stepping stones which are too far apart for you to have a foot on one while reaching for the next. To cross the stream you must jump, so that both feet are taking air, to be able to land on the next stone. At zero rotational velocity of the cam there is no sequence. The most promising suggestions for “decoding” the cam thus far are more in line with cracking combination dials by amplified acoustics and automated (servo controlled) manipulation of the pins. This is a “statistical brute force” attack which, because there are 140 billion unique permutation sets we suggest is not a (life)timely recourse.

Stephen

[mh]

All I can add to previous posts about the “pick-ability” is that the techniques will be VERY DIFFERENT indeed, considering that even the correct key will not operate the lock unless it is inserted above a minimum speed (4 inches/second), because there is no overlap between the serial interactions of pin and permutation. It’s sort of like crossing a stream on stepping stones which are too far apart for you to have a foot on one while reaching for the next. To cross the stream you must jump, so that both feet are taking air, to be able to land on the next stone. At zero rotational velocity of the cam there is no sequence. The most promising suggestions for “decoding” the cam thus far are more in line with cracking combination dials by amplified acoustics and automated (servo controlled) manipulation of the pins. This is a “statistical brute force” attack which, because there are 140 billion unique permutation sets we suggest is not a (life)timely recourse.

Stephen

I think with the current setup, a useful tool would be a variable setup key that you would populate row by row, and an amplified microphone. If you selected the wrong pin, the cam will rewind, with the correct pin it will stay.
Cheers
mh

[sevedus]

The method mh suggests seems perfectly valid.

The velocity key is an array of eight bits wide by thirteen deep. The reduced bit count on the key is due to the increased rotational increment between cam permutations (from 3.4 to 16.4 degrees). I doubt that the rewind can be made acoustically covert. My question now is whether this constitutes a real vulnerability or not, because it seems to me a scenerio which applies the statistical brute force of attempting every iteration of the possible sequences. If you could test one sequence per second and did so for an entire year 24/7/365, you'd have tested 31.5 million of the possible 140 billion permutations. To try all of the possible sets would (at the dubious attempt rate of one per second) require 4500 years. Would the technique that you propose shorten the path to the full sequence enough to be a credible vulnerability?

Stephen

[mh]

what if you can populate the key row by row? Can you try 8 options in the 1st row (and find the correct position there), then 8 options in the 2nd row (and find the correct position there), and so on?
Decoding locks is all about not having to test n^m but only n*m options.

Cheers,
mh

[sevedus]

I should just get an electronic “rubber stamp” that says, “mh is quite right!”

mh proposes to decode the cam in only 104 steps, for the array stipulated, and I believe his elegant solution would be perfectly successful but for two things…

There is nothing to be detected by operating only one pin from the first rank in the array, whether the first rank’s pin is displaced slowly or at speed. Axial and radial displacement and rewind are identical at that point in the cam motion. If any single pin in the first rank is displaced at speed and then held, the cam (even if the correct pin is used), will rattle back and forth between good and bad permutations due to the lack of overlap. The only way that I can see to determine that the correct pin was selected in the first rank is the proper operation of the correct pin in the second rank. So the shortened path to the sequence could only be determined using the single-pin-in-a-rank-technique when applied against the third (and subsequent) ranks. To be certain of the second ranks proper pin would require all 64 iterations of the first and second ranks be tried. Clearly not 4500 years of attempts, however:


Because the means of decoding has shifted from direct measurement of pin displacements inhibited by contact with static (zero-velocity) permutations to the acoustical signature of the cam rewinding….I've got some balls made of a steel alloy at Rc 70-72 (greater hardness translates into greater rebound of balls during elastic collisions). Having approximately 1/3000th the mass of the cam they will continue in motion much longer than will the cam. By extending the length of the permutations sufficiently to intrude through the I.D. of the cam, they contact and drive the balls with the cam until deceleration occurs. Deceleration is abrupt in the proposed decoding scenario (virtually instantaneous) due to the “held” pins, at which point the balls are in free-travel. Welcome to my pin-ball machine.

I suspected that at some point I might need to sonically mask the cam, especially after watching a computer unlock a combination dial safe in Sneek NL using only a rotary encoder, microphone and torque sensors. It only required a few hours.
The membership of TOOOL and Locksport said to me, in so many words both in Sneek ’07 and at Defcon15, that if I intended to take the concept into production they could expose any vulnerabilities. Look at the difference in cam design between where this post started and where we are now….fantastic. My confidence in arriving at a ZERO-NDE lock at the conclusion of this effort remains very high. I think I’ll know how to properly demonstrate my gratitude to the membership when this project comes to full fruition, for now I can only say it with every post…..

From the bottom of my heart, thank you all for helping us do this.

Stephen Maples

[greyman]

Hello sevedus

I have come into this a bit late. I had a look at the previous material but there is so much of it that I don't really have time to go through it. You seem to be getting some good suggestions from mh, but I suspect that many others, like me, are having difficulty following or don't really have time to wade through all the details.

Can you, for my benefit, please post a simple and short description of how you proposed lock works? (I didn't view the original animation - some problem with the flashplayer).

BTW, I really like the CAD pictures.

greyman

[sevedus]

Hello Greyman! Thank you for the kind words. We are indeed delighted by the generous sharing of information both here and back-channel. It was for just this sort of feedback that we came. Refinement of the key/cam portion has been moved at a gratifying pace.
Welcome to the fray!

Greyman asks for a brief of the operation of the key and cam.

The key consists of a flat rectangular metal plate (0.0625 x 0.635 x 1.4 inches). It is populated with bit lands of identical dimension and geometry (right triangle of 0.032 inches vertex). The possible bit locations comprise an eight across by thirteen deep array. Only one position in each rank of eight is populated so thirteen bits are present.

Eight pins are disposed across the keyway so that during the key’s insertion any of the pins may be displaced by a bit land at any point in the insertion. The pins are solid and intrude into the keyway only to the extent of 0.028 inches. The functional displacement of a pin by a bit land is all or nothing… no height steps. Inside the cylinder a cam is mounted parallel with the pin row. The cam is a hollow cylinder, spring biased to both a radial and an axial “home position”, and journaled on fine (ABEC7) bearings. The cam’s outer diameter is populated with permutation surfaces, into contact with which the pins are forced when displaced. The cam rotates radially or traverses axially depending on how the permutation surface is oriented and whether it is “next “in the operating sequence. The permutations are distributed across a 120 degree arc segment of the cylinder in an (roughly) eight by eight array, which is fully populated.

Displacement of the pins in the correct sequence and at the correct intervals results in co-operative, continuous rotation of the cam, followed by axial traverse. During traverse the rotational position is maintained. At the end of the traverse the lock cylinder is rotated to retract the bolt. 80% of the permutations present are decoys to prevent decoding through lack of contact when individual pins are tested at zero rotational velocity of the cam. The functional permutations are angularly spaced far enough apart that unless the cam rotation reaches sufficient velocity the sequence cannot advance. There are extremely hard steel balls, which have complete freedom of motion, within the hollow cam. They generate noise to mask the acoustical interactions between permutations and pins.

Does this bring you up to speed sufficiently?

My post in reply to Yanksfan (Sunday May 10th) has a good analogy on the velocity aspect.
There will be further disclosure of additional components very soon (next week). Thank you for your interest.

Stephen Maples

[mh]

The pictures you want to look at when reading Stephen's latest post above are
the latest version of the cam concept:



and the key rendering from his homepage:



The pin "springs" (magnets) are discussed somewhere earlier in this thread.

Cheers,
mh

[sevedus]

Hello
Sorry to have been off for so long. Normal excuses...very busy here. Now I can show some of the internals of the lock design. Those who've been following the thread will apprehend some obsolete components is the illustrations. There's also a new animation on the web-site. I hope you can tolerate the size of the images, there're several. I'll do multiple posts if the attachments get too large. I'm not going to post a long explaination right now. Most of this stuff should be fairly self-evident.

[sevedus]

Above didn't seem to pull up the images, so I'll try again. Sorry 'bout that.

latchcut1.tif

[sevedus]

JPEG rether than TIFF? duh!

latchcut1.JPG

latchcut2.JPG

latchcut3.JPG

[sevedus]

okay! Just four more. Thank you for your patience while I fumble through these.

latchcut4.JPG

latchcut5.JPG

latchcut6.JPG

[sevedus]

Last one

latchcut7.JPG

[greyman]

sevedus - These pictures are just amazing!

Re: figuring out how your proposed lock design works, I made a little progress when I had a bit of spare time a week ot so ago. I got through the first few pages of the thread and had a look at the animation of the earlier design. I don't think I fully understand that, but it seems to rely on some type of continuous impact from the control surfaces on the key to rotate a cam. This is a very interesting idea - most locks I have come across are essentially "static", i.e. no matter what the insertion speed of the key or the way the tumblers arrive in their correct positions, the lock will still open. Am I on the right track here? Is your basic idea to make the active parts of the lock respond dynamically to the forward movement of the key?

One other thing - is the lock design continuing to change, or are the pictures you are posting different views of the same lock or same type of lock? I found the last set of pictures a bit confusing on a quick inspection.

greyman