Доверие при первом использовании - Trust on first use
Доверие при первом использовании ( TOFU ) или доверие при первом использовании ( TUFU ) - это схема аутентификации , используемая клиентским программным обеспечением, которому необходимо установить доверительные отношения с неизвестной или еще не доверенной конечной точкой. В модели TOFU клиент будет пытаться найти идентификатор конечной точки, обычно либо открытый идентификационный ключ конечной точки, либо отпечаток указанного идентификационного ключа в своей локальной базе данных доверия. Если идентификатор для конечной точки еще не существует, клиентское программное обеспечение либо предложит пользователю подтвердить подлинность предполагаемого идентификатора, либо, если ручная проверка не предполагается возможной в протоколе, клиент просто будет доверять идентификатору, который был предоставлен и записать доверительные отношения в свою базу данных доверия. Если в последующем соединении от противоположной конечной точки будет получен другой идентификатор, клиентское программное обеспечение сочтет его ненадежным.
Внедрение TOFU
В протоколе SSH большая часть клиентского программного обеспечения (хотя и не все) при подключении к еще не доверенному серверу будет отображать отпечаток открытого ключа сервера и предлагать пользователю убедиться, что он действительно аутентифицировал его, используя аутентифицированный канал . Затем клиент записывает доверительные отношения в свою базу данных доверия. Новый идентификатор вызовет предупреждение о блокировке, которое требует ручного удаления сохраненного идентификатора.
При закреплении открытого ключа HTTP браузеры всегда будут принимать первый открытый ключ, возвращаемый сервером, и со строгой транспортной безопасностью HTTP, при которой браузеры будут подчиняться правилу перенаправления на время действия директивы age.
Клиент XMPP Conversations использует слепое доверие перед проверкой , при котором всем идентификаторам слепо доверяют, пока пользователь не продемонстрирует волю и способность аутентифицировать конечные точки путем сканирования представления идентификатора в виде QR-кода . После сканирования первого идентификатора клиент отобразит символ щита для сообщений от аутентифицированных конечных точек и красный фон для других.
В Signal конечные точки изначально слепо доверяют идентификатору и отображают неблокирующие предупреждения при его изменении. Идентификатор может быть проверен либо путем сканирования QR-кода, либо путем обмена десятичным представлением идентификатора (называемым Safety Number) по аутентифицированному каналу. Затем идентификатор можно пометить как проверенный. Это изменяет характер предупреждений об изменении идентификатора с неблокирующего на блокирующий.
Например, в Jami и Ricochet идентификатором является сам позывной пользователя. Обмен идентификаторами может осуществляться по любому каналу, но до тех пор, пока идентификатор не будет проверен по аутентифицированному каналу, ему фактически слепо доверяют. Смена идентификатора также требует смены учетной записи, поэтому для атаки MITM для той же учетной записи требуется доступ к закрытому ключу конечной точки.
В WhatsApp конечная точка изначально слепо доверяет идентификатору, и по умолчанию при изменении идентификатора предупреждение не отображается. Если пользователь демонстрирует желание и способность аутентифицировать конечные точки, обращаясь к отпечатку ключа (так называемому «Код безопасности»), клиент предложит пользователю включить неблокирующие предупреждения при изменении идентификатора. Клиент WhatsApp не позволяет пользователю помечать идентификатор как проверенный.
В дополнительных секретных чатах Telegram конечные точки слепо доверяют идентификатору. Измененный идентификатор порождает новое окно секретного чата вместо отображения какого-либо предупреждения. Идентификаторы можно проверить путем сравнения визуального или шестнадцатеричного представления идентификатора. Клиент Telegram не позволяет пользователю помечать идентификатор как проверенный.
В Keybase клиенты могут подписывать ключи друг друга, что означает, что доверие одному идентификатору позволяет проверять несколько идентификаторов. Keybase действует как доверенная третья сторона, которая проверяет связь между учетной записью Keybase и цепочкой подписей учетной записи, которая содержит историю идентификаторов. Идентификатор, используемый в Keybase, является либо хешем корня цепочки подписей пользователя, либо привязанным к нему именем учетной записи Keybase. Пока пользователь не проверит подлинность корневого хэша цепочки подписей (или учетной записи базы ключей) по проверенному каналу, учетной записи и связанным с ней идентификаторам по существу слепо доверяют, и пользователь уязвим для атаки MITM.
Сильные и слабые стороны модели
Самая большая сила любой модели в стиле TOFU состоит в том, что человек должен изначально подтверждать каждое взаимодействие. Распространенным применением этой модели является использование пользователей-ботов ssh-rpc между компьютерами, при этом открытые ключи распределяются на набор компьютеров для автоматического доступа с централизованных узлов. Аспект TOFU этого приложения заставляет системного администратора (или другого доверенного пользователя) проверять подлинность удаленного сервера при первом подключении.
Для конца в конец зашифрована связей модель TOFU позволяет аутентифицировано шифрование без сложной процедуры получения персонального сертификата , которые являются уязвимыми для CA компромисса . По сравнению с Web of Trust , TOFU требует меньше затрат на обслуживание.
Самым большим недостатком TOFU, требующим ручной проверки, является его невозможность масштабирования для больших групп или компьютерных сетей. Накладные расходы на обслуживание, связанные с отслеживанием идентификаторов для каждой конечной точки, могут быстро масштабироваться за пределы возможностей пользователей.
В средах, где подлинность идентификатора не может быть достаточно легко проверена (например, ИТ-персонал рабочего места или учебного заведения может быть труднодоступным), пользователи склонны слепо доверять идентификатору противоположной конечной точки. Случайно утвержденные идентификаторы злоумышленников также может быть трудно обнаружить, если атака «человек посередине» продолжится.
Поскольку новая конечная точка всегда включает новый идентификатор, предупреждение о потенциальной атаке не отображается. Это вызвало у пользователей неправильное представление о том, что можно продолжать работу без проверки подлинности исходного идентификатора, независимо от того, представлен ли идентификатор пользователю или нет.
Усталость от предупреждений подтолкнула многие приложения для обмена сообщениями удалить предупреждения о блокировке, чтобы пользователи не могли вернуться к менее безопасным приложениям, которые вообще не поддерживают сквозное шифрование .
Скрытые механизмы проверки идентификаторов снижают вероятность того, что методы безопасной аутентификации будут обнаружены и приняты пользователями.
Первое известное использование термина
Первое известное формальное использование термина TOFU или TUFU было сделано исследователями CMU Дэном Вендландтом, Дэвидом Андерсеном и Адрианом Перригом в их исследовательской статье «Перспективы: улучшение аутентификации хоста в стиле SSH с помощью многопутевого зондирования», опубликованной в 2008 году на ежегоднике Usenix Annual. Техническая конференция.
Мокси Марлинспайк упомянул «Перспективы» и термин «TOFU» в ходе разбирательства DEF CON 18 со ссылкой на комментарии Дэна Камински во время панельной дискуссии «Открытое письмо, призыв к действию». Было высказано предположение, что модель инфраструктуры открытого ключа SSH (PKI) превосходит модель SSL / TLS PKI, на что Мокси ответил:
Анонимный : "... итак, если нам не нравится модель сертификата в (tls) PKI, но нам нравится, скажем, SSH PKI, который, кажется, работает достаточно хорошо, в основном, фундаментальный вопрос: если я передам свои данные в кто-то, я доверяю им данные. Поэтому я должен помнить их сертификат. Если кто-то другой приходит с другим сертификатом, подписанным другим органом, я все равно им не доверяю. И если мы сделали это таким образом, то это решило бы множество проблем - это решило бы проблемы мошеннических центров сертификации, в некоторой степени, это не помогло бы вам с начальной загрузкой, но начальная загрузка будет использовать исходную модель, а затем для продолжения взаимодействия с сайтом вы бы использовали ssh-модель, которая позволила бы вам продолжать работать сверх того, что у нас есть сейчас. Таким образом, модель, которая у нас есть сейчас, может быть продолжена для повторного использования, только для первоначального принятия. Так почему бы нам не сделать это? "
Дэн : «Итак, я бывший разработчик SSH, и позвольте мне пройти очень быстро, каждый раз, когда возникает ошибка в генерации ключа ssh, пользователя спрашивают:« Пожалуйста, введите да, чтобы доверять этому новому ключу », или, Пожалуйста, войдите в свой файл известных хостов и удалите это значение », и каждый раз, когда они это делают, потому что это всегда ошибка неправильной конфигурации сервера. Модель SSH крутая, она не масштабируется».
Мокси : « И я бы просто добавил, то, о чем вы говорите, называется« Доверие при первом использовании »или« тофу » , и есть проект, в котором я участвую, который называется перспективами, который пытается использовать это, чтобы более запутанный, чем чистая модель SSH, и я думаю, что это действительно отличный проект, и вам стоит его проверить, если вы заинтересованы в альтернативах системе CA ».
Связанные работы по теме
- Работа по созданию визуального представления хэшей «отпечатков пальцев» сертификатов сервера была реализована в OpenSSH в форме ASCII Art . Цель состоит в том, чтобы пользователи визуально распознавали «графическое» изображение вместо длинной строки букв и цифр. Оригинальная исследовательская работа была написана Адрианом Перригом и Доун Сонг с факультета компьютерных наук Университета Карнеги-Меллон .
- Создатель аббревиатуры «TUFU» описал вдохновение для « плагина Firefox Perspectives », который был разработан для усиления модели SSL / TLS PKI путем обращения к сетевым нотариусам всякий раз, когда ваш браузер подключается к веб-сайту HTTPS.
Предыдущая работа
Темы доверия, проверки и неотказуемости являются основополагающими для всей работы в области криптографии и цифровой безопасности .