Учитывая тип инструментов, о которых вы упомянули, имеющих доступ (HTTP / JSON), я предлагаю взглянуть на JOSE, который является стандартным способом подписывания и шифрования данных такого типа. В частности, вас заинтересуют JWE , JWS и JWT . Кривая обучения для JOSE, к сожалению, несколько крутая, а документы довольно скудные, но она достаточно эффективна и реализована на различных платформах и избавит вас от головной боли при изобретении ваших собственных протоколов (что довольно сложно сделать правильно ). Мне очень повезло с созданием пользовательских систем вокруг JOSE.
Есть несколько ключевых вопросов, которые вам нужно задать:
Вам нужна взаимная аутентификация или только аутентификация? устройства? Если устройство только пишет и никогда не читает, то вам, скорее всего, потребуется только аутентифицировать устройство, а не сервер.
Можете ли вы принять на себя риск, связанный с тем, что один общий секретный ключ будет встроен в устройства? Проблема с одним общим секретом заключается в том, что если какое-либо устройство подвергается обратному проектированию, вся защита теряется до тех пор, пока вы не отключите все устройства с этим ключом.
Можете ли вы принять стоимость изготовления секрет для каждого устройства? В зависимости от вашего производственного процесса генерация уникального секрета для каждого устройства может быть затруднена.
Можете ли вы принять требования к месту на устройстве и требованиям к обработке сертификата клиента? Если нет, можете ли вы принять логистику ведения серверной базы данных ключей каждого устройства? (Если вы не можете исключить ни то, ни другое, вам придется go с одним общим секретом для всей системы.)
Мне кажется, что вы говорите об устройстве это может обработать сложность клиентского сертификата, но не полный стек HTTPS. Если вы также можете справиться со сложностью создания сертификата во время производства или ваши клиенты готовы зарегистрировать свои устройства, то я рекомендую следующее:
Во время изготовления или регистрации создайте сертификат и подписание запроса. Отправьте его на сервер для подписи и установите подписанный X.509 на устройстве. (Генерация CSR на устройстве также возможна, но многим маленьким устройствам не хватает энтропии для генерации приличного случайного числа. В любом случае возможны компромиссы.)
Создание сертификата для сервера и установите его ключ publi c на всех устройствах.
Если предположить, что объем отправляемых данных невелик, я бы связал их все в JWT (веб-токен). ), зашифрован на публичный ключ c сервера и подписан закрытым ключом клиента. Обычно JWT используются для обмена аутентификационной информацией, но на самом деле это просто стандартный контейнер для отправки подписанных и зашифрованных JSON данных, поэтому они действительно могут быть любыми.
In Чтобы предотвратить повторные атаки, сервер должен отслеживать сообщения, которые он видел раньше. Есть два основных подхода, которые мне нравятся, в зависимости от вашей ситуации:
Сделайте jti (JWT ID) комбинацией метки времени и случайного значения (в этом случае серверу просто нужно сохранить кэш последних JTI и отклонить слишком старые временные метки)
Сделать jti комбинацией идентификатора устройства и монотонно увеличивающегося идентификатора сообщения. Затем сервер должен отслеживать идентификатор последнего увиденного сообщения для каждого устройства и отклонять любые идентификаторы, меньшие или равные этому.
Если вам не нужно шифрование, посмотрите на JWS, который просто подписывает данные. Ни один из этих методов не требует шифрования, и это немного проще, если вы уберете эту часть (например, вам не нужен сертификат сервера). Вы по-прежнему можете запретить повторы и разрешить подключение только доверенным клиентам. Кто-то может перепроектировать ваше устройство и получить сертификат клиента. Преимущество клиентского сертификата заключается в том, что если вы обнаружите злоупотребление, вы можете просто запретить этот один сертификат. С общим секретом вы не сможете этого сделать.
Основным преимуществом всего этого является то, что JOSE основан на JSON, который вы уже понимаете и знаете, как анализировать и работать. с. Но он также достаточно компактен для строкового протокола. Он также чрезвычайно гибок с точки зрения алгоритмов, что значительно упрощает его реализацию на небольшом оборудовании. Вы можете создать все то же самое вручную, используя открытые / закрытые ключи, но JOSE уже продумал многие хитрые проблемы безопасности.
Если бы это было лучше задокументировано ....