Авторизация устройств

Всем привет,

Есть у меня своя поделка устройств, которые обмениваются с центральным ХАБом командами и данными по радиоканалу. Заморочился я зашифровать протокол обмена, чтоб данные не светились в эфире. Прикрутил алгоритм AES (либа от ST), все хорошо, теперь хочу еще усилить, дело в том, что у меня есть исполнительные устройства, например выключатель, которому посылается команда, так вот одинаковые данные зашифрованные AES тоже будут одинаковые что не составляет труда перехватить радио посылку и отправлять ту же самую команду но зашифрованную и устройство её примет и обработает. Какие мне видятся способы защиты:
<ul>- самое простое - посылать дополнительный случайный байт (два, три), который будет являться "шумом", тогда кодированные данные всегда будут разные, но все равно повторив одну такую посылку устройство её примет.
- посылать счетчик команд и не принимать команды, если этот счетчик не увеличивается или меньше чем ожидается, уже лучше, но нужно помнить последнюю команду и как-то синхронизироваться с хабом.
- использовать токен и сеансы (сессии) - при включении устройства оно посылает на ХАБ запрос, хаб генерит токен и отсылает его устройству, далее идет обмен данными, "подписаными" этим токеном (например CRC32). Токен протухает на ХАБе раз в N времени и нужно его заново генерить. Все это естественно еще шифруется AES. Вроде не сильно сложно. Но опять же - в пределах одного токена посылка для одной команды будет одинаковая.
- ваш вариант?</ul>

0

Мастер -> периферия.
М - выполнить команду (нюансы команды ниже)
П - выполнена команда, статус [], контрольный_код_следующей_операции (кк) [1]
Проходит время, надо выдать следующую команду.
М - выполнить команду, код доступа кк = [1]
П - выполнена команда, статус [], контрольный_код_следующей_операции (кк) [2]
...
М - выполнить команду, код доступа кк = [2]
При этом кк генерируются периферией рандомно. Не свой кк периферия принимать не должна, возврат статус=foytid + новый кк.
Придется добавить специальную команду - запрос текущего кк. Либо ввести ограничение, что команда _запрос_статуса_ М->П не требует кк, но возращает кк последующий операции.

0

я бы сделал nonce+counter+cmd завернутый в аес. счетчик с нуля, строго без пропусков. nonce достаточно длинный, чтобы быстро не угадать атакой рандома.
далее, нужна спец команда/ответ для генерации новой сессии, когда генерится новый nonce и сбрасывается счетчик. у нее, есессно, нет защиты от replay, но она и не нужна. все что можно сделать реплеем - небольшой DoS, но его ведь можно сделать просто заглушив канал, так что смысла нет.

т.о., реплей не работает, рандом не работает. от чего еще нужно защититься?

п.с. да, еще нужно чтобы всё это укладывалось в один блок аес;) иначе возможны куда более интересные варианты атаки:)

0

Для начала неплохо было бы разобраться с тем кто Вас ломать будет. Будет ли он иметь доступ к коду и исходникам и насколько серьезен и финансово оправдан будет его интерес поломать посылки.
Может и не надо так сильно заморачиваться?
Дальше надо уточнить и разобраться с режимами шифрования AES.
Если заморачиваться, то можно использовать те у которых помимо ключа есть IV на входе. Изменение которого полностью изменит посылку.
А уж как передать его вместе с посылкой или изменять в соответствии с ее номером - отдельная задача.
Как-то так, на первый взгляд.

0

Сообщение от otirt80 Дальше надо уточнить и разобраться с режимами шифрования AES.

Режим шифрования это общая тема для всех блочных шифров.
https://ru.wikipedia.org/wiki/%D0%A0%D0 ... 0%B8%D1%8F
Самый простой с IV это CBC. Но надо учитывать его особенность - при replay атаке, только первый блок повтора будет битым.

0