ReitingPro & Xarn
Я тут нашел умный замок, который работает на искусственном интеллекте, говорит, сама следит за доступом. Хочешь вместе покопаемся в его прошивке и проверим, как он в реальности?
Конечно. Начнём с того, что нужно снять прошивку с устройства. Если там кастомная ОС, поищи проверку подписи загрузчика. Если это просто образ микроконтроллера, проверь, зашумлена ли прошивка или просто в открытом виде. Сравни хеш с информацией о релизе от производителя — любая несовпадение сразу говорит о проблеме.
Дальше, протестируй механизм обновления по воздуху. Слабый challenge-response или предсказуемый nonce – это просто находка. Проверь схему шифрования: используется ли AES-128 в режиме CBC со статическим IV? Это недопустимо.
Потом, проанализируй процесс аутентификации. Если замок принимает 4-значный ПИН-код или Bluetooth-сигнал без взаимной аутентификации, это открывает двери для атак повторного воспроизведения.
На аппаратном уровне, проверь наличие открытых последовательных портов, отладочных пинов или отладочных UART, которые могли быть случайно оставлены включёнными. Они могут позволить местному злоумышленнику выгрузить прошивку или изменить частоту тактирования.
И, наконец, проведи side-channel тест: напряжение кабеля питания и время выполнения. Если задержка механизма замка меняется в зависимости от входных данных, можно вывести секретные ключи.
Если ты обнаружишь хоть один из этих признаков, замок представляет угрозу безопасности. Если все проверки пройдены, то это, по крайней мере, хорошая отправная точка - но следи за обновлениями прошивки; злоумышленники всегда будут искать лазейки.
Звучит как хороший план. Только не забудь записывать каждую ошибку контрольной суммы – по ним я и иду по следу. И помни, если процесс обновления выглядит как детская утренняя зарядка, значит, что-то не так. Держи отладочные UARTы выключенными, если не хочешь услышать неожиданного докладчика из самого прошиваемого кода.
Поняла, всё под контролем. Буду отслеживать любые сбои с контрольными суммами и закрою отладочные UART-порты на замок – если, конечно, не хотим, чтобы прошивка болтала с нами. Если OTA-рукопожатие будет напоминать диктант в детском саду, сразу же сформулирую проблему одним предложением. Давай уже разблокируем этот лок.
Хорошо, сейчас загружаю прошивку. Как только будет образ, я рассчитаю хеш, проверю подписи загрузчика и начну искать зашифрованный или открытый код. Если что-то покажется подозрительным, я сразу сообщу. Посмотрим, какие тайны скрывает этот замок.
Отлично. Следи за цепочкой хешей, дай знать, если увидишь незашифрованные ключи или слабую схему подписи. Я подготовлю логи, чтобы каждый странный байт был помечен. Эта блокировка ни в коем случае не должна что-то скрывать.
Похоже, подпись выглядит подозрительно – как будто подписано ключом RSA с длиной 1024 бита, и без временной метки. И чуть дальше я заметил строку из 32 байта, которая совпадает с известным AES-128 ключом в открытом виде. Это уже серьёзно. Буду копать дальше.
Это просто катастрофа. RSA-ключ с длиной 1024 бита уже устарел, а без метки времени невозможно даже доказать, что прошивка актуальна или не была изменена. А 32-байтовый AES-ключ в открытом виде – это как раздавать схему шифрования направо и налево всем, кто сможет прочитать образ. Не трать время на полировку комментариев. Вернись к поставщику, требуй полной ротации ключей и правильной подписи — идеально RSA с длиной 3072 бита или ECDSA с хешем, например SHA-256 — и настаивай на подписанном, отметченном по времени процессе OTA. Если они не смогут это исправить, этот замок – проблема.
Ты права – это серьёзные нарушения протокола. Я внесу это в систему отслеживания ошибок у поставщика и настоятельно потребуем использования правильных RSA‑3072 или ECDSA‑SHA256 подписей, плюс метку времени. Если они не смогут это исправить, мы будем считать это несоответствием и прекратим поставки. Спасибо за откровенность.