Доверие при первом использовании - Trust on first use

Для использования в других целях см. Тофу (значения).

Доверие при первом использовании (TOFU), или же доверие при первом использовании (TUFU), является аутентификация схема[1] используется клиентским программным обеспечением, которому необходимо установить доверительные отношения с неизвестной или еще не доверенной конечной точкой. В модели TOFU клиент попытается найти идентификатор конечной точки, обычно либо открытый ключ идентификации конечной точки или отпечаток пальца указанного ключа идентификации в своей локальной базе данных доверия. Если идентификатор для конечной точки еще не существует, клиентское программное обеспечение либо предложит пользователю подтвердить, что он подтвердил, что предполагаемый идентификатор является подлинным, либо, если ручная проверка не предполагается возможной в протоколе, клиент просто будет доверять идентификатору, который был предоставлен и записать доверительные отношения в свою базу данных доверия. Если в последующем соединении от противоположной конечной точки будет получен другой идентификатор, клиентское программное обеспечение сочтет его ненадежным.

Реализации TOFU

в SSH протокол, большинство клиентского программного обеспечения (но не все[2]) при подключении к еще не доверенному серверу отобразит отпечаток открытого ключа сервера и предложит пользователю убедиться, что он действительно аутентифицировал его, используя аутентифицированный канал. Затем клиент запишет доверительные отношения в свою базу данных доверия. Новый идентификатор вызовет предупреждение о блокировке, требующее ручного удаления сохраненного идентификатора.

В Закрепление открытого ключа HTTP браузеры всегда будут принимать первый открытый ключ, возвращенный сервером, и с Строгая безопасность транспорта HTTP в котором браузеры будут подчиняться правилу перенаправления на время действия директивы age.

Клиент XMPP Разговоры использует Слепое доверие до проверки,[3] где всем идентификаторам слепо доверяют, пока пользователь не продемонстрирует волю и способность аутентифицировать конечные точки путем сканирования QR код представление идентификатора. После сканирования первого идентификатора клиент отобразит символ щита для сообщений от аутентифицированных конечных точек и красный фон для других.

В Сигнал конечные точки изначально слепо доверяют идентификатору и отображают неблокирующие предупреждения при его изменении. Идентификатор может быть проверен либо путем сканирования QR-кода, либо путем обмена десятичным представлением идентификатора (называемым Safety Number) по аутентифицированному каналу. Затем идентификатор можно пометить как проверенный. Это изменяет характер предупреждений об изменении идентификатора с неблокирующего на блокирующий.[4]

Например, в Джами и Рикошет идентификатор - это сам позывной пользователя. Обмен идентификаторами может осуществляться по любому каналу, но до тех пор, пока идентификатор не будет проверен по аутентифицированному каналу, ему фактически слепо доверяют. Смена идентификатора также требует изменения учетной записи, поэтому для атаки MITM для той же учетной записи требуется доступ к закрытому ключу конечной точки.

В WhatsApp конечная точка изначально слепо доверяет идентификатору, и по умолчанию при изменении идентификатора предупреждение не отображается. Если пользователь демонстрирует желание и способность аутентифицировать конечные точки, обращаясь к отпечатку ключа (так называемому «Код безопасности»), клиент предложит пользователю включить неблокирующие предупреждения при изменении идентификатора. Клиент WhatsApp не позволяет пользователю отмечать идентификатор как проверенный.

В Телеграмма В дополнительных секретных чатах конечные точки слепо доверяют идентификатору. Измененный идентификатор порождает новое окно секретного чата вместо отображения какого-либо предупреждения. Идентификаторы можно проверить, сравнив визуальное или шестнадцатеричное представление идентификатора. Клиент Telegram не позволяет пользователю отмечать идентификатор как проверенный.

В Keybase клиенты могут подписывать ключи друг друга, а это означает, что доверие к одному идентификатору позволяет проверять несколько идентификаторов. Keybase действует как доверенная третья сторона, которая проверяет связь между учетной записью Keybase и цепочкой подписей учетной записи, содержащей историю идентификаторов. Идентификатор, используемый в Keybase, является либо хешем корня цепочки подписей пользователя, либо привязанным к нему именем учетной записи Keybase. Пока пользователь не проверит подлинность корневого хэша цепочки подписей (или учетной записи базы ключей) по проверенному каналу, учетной записи и связанным с ней идентификаторам по существу слепо доверяют, и пользователь уязвим для атаки MITM.[нужна цитата ]

Сильные и слабые стороны модели

Самая большая сила любой модели в стиле TOFU заключается в том, что человек должен изначально подтверждать каждое взаимодействие. Распространенным применением этой модели является использование пользователей-ботов ssh-rpc между компьютерами, в результате чего открытые ключи распределяются на набор компьютеров для автоматического доступа с централизованных узлов. Аспект TOFU этого приложения заставляет системного администратора (или другого доверенного пользователя) проверять подлинность удаленного сервера при первом подключении.

