Регистрация Войти
Рейтинг:0
avatar Crypto

Использование общего секрета в качестве данных аутентификации Out-Of-Band при сопряжении Bluetooth

флаг br
obareey

Согласно спецификации Bluetooth, процесс сопряжения начинается с отправки ведомым устройством рекламного пакета, а затем ведущее устройство инициирует соединение. При аутентификации LE Legacy OOB предполагается, что секретный 128-битный временный ключ (TK) передается через какой-либо другой безопасный канал, например. NFC, который будет использоваться в аутентификации запрос-ответ, которая выглядит следующим образом:

  1. Мастер выбирает случайный Mrand и вычисляет Mconfirm = AES(TK, AES(TK, Mrand XOR p1) XOR p2)
  2. Ведомый выбирает случайный Srand и вычисляет Sconfirm = AES(TK, AES(TK, Srand XOR p1) XOR p2)
  3. Мастер отправляет Mconfirm
  4. Раб отправляет подтверждение
  5. Мастер отправляет Mrand, а Slave подтверждает
  6. Ведомый отправляет Srand, а Мастер подтверждает
  7. Краткосрочный ключ рассчитывается как STK = AES(TK, Srand[65:128] || Mrand[65:128])
  8. Дальнейшая связь шифруется с помощью STK.

где p1 и p2 содержат адреса Master и Slave, а также некоторую информацию о команде сопряжения и т. д.

Теперь предположим, что Master и Slave имеют общий секретный ключ (SK), который вшит в них на заводе. Я намерен отправить 128-битные случайные данные (RD) в рекламном пакете, чтобы обе стороны могли использовать их для вычисления TK как TK = AES(SK, RD). Я не встречал такого подхода больше нигде, и, насколько я понимаю, литературы по анализу OOB-аутентификации LE Legacy очень мало.

Итак, это правильный подход? Какие проблемы с этим?

Прочая связанная информация и предположения:

  1. Полезная нагрузка подключаемого рекламного пакета уже зашифрована и аутентифицирована через CCM с использованием другого ключа, а также с защитой от повторного воспроизведения с помощью счетчика и/или метки времени.
  2. Есть много мастеров и рабов, где мастера находятся в фиксированных местах, а рабы мобильны. Каждое ведомое устройство имеет уникальный SK, и главные устройства могут найти его в защищенной базе данных.
  3. Объединение нельзя использовать, потому что для аутентификации не должно быть никакого взаимодействия с пользователем, а ключи связывания не могут использоваться совместно мастерами.
  4. LE Secure Connections должен быть более безопасным, но требует взаимодействия с пользователем для аутентификации, которую мы не можем предоставить.
  5. Соединение будет производиться каждые 1-10 минут для каждого ведомого устройства.
49
1 + 0
Рейтинг:2
avatar Crypto
флаг us
Mikero

Это не кажется мне очень хорошим протоколом аутентификации. Вы можете просмотреть $(Mrand, \textsf{AES}_{TK}(\textsf{AES}_{TK}(Mrand \oplus p_1) \oplus p_2))$ как попытка рандомизированного CBC-MAC $p_1\|p_2$, с $Мранд$ являющийся вектором инициализации.

К сожалению, рандомизированный CBC-MAC полностью не работает как MAC. Предположим, противник видит действительный MAC $(R,T) = \bigl(R, \textsf{AES}_K(\textsf{AES}_K(R \oplus p_1) \oplus p_2)\bigr)$ сообщения $p_1 \| р_2$. Тогда он может производить $(R \oplus \delta, T)$ который является действительным MAC сообщения $(p_1 \oplus \delta) \| р_2$.

Помимо неудачной попытки получения MAC-адреса, этот протокол страдает от тривиальных атак воспроизведения. Каждая сторона выбирает случайное значение, которое влияет на только свои сообщения. Чтобы предотвратить повтор, каждая сторона должна привязать свои протокольные сообщения к случайному значению, выбранному Другие партия.

Есть даже отражение атаки. В этом протоколе, если мастер отправляет $Mrand, Mconfirm$ тогда клиент может ответить эхом $Срэнд=Мрэнд$ и $Sconfirm=Mподтвердить$, который должен быть проверен правильно, если в протоколе нет большего, чем вы упомянули.

Результатом этих атак является то, что одна конечная точка считает, что она успешно сопряжена, несмотря на то, что другая конечная точка не знает внеполосного ключа. $ТК$. Однако злоумышленник не может получить сеансовый ключ.

0 + 3
флаг br
obareey
Спасибо за ответ. Я еще раз проверил, из чего состоят p1 и p2. Оказывается, p1 содержит только параметры подключения, которые должны быть постоянными для всех подключений. Таким образом, мы можем игнорировать любую попытку подключения, если p1 отличается от ожидаемого. p2 включает в себя как главный, так и подчиненный адреса. Достаточно ли этого, чтобы предотвратить случайную проблему CBC-MAC?
0
Ответить
флаг br
obareey
TK изменяется для каждой сессии в соответствии со случайным значением, предоставленным ведомым устройством в рекламном пакете, и общим секретным ключом, который был предоставлен во время производства. Я предполагаю, что это предотвращает повторные атаки?
0
Ответить
флаг br
obareey
Я предполагаю, что атаку отражения можно предотвратить, проверив $Sconfirm \neq Mconfirm$ или $Srand \neq Mrand$? Я надеюсь, что это реализовано поставщиком стека. Я могу запросить патч, если он не реализован.
0
Ответить
флаг Moldova
Admin
Этот вопрос на других языках:

Ответить или комментировать

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