blocks|key|1370168|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|-4|4|5|6|B|7|@]|8|@]|9|$]]]|A|$]]

Keeloq is used in many but not all key fobs/garage door openers. This article is writen by microchip who created keeloq <a href="http://ww1.microchip.com/downloads/en/AppNotes/00001683A.pdf" rel="noreferrer">Introduction to Ultimate KEELOQ Technology</a>.

tl;dr

The remote(key fob/garage door opener) and receiver(car/garage motor unit) use the same 64 bit key to encrypt and decrypt. A "serial number" is used to identify a specific remote. Every time a button is pressed the remote's "sync counter" is incremented by 1. If the remotes "sync counter" is 0 to ~250 ahead of the receivers "sync counter" then it accepts the code and updates the sync counter for that remote. Since the "sync counter" is encrypted with a key that is only known to the remote and reciever a sniffer cannot forge a code even if it knew the next "sync counter" because it doesn't have the 64 bit key.

<a href="https://i.stack.imgur.com/r0oXB.png" rel="noreferrer"><img src="https://i.stack.imgur.com/r0oXB.png" alt="keeloq packet structure"></a>

<blockquote>
 My original understanding of rolling codes was that there was a shared secret (perhaps a serial number?) between the fob and the car, and that this was used to cryptographically generate the same infinite sequence of rolling codes on both sides.
</blockquote>

The remote encrypts the "Encrypted Portion" of the packet and sends that and the fixed portion to the receiver which then decrypts the "Encrypted Portion" using the same 64 bit key that the remote used. This is a different scheme than <a href="https://en.wikipedia.org/wiki/One-time_password" rel="noreferrer">one time passwords</a> which is often used for web authentication.

Well it's not infinite. Every time a button is pressed the "Sync Counter" is incremented by 1. The "Sync Counter" can range from 0 to 65535. So after 65536 transmissions you would see the same codes repeat. If you captured 65536 unlock transmissions you'd be able unlock the car/garage by playing the next raw capture 
in that sequence since it just wraps around.

<blockquote>
 I now think that I was over-estimating the technology, because it appears that a receiver can be trained to accept a new fob with a relatively simple process that doesn't require transferring a secret - you just need to push the fob once when the car/garage is in the equivalent of a "change password" mode.
</blockquote>

Kind of. You're right that no shared-secret is exchanged or communicated. How the remote and receiver end-up using the same 64 bit key depends on the scheme.

There are 3 learning modes "simple" "normal" "secure" described by the pdf.

<ol>
<li>Simple</li>
</ol>

<blockquote>
 The Simple key generation scheme is the simplest
 scheme that a KEELOQ technology system supports.
 When using simple key generation, one single key is
 used by all encoders and the transmitters are differen-
 tiated only by the serial number.
 It is very important that the user understands exactly
 what the implications of using such a key generation
 scheme are. This could be a potential security risk. If
 any encoder is compromised and the encryption key is
 found, then all the encoders are compromised,
 because they use exactly the same key.
</blockquote>

All remotes and receivers use EXACTLY the same 64 bit key to encrypt and decrypt packets.

<ol start="2">
<li>normal</li>
</ol>

<blockquote>
 The Normal key generation scheme is the common key
 generation scheme for KEELOQ technology systems.
 During Normal Learn, a master key is used (known as
 the “manufacturer code”). 
 When using the normal learning mechanism, the
 decoder uses the manufacturer code and the serial
 number to calculate the decryption key for each
 transmitter. 
 Using the serial number of each encoder and the
 manufacturer code, the unique encryption key for each
 encoder is calculated. The encoder stores only the
 serial number and the calculated encryption key. The
 decoder needs to be programmed with this
 manufacturer code in order to be able to calculate
 individual encryption keys. To calculate the encryption
 key, the 28-bit serial number is padded with
 0x6000000 and 0x20000000 and decrypted using
 the manufacturer code as the decryption key. This
 operation is done twice, in order to calculate the high
 part and the low part (MSB and LSB) of the encryption
 key.
</blockquote>

The 64 bit key is derived using the "serial number" and the "manufacturers code". The remote only stores the derived key not the master key, but the receiver knows the master key so that it can derive any specific remote key. So it "learns" the remotes "serial number" and then derives that remote's 64 bit key.

