Основные данные высокой производительности аутентичность


(я не носитель языка и, возможно, не прав в терминологии. Сожалеть об этом.)

Я передаю данные по радио между микроконтроллерами AVR для личного использования и хотел бы, чтобы клиенты продемонстрировали подлинность передаваемых данных в том, что они исходят от одного из авторизованных клиентов. Это означает, что я не требую отказа и смогу заранее определить общий ключ. Я провел некоторые исследования по различным подходам и обнаружил, что мне нужно некоторая помощь в выборе того, что лучше всего соответствует моим требованиям.

Пожалуйста, поймите, что я не требую максимальной безопасности. Я просто хотел бы предотвратить проникновение потенциального соседа по сценарию kiddie в течение нескольких часов. Если бы взлом со средним потребительским снаряжением потребовал нескольких недель, начиная с сегодняшнего дня, я был бы в порядке.

Сообщения, которые я передаю, довольно малы по размеру (не более 30 байт с полезной нагрузкой всего в несколько байт), и частота будет не больше более 30 сообщений / мин.

Одним из вариантов использования является детектор движения, посылающий сообщение по воздуху в блок обработки, который затем отправляет другое сообщение по воздуху на выключатель света. Пожалуйста, не зацикливайтесь на транспорте. Этот вопрос касается только достоверности данных.

Я запускаю клиент / серверное программное обеспечение (в C) на 20 МГц микроконтроллерах AVR с очень ограниченной флэш-памятью и оперативной памятью. Поэтому я ищу решение с небольшим размером кода и использованием оперативной памяти, обеспечивая при этом высокий уровень данных ставка.

Я провел тестирование производительности с помощью реализации MD5 (C), создающей хэши из 20-байтовых данных, и обнаружил, что это может быть слишком медленно. Я понимаю, что реализация MD5 сама по себе не решит эту проблему. Я провел тестирование только для оценки производительности хэширования.

Спасибо за комментарии

2 2

2 ответа:

Я бы использовал 128-битный AES для подписи сообщений. Вот отличный источник, который уже реализовал это для AVR, с полной документацией размеров и количества циклов, включая различные версии, которые торгуют размером / скоростью. http://avrcryptolib.das-labor.org/trac/wiki/AES

Если вас устраивает компромисс, вычислите CRC-32 или CRC-64 полезной нагрузки сообщения с секретным ключом, добавленным к концу (полезной нагрузки, а не контрольной суммы CRC). Оба конца могут сделать это с помощью одного и того же секретного ключа, чтобы получить один и тот же результат. Не уверен в точной хакабельности этого, но это точно не ноль.