5

I have a question about Keeloq security. I have an original car remote controller (BFT Mitto 2) and I know this chip uses HCS301 with Keeloq implementation.

I would like to clone this remote for my girlfriend because it's very expensive to buy a new one. I know universal remotes can copy this remote like this stuff (http://www.amazon.fr/T%C3%A9l%C3%A9commande-Copieuse-T%C3%89L%C3%89COMMANDES-t%C3%A9l%C3%A9commandes-descriptif/dp/B00GTV5SUQ) but I'm curious and I think it's a good electronic project for fun. So, I studied the datasheet of this component. I have already spoofed two consecutive commands and I saved the seed code (retrieved by pushing all the buttons).

Data 1: Crypt part: 0xFD32DEBA Serial number: 0x719A00

Data 2: Crypt part: 0xB1755164 Serial number: 0x719A00

SEED CODE: 0xFAA7B14

How can I learn a new remote with this information? I don't know how universal remote works but according to the datasheet I need to know the manufacturer Id to create a device Key. Can you advise me how I can proceed please.

Thank you!

migrated from security.stackexchange.com Feb 10 '16 at 16:39

This question came from our site for information security professionals.

9
+150

To create a full duplicate, able to generate valid transmission packets you'll need the following information:

  1. Serial Number
  2. Button press mapping
  3. 32 bit of KeeLoq encrypted data

See attached Figure 1-2, from the datasheet, near "Transmitted information" at the bottom right:

enter image description here

Using those three pieces of information you can theoretically create your own device.

Serial Numer

The serial number is a unique identifier of the remote control, and is trivially retrievable by capturing a single transmission packet because it is sent as-is. OP already retrieved it.

The serial is later required because it is part of the encrypted data as well, so the ability to retrieve it without first decrypting a transmission might help us down the line when we'll create the encrypted part.

Key mappings

In order to send a specific key, you'll need to create your own mapping of values to key meaning. This is not as easy as getting a single value of any transmitted message but does not prove any difficulty, just hit every key and capture it's Button Press Information field. OP seems to have managed that as well.

32 bit of KeeLoq encrypted data

