Cyber Lock

[dosman]

Has anyone played with one of these?
Link

It appears the "pins" are only for electrical signals (+/-/data), that's just my guess. It looks like an interesting lock system. However due to the size I'm skeptical of the security if there's actually any hand-shaking going on between the key and an internal cpu in the lock. Tiny cpu=light weight algorithm.



Modded link

[Jaakko]

The lock seems nice, but anything deeper might get advanced.

Tiny CPU = weak algorithm? Where that came from? Tiny CPU is just physically tiny. It can still produce "unbreakable" code, such as AES or it uses public key cryptography. For example, the AES can be coded into one kilobyte, so it is really tiny.

[zeke79]

UWSDWF has some experience with these locks I believe. There are issues of maintaining good connections between the keys and the locks.

[dosman]

Tiny CPU = weak algorithm? Where that came from? Tiny CPU is just physically tiny. It can still produce "unbreakable" code, such as AES or it uses public key cryptography. For example, the AES can be coded into one kilobyte, so it is really tiny.

Tiny code doesn't necessarily mean that it only requires a tiny cpu. Remember, this setup is powered (presumably) by a button battery in the key so you're talking a relatively slow clock cycle, maby as slow as 20Khz or so. AES is an expensive algorith in terms cpu cycles around these speeds. You can speed up calculations by using a smaller key size but you just defeated the purpose of using AES or anything else at that point. Sure, they may have used AES or another good cipher but the odds are that they used some silly in-house code with no peer-review that's optimized for a custom glop-drop running at 20Khz. However, I'm certainly no expert and I'd be happy to be proven wrong though.

This EETimes article has some interesting info on implementing AES on various processor architectures with reference to cycle counts for each platform.
http://www.us.design-reuse.com/articles ... e5794.html

You may note that a 68HC08 (4MHz @ 3v assuming a single lithium battery) requires about 8390 cpu cycles to process a 128-bit AES frame. At 4MHz that is quite fast enough to be usable in real time (less than a 10th of a second for a single "frame"). I'd be interested to find out what cpu they did use though, I doubt that even the smallest available 68HC08 would fit inside a KIK along with the additional required parts.

UWSDWF has some experience with these locks I believe. There are issues of maintaining good connections between the keys and the locks.

Over all it sounds like an interesting lock system, I'd love to play with one.

[Jaakko]

Tiny code doesn't necessarily mean that it only requires a tiny cpu. Remember, this setup is powered (presumably) by a button battery in the key so you're talking a relatively slow clock cycle, maby as slow as 20Khz or so.

20MHz would be better. Remember that the little battery has to provide power for like a second, so it will last a long time.

You may note that a 68HC08 (4MHz @ 3v assuming a single lithium battery) requires about 8390 cpu cycles to process a 128-bit AES frame. At 4MHz that is quite fast enough to be usable in real time (less than a 10th of a second for a single "frame"). I'd be interested to find out what cpu they did use though, I doubt that even the smallest available 68HC08 would fit inside a KIK along with the additional required parts.

What is that parts packaking? DIL? Try something like MLP-packaged chips, like this. It has a size of 2mm x 3mm and clocks at 25MHz.

Stand corrected, I study automation electronics so I think I know what I'm talking about

[globallockytoo]

Oh yeah....It's definitely bump proof and pick proof. Keys are quite expensive tho. Priced quite high but it is a good product....all powered from the key.

Medeco have brought out something similar for Gaming machines too.

[zeke79]

There was a kit a few weeks ago on ebay that had a single cylinder and operating keys along with a programming key, etc. I believe it was being sold for $700-$800.

Great system indeed but geared more towards commercial applications (in my opinion) where security, key control, and audit trails are all required.

[UWSDWF]

i use it daily at work

[Shrub]

Is that the one you couldnt get appart?

[UWSDWF]

oh i got it apart ..... with a dremel.... it didn't work afterwords though

[Shrub]

Lmao,

[absynthe]

In regards to AES... ~8000 cycles would probably not be a problem for a small cpu. The 68HC08 mentioned, if it was at 4Mhz and could do it in that many cycles, would be closer to 2/1000ths of a second (neglecting memory latency which does add time but not enough to make someone feel the lock would be unusable).

But in a practical system.. it would be far faster than 8000 cycles.. they would not use a general purpose processor like a 68HC08. They would use hardware that was designed purely for AES. Some of the operations can be done in parallel... one specialize chip can do a block in ~60 cycles. Gains are really seen when you do multiple blocks in parallel.. but that wouldn't apply to the lock because they would simply do a quick challenge-answer on a single block.

AES is also considered fairly slow compared to other high security algorithms. Serpent and a slew of others could be used. And they very easily could have simply done a hash algorithm. With a hash... any size number fed into it will pop out as a particular length. These are often very fast and in general are not going to be broken very quickly (if ever). The cylinder does not need to make a perfect cipher as the key (or person impersonating a key) probably has a small amount of time to answer. Even if the person were to "take it offline" and try to crack the answer... the lock would probably time out and when they tried again... the challenge would change. So even if you use a poor algorithm... it only has to prevent the person from answering in a very brief period of time.

As a side note.. it would be extremely foolish for this company to use a homegrown cipher. It is certainly done a lot because a company things its cool. But it is stupid. You want an algorithm that has been attacked by thousands of people from around the world. Besides.. so many of the algorithms that came out of the AES competition are free. So why not?

[absynthe]

I checked out that link and 8000 cycles is extremely high because it was on an 8-bit processor. Optimized versions running on 32 bit processors will be sub 1000. I saw one hardware version that was about 40.

I mainly posted again to show a link that describes the algorithm nicely. I had to refer to it many times because I was writing AES in assembly once and some parts were kind of confusing when reading technical papers about it. I think it is a pretty neat flash because it is a pretty neat digital lock of sorts..

http://www.cs.bc.edu/~straubin/cs381-05 ... es2004.swf

Anyway.. AES in a lock is an extreme overkill. AES is used to encrypt a document or some other data and hope that it will be safe for 30+ years (as a side note.. in cryptography.. it is really interesting to wonder how strong something really is because the NSA is so powerful.. I don't remember the real stats but they own something like 70%? of hardware and 95% of people there are PhDs)

For a system like this the lock would give the "key" maybe half a second to answer. If it did not... it would cut the channel and wait for another attempt. On the subsequent attempts it would create a whole new challenge. One side attack would be guessing what number it would make ahead of time. So for a challenge-answer to work.. you need a decent random (or psuedo) number generator.

[Shrub]

absynthe please have a read of the rules and the posting of opening advanced locks in the open forums,

A lot of your threads and posts are verging on being locked and its hard work keeping an eye on someone who makes so many of that type of post in the wrong place,

[HeadHunterCEO]

I install them in Ambulances on the narc boxes
The state likes the audit trail

I have an intact one sitting here but i do not want to destroy it to see what makes it tick.

anyone have any dissection pics to post in the adv forum?