3 expanded posts ยท every known parent and child
Hi all, Seems to me the way to do this is to 'dock' the receiver and xmitter prior to leaving (could rationalize it by also doing battery charging at this time) and each time they share a unique one-time pad. Plug-N-Play so to speak... Take care.
I'm in favor of a one-way transmission system, even though a challenge- response system is more fun. The costs are much higher for a remote with both transmitter and a receiver sensitive enough to work without a decent antenna. That said, Jim Choate writes: > Seems to me the way to do this is to 'dock' the receiver and xmitter prior > to leaving (could rationalize it by also doing battery charging at this > time) and each time they share a unique one-time pad. The remote and opener could exchange a list of OTP entry codes. The list could be sufficiently large that docking would be unnecessary for months. With a public key system, the remote could transmit its OTP by radio, eliminating the need for docking hardware. The opener should not accept codes out of order. If it accepts code 'n' from the OTP list, it should ignore codes 1..n thereafter. That helps to reduce the risk of having your remote "borrowed" for awhile to acquire codes. I like the OTP because the message size can be set arbitrarily small as a tradeoff of transmission time against security level. With full message encryption, the minimum message is necessarily bulky. For example, the minimum DES block size is 64 bits. With a OTP, though, a 48 bit number might suffice. Assume the OTP is 2^7 entries long, and transmission takes a second. A hacker can generate abouabout 2^22 tries in a full month if he's broadcasting continuously. The odds of succeeding in finding a 48 bit OTP entry would be about (48-22-7), or 1 in 2^19, in that time. Again, transmission speed is an important issue. The overall responsiveness and convenience of a system can hinge on trivial details like the number of bits in a message sent by slow radio. If you're uncomfortable with a 1 in 500,000 chance of being hacked by a persistent criminal who'd rather not break into your car or find another point of entry, by all means bump up the OTP entry size to 64 bits. I could be wrong about transmission time, but it's my impression that it's a lot easier to shovel a few dozen bits per second through a cheap transmitter than a few thousand. It makes sense not to redesign the transmitter anyway (FCC approval can be a pain sometimes!) - Jim Nitchals
> That said, Jim Choate writes: > > > Seems to me the way to do this is to 'dock' the receiver and xmitter prior > > to leaving (could rationalize it by also doing battery charging at this > > time) and each time they share a unique one-time pad. > > The remote and opener could exchange a list of OTP entry codes. The list > could be sufficiently large that docking would be unnecessary for months. > With a public key system, the remote could transmit its OTP by radio, > eliminating the need for docking hardware. > The problem with this scenario is that in order to keep the security you must keep the door-opener in your possession for the entire time limit the key-list is used. All it would take to circumvent it would be to have somebody gain access to the hardware. Shoot, if you let somebody have access to the opener then it is possible they might put some kind of ghost on the ram and make it possible for them to do all kinds of stuff to circumvent the list. If you dock each time then you don't need that kind of security. For them to get at the opener they would need to gain access to your house in which case they would attack the base-unit. As to the suggestions relating to sync'ed clocks. This would be ok for a day or so but longer than that and the clocks will be far enough out of sync such that they will no longer match keycodes. Clock chips just aren't that accurate.