Arduino as HCS301 (KEELOQ) Rolling Code Receiver?

I am trying to control a circuit with a secure one-button remote control device. After doing some research I came up with the Keeloq system and some affordable transmitters based on the HCS301 chip.

I searched several sites like eBay but I found some receivers which I found to be a bit overpriced. I am trying to keep costs as low as possible, so I am trying to use stuff that I already have like RF kits and the like.

So I was wondering if there was any way to use the arduino + RF receiver + VirtualWire for this task?

I admit I don't know much about Keeloq I did some research but I am clueless as to how the receiver 'learns' the transmitter. Is there a fixed algorithm of some sort?

If the receiver is capable of generating a sequence of numbers that matches the transmitter only by decoding a single message I don't see how that would be secure. Anyone who managed to capture it would be capable of generating the same sequence.

I found this on GitHub which I assume could be of great help but I still can't get to understand how to do the syncing.

Any help would be greatly appreciated !

1 Like

Is there a fixed algorithm of some sort?

There must be. But, it's unlikely that they will tell you what the algorithm is.

If the receiver is capable of generating a sequence of numbers that matches the transmitter only by decoding a single message I don't see how that would be secure.

The receiver simply generates a stream of data that is one of the streams of data that the receiver understands. It does this in the same way that MasterCard generates valid credit card numbers. They are not about to tell you how they know that a set of 16 digits is, or is not, a valid credit card number. Nor, I'm sure, are the Keeloq people going to tell you anything.

Anyone who managed to capture it would be capable of generating the same sequence.

Except the receiver knows not to expect to see that same sequence again, until after a number of other sequences have been received. The transmitter knows to send a different sequence each time. The receiver knows what sequence should be next. Anything out of order is rejected.

1 Like

PaulS:
There must be. But, it's unlikely that they will tell you what the algorithm is.

It seems like someone has figured out what algorithm it is using.

unsigned long Keeloq::encrypt(unsigned long data)
{
  unsigned long x = data;
  unsigned long r;
  int keyBitNo, index;
  unsigned long keyBitVal,bitVal;

  for (r = 0; r < 528; r++)
  {
    keyBitNo = r & 63;
    if(keyBitNo < 32)
      keyBitVal = bitRead(_keyLow,keyBitNo);
    else
      keyBitVal = bitRead(_keyHigh, keyBitNo - 32);
    index = 1 * bitRead(x,1) + 2 * bitRead(x,9) + 4 * bitRead(x,20) + 8 * bitRead(x,26) + 16 * bitRead(x,31);
    bitVal = bitRead(x,0) ^ bitRead(x, 16) ^ bitRead(KeeLoq_NLF,index) ^ keyBitVal;
    x = (x>>1) ^ bitVal<<31;
  }
  return x;
}

I think it makes no sense to keep the algorithm secret. Security shouldn't be purely based on that. Otherwise if someone discovered the algorithm somehow or it was leaked then there would be a huge problem.

It should be like the SSL protocol. Everyone knows how to generate keys and everyone has access to the public keys but you still can't hack it.

PaulS:
The receiver simply generates a stream of data that is one of the streams of data that the receiver understands. It does this in the same way that MasterCard generates valid credit card numbers. They are not about to tell you how they know that a set of 16 digits is, or is not, a valid credit card number. Nor, I'm sure, are the Keeloq people going to tell you anything.

I am assuming that you meant 'The transmitter simply generates'. Okay, the transmitter will transmit a certain code and the receiver will receive it. Fine. However, I don't think the receiver has a way of guessing what the next code will be, otherwise it wouldn't be secure. There will be millions of possible combinations so really, next time a code is received there's no way to know if it was the expected one.

PaulS:
Except the receiver knows not to expect to see that same sequence again, until after a number of other sequences have been received. The transmitter knows to send a different sequence each time. The receiver knows what sequence should be next. Anything out of order is rejected.

I do understand that wrong codes are simply ignored. This is why parking your car in a car lot won't cause your system any trouble, even if the other cars are exactly the same model as yours - because the key does not match and it will never because there are millions of possibilities.

I am assuming that you meant 'The transmitter simply generates'.

Yes, that was a mistake.

I think it makes no sense to keep the algorithm secret. Security shouldn't be purely based on that. Otherwise if someone discovered the algorithm somehow or it was leaked then there would be a huge problem.

I wonder why MasterCard doesn't publish it's algorithm, then. Thieves would love it. Keeping the algorithm secret is important.

However, I don't think the receiver has a way of guessing what the next code will be, otherwise it wouldn't be secure.

It doesn't have to guess. If the receiver knows that every sequence that it gets will be one of several known sequences, but that it will never be the same one it got last time, then, if it gets the same sequence twice in a row, it knows the second one is not to be trusted.

If the order that the transmitter steps through the sequences is known, and the number of transmitters is known, then the receiver has a reasonably good idea what the next sequence it should receive will be. If it gets that, great. The transmitter is legitimate. If it gets something else, that is not a valid sequence, then the receiver does nothing. If it gets a sequence that is valid, but is a duplicate of one that it recently received, it ignores it.

Just in case anyone stumbles on this post, the Keeloq algorithm is public knowledge and its use is adequately described in various places, including the HCS301 datasheet from Microchip. The Github link shows how simple it is -- very similar to a CRC calculation.

Each manufacturer of devices (like keyfobs) that use Keeloq is expected to provide a secret key that is used in the encryption process. However, Keeloq can be broken.