Rather interesting Israeli lock!

[Phatphish]

Cheers mh for the heads up on the google search function, very useful.

[niksoft]

I love that google search function.... infact i very commonly use google's more advanced functionalities to find stuff (maybe one day i will post my most favorite searches list ). It is sad that the search function is broken, though i am sure i could fix it, lol.

On another note, since you guys are talking about search function being broken, here are a few more, and actually this should be posted somewhere in general discussion forums, but oh well, here it goes:

The website seems a bit slow a lot of times, well "a bit slow" is an understatement, its like watching a youtube movie on 14.4K dialup. Actually another thing i'd like to see is the ability to post images and such content to this site, instead of having to always outsource it to other servers (just think it would be a big plus, thats all)... I'm actually looking at getting another hosting acct in addition to the one i already have, maybe if you (admin) guys want, i could host this forum (free of charge ofcourse), that is if and only when the maintenance people agree whether to allow me to, and when and if it does not cause any problems for anyone (keep this as an open invitation for now guys, not saying hurry, not saying you have to, its an honest offer, for a website that is good and fun, if you would like more info on my server running experience, pm or email me).

Anyways, random Wednesday morning thoughts time for another coffee

[dougfarre]

How did this topic turn into a discussion about how to search google?

[niksoft]

It all started off with this knock lock, and someone (globallockytoo) mentioning that it has been discussed here and that people need to search the forums ..... and then that the search feature on the site was broken, and then that google is a better search engine to search the forums, and thats about the shakedown, doug

back on track at your request though

This is a cool technology, because it combines the RFID like technology except its variable sequencing on the password

Have not seen variable key two-factor authentication rfid tags that change the passcode every minute or so.... i'm talking about something like this: http://www.rsa.com/node.aspx?id=1156

[dougfarre]

From what I know about these token systems (like the one you linked to, niksoft) is that there is a token server, that knows all the individual codes of each individual token. When you enter in your password, you also have to enter in the code on the readout of your hand held unit. It then compares it with the number generated at the server and allows you access.

I assume the way this lock works, is that you give the lock, and the hand-held knocker the password at the same time. Then a sequence will start on the lock and the knocker where an algorithm generates a new code every so often. Since the algorithm is the same on both the lock and the knocker AND since we started the sequence at the same time, they will be in-sync (like the boy band).

So even if you did know the persons knocker password, and you had your own knocker to program, you still wouldn't be able to unlock their lock. Unless you were able to manipulate the knocker to change the time in which password was programed... And you knew the time when the password was programed.

This lock sounds awesome!

[globallockytoo]

Doug,

In reading extensively on the knocknlock product, I found out that the remote unit generates a "rolling code" which is recognized by the reader so everytime the knock sequence changes.

If it were not a "rolling code" it would be somewhat easier to hack the system. The Israeli engineers took this into account before releasing their prototypes.

[mh]

Doug and Globallocky, both the systems you describe are very similar.

In both cases, the intention is to make sure that a 3rd party cannot guess future valid authentication values.
Both systems rely on a shared secret, a changing value and an encryption mechanism of some sort.

The time-based system uses the current time as the changing value, whereas the rolling code uses a counter that counts how often the user pushes the button on the key device.

The shared secret ensures that not two key devices are the same.

The changing value should make sure that you can't use codes from the past. It needs a synchronization feature in case the two clocks get out of sync or in case the user presses the button while the receiver is not listening.

The encryption mechanism should make sure that a 3rd party can't find out about the shared secret.


As with any cryptographic system, there might be weaknesses, in the algorithm itself, in the authentication protocol, etc.
If the system isn't published, there are likely to be more weaknesses, because fewer people reviewed it.
If some local intel organization were involved in the development, there would be backdoors, too.

The only solution to that will be The Open Source Lock where everyone can review the whole system and contribute to its improvement

Cheers,
mh

[greyman]

