🔐

رمزنگاری در ریموت‌های کنترل بی‌سیم (Fixed Code و Rolling Code) — کلیکتو و میکروچیپ

🧾 چکیده

ریموت‌های کنترل بی‌سیم (مانند درب پارکینگ، خودرو و سیستم‌های امنیتی) از دو دسته اصلی رمزنگاری استفاده می‌کنند: کد ثابت (Fixed Code) و کد غلتان (Rolling Code). در ایران، اکثر ریموت‌های ارزان‌قیمت بازار (کلیکتوهای معمولی) از کد ثابت (مانند PT2262/EV1527) استفاده می‌کنند و به راحتی قابل کپی هستند. اما ریموت‌های پیشرفته‌تر (مانند HCS300/HCS500 میکروچیپ) از الگوریتم KeeLoq بهره می‌برند و امنیت بالاتری دارند.

در این مقاله به طور کامل به ساختار فریم‌ها، تعداد بیت‌ها، نحوه احراز هویت، پروتکل‌ها و روش‌های پیاده‌سازی در ESP32 (مانند ماژول Manchester RF) می‌پردازیم.

📌 مقدمه

ریموت‌های کنترل بی‌سیم در درب پارکینگ، خودرو و سیستم‌های امنیتی بر پایه الگوریتم‌های رمزنگاری مختلف طراحی شده‌اند.
درک تفاوت این الگوریتم‌ها، کلید تحلیل و طراحی گیرنده‌های امن است.

در این مقاله به بررسی می‌پردازیم:

• تفاوت کد ثابت و کد غلتان
• نحوه عملکرد HCS300 و HCS500
• الگوریتم Keeloq
• ساختار فریم‌های ۶۶ بیتی
• تحلیل سیگنال Manchester
• امنیت گیرنده‌های بازار ایران

🧠 انواع سیستم‌های رمزنگاری ریموت

۱️⃣ کد ثابت (Fixed Code) – مثل PT2262 / EV1527

در این مدل، هر ریموت یک شناسه ثابت دارد که همیشه ارسال می‌شود.

منطق عملکرد:

1. ریموت یک کد مشخص ارسال می‌کند
2. گیرنده بررسی می‌کند آیا این کد مجاز است

مشکل اصلی: اگر یک بار ضبط شود، قابلیت Replay Attack وجود دارد.

مزایا: ساده، ارزان، مناسب کاربردهای غیرحساس
معایب: امنیت پایین، آسیب‌پذیر در برابر حملات بازپخش

۲️⃣ کد غلتان (Rolling Code) – مثل HCS300 / HCS500

در این روش، کد هر بار تغییر می‌کند و تکرار آن غیرممکن است.

ایده اصلی:

• ریموت و گیرنده یک شمارنده مشترک دارند
• هر بار فشردن دکمه → کد جدید تولید می‌شود
• گیرنده فقط بازه محدودی از کدها را می‌پذیرد

نتیجه: ضبط و پخش مجدد سیگنال‌های قدیمی بی‌اثر می‌شود

🧩 روش‌های امنیتی در گیرنده‌ها

• Learning Mode: ذخیره شناسه ریموت در حالت آموزش
• Acceptance Window: پذیرش کدهای داخل یک بازه محدود
• Simple Encryption: رمزنگاری ساده برای جلوگیری از خواندن مستقیم داده

🔐 الگوریتم Keeloq و HCS300

HCS300 مبتنی بر Keeloq، LFSR، شمارنده داخلی و Manufacturer Key است.

فرمول ساده‌شده:

NextCode = (CurrentCode × 0x0431 + 0x0C39) & 0xFFFF

همگام‌سازی (Resync): در صورت فشار خارج از برد، گیرنده با مکانیزم محدود دوباره همگام می‌شود.

