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