Информацию о том, как настроить и использовать подпись, см. на сайте документации API. Иногда, некоторые изменения публикуются на бета-ветке (ветвь развития) библиотеки. По этой причине документация подписей содержится в исходниках, чтобы гарантировать, что они обновятся с кодом. Здесь вы найдете документацию для последней официальной версии и документацию для последней беты.
Ниже приведена некоторая справочная и теоретическая информация.
Предыстория и концепции
Предположим, что два участника, Алиса и Боб, хотят обменяться сообщениями. Алиса посылает сообщение Бобу. В представлении MySensors Алиса может быть шлюзом, а Боб — исполнительным узлом (выключатель света, электронный замок и т. д.). Но чтобы быть универсальным, мы заменим термин «шлюз» на Алиса и «узел» на Боб (хотя обратная связь также возможна).
Алиса посылает сообщение Бобу. Это сообщение может услышать любой, кто может слушать (а также любой, кто находится в пределах «слышимости»). В обычных случаях это так и есть. Ничто из сказанного Алисой для Боба не может быть секретным. Однако иногда (или, возможно, всегда) Боб хочет быть уверен, что сообщение, которое он получает, действительно пришло от Алисы. В криптографии это называется аутентичностью. Бобу необходимо определить способ аутентификации сообщения от Алисы, когда его получит. Это предотвращает подслушивание. Ева — может обмануть Боба, сделав вид, что это сообщение от Алисы. Бобу необходимо определить было ли услышанное сообщение повторено кем то другим. Ева могла запомнить услышанное сообщение, отправленное Алисой для Боба, а затем снова отправить тоже сообщение. Ева может также каким-то образом помешать Бобу получить сообщение или задержать его, чтобы сообщение для Боба не дошло, чтобы Ева могла подменить сообщение. Такая атака известна как атака повтора. Аутентичность позволяет Бобу определять, является ли Алиса истинным отправителем сообщения.
Бобу также нужно знать, что сообщение Алисы, не было подделано. Это называется целостность сообщения. Теперь мы представим Мэллори, который мог бы перехватить сообщение между Алисой и Бобом и заменить некоторые части сообщения, но сохранить те части, которые аутентифицируют сообщение. Таким образом, Боб по-прежнему будет доверять сообщению Алисы, но содержимое сообщения было изменено. Боб должен уметь определить, что содержимое сообщения не было изменено. Мэллори в этом случае называется «Атака посредника» или атака «человек посередине». Целостность позволяет Бобу проверить, что сообщения, полученные от Алисы, не были подделаны. Это достигается добавлением подписи к сообщению, которое Боб может проверить, чтобы удостовериться, что Алиса является автором.
Используемая схема подписи должна учитывать оба сценария атак. Ни Еве, ни Мэллори не должно быть позволено вмешиваться в обмен сообщениями между Алисой и Бобом.
Основная задача внедрения схемы безопасного подписания состоит в том, чтобы гарантировать, что каждая подпись отличается от другой, даже если это сообщение отсутствует. По этому повторить атаку будет очень сложно. Один из способов сделать это — увеличить счетчик на стороне отправителя и включить его в подпись. Правда это предсказуемо. Лучшим вариантом было бы ввести в подпись случайное число. Таким образом, невозможно предсказать, что будет подписью. Проблема в том, что это не позволяет Бобу проверить правильность подписи. Решение этого состоит в том, чтобы позволить Бобу генерировать случайное число, хранить его в памяти и отправлять его Алисе. Алиса может затем использовать случайное число в вычислении подписи и отправить подписанное сообщение обратно Бобу, который может проверить подпись с использованием случайного числа. Это случайное число в криптографии, известное как nonce или salt.
Тем не менее, Мэллори может перехватывать сообщение и отслеживать одноразовый код, чтобы создать новую действительную сигнатуру (подпись) для другого сообщения. Чтобы противостоять этому, Алиса и Боб скрывают, что знают только они. Эта тайна никогда не передается по воздуху, и никому она не открыта. Этот секрет известен как предварительный общий ключ (PSK).
Если Ева или Мэллори действительно профессионалы, они могут использовать отложенную атаку повтора. Это можно реализовать, разрешив Бобу передать nonce Алисе. А когда Алиса передает уникально подписанное сообщение, Мэллори может помешать Бобу получить это сообщение, и подменить его. Здесь описан пример такой атаки. Как решить проблему этой атаки? Заставить Боба отслеживать время между переданным одноразовым и подписанным сообщением для проверки. Если Бобу дают такое задание, Боб знает, что подписанное сообщение поступит «скоро». Боб может понять, что если подписанное сообщение не приходит в течение предопределенного времени, то Боб отбрасывает сгенерированное одноразовое число и не проверяет сообщение, если оно задерживается.
Обмен может быть описан следующим образом:
Поддержка этих алгоритмов MySensors очевидны. Никто не хочет, чтобы другие могли управлять их домом.
Почему шифрование не нужно для этого
Ну, некоторым может не понравится, когда кто-то может отслеживать температуру, движение или изменения состояния замков в эфире. Подписание не решает эти проблемы. Для предотвращения этого требуется шифрование. Моя личная точка зрения заключается в том, что шифрование не должно быть частью «протокола» MySensors. Причина в том, что шлюз и узел на самом деле не должны заботится о том, чтобы сообщения были «другими». Имеет смысл, что такие гарантии обеспечиваются базовым уровнем передачи (в данном случае RF-решением). Информация, передаваемая по воздуху, должна быть секретной (если пользователь этого пожелает). Уровень «доверия», с другой стороны, должен быть полностью написан в эскизе (в котором могут быть разные требования доверия в зависимости от участка сообщения), и по этой причине более важно (и менее сложно) обеспечить подлинность и целостность на уровне протокола, так как содержимое сообщения все еще доступно для чтения в стеке протоколов. Но как только сообщение покидает «стек», оно может переместиться в «мусор» при передаче по воздуху, а затем снова получено принимающим узлом до того, как оно будет «удалено» из стека на принимающей стороне.
Существуют методы и возможности для обеспечения шифрования также в программном обеспечении, но если это сделано, то я рекомендую, чтобы это было сделано после того, как в сообщение было отправлено сообщение о целостности и аутентификации (если это необходимо). Целостность и аутентификация, конечно, не являются обязательными, и некоторые могут быть довольны только тем, что имеют шифрование, чтобы покрыть их потребность в безопасности. Тем не менее, я сосредоточил внимание только на целостности и аутентичности, сохраняя в то же время существующие механизмы маршрутизации сообщений, и поэтому оставляю вопрос о секретности для реализации в «физическом» транспортном уровне. С целостностью и аутентичностью, выполняемой в протоколе, этого должно быть достаточно для простого шифрования (non-less AES с PSK например) в сообщении, так как оно отправляется на RF-backend. Atmel также предоставляет такие схемы, но я еще не исследовал этот вопрос, так как он с учетом того, что текущий размер эскиза Ethernet-шлюза близок к пределу размера на Arduino Nano, поэтому будет трудно вписать это в некоторые существующие конструкции шлюза. Также стоит учитывать, что состояние блокировки можно так же легко определить, просто просмотрев дверь или пытаясь ее открыть, поэтому утаивание этой информации никоим образом не сможет сдерживать злоумышленника. Тем не менее, я действительно признаю, что люди находят факт, что вся информация отправляется «в ясном» виде, даже если это требует некоторых технических усилий, чтобы злоумышленник мог получить и проверить эту информацию. Поэтому я рекомендую использовать шифрование транспортных слоев. Однако это не распространяется на эту реализацию.
Как это реализовано
Существует множество форм решений для подписи сообщений для борьбы с Евой и Мэллори. Большинство этих решений являются довольно сложными в плане вычислений, поэтому я решил использовать алгоритм, который может обрабатывать внешняя схема. Это имеет дополнительное преимущество в защите любых ключей и промежуточных данных, используемых для расчета подписи, так что даже если кто-то украл датчик и разобрал его, он не смог бы извлечь ключи и другую информацию с устройства. Общая схема подписи сообщений (подлинность и целостность) реализована с использованием HMAC, который в сочетании с сильной хэш-функцией обеспечивает очень высокий уровень защиты. Atmel ATSHA204A — это недорогая низко вольтная, мало мощная микросхема, которая обеспечивает возможности расчета HMAC с хешированием SHA256, она имеет (в настоящее время) устойчивый алгоритм защиты. Если бы SHA256 были взломаны, определенная криптовалюта сразу же оказалась бы бесполезной. Устройство ATSHA также содержит генератор случайных чисел (RNG), который позволяет генерировать хороший, непредсказуемый nonce. Поскольку я признаю, что многие, не хотят использовать дополнительную внешнюю микросхему, я также реализовал версию программного обеспечения устройства ATSHA, способную генерировать те же сигнатуры, что и устройство ATSHA. Поскольку это программная упрощённая реализация, она не обеспечивает настолько непредсказуемый nonces (он использует псевдослучайный генератор Arduino), а ключ HMAC хранится в SW и поэтому может быть считан. Это требует больше места на флэш-памяти, из-за дополнительного программного обеспечения, но для внутренних датчиков и/или исполнительных механизмов этого может быть достаточно для большинства людей.
Техническое описание
Какой формат у сообщений с подписями? На следующем рисунке показано, какая часть сообщения подписана и где хранится подпись:
Первый байт заголовка не покрывается сигнатурой, поскольку в сети этот байт используется для отслеживания переходов в сети и, следовательно, может измениться, если сообщение передает узел-ретранслятор. Таким образом, это не может быть частью подписи или подпись будет недействительной, когда достигнет места назначения. В сигнатуре также содержится байт с идентификатором подписи, чтобы предотвратить ложные результаты случайного смешивания несовместимых внутренних подписок в сети. Таким образом, максимальный размер полезной нагрузки составляет 29-7 байт. Невозможно подписать данные большего размера. Другое дело, что сложность подписи обратно пропорциональна размеру данных.
Для программного метода, ATSHA не выполняет «ванильную» HMAC-обработку. К счастью, Atmel точно описал, как схема обрабатывает данные и хэши, что позволяет генерировать сигнатуры, идентичные сигнатурам, генерируемым схемой.
Подписи вычисляются следующим образом:
Как именно это сделать, можно просмотреть в источнике для ATSHA204SOFT backend и ATSHA204A. В протоколе MySensors следующие внутренние типы сообщений обрабатывают требования к подписи и запросы nonce: I_SIGNING_PRESENTATION, I_NONCE_REQUEST, I_NONCE_RESPONSE
Кроме того, поле версии в заголовке было сокращено с 3 до 2 бит, чтобы этот один бит указывал, что сообщение подписано.
Известные ограничения
Из-за ограничивающего фактора наших самых дешевых узлов Arduino использование разнообразных ключей не реализовано. Это означает, что все узлы в вашей сети используют один и тот же PSK (по крайней мере те, которые должны обмениваться подписанными данными). Важно понимать последствия этого, и это описано в главе «Типичные варианты использования» ниже. Также следует помнить, что сложность подписи обратно пропорциональна размеру сообщения. Чем больше сообщение, тем слабее подпись.
Перевод ориентальной статьи https://www.mysensors.org/about/signing