Good points, mh. The rolling or cylic crypto code is also used in automotive transponder keys. I don't know much about these systems or anything at all about MulTLock's new system, but I would imagine it's based on a shift-register algorithm.

As dougfarre pointed out, the sequences generated by the lock and the key have to be in synchronisation or the key won't unlock the lock. I imagine there has to be some logic in the lock to make sure that the key has actually opened the lock or whatever condition has to be met so that the key moves on to the next code. Maybe the lock could also transmit the next code to use to the key, which would store it for the next time round.

[mh]

As dougfarre pointed out, the sequences generated by the lock and the key have to be in synchronisation or the key won't unlock the lock. I imagine there has to be some logic in the lock to make sure that the key has actually opened the lock or whatever condition has to be met so that the key moves on to the next code. Maybe the lock could also transmit the next code to use to the key, which would store it for the next time round.

For rolling codes, it's quite simple usually:
The key has a counter that increments with each code sent.
The lock receives the counter value and checks that it's not lower than or equal to the last received counter value. A window of half the counter's maximum value is usually accepted.
With a 16 bit counter that rolls over after 65535, the user could push the button 32767 times without the lock listining and the lock would still accept the code. This also means that if you could record a code and wait for 32767 accepted transmissions, then that code would work again.

The transmit-new-code-back option is also used in some transponder based systems, e.g. the Honeywell/Novar/Esser IdentKey-3 system that's used for higher-end alarm systems.

Cheers,
mh

[niksoft]

Well, both mh, doug and global, i wasn't saying that the knocker is the same type of a security device as that rsa two-factor authentication deal (i was just providing an example of other two-factor auth systems that's all)

In all reality, and i am not saying they did or they didn't, i'm merely speculating, i think that it would be cumbersome to enter your password in twice on the door side and into the hand-held, from what i read, it said that there was nothing on the door side, no panel or anything that could be seen (or so is my impression anyways)

What i think it is, is it is probably a two-factor, public key private key encryption (some type of asymmetric encryption, either RSA or DSA based algo, or like ECDSA or even ECMQV or a combination of a couple of algorithms) The handheld probably houses the public key, you type in the password, it runs through the algo, and then you have a knock go through (which will be different every time with low probability of prediction of what it is going to be next time) anyways it knocks, and it probably does not matter if you type in the right password or not to the pad, it's just there to run the private key encryption of the knock and play it. Now the pad may also attatch its own id to the knock, coupld probably use the signature option in pub/priv key encryption algorithms, this way you can track which pad has knocked, how many times, and so forth. Then the knock is received by a sound/vibration sensor on the lock, which then decrypts the message with a private key, parses out the ID (if such is present) and then checks the password. Oh the password may be hashed before encryption too, so even if you figured out what the algorithm that is used was, you would still have a hell of a time decrypting anything, even if you have a public key.

Or it can use an Elliptic Curve algorithm if there is a lack of space for larger asymmetric keys.... or as i said it can use a combination of algorithms of some sort... dunno...

Those are my thoughts for it for now anyways... i'll have to read into it, gotta run

[DiamondHead.exe]

Well it's clearly not bump proof!

Oy vey...

Oy gevalt, good to know us yids do exist

awesome article, i wish i had seen one when i was there
I did see a lot of crappily installed locks that had a lot of give when you turned the key so you had to giggle the key like a madman.

But it was the first time i had ever seen a Euro lock or a upside-down lock..(or a upside up for you Euros)

[Phatphish]

giggle the key like a madman.

I'm sure you meant "jiggle", but I'm glad it came out the way it did.

[globallockytoo]

In many commercial places in Israel, Multlock is not used...rather they use Cisa copies...or Italian Yale....also know as Yardeni teardrop or yoke Euro cylinders. The profile is often a Yale derivative or a Corbin derivative. The cylinders are easily picked or bumped and the inside cam mechanism will usually only turn when the cam has either a key or a pick that activates it.

Multlock is found predominantly on residential housing. Almost exclusively. The building code specifically recommends "Pledelet brand" (in hebrew) locks.