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

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

Реализации TOFU

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

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

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

Например, в 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. Техническая конференция. ^[5]

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

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

Сопутствующая работа по теме

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

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

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

См. также

Ссылки

^ TOFU для OpenPGP , Уолфилд, Кох (EUROSEC'16, 18–21 апреля 2016 г.)
^ Каков безопасный/правильный способ добавления github.com в файлknown_hosts? Проверено 19 ноября 2020 г.
^ Дэниел Гульч (20 ноября 2016 г.). «Слепое доверие перед проверкой» . Проверено 19 января 2017 г.
^ «Обновление номеров безопасности» .
^ «Перспективы: улучшение аутентификации хоста в стиле SSH с помощью многопутевого зондирования» .

Внешние ссылки

[1] TOFU для OpenPGP , Уолфилд, Кох (EUROSEC'16, 18–21 апреля 2016 г.)

[2] Каков безопасный/правильный способ добавления github.com в файлknown_hosts? Проверено 19 ноября 2020 г.

[3] Дэниел Гульч (20 ноября 2016 г.). «Слепое доверие перед проверкой» . Проверено 19 января 2017 г.

[4] «Обновление номеров безопасности» .

[5] «Перспективы: улучшение аутентификации хоста в стиле SSH с помощью многопутевого зондирования» .

[1]

[2]

[3]

[4]

[5]