1. ریموت‌های کد غلتان (Rolling Code) مانند HCS300 از شرکت Microchip، در سیستم‌های امنیتی پیشرفته خودرو، درب گاراژ و سیستم‌های هوشمند استفاده می‌شوند. این ریموت‌ها با استفاده از الگوریتم KeeLoq، هر بار یک کد جدید تولید می‌کنند تا امنیت و جلوگیری از حملات Replay تضمین شود.

   ---

   2. ساختار واقعی فریم ۶۶ بیتی HCS300

   فریم کامل HCS300 همیشه ۶۶ بیت است و از MSB به LSB به ترتیب زیر ارسال می‌شود:

   موقعیت بیت	تعداد بیت	نام فیلد	توضیحات
   65–38	28 بیت	Serial Number (DISC)	شناسه ثابت ریموت – منحصر به فرد برای هر ریموت
   37–34	4 بیت	Button / Function Code	کد دکمه فشرده‌شده (مثلاً 0001 = دکمه ۱، 0010 = دکمه ۲ و …)
   33–18	16 بیت	Counter (CNT)	شمارنده ۱۶ بیتی که با هر فشار دکمه افزایش می‌یابد
   17–2	16 بیت	Encrypted Counter + Button + Status	خروجی رمزنگاری KeeLoq
   1–0	2 بیت	Status Bits	بیت‌های وضعیت (مثلاً باتری کم، تکرار و غیره)

   ترتیب ارسال فریم:

   [28 بیت Serial Number] + [4 بیت Button] + [16 بیت Encrypted Block] + [2 بیت Status]


   نکته مهم: ۱۶ بیت Encrypted Block شامل ترکیبی از Counter، Button و Status است که رمزنگاری شده‌اند و گیرنده پس از رمزگشایی آن‌ها را استخراج می‌کند.

   ---

   3. الگوریتم KeeLoq در HCS300

   3.1 ورودی رمزنگاری (۶۴ بیت)

   [16 بیت Counter] + [4 بیت Button] + [2 بیت Status] + [10 بیت ثابت (معمولاً 0) + 32 بیت Serial Number]


   3.2 کلید رمزنگاری (۶۴ بیت)

   • کلید منحصر به فرد برای هر ریموت (Encoder Key)

   • معمولاً ترکیبی از Manufacturer Key + Serial Number برای تولید کلید نهایی

   3.3 خروجی رمزنگاری

   • ۱۶ بیت پایین (LSB) از خروجی ۶۴ بیتی KeeLoq → Encrypted Block

   • این بیت‌ها در فریم ۶۶ بیتی ارسال می‌شوند

   3.4 فرمول تقریبی (برای آموزش)

   uint16_t next_counter = (current_counter * 0x0431 + 0x0C39) & 0xFFFF;


   توجه: این فقط تقریبی است. الگوریتم واقعی بر پایه LFSR و چرخش با XOR است.

   3.5 شبه‌کد واقعی KeeLoq

   uint32_t keeloq_encrypt(uint32_t data, uint64_t key) {
uint32_t y = data;
for (int i = 0; i < 528; i++) { // تعداد دورها معمولاً ۵۲۸ است
uint8_t bit = (y >> 31) & 1;
y = (y << 1) | bit;
if (some_condition) y ^= (key >> some_position) & 1;
// عملیات پیچیده‌تر …
}
return y;
}


   ---

   4. نحوه کار گیرنده (Decoder)

   4.1 یادگیری (Learning)

   1. دریافت Serial Number + Encrypted Block

   2. رمزگشایی Encrypted Block با کلید تولید شده

   3. استخراج Counter اولیه، Button و Status

   4. ذخیره: Serial + Current Counter + Encoder Key

   4.2 اعتبارسنجی عادی

   1. دریافت فریم جدید

   2. رمزگشایی Encrypted Block → استخراج Counter

   3. بررسی:

   abs(received_counter - stored_counter) ≤ WINDOW_SIZE


   معمولاً WINDOW_SIZE = 16

   4. اگر درست باشد → عملیات انجام شود + ذخیره Counter جدید

   4.3 حالت Resync (همگام‌سازی مجدد)

   • اگر Counter خارج از پنجره کوچک باشد اما داخل پنجره بزرگ (۱۰۰۰–۶۵۵۳۵)

   • گیرنده Counter را به مقدار جدید به‌روزرسانی می‌کند

   • این مکانیزم اجازه می‌دهد ریموت حتی اگر دکمه‌ها زیاد فشرده شوند، دوباره همگام شود

   ---

   5. نقاط ضعف HCS300

   ضعف	توضیح
   کلید ۶۴ بیتی ضعیف	قابل حمله Brute Force یا Side-Channel در تئوری
   Resync Window بزرگ	امکان جلو بردن Counter توسط مهاجم
   Manufacturer Key لو رفته	همه ریموت‌ها در سیستم‌های قدیمی قابل کلون شدن
   عدم احراز هویت دوطرفه	گیرنده نمی‌تواند ریموت را تأیید کند

   ---

   6. حمله RollJam روی HCS300

   • بسیار سخت‌تر از سیستم‌های ساده

   • پنجره Resync محدود (۱۰۰۰–۶۵۵۳۵)

   • گیرنده فقط یک بار Resync انجام می‌دهد

   • اگر دو سیگنال متوالی ضبط شود، کد قدیمی پذیرفته نمی‌شود

   نتیجه: HCS300 نسبتاً امن است و برای کاربردهای خانگی و پارکینگ مناسب است.

   ---

   7. خلاصه

   • فریم واقعی ۶۶ بیت:
     Serial (28) + Button (4) + Encrypted (16) + Status (2)

   • الگوریتم: KeeLoq با کلید ۶۴ بیتی

   • امنیت: مقاوم به Replay، آسیب‌پذیر به Resync Abuse و لو رفتن کلید

   • Resync: پنجره کوچک (۱۶) + پنجره بزرگ (تا ۱۰۰۰+) برای همگام‌سازی

   اگر کد قدیمی باشد → رد می‌شود (Replay Attack خنثی می‌شود).