Для сквозной зашифрованной связи модель TOFU позволяет аутентифицированное шифрование без сложной процедуры получения личного сертификата, который уязвим для CA Компромисс. В сравнении с Сеть доверия, TOFU требует меньше затрат на обслуживание.

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

В средах, где подлинность идентификатора не может быть достаточно легко проверена (например, ИТ-персонал рабочего места или учебного заведения может быть труднодоступным), пользователи склонны слепо доверять идентификатору противоположной конечной точки. Случайно утвержденные идентификаторы злоумышленников также может быть трудно обнаружить, если атака "человек посередине" сохраняется.

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

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

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

Первое известное использование термина

Первое известное формальное использование термина TOFU или TUFU было сделано исследователями CMU Дэном Вендландтом, Дэвидом Андерсеном и Адрианом Перригом в их исследовательской статье «Перспективы: улучшение аутентификации хоста в стиле SSH с помощью многопутевого зондирования», опубликованной в 2008 году на Usenix Annual Техническая конференция.[5]

Мокси Марлинспайк упомянутые перспективы и термин TOFU DEF CON 18 разбирательств, со ссылкой на комментарии, сделанные Дэн Камински, во время панельной дискуссии «Открытое письмо, призыв к действию». Было высказано предложение аудитории, подразумевающее превосходство SSH Инфраструктура открытого ключа (PKI) над SSL / TLS Модель PKI - на что Мокси ответил:

Анонимный: "... итак, если нам не нравится модель сертификата в (tls) PKI, но нам нравится, скажем, SSH PKI, который, кажется, работает достаточно хорошо, в основном, фундаментальный вопрос: если я передаю свои данные кому-то , Я доверяю им данные. Поэтому я должен помнить их сертификат. Если кто-то приходит с другим сертификатом, подписанным другим органом, я все равно им не доверяю. И если мы сделали это таким образом, то решит множество проблем - это решит проблемы мошеннических центров сертификации, в некоторой степени это не поможет вам с начальной загрузкой, но при начальной загрузке будет использоваться исходная модель, а затем для продолжения взаимодействия с сайтом, который вы использовал бы модель ssh, которая позволила бы вам продолжать работу сверх того, что у нас есть сейчас. Таким образом, модель, которая у нас есть сейчас, может быть продолжена для повторного использования, только для первоначального принятия. Так почему бы нам не сделать это? "

Дэн: "Итак, я бывший разработчик SSH, и позвольте мне пройти очень быстро. Каждый раз, когда возникает ошибка в генерации ключа ssh, пользователя спрашивают:" Пожалуйста, введите "да, чтобы доверять этому новому ключу" или "пожалуйста войдите в свой файл известных хостов и удалите это значение ', и каждый раз, когда они это делают, потому что это всегда вина неправильной конфигурации сервера. Модель SSH классная, не масштабируется ».

Moxie: "И я бы просто добавил, то, о чем вы говорите, называется «Доверие при первом использовании» или «тофу»., и есть проект, в котором я участвую, так называемые перспективы, который пытается использовать это, чтобы сделать его менее запутанным, чем чистая модель SSH, и я думаю, что это действительно отличный проект, и вы должны проверить его, если вас интересуют альтернативы. в систему CA ".

Связанные работы по теме

  • Работа по созданию визуального представления хэшей «отпечатков пальцев» сертификатов сервера реализована в OpenSSH в виде Искусство ASCII. Цель состоит в том, чтобы пользователи визуально распознавали «графическое» изображение вместо длинной строки букв и цифр. Оригинальная исследовательская работа была написана Адриан Перринг и Рассветная песня, на Университет Карнеги Меллон Кафедра компьютерных наук.
  • Создатель аббревиатуры «TUFU» описывал вдохновение для «Плагин для Firefox Perspectives ', который был разработан для усиления SSL / TLS Модель PKI, обращаясь к сетевым нотариусам всякий раз, когда ваш браузер подключает HTTPS интернет сайт

Предыдущая работа

Темы доверия, проверки, неотречение являются основополагающими для всей работы в области криптография и цифровая безопасность.

Смотрите также

Рекомендации

  1. ^ TOFU для OpenPGP, Уолфилд, Кох (EUROSEC’16, 18–21 апреля 2016 г.)
  2. ^ Каков безопасный / правильный способ добавления github.com в файл known_hosts? Проверено 19 ноября 2020 г.
  3. ^ Даниэль Гульч (20 ноября 2016 г.). «Слепое доверие до проверки». Получено 19 января, 2017.
  4. ^ [1]
  5. ^ http://www.usenix.org/events/usenix08/tech/full_papers/wendlandt/wendlandt_html/index.html

внешняя ссылка