This is where shit gets serious, we'll need to know what to encrypt in addition to the key:

  1. Button status.
  2. DISC bits.
  3. OVR bits.
  4. Sync Counter (16 bit word incremented once for every button press in the controller's life span).
  5. Encryption Key (called "Crypt Key" to sound leet in the datasheet :D )

See attached Figure 4-2, from the datasheet, right part:

enter image description here

Button status bits

These four bits are the same ones sent unencrypted, so we've already discussed their rather easy retrieval.

DISC bits

The discrimination value aids the post-decryption check on the decoder end. It may be any value, but in a typical system it will be programmed as the 10 Least Significant bits of the serial number. Values other than this must be separately stored by the receiver when a transmitter is learned. The discrimination bits are part of the information that form the encrypted portion of the transmission (Figure 4-2). After the receiver has decrypted a transmission, the discrimination bits are checked against the receiver’s stored value to verify that the decryption process was valid. If the discrimination value was programmed as the 10 LSb’s of the serial number then it may merely be compared to the respective bits of the received serial number; saving EEPROM space.

These bits are used to identify the device, and according to the datasheet are usually the Least Significant Bits of the previously discussed Serial Number.

OVR bits

The overflow bits are used to extend the number of possible synchronization values. The synchronization counter is 16 bits in length, yielding 65,536 values before the cycle repeats. Under typical use of 10 operations a day, this will provide nearly 18 years of use before a repeated value will be used. Should the system designer conclude that is not adequate, then the overflow bits can be utilized to extend the number of unique values. This can be done by programming OVR0 and OVR1 to 1s at the time of production. The encoder will automatically clear OVR0 the first time that the synchronization value wraps from 0xFFFF to 0x0000 and clear OVR1 the second time the counter wraps. Once cleared, OVR0 and OVR1 cannot be set again, thereby creating a permanent record of the counter overflow. This prevents fast cycling of 64K counter. If the decoder system is programmed to track the overflow bits, then the effective number of unique synchronization values can be extended to 196,608.

Under normal circumstances, these bits will be zero. They're used to increase the overall Sync Counter size by two bits but are unused by default, according to the datasheet.

Sync Counter

Out of the datasheet:

This is the 16-bit synchronization value that is used to create the hopping code for transmission. This value will increment after every transmission.

This is a value incremented every time a button is pressed, so once we get it we'll be able to roughly know what is the next expected value (which will depend on the number of button presses since).

Additionally:

Figure 7-3 shows a 3-partition, rotating synchronization window. The size of each window is optional but the technique is fundamental. Each time a transmission is authenticated, the intended function is executed and the transmission’s synchronization counter value is stored in EEPROM. From the currently stored counter value there is an initial "Single Operation" forward window of 16 codes. If the difference between a received synchronization counter and the last stored counter is within 16, the intended function will be executed on the single button press and the new synchronization counter will be stored. Storing the new synchronization counter value effectively rotates the entire synchronization window.

A "Double Operation" (resynchronization) window further exists from the Single Operation window up to 32K codes forward of the currently stored counter value. It is referred to as "Double Operation" because a transmission with synchronization counter value in this window will require an additional, sequential counter transmission prior to executing the intended function. Upon receiving the sequential transmission the decoder executes the intended function and stores the synchronization counter value. This resynchronization occurs transparently to the user as it is human nature to press the button a second time if the first was unsuccessful.

Which means we don't have to hit the exact value, and actually can guess a number the the range of up to 32k values further away, nearly half the size of the value-space.

There are three possible ways to figure it out.

Reading the EEPROM

By reading the EEPROM, which stores the Sync Counter. Since it is not possible to read EEPROM using the HCS301 without first writing it, you cannot normally read it without tinkering with the hardware. If you've managed to do that you can easily duplicate a remote. Good for you!

Decrypting a single transmission

By decrypting a single transmission you can get the currently used Sync Counter, and have a rough estimate going forward. Since the counter is incremented relatively rarely (datasheet estimates 10 times a day), you can easily guess enough values to succeed.

Good old bruteforcing

By bruteforcing the entire value, you're also able to get the correct value. Since the key-space is relatively small 64k values, you could go at it. According to this cryptanalysis and related-works review:

Depending on the transponder, it takes 65 or 98 minutes to gather 2^16 plaintext/ciphertext pairs.

Note they quote is taken a bit out of context here. While the original intent was getting samples of known plaintext/ciphertext for the challenge-response part of the chip, they also provide a rough estimate at the protocol's speed.

And that essentially means a receiver can handle these many messages in under two minutes.

Thankfully, using the 16 values window mentioned above, we can shave off four bits if done properly.

Encryption Key

The A Practical Attack on KeeLoq article describes different vulnerabilities of the KeeLoq encryption espclifically as used for vehicle remote controls and immobilizers. This is a good read if you're interested retrieving the key using cryptanalysis, and it demonstrates several potentially feasible methods. It also reviews related works for your convenience.

I'll iterate possible approaches:

Reading the EEPROM (again)

if you've done that, you could just as easily get the key itself together with the Sync Counter.

Cryptanalysis

Cryptographically retrieving the key, as described in detail at the above article and it's references.

Using the "Learning" feature

According the datasheet, the chip has a feature called "Learning" to communicate / share the key which might use the SYNC value OP has mentioned.

There are three types of "Learning":

  1. Simple Learning - this basically means all Encoder (remote controls) and Decoders (cars) by the same manufacturer share the same key, and are associated using the Serial Number. This is useful because it makes bruteforcing slightly more beneficial because a successful retrieval will provide keys for all of that manufacturer's cars. It also makes it easy to parallelize using multiple vehicles.

  2. Normal Learning

    The receiver uses information transmitted during normal operation to derive the crypt key and decrypt the received code word’s encrypted portion

  3. Secure Learning

    The transmitter is activated through a special button combination to transmit a stored 60-bit seed value used to generate the transmitter’s crypt key. The receiver uses this seed value to derive the same crypt key and decrypt the received code word’s encrypted portion.

It is possible to use the "Secure Learning" feature, with the manufacturer key to calculate the key. For that, you'll need to reverse engineer the Key generation algorithm (stored in the receiver/car) and fetch the manufacturer key from there.

Normal Learning and Secure Learning are only mentioned, but aren't described in the datasheet in depth which makes it harder to bypass those without manual analysis.

Although the implementation/design details of "Secure Learning" are not described in the datasheet, a patent filing titled "Secure self learning system" (USA Patent US 5686904 A) is mentioned on page 29.

The patent includes the following relevant yet vague paragraph:

The key generation algorithm that is used in key generation unit 42 during the secure learning operation is usually a non-linear algorithm. This algorithm accepts as input the manufacturer’s master key 40 (not known) and key generation information. The key generation information can consist of the encoder serial number 24 or the seed 20 or both. This information is transferred from the encoder in a learning operation to the decoder. The decoder 12 uses the key generation algorithm to generate a key 44 that is used to decode a normal code hopping transmission. The security of this mechanism pertains to the fact that the relationship between the transmitted seed and the decoding key is not lmown, rendering any kind of interception of the transmission useless. The non-linear key generation function also makes it impossible to establish any relationship between the key and the key generation information, making it impossible for a possible imposter to copy an illegitimate encoder. The key 22, serial number 24 and randomly generated seed 20 of an encoder 10 are loaded during the manufacturing process. The manufacturer generates the key using the seed, serial number, manufacturers master key and key generation algorithm. The key genera tion algorithm is not made known publicly. Because the seed is a random number, the possibility of manufacturing two encoders with the same keys are very slim. Considering the fact that the serial number is also used in this process, it is highly improbable.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy