Недавно я ознакомился с реализацией AES в C для встраиваемых систем и пытался использовать ее в беспроводном соединении «точка-ко-многим точкам» (или «точка-точка» для начинающих).
Код корректно компилируется на моей платформе и, похоже, дает правильные результаты при использовании тестового кода, предоставляемого в режиме CTR, вплотную (этот режим CRT - то, что мне требуется, поскольку мои пакеты имеют размер 120 байтов каждый и не могут быть изменены).
По сути, передатчик Tx должен использовать функцию шифрования tiny-AES, чтобы генерировать непрерывный поток зашифрованных пакетов по 120 байтов каждый, передавать их с прикрепленным CTR и заголовком и т. Д., А также принимать и дешифровать надругой конец приемником Rx.
Предусматривается, что передатчик Tx и приемник Rx используют точно один и тот же крошечный код AES с тем же ключом, который известен только мне.Этот ключ может быть установлен и будет отличаться для разных пар Tx-Rx.
Мой вопрос касается, в частности, режима CRT и использования следующих функций как на Tx, так и на Rx:
/* Initialize context calling (iv can be NULL): */
void AES_ctx_init(AES_ctx *ctx, uint32_t keylen, const uint8_t *key, const uint8_t *iv);
/* ... or reset IV or key at some point: */
void AES_ctx_set_key(AES_ctx *ctx, uint32_t keylen, const uint8_t *key);
void AES_ctx_set_iv(AES_ctx *ctx, const uint8_t *iv);
Итак
- Какова цель
AES_ctx_init() и выполняется ли это только один раз в начале сеанса шифрования / дешифрования защищенной линии? - Чтоцель функции
AES_ctx_set_iv() и опять же, выполняется ли это только один раз в начале сеанса защищенного канала?Комментарий «... или сбросить IV или ключ в какой-то момент» мне не понятен - причина моего вопроса ... То есть когда нужно сбрасывать IV при использовании AES в режиме CRT? - Требуется ли для Tx и Rx использовать один и тот же IV, и можно ли оставить его как есть или его нужно менять при каждом новом сеансе защищенной линии?Я понимаю, что секретный ключ обычно выбирается для пары Tx / Rx и изменяется пользователем только на обоих при необходимости, но обычно он остается неизменным для каждого сеанса.Это вообще правильно?Является ли это случаем (или нет) для IV, и в какой момент можно сбросить IV?
В беспроводных линиях связи из-за шума, и если нет реализации FEC,получатель будет вынужден отбросить пакеты из-за неправильных CRC.В моей ссылке CRC проверяется для полученного 120-байтового пакета (один за другим, когда они получены), и начинается дешифрование для восстановления исходных данных, если CRC верен, но данные отбрасываются, если нет.Каковы последствия этого для потока зашифрованных пакетов Tx, поскольку они продолжают передаваться независимо от того, как не существует протокола дрожания рук, чтобы сообщить Tx, что Rx отбросил пакет из-за ошибки CRC, если таковая имеется?
Если ответы на эти вопросы существуют в виде дополнительной документации по крошечному AES, я был бы признателен за некоторые ссылки на него, так как предоставленные примечания предполагают, что люди уже знакомы с AES и т. Д.
ИтакВот некоторые дальнейшие комментарии и ответы, уже сделанные.По сути, пара Tx / Rx имеет заранее заданную структуру пакета с определенной полезной нагрузкой, CRC заголовка и т. Д., Но давайте назовем это «пакетом».Полезная нагрузка - это то, что мне нужно, чтобы зашифровать, и это установлено в 120 байтов, не подлежит обсуждению независимо, и это находится в пакете.Итак, вы говорите, что при каждой передаче пакета Tx и Rx должны будут изменять одноразовый номер с каждым пакетом, и оба Tx & Rx должны использовать один и тот же одноразовый номер с каждой обработкой пакета?
Скажем, я начинаю передачу, и у меня есть пакет (1), пакет (2)… пакет (n) и т. Д., Затем с каждым переданным пакетом мне нужно обновить «счетчик», и что и передатчик, и приемник должны быть синхронизированы так,что оба используют один и тот же nonce в сеансе?
Это может быть проблематично, когда и если из-за шума или помех система Tx / Rx теряет синхронизацию, как это может произойти, и каким-то образом два независимых счетчика дляnonce больше не синхронизируются и на одной странице, так сказать ... вообще session не потребует в среднем более 2 ^ 16 пакетов, так что вы можете обойти это?Как я уже сказал, вопрос об отправке другого одноразового номера с каждым отдельным пакетом полностью исключен, поскольку полезная нагрузка уже завершена и полна.
Другой способ, которым я подумал, возможно, вы можете пролить некоторый свет, если это можетработа, есть через GPS.Скажем, если у каждого Tx и Rx есть каждый модуль GPS (что имеет место), то информация о синхронизации может быть получена из часов GPS на обоих Tx и Rx, поскольку оба получат это независимо, и некоторый вид синхронизированного счетчика может быть переведен вобновить одноразовый номер на обоих, скажем, от 0 до 2 ^ 16 в сеансе ... вы согласны?Таким образом, даже если из-за шума / помех пакеты будут потеряны приемником, счетчик продолжит обновлять одноразовый номер с некоторой формой надежного «тика» в фоновом режиме…
Что касается источника энтропии, хорошоочевидно, ламповая схема обеспечит это для хорошего PRNG, работающего локально, скажем, для сеанса из 2 ^ 16 пакетов, но это еще не доступно в моей системе, но может быть, если мы решим пойти дальше…
Что вы думаете об этом как профессионал в этой области?С уважением,