🆙 HCS500 – نسل پیشرفته

• رمزنگاری AES
• احراز هویت دوطرفه
• مدیریت کلید پویا
• ثبت لاگ امنیتی
• قفل در صورت حمله مکرر

مناسب برای: خودروهای مدرن، سیستم‌های بانکی و صنعتی

📡 ماژول Manchester RF در ESP32 (EVM)

این ماژول قادر است:

• دریافت سیگنال RF
• Decode Manchester
• تشخیص خودکار پروتکل
• تحلیل Keeloq
• ذخیره پالس خام

پروتکل‌های پشتیبانی شده: HCS300 / HCS200 / RC5 / SIRC

📘 ماشین مجازی EVM (Embedded Virtual Machine)

📌 EVM چیست و چرا ساخته شد؟

• منطق برنامه جدا از Firmware اجرا می‌شود
• امنیت و توسعه سریع‌تر
• امکان آپدیت بدون Reflash کامل

معماری داخلی

JavaScript App → EVM Runtime Engine → Secure API Layer → Hardware Abstraction → ESP32 Firmware

اصل مهم: هیچ اسکریپتی مستقیماً به سخت‌افزار دسترسی ندارد

🔒 مدل امنیتی  JS for ESP32 EVM

1. جداسازی حافظه (Sandbox)
2. محدودیت API
3. کنترل زمان اجرا (Watchdog, RAM limit)

🧩 احراز هویت (Authentication)

• سطح ۱: بر اساس شناسه (ID-Based)
  

  

• سطح ۲: Stateful، ذخیره آخرین کد معتبر
• سطح ۳: Challenge / Response
• سطح ۴: Hybrid (RF + زمان + شمارنده + رفتار کاربر)

🚗 کاربرد EVM در سیستم پارکینگ

• مدیریت هویت دیجیتال خودروها
• تصمیم‌گیری امنیتی توسط EVM، نه RF
• کنترل کامل نرم‌افزاری و قابلیت تغییر سیاست‌ها بدون تغییر سخت‌افزار

📡 تحلیل RF در EVM

• Manchester Decode
• استخراج فیلدها
• تشخیص نوع پروتکل
• تحلیل امنیتی

🖥️ رابط گرافیکی LVGL

• مدیریت کاربران
• افزودن / حذف مجوز
• نمایش لاگ و وضعیت سیستم

همه UI در JavaScript نوشته می‌شود

✅ جمع‌بندی

• EVM یک پلتفرم امنیتی حرفه‌ای است
• احراز هویت در EVM قابل طراحی و توسعه است
• RF فقط لایه فیزیکی، تصمیم نهایی با EVM است
• مناسب پارکینگ، خودرو، HMI، ترموستات و IoT

کلمات کلیدی: ماشین مجازی EVM، Embedded Virtual Machine، EVM ESP32 JavaScript، احراز هویت در سیستم‌های امبد، EVM Security Authentication

📚 منابع و مراجع

•  پروتکل‌ها و تایمینگ‌ها
• Keeloq Microchip
• EV1527 / PT2262 دیتاشیت‌ها