Безопасная аутентификация по слабому ключу без утечки информации

Мы изучаем проблему аутентификации, основанной на слабом ключе, в теоретико-информационной области. Ключ называют слабым, если его мин-энтропия — произвольная малая доля его битовой длины. Этой проблеме в последнее время уделяют значительное внимание, с помощью различных решений оптимизируя различные параметры. Мы рассматриваем данный вопрос в широком смысле, где слабый ключ — одноразовый сессионный ключ, полученный от публичного источника случайным образом с помощью (потенцильно тоже слабого) долгосрочного ключа. Наша задача в настоящий момент — аутентифицировать сообщение с помощью слабого сессионного ключа таким способом, чтобы не произошло (почти) никакой утечки информации долгосрочного ключа. Обеспечение конфиденциальности долгосрочного ключа жизненно важно для его вторичного использования. Предыдущая работа не считается такой проблемой конфиденциальности, и прошлые решения не выглядят удовлетворяющими этим требованиям. Мы покажем существование практического четырёхэтапного протокола, обеспечивающего аутентификацию сообщений слабым сессионным ключом, и избегающего незначительных утечек долгосрочного ключа. Безопасность нашей схемы также принимает во внимание моменты, где злоумышленник может ограничиться частичной информацией слабого сессионного ключа. Как применение нашей схемы, мы покажем существование идентификационной схемы в ограниченной квантовой(порционной) модели хранения, противостоящей атаке man-in-the-middle(встраивание) и имеющей чисто парольную основу: она не нуждается в ключе с высокой энтропией, в противоположность схеме, предложенной Дамгардом и другими.

Введение

Рассмотрим проблему достижения аутентичной коммуникации через общественный канал, который может находиться под контролем активного злоумышленника. Мы изучаем эту проблему в информационно-теоретической области, т. е. мы полагаем, что злоумышленник не ограничен в вычислительных средствах. Конкретно, мы рассмотрим следующий сценарий. Алиса и Боб имеют долгосрочный ключ W. При необходимости Алиса и Боб могут извлечь слабый сессионный ключ Xw из вспомогательного источника случайных чисел с помощью W. Свойствами такого источника гарантируется, что потенциальный злоумышленник Ева, не знающий W, имеет ограниченную информацию о слабом сессионном ключе Xw. Это формализуетс я требованием Hmin (Xw|W E) ≥ k для некоего параметра k, где E обозначает информацию на стороне Евы. Примеры, в которых данный сценарий имеет место естественным образом, ограничены моделью хранения, где W определяет, какую часть огромной строчи читать, или частичной областью, где W определяет, в каком базисе измерять некое квантовое состояние. Теперь стоит задача проверить подлинность сообщения μ от Алисы Бобу с помощью слабого сессионного ключа Xw, таким образом, чтобы (1) Ева не могла исказить его, не будучи замеченной, и (2) Ева не узнала никакой информации о долгосрочном ключе W. Мы подчёркиваем, что свойство (2) жизненно необходимо Алисе и Бобу для того, чтобы в дальнейшем использовать ключ W. Заметим, что использовав аутентификацию слабым ключом, Алиса и Боб могут также заключить ключевое соглашение, просто стандартно случайным образом производя извлечение, где источник экстрактора связано подтверждённым образом. Мы хотим подчеркнуть, что, по предположению, каждый новый Xw ключ сеанса для того же самого долгосрочного ключа W содержит новую случайность, обеспечиваемую вспомогательным источником. Следовательно, выше описанная задача не противоречит хорошо известной невозможности аутентификационного ключа без обновления. Заметим также, что мы не указываем, как точно вспомогательный источник случайности создаёт Xw из W; вопреки этому мы хотим безопасности независимо от того, как Xw был получен, как только Xw содержит достаточно ми-энтропии (данной информацией злоумышленника и ключом W).