<ol start="3">
<li>secure</li>
</ol>

<blockquote>
 The Secure key generation scheme is a more
 advanced key generation scheme. When using the
 normal key generation scheme, the key is generated
 from the serial number and the manufacturer code.
 Since the serial number is transmitted in any packet,
 one part of the key generation scheme is always
 exposed. But an even more secure method is to
 generate a random number (called “seed”). Depending
 on the length of the seed, there are three key
 generation schemes: 32-bit seed, 48-bit seed and
 60-bit seed. During normal operation, the seed is not transmitted.
 The only time when the seed is transmitted is during
 the learning/pairing phase. Thus, the information that is
 used to generate the encryption key is kept confiden-
 tial. Some implementations take the security level even
 further, by allowing the seed to be transmitted only for
 a limited period (in which the system is installed) and
 then disabling this feature.
</blockquote>

A seed is used instead of the "serial number" for deriving the 64 bit key. The only time this seed is transmitted is at learning/pairing time.

As a final note. There are other schemes out there that are better than keeloq. Even the pdf describes a scheme that uses AES instead of keeloq, but there are worse ones too. Some garages still used fixed codes.

<blockquote>
 I am disappointed in car/garage security systems.
</blockquote>

Me too.

This is a follow-up question to my earlier one: <a href="https://security.stackexchange.com/questions/202026/does-pressing-a-car-remote-many-times-offer-denial-of-service-attack-for-rolling">Does pressing a car remote many times offer denial of service attack for rolling codes?</a> 

I want to emphasize that I am asking this question more to shore up holes in my academic (mis)understanding of rolling codes than as a practical "How do I start my car?" question.

Many (older) car and garage remotes use a rolling code system, so every time the fob button is pressed, a different code is sent, to protect against replay attacks.

<h1>Shared Secret?</h1>

My original understanding of rolling codes was that there was a shared secret (perhaps a serial number?) between the fob and the car, and that this was used to cryptographically generate the same infinite sequence of rolling codes on both sides.

That way, a simple replay attack wouldn't work. (The receiver wouldn't accept the same code twice.) 

I also thought that an attacker would need to sniff an infeasibly long sequence of codes before they could reverse engineer what the original secret was, and thus generate new items in the sequence.

<h1>Security through Obscurity?</h1>

I now think that I was over-estimating the technology, because it appears that a receiver can be trained to accept a new fob with a relatively simple process that doesn't require transferring a secret - you just need to push the fob once when the car/garage is in the equivalent of a "change password" mode.

This suggests to me that there is no shared secret, but just one very long (algorithmically generated?) sequence, that the two devices need to synchronise upon.

If the car can listen to the fob once and predict future codes, surely a sniffer can do the same?

If my new understanding is right:
 * All fobs using the same generating sequence. The algorithm may be obscure, but it isn't customised by a secret - the only "secret" is what the fob's current internal state is, and that is broadcast on every button press.
 * While a naive sniffer could not use a replay attack, a sophisticated sniffer could generate the entire future sequence from a single code.
 * I am disappointed in car/garage security systems.

Do car/garage fobs use a shared secret, and generate the sequence based on that? If so, what is the internal process that allows the remote and fob share the secret key during the synchronisation process?

How do rolling code fobs and receivers synchronise?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

这是我之前的一个问题：多次按下汽车遥控器是否为滚动代码提供拒绝服务攻击？的后续问题。我想强调的是，我问这个问题更多的是为了弥补我对滚动代码的学术(错误)理解上的漏洞，而不是作为一个实用的“我如何启动我的车？”有个问题。许多(旧的)汽车和车库遥控器使用滚动代码系统，所以每次按下fob按钮，就会发送不同的代码，以防止重放攻击。共享秘密？我对滚动代码的最初理解是有一个共享的秘密(也许是序列号？)在fob

滚动码和接收器是如何同步的？-腾讯云开发者社区-腾讯云

问滚动码和接收器是如何同步的？
EN

共享秘密？

安全性？

回答 1

Security用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问滚动码和接收器是如何同步的？EN