Основные данные высокой производительности аутентичность
(я не носитель языка и, возможно, не прав в терминологии. Сожалеть об этом.)
Я передаю данные по радио между микроконтроллерами AVR для личного использования и хотел бы, чтобы клиенты продемонстрировали подлинность передаваемых данных в том, что они исходят от одного из авторизованных клиентов. Это означает, что я не требую отказа и смогу заранее определить общий ключ. Я провел некоторые исследования по различным подходам и обнаружил, что мне нужно некоторая помощь в выборе того, что лучше всего соответствует моим требованиям.
Пожалуйста, поймите, что я не требую максимальной безопасности. Я просто хотел бы предотвратить проникновение потенциального соседа по сценарию kiddie в течение нескольких часов. Если бы взлом со средним потребительским снаряжением потребовал нескольких недель, начиная с сегодняшнего дня, я был бы в порядке.Сообщения, которые я передаю, довольно малы по размеру (не более 30 байт с полезной нагрузкой всего в несколько байт), и частота будет не больше более 30 сообщений / мин.
Одним из вариантов использования является детектор движения, посылающий сообщение по воздуху в блок обработки, который затем отправляет другое сообщение по воздуху на выключатель света. Пожалуйста, не зацикливайтесь на транспорте. Этот вопрос касается только достоверности данных.
Я запускаю клиент / серверное программное обеспечение (в C) на 20 МГц микроконтроллерах AVR с очень ограниченной флэш-памятью и оперативной памятью. Поэтому я ищу решение с небольшим размером кода и использованием оперативной памяти, обеспечивая при этом высокий уровень данных ставка.
Я провел тестирование производительности с помощью реализации MD5 (C), создающей хэши из 20-байтовых данных, и обнаружил, что это может быть слишком медленно. Я понимаю, что реализация MD5 сама по себе не решит эту проблему. Я провел тестирование только для оценки производительности хэширования.
Спасибо за комментарии
2 ответа:
Я бы использовал 128-битный AES для подписи сообщений. Вот отличный источник, который уже реализовал это для AVR, с полной документацией размеров и количества циклов, включая различные версии, которые торгуют размером / скоростью. http://avrcryptolib.das-labor.org/trac/wiki/AES
Если вас устраивает компромисс, вычислите CRC-32 или CRC-64 полезной нагрузки сообщения с секретным ключом, добавленным к концу (полезной нагрузки, а не контрольной суммы CRC). Оба конца могут сделать это с помощью одного и того же секретного ключа, чтобы получить один и тот же результат. Не уверен в точной хакабельности этого, но это точно не ноль.