Пусть n — битовый размер ключа (в нашем случае, ключа сессии) и k — его мин-энтропия (в битах). Додисом и Вичсом доказано, что неинтерактивная аутентификация невозможна, когда k ≤ n/2, даже в том случае, когда стороны имеют доступ к локальному источнику случайности, который мы будем предполагать. Авторство первого протокола интерактивной аутентификации для произвольного слабого ключа принадлежит Реннеру и Вулфу. Требуется Θ (l) раундов взаимодействия для проверки подлинности сообщения длиной l –бит. В случае [1] аутентификационный протокол для произвольного слабого ключа описан так, что требуется всего два раунда, что является оптимальным (с точки зрения количества раундов). Чандран и другие [2] делают акцент на минимизации энтропийной потери и описывают протокол усиления конфиденциальности, оптимальной с точки зрения энтропийной потери (с точностью до констант). Их конструкция требует линейного числа раундов (линейного в параметрах безопасности). Случай, в котором Алиса и Боб имеют высоко-коррелированные, но возможно, неравные ключи – “нечёткий” случай – решён в [3] и улучшен Канукурти и Рейзином [4] , но также покрывается [1] и [2] . Мы подчеркиваем, что ни одна из этих работ не может решить случай, когда слабый ключ получен из долгосрочного ключа и где сохранность долгосрочного ключа должна быть гарантирована.

Мы предлагаем новый четырёх-раундовый протокол аутентификации сообщений со слабым сессионным ключом Xw . Мы докажем, что наш протокол удовлетворяет требованиям безопасности и приватности долгосрочного ключа, имея ввиду, что злоумышленник Ева не может подделать аутентифицированное сообщение, не будучи обнаруженной, и не может получить никакой сколько угодно малой информации о долгосрочном ключе W . Наши доказательства также применяются в частном случае, когда ограниченные знания Евы о Xw могут находиться в форме квантового состояния. Также мы обсудим, как наша техника может быть применена в случает нечёткости, где существуют ошибки между слабыми сессионными ключами Алисы и Боба. Наконец, мы подчеркнём, как наша схема может быть использована для улучшения существующей идентификационной схемой с парольной основой в модели ограниченного частичного хранилища (более детально применение описано ниже).

Наше главное применение заключается в парольной идентификации на ограниченной квантовой модели хранения, предложенной Дамсгардом и другими. Две идентификационные схемы были предложены в [5] , Q-ID, защищённая только от злоумышленных Алисы и Боба, и Q-ID + , которая также защищена против MITM атак. Тем не менее, только Q-ID на самом деле имеет парольную основу; в Q-ID+ Алиса и Боб, в дополнение к паролю, должны делить ключ с высокой энтропией. Включением наших новых технологий в Q-ID + , мы покажем существование действительно парольной идентификационной схемы ы ограниченной квантовой модели хранения с защитой от MITM атак. Основываясь на Q-ID + , Дамгард и другие также предложили схему распространения аутентифицированного частичного ключа в ограниченной квантовой модели хранении, которая, по сравнению со стандартной схемой распространения частичных ключей, не требует аутентифицированной коммуникации, но имеет встроенную проверку подлинности. Наша релаксация на требуемый ключевой материал в Q-ID + влияет на схему распределения ключей и обходит необходимость в ключе с высокой энтропией. Как результат, мы получаем схему распределения парольных аутентификационных ключей в ограниченной модели хранения.

Статья имеет следующую структуру. В секции 2 мы представляем нотацию, даём некоторые стандартные определения и представляем требования безопасности, которым должен удовлетворять наш протокол. Затем, в Секции 3, мы описываем существующий протокол аутентификации, которым мы берём за основу нашего протокола. Также мы поясняем, почему существующий протокол не удовлетворяет нашим требованиям по безопасности и обсуждаем шаги по улучшению протокола. В конечном этоге мы приходим к нашему собственному протоколу AUTH, представленному в Секции 4. В этой же секции мы приводим важную лемму, используемую в доказательстве безопасности для борьбы с определёнными трудностями. Секция 5 состоит из доказательств безопасности и приватности. В секции 6 мы утверждаем, что наш протокол может быть использован в нечётких случаях, и, наконец, в секции 7 обсуждаем наше приложение. Больше информации, связанной с инсталляцией нашего протокола можно найти в полной версии статьи [6] .