Коротко: ваша идея — классический challenge–response на общем секрете — в принципе лучше «статического кода» и ломкого Keeloq, но на практике такая простая схема не закрывает ряд реальных угроз и вызывает массу практических проблем (питание, хранение ключей, производство, сертификация, удобство, защита от ретрансляции и физического взлома). Именно поэтому «дешёво и надёжно» не так просто получить в массовом продукте.
Разберу по пунктам — сначала уязвимости и недостатки вашей схемы, затем почему рынок не внедряет более защищённые решения массово, и в конце — практичный набор рекомендаций для реальной реализации.
1) Что не так с предложенным протоколом
- Ретрансляция (relay attack). Протокол с challenge–response не защищает от ретрансляции: злоумышленник рядом с воротами перехватывает challenge R и мгновенно ретранслирует его кому‑то рядом с настоящим брелоком; тот вычислит ответ и злоумышленник доставит его на приёмник. Криптография тут бессильна без мер по проверке расстояния/времени.
- Нужна надёжная генерация и проверка «свежести». Если приёмник не помечает одноразовые nonces как использованные или не использует счётчик/окно, возможны повторы/реплеи. Если в сообщениях используются простые хеши вместо HMAC/AES‑MAC, возможны уязвимости.
- Экстракция ключа из устройства. Если ключ запрограммирован в ESP32/микроконтроллер без Secure Element, физический доступ к простому чипу/прошивке позволяет извлечь ключ — и тогда любой клонирует брелок.
- Прослушивание и подмена. Если хеш/ответ передаются в открытом виде, активный злоумышленник может сбивать/вставлять пакеты. Надёжный протокол должен быть аутентифицированным (HMAC/AES‑CMAC или AEAD).
- Отказ от обслуживания и DoS. Лёгкий способ заблокировать систему — глушение, частые неспецифические запросы, ввод таймаутов. Продукт должен корректно обрабатывать атаки и отказ в обслуживании.
- Энергопотребление и аппаратные требования. ESP32 (Wi‑Fi) — неудачный выбор для батарейного брелока: питание быстро сядет. Нужны радиомодули с ultra‑low‑power (BLE, proprietary 433/868 MHz с энергоэффективным RX/interrupt или Zigbee с оптимизацией).
- Размер/цена/сертификация. Добавление Secure Element, UWB и прочих защит увеличивает BOM, стоимость и сложность сертификации (FCC/CE), а производители дешёвых систем этого избегают.
- Производство и управление ключами. На millions‑scale нужно безопасно впаять/запрограммировать уникальные ключи, вести учёт, иметь процедуру восстановления/перепрограммирования — это логистика и расходы.
- Пользовательский опыт. Надёжность/удобство (быстрое срабатывание, простое сопряжение) часто важнее абсолютной криптобезопасности для массового покупателя. Сложные процедуры отпугивают клиентов.
2) Почему на рынке не массово «лучше» решение
- Стоимость. Добавление аппаратной защиты (secure element), UWB для противотеятельных атак, и сложной прошивки — повышение цены продукта. Большинство производителей выбирают минимально приемлемую безопасность.
- Рынок и риск. Для многих применений риск взлома считается низким (гараж чаще под видеонаблюдением, физическая защита и т.д.), и производители балансируют цена/функция/риск. Производители управляющих ворот/шлагбаумов часто не хотят брать на себя усложнённые процедуры или повышенные расходы.
- Сложность и сертификация. Новая радиосхема (Wi‑Fi/BLE/UWB) требует тестов, поддержки нескольких стран/частот, прошивок — всё это тормозит распространение.
- Инерция стандартов и притязания к совместимости. Старые системы с Rolling Code (Keeloq) распространены, заменять всю экосистему дорого и неудобно.
- Уязвимости чаще в реализации, а не в алгоритме. Даже AES‑HMAC в дешёвом устройстве можно реализовать неправильно или ключ вытекут через прошивку, GPIO, отладочный порт и т.д.
3) Что нужно сделать, чтобы реально получить «надёжный и дешёвый»
Если хотите сделать защищённый коммерчески жизнеспособный продукт, учтите эти аспекты.
Аппаратная часть:
- Используйте контроллеры/чипы с аппаратным Secure Element (например Microchip ATECC608A, Infineon OPTIGA) для хранения ключей и выполнения криптоопераций. Это препятствует извлечению ключей при физическом доступе.
- Для брелока — низкоэнергетичное радио: BLE (nRF52 с оптимизацией), или специальный суб‑ГГц модуль. Wi‑Fi/ESP32 — слишком «жоркий» для батарейки, но годится для приёмника на mains.
- Для защиты от ретрансляции используйте радио с измерением времени прохождения (time‑of‑flight) — UWB (802.15.4z) обеспечивает безопасное дистанцирование; RSSI/фингерпринтинг легко обманываются, поэтому малоэффективны.
Протокол (рекомендации):
- Используйте аутентифицированную криптографию: HMAC‑SHA256 или AES‑CMAC/AES‑GCM, ключ ≥ 128 бит.
- Протокол с синхронизацией счётчиков (rolling counter) или challenge–response с одноразовыми nonce и защитой от повторного использования: приёмник хранит последнее значение счётчика/использованные nonces.
- Для уменьшения времени отклика и энергопотребления — пусть брелок инициирует команду с включением минимального набора данных; приёмник отвечает, затем брелок вычисляет MAC и шлёт назад.
- При возможности используйте ECDH при первичном сопряжении + per‑session keys, но это требует больше вычислений.
- Всегда проверяйте правильность реализации (без «домысленных» схем) — используйте проверенные библиотеки.
Защита против ретрансляции:
- Лучшее решение — аппаратная проверка расстояния (UWB, distance bounding).
- Альтернативы: одноразовые подтверждения с временными метками — но их легко ретранслировать; RSSI/velocity checks помогают но не гарантируют безопасность.
- Для высокой безопасности — комбинируйте крипто‑аутентификацию с физическими мерами (сенсоры в воротах, механическая блокировка, наблюдение).
Производство и управление ключами:
- Внедрите защищённый процесс программирования ключей (secure provisioning), ведите уникальные ключи и их учёт.
- Подумайте по умолчанию об обновлении прошивки с цифровой подписью и механизме восстановления/смены ключей для утерянных брелоков.
Пользовательский интерфейс и отказоустойчивость:
- Учтите сценарии потери батарейки, замены брелока, отказа связи, DoS. Должен быть безопасный резервный доступ (ключ/код), но минимизирующий уязвимости.
- Логирование и лимит количества неудачных попыток, таймауты, блокировки и опциональные уведомления владельцу.
4) Конкретный рекомендованный стек для «ближайшего коммерчески реализуемого» варианта
- Радио: BLE Low Energy с LE Secure Connections (если защита от ретрансляции не критична) или UWB (для защиты от ретрансля).
- Ключи: уникальный симметричный ключ в Secure Element; HMAC‑SHA256/AES‑CMAC для MAC.
- Протокол: первичное сопряжение через ECDH (или заводская привязка ключа), затем короткие challenge–response с nonce и проверкой счётчика/one‑time. Сообщение формата: {ID, nonce, flags} + MAC.
- Защита от ретрансляции: если нужно — UWB distance bounding; иначе минимум — проверка времени реакции/счётчик + антиретрансляционная логика.
- Обновления: OTA с цифровой подписью; приёмник на mains, поэтому всегда online для обновлений.
5) Итог — почему «ваша простая схема» не уходит в массы
- Она улучшение по сравнению со статическим кодом, но не закрывает ключевые практические угрозы (ретрансляция, физический взлом устройства, управление ключами).
- Инженерно‑производственные и коммерческие ограничения (стоимость, батарея, сертификация, удобство) заставляют производителей выбирать компромисс.
- Чтобы получить действительно надёжный массовый продукт, нужно вложиться в secure element, сертификацию, качественную реализацию протокола и/или аппаратную защиту против ретрансляции — это уже не «пара строк кода» на ESP32.
Если хотите, могу:
- Нарисовать конкретный протокол‑схему (обмен сообщений с форматом, MAC, счётчиком, таймингом).
- Предложить перечень компонентов и примерную оценку стоимости BOM для брелока и приёмника.
- Описать процедуру безопасного производства/впаянного программирования ключей.
Какая из этих дополнительных задач вам интересна?