Idea: The Open Source Lock

[JackNco]

why not have a loop system. so power is fed from the lock in to the key, recharging the key, but then if theres a power failure the battery operates the lock... well not recharging the key just power going through it so it doesn't draw from the battery any more than is going in.

[TOWCH]

I think that's a misconception. There is no inherant rule that you can pick anything. Man cannot build a lock so secure that man cannot compromise it. That doesn't mean that you can't specifically address all likely vectors of attack and even completely address all non-destructive ones within a given set of assumptions. "High security" would be meaninless otherwise.

[JackNco]

i think the point was whats the point of having a mechanical backup in place if its an electronic lock. the point being that you leave your self open to two area of attack instead of just one. most locks have flaws and most people are better at picking certain kinds of locks open. so having two different locks on a door that either being compromised means the door opens is a massive weakness.

[mh]

I don't know if this is how car rolling code sysems already work, but if it is, I don't understand how anything could be compromised. Timing the exchange seems like it would secure everything.

I agree, it's another option - instead of cryptographically signing a random value, one could also sign counter values.

However, it wouldn't make a difference in required cryptographic processing power, right?

One advantage of the 'counter' approach would be that you don't need a true random generator.

Cheers,
mh

BTW, most car rolling code systems are one-way, the remote sends only, and the security relies on the idea that each transmission can be used only once, until the counter rolls over.

[mh]

Nice one guys...but...one of the most important rules in lockpicking is that every lock can be opened with alternative methods...why would you like to do a lock that you can't open using lock picks?..i realise that technology has evolved but as long as you have a key or a code to open it...it can be picked...if not by lockpickers maybe by hackers...
my opinion...

I think the fascinating thing about it would be

(1) in addition to finding flaws in somebody else's concepts (read: locks)
we would make something on our own that's much better

(2) real experts on finding such flaws (read: e.g. members of lp101) would check the concept and realization - until it's really foolproof


And I would respectfully disagree on the hackers part.
Hackers can manipulate systems if their design has flaws.
Many large software packages are too complex to design them without flaws. => Hackers can manipulate them.

However, an embedded system of the complexity of an electronic lock CAN be designed properly. Especially with the help of so many talented critics

[mh]

The issue of mechanical backup is an important one. It is all well and good to design a hyper-secure lock, but it has to be functional as well.

And, of course, if you put a mechanical backup in the the lock, you are open to physical bypass issues.

That's true. Some safes have 4-wheel mechanical override locks in them, so that you don't have to destroy the door should the electronic lock fail.

It's part of the trade-offs that would have to be considered.

If the door is the only access point, a mechanical override might make perfect sense.

However, what if the lock itself had no power source and drew it's power from the key? No worries of power failures at that point. If your battery dies in your key, at least it's a simple matter to change it and you're back in.

That's right and as UWSDWF pointed out, it's the Videx concept.

The issue I see with that is that power supply lines to the outside can be used for many bad things, incl. sabotage (taser...), plotting the electric current over time in order to learn about the secret key, working around time delay penalties, and more.

For some applications, it might have to be done, though.

Other options could be the generator mentioned before (as used in some safe locks), solar cell inside the lock (powered from a laser pointer in lockout situations), or other ideas.


Or of course the mechanical override.
If one could build a reasonably small combination lock with a long combination, that could be a pretty secure concept.
Like - turn the key left x times, then right y times, etc.
Maybe a code checking method similar to Simplex could be used.
However I have no idea how to make something like that really manipulation-proof.

Cheers,
mh

[TOWCH]

I think the project has alot of potential if we run with it.

Following brainstorming, to start things off, people can start submitting prototype developement boards. Ideally: a compact, powerful, general purpose one will get put together and the project can start to revolve around that platform standard. If the board is nice and flexible, from there people can start submitting code, mechanical designs, and improvements to the development board.

The authentication process is the vital guts of an electronic lock. The mechanical implementation is in a sense a parallel project. If the guts are designed right, the design should be portable to different mechanical implementations.

[morphje]

However, what if the lock itself had no power source and drew it's power from the key? No worries of power failures at that point. If your battery dies in your key, at least it's a simple matter to change it and you're back in.

powering a lock from a battery that fits inside a key is near impossible. Operating mechanical bits takes a lot of energy. A lot of amps in a short time, sadly there is no small battery that can handle it

And while on the bolt question, i would prefer an AC spool, instead of an DC spool, this will prevent magnetization to various iron parts closeby. Some might argue over using an AC spool because of the noise.

Another option is using a small motor and gears to slowly operate bolts and such things. I personally find those solution prone to error. (while remembering every time i had to walk to the other entrance because the door didn't function _AGAIN_). Although using this kind of system you could operate large bolts, which would be impossible to operate with just spools. Downside is the long time it takes to operate a door and generally makes even more noise then just AC spools.

[andreasm]

powering a lock from a battery that fits inside a key is near impossible. Operating mechanical bits takes a lot of energy. A lot of amps in a short time, sadly there is no small battery that can handle it.

All the motor should have to do, is to allow the plug to turn (move pins), which won't take much power or time.

ASSA ClIQ has a battery and a chip in the key, and a chip with motor in the cylinder. That is in addition to the ASSA Twin mechanical part I think.

No point in using the battery for opening the door.

[mh]

The authentication process is the vital guts of an electronic lock. The mechanical implementation is in a sense a parallel project. If the guts are designed right, the design should be portable to different mechanical implementations.

I agree. I also think that the authentication process could be simulated on normal PCs (or MACs or whatever), that would increase the range of potential contributors.

As for embedded system hardware, rather cheap small boards are available e.g. here: http://focus.ti.com/mcu/docs/mcugetting ... =342#tools
http://focus.ti.com/docs/toolsw/folders ... f2013.html
I didn't check the specs yet, but that might be something worthwhile looking at.

I do think however that one or two mechanical reference applications (I thought of a Euro cylinder and a U.S. version) would make sense very early in such project,
because more people will become interested.
Not many people can relate to other people's ideas as long as they are just 'theories'; but many would be excited by seeing the 'actual thing'...

BTW, I wonder if any potential contributors are reading this, and would be interested -

obviously such project would need
(1) mechanical design skills
(2) electronics design skills
(3) software skills - (3a) embedded design & debugging and (3b) crypto stuff
(4) a platform for communication and data exchange & storage (drawings, source code, ...)
(5) some marketing, to get others interested
(6) ... ?

Personally, I would be very interested - surprise... -;
having a EE background, specifically in embedded systems (mobile phones - software and some hardware, and lots of PM), I could probably contribute best to parts 2 and 3a... Of course I would try the other parts as well...

Cheers,
mh

P.S. Another interesting link I found in that context is http://www.emachineshop.com/

[mh]

powering a lock from a battery that fits inside a key is near impossible. Operating mechanical bits takes a lot of energy. A lot of amps in a short time, sadly there is no small battery that can handle it.

All the motor should have to do, is to allow the plug to turn (move pins), which won't take much power or time.

ASSA ClIQ has a battery and a chip in the key, and a chip with motor in the cylinder. That is in addition to the ASSA Twin mechanical part I think.

No point in using the battery for opening the door.

Exactly, the CLIQ and the Videx concepts are examples for manually turned locks, where the electronics are powered from the key's battery.

I just wonder how they reliably protect the lock from high voltage attacks. The problem being that eletrostatic discharges are not always attacks, but could also result from the authorized user touching the lock - and that shouldn't disable the lock.
I somehow think that without real EMC / ESD experts, one should not try to design such concept, because you don't know exactly about the vulnerabilities. Obviously ASSA has these experts,
but for a community project proposal like this, where to find them?


BTW, the opposite examples would be the battery powered deadbolts from various manufacturers in the U.S. (PowerBolt etc.) or the German ELV KeyMatic system; those move the bolt(s). But they indeed need lots of energy and usually have simple key overrides, as the batteries might drain fast.

Cheers,
mh

[unjust]

what your'e describing was recently produced using an led key card. due to the proximity required a mim attack doesnt' work, and using a shared progressive key means that the -only- key that will work is the correct one, as both the key adn door cross check each other. w/o both parties presesent neither has the means to generate the hash necessary to open the door, and as it's a progressive key, you can't simply repeat an earlier code, or reverse engineer (w/o some -serious- cryptoanaylsis on the massive distributed superconputer scale takign years) the handshake from one to the next.

busy week but i'll find the white paper on it .... maybe tomorrow.

[unjust]

or i'll find it really fast in my history.

i only spent 4 years there you'd think i'd remember it was a cornell project.

http://instruct1.cit.cornell.edu/course ... index.html

[mh]

[quote="unjust"http://instruct1.cit.cornell.edu/courses/ee476/FinalProjects/s2006/bcr6/final_report/index.html[/quote]

Great, thanks a lot.
Now let's pack this into a nice secure package

Cheers,
mh

[TOWCH]

Good deal, that puts the ball back in the court of mechanical design which is more appropriate for this forum anyway.

I'll go pull the half euro out of my door to see what constraints we are up against on euro tail piece redesign. I want to address the primary weakness of the standard before doing anything else. Designing KIK/CAM cylinders should be fairly easy I think.

I'll get to work. :D