Inferno OS Wiki
Регистрация
Advertisement
Безопасность в Plan9
Russ Cox, MIT LCS
Eric Grosse, Bell Labs
Rob Pike, Bell Labs
Dave Presotto, Avaya Labs and Bell Labs
Sean Quinlan, Bell Labs

Примечание

Этот документ описывает программный комплекс, изначально реализованный для операционной системы Plan9. Рассматриваемые программы fsctotum и secstore были портированы в inferno (/appl/cmd/auth/factotum/, /appl/cmd/auth/secstore.b), так что все сказанное актуально и для этой операционной системы.

ОБЗОР[]

Архитектура безопасности операционной системы Plan 9(tm) была недавно изменена из-за нескольких технических недостатков. Это изменения призваны сделать систему более удобной с точки зрения безопасности. Plan 9 в соответствии с этими улучшениями преследовал две обычно не совместимые цели: стать более безопасным и более легким в использовании.

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

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

Factotum имеет необычную архитектуру: он реализован как файл-сервер Plan9.

1. Введение[]

Компьютерные системы безопасности сталкиваются лицом к лицу с двумя трудностями: первая, они должны применять сложные технологии которые трудно правильно проектировать и испытывать; и второе, они должны быть простыми чтобы люди ими пользовались. Вопрос простоты использования зачастую забывался, но это первоочердное требование: поскольку даже ненадежное, но легкое в использовании средство безопаасности может быть намного эффективнее, чем мощное но трудное в применении средство если они больше нравяться людям. Люди запирают свои парадные двери когда покидают дом, зная наверняка что взломщик сможет открыть замок (или же сломать дверь); а еще они понимают сколько стоит и насколько неуклюжа дверь банковского хранилища в их доме, несмотря на то, что она значительно снизит вероятность ограбления.

В связи с этим пользователь нуждаются в ясной модели того как приводится в действие система безопасности (а не то, как она в действительности предоставляет безопасность) для того чтобы ей воспользоваться; например, ясная для понимания иконка замка на панели веб-браузера весьма далека от сбивающих с толку и обычно небезопасных шагов по установке сертификатов X.509.

Архитектура безопасности ОС Plan9 (Pike95) была недавно перепроектирована и для повышения безопасности и для простоты использования. Под безопасностью мы имеем в виду три вещи: во-первых, дело аутентификации пользователей и сервисов; во-вторых, безопасное обслуживание и развертывание, и использование ключей и другой секретной информации; и в-третьих, использование шифрования и проверки целостности охраняемых коммуникаций от любопытных глаз.

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

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

В-третьих, файловы протокол 9P (Pike93), который образует ядро Plan 9 систем, по замыслу уже имеет встроенный аутентификационный протокол. Это значит что исправляя или изменяя аутентификацию используемую в 9P требует внесения глубинных изменений в систему. Если кто-то найдет способ взломать протокол, система будет широко доступна и ее будет черзвычайно трудно исправить.

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

Краеугольным камнем новой архитектуры стал агент, названный factotum, который обслуживает пользовательские ключи и участвует во всех секретных переговорах с системными сервисами и приложениями. Как доверенный помощник с копией ключей собственника, factotum ведет все переговоры о безопасности и аутентификации. Теперь нет нужды в компиляции программ с криптографическим кодом; вместо этого они общаются с агентом factotum который представляет различные сущности в криптографическом обмене, таких как пользователь и сервер службы безопасности. Если есть потребность в добавлении протокола безопасности, удалении или модификации, только factotum будет обновлен для всех обеспечения безопасности системных сервисов.

Разрабатывая factotum, мы модифицировали службы безопасности в системе для вынесения кода аутентификации пользователя в factotum.; сделали аутентификацию отдельным компонентом файл-серверного протокола; внедрили новые протоколы безопасности; разработали безопасное хранилище файлов, названное secstore, для защиты наших ключей, но сделали так чтобы их было легко извлечь, когда они понадобятся; разработали новый модуль ядра для прозрачного использования Transport Layer Security (TLS) [RFC2246]; и начали использовать шифрование ля всех коммуникаций в системе. Общий взгляд на архитектуру показан на Рисунке 1а.

Components of the security architecture

Рисунке 1а. Компоненты архитектуры безопасности.

Каждый квадрат (обычно) является отдельным компьютером; а каждый эллипс процессом. Эллипсы помеченные FX это процессы factotum; другие помеченные PX части и прокси распределенной программы. Сервер аутентификации один из нескольких хранилищ для пользовательской приватной информации к которой процесс factotum'а обращается при необходимости. Secstore общий ресурс для хранения частной информации такой как ключи; factotum обращается к ней для пользователя во время загрузки.

Протоколы безопасности и алгоритмы хорошо понятны и обчно не являются слабым звеном системной безопасности. На практике, большинство проблем с безопасностью возникает из-за серверов кишаших багами, сбиваюших с толку программ, или из-за административных оплошностей. Все это практические проблемы нак которые мы ссылались. Не смотря на то что этот документ описывает алгоритмы и протоколы которые мы использовали, они были включены в основном для большей конкретности. Наше главное намерение это предстваить простую архитектуру безопасности построенную базе на довернного кода маленького размера, который легко проверить (не зависимо делается это автоматически или вручную), легко понять, легко использовать.

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

2. Агент безопасности[]

Одной из первостепенных причин перепроектирования инфрастуктуры безопасности Plan9 было удаление методов аутентификации как из приложений, так и из ядра. Криптографический код большой и замысловатый, он должен быть упакован в отдельный компонент который может быть изменен или исправлен без переделки и перелинковки всех приложений и сервисов которые от него зависят. Если протокол безопасности окажется поврежденным, починка его, отключение или замена должны быть тривиальной задачей. Аналогично, должна существовать возможность нескольким прораммам использовать общий протокол безопасности, без внедрения его в каждую программу.

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

Следуя примеру агента SSH (Ylon96), мы дали каждому пользователю процесс-агент ответственный за хранение и использование пользовательских ключей. Программа-агент названа factotum, потому что она просто созвучна латинскому названию слуги fac totum ("do/make everything"). и она совместно со своим хозяином наделена силой к действию, потому что она хранит ключи от всех хозяйских владений.

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

Factotum реализован наподобие многих сервисов Plan 9, как файл-сервер. он традиционно монтируется в директорию /mnt/factotum, и файлы им обслуживаемые аналогичны виртуальным устройствам которые предоставляют доступ, управляют сервисами factotum. Следующие несколько разделов описывают дизайн factotum и как он взаимодействует с другими частями Plan 9 для предоставления безопасных сервисов.

2.1. Авторизация / Logging in[]

Чтобы сделать изложени более конкретным, мы рассмотрим несколько примеров, показывающих как архитектура безопасности Plan 9 представляется пользователю. Оба этих примера заставляют пользователя gre авторизоваться после загрузки компьютера. Пользователь может иметь или не иметь защищенное хранилище в котором хранятся все его ключи. Если он делает это, factotum спрашивает его пароль к защищенному хранилищу и получает ключи из него, обращаясь к пользователю только тогда, когда ключи не найдены в хранилище. В противном случае, factotum должен обращаться за каждым ключом.

В листинге, \n представляет собой символ перевода строки, набранный для окончания ввода. Ввод пользователя показан курсивом, и длинные строки были перенесены для удобства чтения.

В первом примере показано как пользователь авторизуется без помощи от защищенного хранилища. Во-первых, factotum спрашивает имя пользователя, которое будет использовано локальным ядром:

    user[none]: gre

(Ответ пользователя по умолчанию показан в квадратных скобках.) Ядро затем начинает доступ к локальным ресурсам и запрашивает через factotum пару логин/пароль для этого:

    !Adding key: dom=cs.bell-labs.com proto=p9sk1

    user[gre]: \n
    password: ****

Теперь пользователь зашел в локальную систему и запускается почтовый клиент:

    !Adding key: proto=apop server=plan9.bell-labs.com
    user[gre]: \n

    password: ****

Factotum все время запрашивал логин/пароль и запущенные приложения не прикосались к ключам. Обратите внимание что всегда ясно какой ключ был запрошен.

Теперь предположим, ту же последовательность авторизации, но теперь у пользователя gre есть аккаунт в защищенном хранилище.

    user[none]: gre
    secstore password: *********

    STA PIN+SecurID: *********

Это было последнее что услышал gre от factotum до тех пор пока он не обратится к системе от которой нет ключей в secstore.

2.2. Factotum[]

Каждый компьютер с запущенным Plan 9 имеет один пользовательский идентификатор который владеет всеми ресурсами этой системы - планировщиком, локальными дисками, сетевыми интерфейсами и т.д. Этот пользователь, владелец компьютера, аналогичен пользователю root из мира Unix (хотя и намного слабее его; сокрее обладающий специальными полномочиями, вытекающими из того что владелец компьютера это простой пользователь и так случилось что он владее ресурсами локальной машины). На однопользовательской системе, которую мы называем терминалом, у владелеца хоста тот же самый id что и у терминального пользователя.

Сервера с общим доступом, такие как CPU сервера обычно имеют псевдо-пользователя который изначально владеет всеми ресурсами. Во время загрузки ядро Plan 9 запускает factotum с привилегиями владельца компьютера.

Новые процессы запускаются от имени пользовательского процесса который их создал. Когда поцесс должен взять идентификатор нового пользователя, как например для получения login shell на CPU-сервере, он делает это предоставляя factotum владельца компьютера который и выполняет авторизацию. Это происходит при помощи запуска протокола аутентификации с factotum для получения доступа к секретной информации которой должен владеть только новый пользователь. Например, рассмотрим схему из Рисунка 1а. Если пользователь терминала желает получить доступ к CPU-серверу используя cpu-сервис Plan 9 (Pike93), тогда PT модет быть клиентской cpu-программой а PC cpu-сервером. Никто, ни PC, ни PT не знают деталей аутентификации. Все что они должны сделать как это отослать сообщение и принять сообщения между двумя factotum, но это обычная функция легко осуществляемая без узнавания, или возможности извлечь секреты (здесь и далее под словом "секрет" понимается пароль) из сообщений. PT поизведет сетевое соединение с PC. PT и PC затем перенаправят свои сообщения между factotum которым владеет пользователь, FT, и другим factotum владелец которого CPU-сервер, FC, пора кне будет установлена взаимная аутентификация. Последующие разделы опишут RPC между factotum и приложениями и библиотечными функциями для поддержки прокси операций.

Ядро всегда пользуется единственным экземпляром factotum запущенного от имени владельца компьютера дляцелей аутентификации, но и обычный пользователь может запустить своего factotum-агента. В действительности, factotum представляющий пользователя не обязательно должен быть запущен на той же машине что и клиент. Например, это легко сделать пользователю CPU- сервера, через стандартную операцию Plan9, заместив /mnt/factotum в пользовательском приватном пространстве имен сервера соединив с factotum работающим на терминале. (Обычно, правай файловой системы препятствуют тем кто умышленно стремится нанести вред) Это дает разрешения на операции с безопасностью на CPU-сервере, которые будут прозрачно проходить проверку на собственном пользовательском factotum, и таким образом секретные ключи никогда не выйдут за пределы терминала. SSH агент (Ylon96) делает практически то же самое со специальными сообщениями протокола SSH , но преимущество создания нашего агента, в том что нам не нужен новый механизм для доступа к нашему удаленному агенту; удаленный файловый доступ так же успешен.

С factotum, каждый протокол реализован как структура с общим интерфейсом, так что протоколы являются по существу подключаемыми модулями, лекими в модификации, добавлении и удалении. Запись сообщения и чтение сообщения из factotum каждое потребует отдельный RPC и результатом будет переход в единое состояние. Поэтому factotum всегда запускается по завершении каждого RPC вызова и никогда не блокируется ожидая ввода во время любой аутентификации. Кроме того, количество одновременных аутентификаций ограничено только размером памяти которая предоставлена машине.

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

На момент написания, factotum содержит модули для протокола Plan 9 с разделяемым ключом (p9sk1), SSH's RSA аутентификацию, пароли в чистом виде, APOP, CRAM, PPP's CHAP, Microsoft PPP's MSCHAP, и VNC's вызов/отклик.

2.3. Локальные возможности[]

Возможности системы управляемой ядром, используются для того, чтобы уполномочить factotum дать разрешение другому процессу для смены пользовательского идентификатора. Драйвер устройства ядра реализует два файла, dev/caphash и /dev/capuse. Файл с возможностью только-для-записи /dev/caphash может быть открыт только владельцем компьютера, и только один раз. Factotum открывает этот файл немедленно после загрузки.

Для имспользования этого файла factotum создает строку в форме userid1@userid2@random-string, используя хэш SHA1 HMAC для кодирования строки userid1@userid2 с ключевой случайной строкой, и записывает этот хэш в /dev/caphash. Затем factotum передает оригинальную строку другому процессу на той же машине, запущенному от имени пользователя userid1, который в свою очередь записывает строку в /dev/capuse. Ядро хэширует строку и ищет соответствия хэша в этом списке. Если такое соответствие найдено, идентификатор записывающего процесса изменяется с userid1 на userid2. После однократного использования или после некоторого таймаута, эта возможность сбрасывается ядром.

Эта способность локальна для машины на которой она создана. Следовательно factotum запущенный на одной машине не может передать возможности процессу запущенному на другой машине и ожидать что это сработает.

2.4. Ключи[]

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

Беря пример с SDSI (Simple Distributed Security Infrastructure), которая представляет информацию о безопасности как текстовые S-выражения, ключи в Plan9 являются чистым текстом в кодировке UTF-8. Текст понимается и изменяется пользователями. В противоположность этому, двоичный или другой формат крипто-информации может действительно понизить общую безопасность. Двоичные форматы сложны для проверки пользователями могут быть взломаны только специальными инструментами, которые сами по себе малопонятны большинству пользователей. Например, только несколько людей знают или понимают что скрывается за сертификатами X.509. Большинство же не знает где их найти в системе. Поэтому у них нет понимания, чему же они собственно доверяют, и почему они бессильны изменить эти доверенные отношения. Текстовые, хранящиеся и управляемые централизованно ключи легко и безопасно использовать.

В Plan 9 базы данных исторически выглядят как пары атрибут/значение, с тех пор они хорошо себя зарекомендовали для операций выборки и отсеивания. Поэтому ключи в factotum представлены в формате атрибут=значение, где атрибут это идентификатор, возможно с префиксом из одного символа, и значение произвольная строка в кавычках. Сами пары разделены пробелами. Например, ключ Plan 9 и ключ APOP могут быть представлены следующим образом:

dom=bell-labs.com proto=p9sk1 user=gre !password='don''t tell' 
proto=apop server=x.y.com user=gre !password='open sesame'

Если значение пустое или содержит пробел или едмнственную кавычку, оно должно быть заключено в двойные кавычки. Атрибут который начинается с восклицательного знака (!) содержит секрет. Factotum никогда не оставит значение секрета в своем адресном пространстве и отключит отображение клавиатурного ввода (эхо) когда просит набрать пользователя его.

Программа запрашивающая аутентификацию отбирает ключи посылая запрос - список элементов которые соответствуют ключу. Каждый элемент из этого списка пары атрибут=значение, или атрибут и следующий за ним знак вопроса, атрибут?, удовлетворяют ключам некоторой пары указанной по атрибуту. Ключ соответствует запросу если каждый элемент списка соответствует. Например, для получения ключа APOP в предыдущем примере, APOP-клиента моежт послать запрос

server=x.y.com proto=apop

Внутренний APOP-модуль factotum'а добавит необходимые атрибуты user и !password, формируя запрос

server=x.y.com proto=apop user? !password?

когда ищет пододящий ключ.

Модуль factotum ждет появления ключей с известными атрибутами. Например, атрибут proto указывает на то, какой из модулей протоколов отвечает за атрибуты (например, многие ждут !password ). Вдобавок атрибуты могут использоваться как коментарии или для дальнейшего разбора без вмешательства factotum; например, почтовые клиенты APOP и IMAP по-соглашению включают атрибуты сервера для выбора соответствующего ключа аутентификации.

В отличии от SDSI, ключи в Plan 9 не имеют вложенной структуры. Такой дизайн сохраняет представление простым. Если неободимо, мы можем добавить вложенный атрибут, или как в реляционных СУБД , этот атрибут отбирает другой тьюпл, но для простоты дизайна этого будет достаточно.

Простая, общая для всех ключей структура делает их легко администрируемы для пользователя, однако набор атрибутов и их интерпретация все еще остается зависимой от протокола и может быть таинственным. Множество атрибутов (proto, user, password, server) самодостаточны и наш небольшой опыт выявил случаев затруднения в обращении с ключами. Вещи выглядят куда более запущенными когда мы сталкиваемся с публичными ключами и бесчисленными их составляющими.

2.5. Защита ключей[]

Пароли должны предохраняться от утечки из factotum. Существует несколько путей того как они могут просочиться наружу: другой процесс может получить возможность отладки процесса-агента, агент может уйти в (своп) область подкачки на диск, или другой процесс может добровольно раскрыть ключ. Последнего наиболее легко избежать: секретная информация в ключе помечается как таковая, и когда бы factotum не печатал ключи или запрашивал новые, он избегал отображения секретной информации. (Единственным исключением являются пароли из протоколов "чистого текста", которые содержат передаваемые значения атрибутов user и !password. Только ключи отмеченные proto=pass могут быть уязвимы к раскрытию их паролей этим механизмом.)

На предотвращение утечек в первых двух случаях на помощь приходит ядро. В Plan 9, каждый процесс представлен в каталоге /proc файловой системы. Используя файлы в этой директории другие процессы могут (в соответствии с установленными ограничениями/правами доступа) обследовать память и регистры factotum. По умолчанию factotum защищен от процессов других пользователей правами установленными на его каталог в директории /proc. Как бы там ни было, мы также хоим защитить агент от других процессов владельцем которых выступает тот же пользоваетль, для избежания прямых ошибок и предотвращения захвата оставленного без присмотра терминала, для раскрытия пароля. Для достижения этого, мы добавили управляющее сообщение в /proc названное "частным". Как только процесс factotum записывает частную информацию в собственный файл /proc/pid/ctl, никой другой процесс не может обратиться к памяти factotum через /proc. (В Plan 9 не существуетдругих механизмов для доступа к памяти, таких как /dev/kmem.)

Аналогично, адресное пространство агента не должно уходить в подкачку, для предотвращения раскрытия незашифрованных ключей на носителях используемых для свопа. Управляющее сообщение noswap в /proc предохраняет от такого сценария. Ни private, ни noswap не принадлежат только factotum. Файловые сервера пользовательского уровня, такие как dossrv дающие доступ к файловой системе FAT, могут использовать noswap для предохранения своих буферов от кэширования на диск.

Вопреки нашим предостарожностям, атакующие все еще могли найти пути для получения доступа к процессам запущенным с правами владельца хоста на машине. И даже не смотря на это, они не смогли бы напрямую получить доступ к локально выполняющемуся factotum для того чтобы он прошел аутентификацию за них. В случае некоторых ключей, которые например, дают доступ к банковыским счетам, мы хотели бы найти способ для блокировки такого доступа или хотя бы для обнаружения такого обращения. Эту в ключе роль берет на себя атрибут confirm. Когда бы не происходило обращение к ключу с атрибутом confirm, локальный пользователь должен будет подтвердить использование этого ключа через локальный GUI. Следующий раздел описывает действующий механизм.

Мы не обращаемся к утечкам возможным в результате того, что кто-то перезагружает или сбрасывает машину с запущенным factotum. Например, кто-то может сбросить машину и перезагрузить ее с отладчиком вместо ядра, который позволит ему осмотреть память и обнаружить ключи. Мы не нашли приемлемого решения этой проблемы.

2.6. Транзакции factotum[]

Внешние программы управляющие внутренним состоянием factotum через его интерфейс, записывают чистым текстом команды key и delkey в файл /mnt/factotum/ctl. Обе команды принимают в качестве аргументов список атрибутов. Команда "key" создает ключ с заданными атрибутами, замещая любой существующий ключ с идентичным набором атрибутов. Команда "delkey" удаляет все ключи которые соответствуют заданному набору атрибутов. Чтение файла ctl возвращает список ключей, по одному на строку, показывая только публичные атрибуты. Следующий пример показывает это взаимодейтсвие:


    % cd /mnt/factotum
    % ls -l
    -lrw------- gre gre 0 Jan 30 22:17 confirm
    --rw------- gre gre 0 Jan 30 22:17 ctl
    -lr-------- gre gre 0 Jan 30 22:17 log
    -lrw------- gre gre 0 Jan 30 22:17 needkey
    --r--r--r-- gre gre 0 Jan 30 22:17 proto
    --rw-rw-rw- gre gre 0 Jan 30 22:17 rpc
    % cat >ctl
    key dom=bell-labs.com proto=p9sk1 user=gre !password='don''t tell'
    key proto=apop server=x.y.com user=gre !password='bite me'
    ^D
    % cat ctl
    key dom=bell-labs.com proto=p9sk1 user=gre
    key proto=apop server=x.y.com user=gre
    % echo 'delkey proto=apop' >ctl
    % cat ctl
    key dom=bell-labs.com proto=p9sk1 user=gre
    % 

(Файл с установленным битом "l" может быть открыт только одним процессом одновременно.)

Сердце интерфейса - это файл rpc. Программа проходящая аутентификацию с factotum записывает запрос в файл rpc и считывает ответ; эта последовательность называется RPC-транзакция. Запросы и ответы имеют одинаковый формат: глагол в текстовом виде с возможными аргументами, которые могут быть текстовыми или двоичными. Наиболее частый отклик "ok", показывает успех. Сессия RPC начинается с начала транзакции, агрументом является запрос "key" о котором упоминалось раньше. Однажды начавшееся RPC соединение обычно содержит последовательность транзакций чтения и записи. Если соединение было удачным, транзакция authinfo вернет информацию о идентификаторе полученном во время транзакции Транзакция attr вернет список атрибутов текущего соединения; список включает атрибуты данные в начале запроса и так же все публичные атрибуты ключа, которые использовались.

Пример работы файла rpc, рассматривающий почтового клиента соединяющегося с почтовым сервером по протоколу POP3 и APOP запросом/ответом. Здесь задействованы четыре программы: прочтовый клиент PC, клиент factotum FC, почтовый сервер PS, и сервер-factotum FS. Все вычисления по аутентификации обслуживаются процессом factotum. Роль программы mail сводится к трансляции сообщений

При запуске почтовый сервер x.y.com начинает переговоры APOP с factotum который получает баннер с приветствием, который содержит запрос:

PS->FS: start proto=apop role=server
FS->PS: ok
PS->FS: read
FS->PS: ok +OK POP3 challenge

Для получения требования (challenge) сервер приветствует клиента:

PS->PC: +OK POP3 challenge

Клиент использующий APOP для переговоров с factotum получает отклик:

PC->FC: start proto=apop role=client server=x.y.com
FC->PC: ok
+OK POP3 challenge
FC->PC: ok
PC->FC: read
FC->PC: ok APOP gre response

Factotum ждет что начальный запрос включает атрибут proto, и модуль APOP ожидает дополнительного атрибута role, однако другие атрибуты опциональны и ограничены только пространством ключа. Перед ответом в начале транзакции, клиент-factotum ищет ключ который используется на протяжении переговоров. Поскольку аргументы в начальном запросе, ключ должен иметь публичные атрибуты proto=apop и server=x.y.com; как отмечено раньше, и модуль APOP дополнительно ожидает ключ с атрибутами user и !password. Теперь клиент получив ответ от своего factotum, отображает ответ сервера:

PC->PS: APOP gre response

Аналогично, сервер передает это сообщение своему factotum и получает другой отклик.

PS->FS: write APOP gre response
FS->PS: ok
PS->FS: read
FS->PS: ok +OK welcome
PS->PC: +OK welcome

Теперь протокол аутентификации завершен, и сервер может извлечь информацию о том, что протокол установлен.

PS->FS: authinfo
FS->PS: ok client=gre capability=capability

Данные authinfo это список пар атрибут=значение, тут и имя пользователя и возможности протокола. (Протокол который использует разделяемые секреты или предоставляет взаимную аутентификацию указывает это добавляя соответствующую пару атрибут=значение.) Возможности протокола которые используются сервером для изменения идентификатора на клиентский описаны ранее. Как только идентификатор изменен, сервер получет возможность доступа и обслуживания клиентского почтового ящика.

Два других файла обеспечивают связь с графическим интерфейсом управления factotum. Первый, confirm, дает пользователю возможность детального управления и использования над определенными ключами. Если у ключа есть атрибут confirm= , тогда пользователь должен подтвердить каждое использование ключа. Отдельная программа с графическим интерфейсом читает из файла confirm наблюдаяя когда подтверждение необходимо. Чтение блокируется до тех пор, использование ключа не будет подтверждено, после чего возвращается строка вида

confirm tag=1

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

tag=1 answer=yes
(или answer=no).

Второй файл, needkey, перенаправляет запросы ключей. В примере APOP, если подходящий ключ не был найден во время начала транзакции, factotum просигнализирует о сбое вернув отклик с указанием того что нужен ключ:

FC->PC: needkey proto=apop server=x.y.com user? !password?

Типичный клиент затем спросит пользователя желаемую ключевую информацию, создаст ключ и поместит его в ctl файл, и заново пошлет стартовый запрос. Если файл needkey открыт, тогда вместо сбоя, транзакция будет блокирована, и следующее чтение из файла /mnt/factotum/needkey вернет строку вида

needkey tag=1 attributes

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

Оставшиеся файлы информационные и используются для отладки. Файл proto содержит список поддерживаемых протоколов (чтобы посмотреть какие протоколы поддерживает система, выполните командуcat /mnt/factotum/proto ), и файл log содержащий, записи об операциях и отладочный вывод если используется управляющее сообщение debug.

Следующий раздел пояснит то, как factotum используется системными службами.

3. Аутентификация в 9P[]

Plan 9 использует протокол доступа к удаленным файлам 9P [Pike93], для соединения с ресурсами такие как файл-сервер и удаленный процесс. Оригинальный дизайн 9P включает специальные сообщения в начале диалога для аутентификации пользователя. Множество пользователей могут разделять единственное соединение, например когда CPU-сервер запускает процессы для многих пользователей подключаясь к единственному файл-серверу, но каждый авторизуется отдельно. Протокол аутентификации, похож на Kerberos [Stei88], и использует последовательность сообщений передаваемых между клиентом, файл-сервером и сервером аутентификации для проверки идентичности пользователя, вызываемая машина и обслуживающая машина. Один главный недостаток дизайна заключался в том, что метод аутентификации был опреелен в самом 9P и не мог изменяться. Кроме того, не существовало механизма передать аутентификацию внешнему (доверенному) агенту, таким образом требуется процесс реализующий 9P, помимо поддержки файлового сервиса, с увесистой частью криптографического кода, реализующего начальные сообщения в протоколе.

Недавние изменения в 9P направлены на несколько задач связанных с файловыми серверами и они выходят за рамки этого документа. В связи с задачами аутентификации были поставлены две цели: первая, убрать детали аутентификации из самого протокола; второе, дать внешним программам выполнять часть связанную с аутентификацией. В общем мы хотели включить идеи найденные в других системах наподобие SFS [Mazi99].

И поскольку 9P все таки является файл-сервисным протоколом, решением стало создать новый тип обслуживаемого файла: аутентификационный файл. Соединения в сервисе 9P начинаются в состоянии в котором нет общего доступа к файлам, однако есть доступ клиенту к аутентификационному файлу, путем посылки специального сообщения, генерируемого новым системным вызовом fauth: afd = fauth(int fd, char *servicename);

Здесь fd дескриптор пользовательского файла для установленного сетевого соединения сервера 9P и имя сервиса - это наименование желаемого сервиса предлагаемого этим сервером, обычно это файловая подсистема к которой разрешен доступ. Возвращаемый файловый дескриптор, afd это уникальный хэндл представляющий аутентификационный файл созданный для этого соединения для аутентификации этого сервиса; это аналогично возможности сервиса. Доступ к аутентификацинному файлу представляемый afd, не может быть получен на сервере через дерево файлов. Во всех других отношениях он обычный файл, что самое важное он принимает стандартные операции чтения и записи.

Для доказательства своей идентичности, пользоваетльский процесс (через factotum) выполняет аутентификационный протокол, описанный в следующем разделе, через файловый дескриптор afd обычными операциями чтения и зписи. Когда клиент и сервер успешно договорились, аутентификационный файл исзменяет состояние так что он может использоваться как доказательство полномочий для монтирования.

Как только идентичность установлена, процесс представляющий (теперь проверенный) afd в доказательство идентичности делает системный вызов mount:

mount(int fd, int afd, char *mountpoint, int flag, char *servicename)

в случае успеха, пользователь теперь имеет соответствующие права на файловую иерархию видимую в точке монтирования.

Эта последовательность событий несет несколько выгод. Во-первых, действительный протокол аутентификации реализован с использованием обычных операций чтения-записи, а не специальными сообщениями 9P, так что бы их надо было обработать, переслать, проксировать и т.д. агентом 9P без специального соглашения. Второе, процесс переговоров посредством чтения-записи аутентификационного файла можно делегировать стороннему агенту, обычно factotum; программы которые реализуют клиентские и серверные части переговоров 9P не нуждаются в аутентификационном или криптографическом коде. В-третьих, когда аутентификационный протокол не определен в самом 9P, его легко изменять и эо можно делать динамически во время переговоров. И наконец, afd выступает в роли возможности сервиса, он может быть обработан одним из следующих способов: передан другому процессу для получения особых разрешений; сохранен для последующего использования когда вновь потребуется аутентификация; или закрыт для того чтобы удостовериться что никакой другой процесс не получит к нему доступ.

Все эти выгоды стали стержнем при переходе на аутетификационный файл. Как это часто случается в Plan9, создание ресурса (здесь аутентификация) с доступом в виде файла априори уменьшает потребность в наличии специальных интерфейсов.

3.1. Протокол разделяемых ключей Plan 9[]

В добавок к различным стандартным протоколам поддерживаемым factotum, мы пользуемся протоколом разделяемых ключей для нативной поддержки аутентификации Plan 9. Этот протокол предоставляет обратную совместимость со старыми версиями системы. Единственной причиной для новой архитектуры - это возможность нам заменить подобные протоколы в ближайшем будущем на более безопасные в плане криптографии.

P9sk1 это протокол с разделяемыми ключами который использует тикеты подобно исходному Kerberos. Разница в том, что мы заменили время истечения в тикетах Kerberos случайным параметром nonce и счетчиком. Здесть мы подведем итог:

C->S: nonceC S->C: nonceS,uidS,domainS
C->A: nonceS,uidS,domainS,uidC,factotumC 
A->C: KC{nonceS,uidC,uidS,Kn}, KS{nonceS,uidC,uidS,Kn}
C->S: KS{nonceS,uidC,uidS,Kn}, Kn{nonceS,counter} 
S->C: Kn{nonceC,counter}

(Здесь K{x} показывает, что x зашифрованный алгоритмом DES ключ K.) Первые два сообщения обменивают nonces и идентификацию сервера. После этого начального обмена, клиент соединяется с сервером аутентификации для получения пары зашифрованных тикетов, один из которых зашифрован клиентским ключом, а другой серверным ключом. Клиент отсылает серверный ключ на сервер. Сервер верит что тикет новый поскольку он содержит nonceS что тикет от сервера аутентификации поскольку он зашифрован серверным ключом KS. Тикет, в основном, это заявление от аутентификационного сервера что теперь uidC и uidS разделяют секрет Kn. Аутентификатор Kn{nonceS,counter} доказывает серверу что клиент знает Kn и таким образом, должен быть uidC. Аналогично, аутентификатор Kn{nonceC,counter} доказывает клиенту что сервер знает Kn и поэтому должен быть uidS. Тикеты могур использоваться повторно, без установления нового соединения с сервером аутентификации, при помощи инкрементирования счетчика перед каждой генерацией аутентификатора.

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

3.2. Сервер аутентификации[]

Каждый домен безопасности Plan 9 имеет сервер аутентификации (AS) которому доверяют все пользователи доверяют полный набор разделяемых ключей. Он так же предлагает сервисы для пользлвателей и администраторов для управления ключами, создания и удаления аккунтов и т.д. Он обычно бывает запущен на отдельной машине совместно с несколькими другими сервисами. AS включает в себя два сервиса: keyfs и authsrv.

Keyfs это файловая система пользовательского уровня которая управляет зашифрованную базу данных пользовательских аккаунтов. Каждый аккаунт представляет собой директорию содержащую файлы ключей, содержащие ключт Plan9 для p9sk1; пароли для запроса/отклика протоколов (APOP, VNC, CHAP, MSCHAP, CRAM); лог-файл результатов аутентификации; время истечения срока действия аккуанта; и статус. Если истекает время действия аккаунта, если количество неудачных попыток аутентификации превысило 50; если файл статуса содержит запись "disabled", любая попытка доступа к ключу или секрету будет неудачной.

Authsrv это сетевой сервис который является посредником в аутентификации с разделяемым ключом для протоколов p9sk1, APOP, VNC, CHAP, MSCHAP, и CRAM. Удаленные пользователи могут также вызывать authsrv для изменения своих паролей.

Протокол p9sk1 был описан в предыдущем разделе. Протоколы запрос/отклик различаются деталями, но следуют общей структуре:

C->S: nonceC 
S->C: nonceS,uidS,domainS 
C->A: nonceS,uidS,domainS, hostidC,uidC 
A->C: KC{nonceS,uidC,uidS,Kn}, KS{nonceS,uidC,uidS,Kn} 
C->S: KS{nonceS,uidC,uidS,Kn}, Kn{nonceS} 
S->C: Kn{nonceC}

Протокол с паролем следующий:

C->A: uidC 
A->C: Kc{Kn} 
C->A: Kn{passwordold,passwordnew} 
A->C: OK

Для избежания повторных атак (// атак по подбору??), в предварительно зашифрованный чистый текст для каждого протокола (в том числе и p9sk1) включается метка укзывающая role шифрования в этом протоколе. Мы не будем углубляться в этот момент.

3.3. Протокол согласования / ппротокол переговоров[]

Мы реализовали метапротокол переговоров - p9any, который отбирает для использования действительный аутентификационный протокол. P9any теперь используется всеми нативными сервисами в Plan9.

Метапротокол прост. Вызавающий посылает строку заканчивающуюся нулем следующей формы:

vn proto1@domain1 proto2@domain2 ...

где n десятиный номер версии, protok имя протокола для которого у factotum есть ключ, и domaink имя домена в катором этот ключ валиден. Вызывающий получает ответ

proto@domain

указывающий этот выбор. В заключении вызывающий получает

OK

Любая другая строка указывает на ошибку. С этой точки вступает в действие выбранный протокол. Финальный отклик фиксированной длины используется для легкого ограничения потока I/O который выбранный протокол ожидает вызывающий скорее чем вызываемый для посылки первого сообщения.

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

P9any подвержен атакам типа посредник (man in the middle) на протяжении которой атакующий может подставить возможные варианты изменяя принимаемый поток. Тем не менее, мы верим что это приемлимо, и атакующий не может принудить обе строны использовать протокол который они не желают использовать.

4. Библиотечный интерфейс к Factotum[]

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

Во-первых, давайте рассмотрим проблемы при монтировании удаленного файл-сервера используя 9P. Обсуждение выше показало как системные вызовы fauth и mount используют аутентификационный файл, afd как возможности сервиса, но теперь factotum будет управлять afd. Библиотека содержит процедуру amount (authenticated mount), которая используется большинством программ в предпочтении сырым вызовам fauth и mount. Amount привлекает factotum проверить afd; далее приведен завершенный код:

    int
    amount(int fd, char *mntpt, int flags, char *aname)
    {
        int afd, ret;
        AuthInfo *ai;
        afd = fauth(fd, aname);
        if(afd >= 0){
             ai = auth_proxy(afd, amount_getkey,
              "proto=p9any role=client");
            if(ai != NULL)
              auth_freeAI(ai);
        }
        ret = mount(fd, afd, mntpt,flags, aname);
        if(afd >= 0)
            close(afd);
        return ret;
    }

где параметр fd это дескриптор файла возращаемый функциями open или dial для новых соединений к файл-серверу. Переговоры с factotum начинаются в обращении к auth_proxy, указывающей как ключ запрашивается, какой аутентификационный протокол используется (тут метапротокол p9any) и какая роль (role) испольняется (client). Auth_proxy считывает и записывает файлы factotum'а и дескриптор файла аутентификации afd, для проверки прав пользователя на доступ к сервису. Если вызов прошел успешно, любые вспомогательные данные хранящиеся в структуре AuthInfo становятся доступны. В любом случае, mount вызывается с afd (предположительно валидным). Сервер 9P может иницировать сбой системным вызовом fauth, как показатель того, что аутентификация не обязательна для доступа к сервису.

Второй аргумент у auth_proxy это функция, в данном случае amount_getkey, вызываемая если секретная информация, такая как пароль или отклик необходимы для дальнейшей аутентификации. Конечно, эта функция предоставит информацию factotum как ключевое сообщение для файла /mnt/factotum/ctl.

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

Другой пример, показывает сервер cpu в Plan 9, который экспортирует локальные устройства в shell-процесс на удаленной машине, обычно для подключения локального экрана и клавиатуры к более мощному компьютеру. В ядре, cpu является супернабором сервисов названном exportfs [Pike93], которое позволяет одной машине видеть сулчайную часть файлового пространства имен другой машины, так же для экспортирования сетевого устройства (сетевой карты) другой машины в качестве шлюза. Тем не менее, cpu это не только exportfs, потому что он также доставляет сигнали как например прерывания и взаимодействует с начальным окружением для удаленного интерпретатора.

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

    /* client */

    int
    p9auth(int fd)
    {
        AuthInfo *ai;
        ai = auth_proxy(fd, auth_getkey, "proto=p9any role=client");
        if(ai == NULL)
            return -1;
        /* start cpu protocol here */
    }
    
    /* server */

    int
    srvp9auth(int fd, char *user)
    {
        AuthInfo *ai;
        ai = auth_proxy(fd, NULL, "proto=p9any role=server");
        if(ai == NULL)
            return -1;
        /* set user id for server process */
        if(auth_chuid(ai, NULL) < 0)
            return -1;
        /* start cpu protocol here */
    }

Auth_chuid инкапсулирует взаимодействие для изменения пользовательского id при помощи файлов caphash и capuse на стороне сервера. Отметьте, что даже если клиентский процесс может зарпосить у пользователя новый ключ, при помощи auth_getkey, компьютер-сервер предположительно разделяемая машина в псевдо-пользователем в качестве владельца хоста, установит получающую ключи функцию в NULL.

5. Защищенное хранилище / Безопасное хранилище[]

Factotum хранит ключи в пямяти не сохраняющий информацию при выключении электропитания, которая должна каким-то образом инициализироваться во время загурзки компьютера. Поэтому factotum должен дополнительно с постоянного носителя, например флоппи-диска содержащего ключевой файл скопировать его в /mnt/factotum/ctl во время загрузки. Но съемные носители неудобны для перевозки и подвержены риску кражи. Ключи должны храниться в зашифрованной файловой системе с разделяемым доступом, но только если эти ключи не необходимы для аутентификации файловой системы в первую очередь. Даже если ключи зашифрованы пользовательским паролем, вор может добиться успехапроведя атаку по словарю. Другие риски локального хранилища - потеря содержимого в случае механической порчи или севших батарей. Поэтому для удобства и безопасности мы предоставляем в сети сервер secstore (secure store - безопасное хранилище) которое хранит для каждого пользователя список его первичных ключей, ключевой файл.

Secstore это файловый сервер для зашифрованной информации, используемый только во время загрузки. Он должен обеспечить надежную аутентификацию и усточивость к пассивным и активным атакам протокола не принимая ничего кроме клиентского пароля. Только factotum загрузив файл ключей, для дальнейшей аутентификации или шифрации файл-хранилища может завершить это при помощи стандартных механизмов.

Криптографическая технология которая позволяет secstore сформировать зашифрованный обмен ключами называется PAK [Boyk00], аналогична EKE [Bell93], SRP [Wu98], или SPEKE [Jabl]. PAK была отобрана потому что она по силе эквивалентна алгоритму Diffie-Hellman; едва уловимые утечки в ранних протоколах ключей обмена побудили нас подойти к этому вопросу со всей тщательностью. В общих чертах, протокол PAK есть:

C->S: C,gxH
S->C: S,gy,hash(gxy,C,S)
C->S: hash(gxy,S,C)

где H предварительно известный пароль обоим и клиенту C и серверу S. Есть несколько вариантов PAK,все они описаны документально с доказательствами их криптографических свойств. В помощь тем кто реализует алгоритмы, мы отделили их описание в раздел Приложение. Open source лицензия Plan 9 предоставляет для использования патент Lucent для зашифрованного обмена ключами.

Дальнейший уровень обороны от кражи паролей, мы обеспечиваем (при шифровании канала C->S) сообщения что они проверены на RADIUS-сервере, таком как цифровая форма аппаратного ключа (token) [RFC2138]. Он обеспечивает двух-факторную аутентификацию (т.е. при участии двух сторон), которая будет успешной только в случае, если удасться обмануть двух независимых администраторов одной из атак социальной инженерии.

Файл ключей хранится на сервере зашифрованный по алгоритму AES (Rijndael) с использованием CBC с 10-байтовым вектором инициализации и замыкающим аутентификационным подкладкой (padding). Все это невидимо для пользователя secstore. По сути, это невидимо и для сервера secstore, если для AES стандартизируют новый формат шифрования, он может быть реальзован клиентом без изменения сервера. Хранилище secstore преднамеренно не сохраняется в резервных копиях, пользователь может использовать более одного secstore или хранить файл ключей на съемном носителе. Пользовательский пароль хэшируется создавая H, для использования в протоколе PAK; другой хэш пароля как ключ шифрования файла. И наконец, существует команда (внутри аутентифицированного, зашифрованного канала между клиентом и secstore) для изменения пароляпутем посылки нового H; для логичности, клиентский процесс должен в то же самое время извлечь и перекодировать все файлы.

Когда factotum запускается, он соединяется с локальным secstore и проеряет имеет ли пользователь аккаунт. Если это так, он спрашивает пользовательский пароль от secstore и извлекает из него файл ключей. Протокол PAK гарантирует взаимную аутентификацию и предотвращает атаку по словарю, или перехват пароля при прослушивании соединения, или утечку пароля при активном внедрении. Пароли сохраненные в файле ключеймогут быть длинными строками случайных символов предназначенные для простых протоколов вызов/отклик. Следовательно, пользователю нужно запомнить единственный, слабый пароль для разрешения сильной централизованной аутентификации оставляя без изменения наследие из программ разбросанных между несколькими доменами аутентификации.

6. Транспортный уровень безопасности / TLS[]

Во время разработки операционныой системы Plan 9, предполагалось что она будет использоваться в элементах сети которые подвержены прямым атакам, не защищены файерволами или VPN, мы искали гарантии того что все приложения каналы со взаимной аутентификацией и шифрованием. Для этого за основу было взято TLS 1.0 [RFC2246]. (TLS 1.0 это практически то же само, что и SSL 3.0, и наше программное обеспечение проектировалось для взаимодействия с обоими стандартами.)

TLS определяет протокол уровня записей для целостности сообщения и секретности посредством подписывания сообщения и шифрования разделяемым ключом. Мы реализовали эту службу как устройство ядра, хотя они и будет исполняться со слегка завышенными затратами при помощи вызова отдельной программы. Библиотечный интерфейс к TLS устройству ядра:

int pushtls(int fd, char *hashalg, char *cryptalg, int isclient, char *secret, char *dir);

Передаются файловый дескриптор, имена дайджеста и алгоритма шифрования, и разделяемый секрет, pushtls возвращает новый файловый дескриптор для зашифрованного соединения. (Последний аргумент - dir принимает название директории в устройстве TLS которое ассоциируется с новым соединением.) Функция названа по аналогии с операцией "push" поддерживаемой системой потокового ввода-вывода в Research Unix и двух первых редакциях Plan 9. Поскольку добаление шифрования это просто замена одного фалового дескриптора на другой, добавление шифрования в обчный сетевой сервис становится тривиальным.

В Plan 9 протокол аутентификации с разделяемым ключом устанавливается с взаимным 56-битным паролем. Родные сетевые сервисы Plan 9 такие как cpu и exportfs используют эти протоколы для аутентификации и затем вызывают pushtls с общим секретом.

Над уровнем записей, TLS определяет протокол рукопожатия использующий публичные ключи для установления сессионного секрета. Этот протокол широко используется с HTTP и IMAP4 для предоставления серверной аутентификации, через клиентский сертификат дающий возможность произвести взаимную аутентификацию. Библиотечная функция int tlsClient(int fd, TLSconn *conn)

обслуживает начальное рукопожатие и возвращяет результат pushtls. По возвращении она заполняет структуру conn сессионным ID и сертификатом X.509 пердставленным сервером, но не прикладывает усилий для проверки этого сертификата. Хотя в первоначальном дизайне намеревались работать с сертификатами X.509 в инфрастуктуре с публичными ключами, дальнейшее равертывание затягивалось и было проблематичным, так что мы усвоили простую политику простого использования сертификатов X.509 как представления публичного ключа, в зависимости от локально администрируемой директории с отпечатками SHA1 позволяющим приложениям решить какому публичному ключу доверять и с какой целью.

7. Дальнейшая работа и дискуссии[]

Kerberos, одна из ранних распределенных систем аутентификации, хранит набот аутентификационных тикетов во временном файле, называемом кэшем тикетов. Кэш тикетов защищен правами файловой системы Unix. Переменная окружения содержит имя файла кэша тикетов, делая возможным разным кэшам тикетов участвовать в обновременных разных сессиях. Пользователь авторизуется пибирая его или ее пароль Kerberos. программа login пользуется паролем Kerberos для получения временного тикета - дарственный тикет, и затем забывает пароль. Другое приложение может воспользоваться дарственным тикетом для подписывания своих тикетов в защиту пользователя на время сессии. Кэш тикетов разблокируется всякий раз когда требуется аутентификация и пользователь набирает пароль.

Разработчики SSH развили эту идею дальше, заменив временный файл на именованные сокеты Unix соединенные с программой уровня пользователя, названную агентом. Когда агент запускаетя и инициализируется одиним или более приватным ключом RSA, клиент SSH может использовать его для осуществления аутентификации RSA в своих нуждах. При отсутствии агента, клиент SSH обычно считывает ключи RSA с зашифрованного файла или применяет аутентификацию основанную на вводе пароля, обе они запрашивают ключевую фразу когда возникает потребность в аутентификации [Ylon96]. Самоподписанная файловая система (self-certifying file system) SFS использует похожий агент [Kami00], ограничения использования ключей клиентской аутентификации но также и для проверки публичных ключей сервера [Mazi99].

Factotum является логическим продолжателем этой эволюции, заменяя программно зависимые агенты SSH или SFS общим агентом способным обслуживать широкий спектр программ. При наличии одного агента для всех программ отпадает поребность иметь одного агента на каждую программу. Также это дает самим программам быть протоколонезависимым, так что, например, одна может быть построена по типу SSH и пользоваться к любым протоколом который поддерживает factotum, без того чтобы программа хоть что-нибудь о протоколах. Тардиционно каждая программа нуждалась в реализации каждого протокола аутентификации для себя, и проблему кодирования O(n2) factotum сократил до O(n).

Предыдущая работа над агентом была сосредоточена на его использовании в клиентской аутентификации с серверами. Посмотрев в другом направлении, подключаемый модуль аутентификации (PAM) от Sun Microsystem явился ранней попыткой предоставить общий аутентификационный механизм для Unix-подобных операционных систем [Sama96]. Без центра авторизации как в случае с PAM системные политики были связаны с различными реализациями сертевых служб. Например, в типичной Unix-системе, если системынй администратор решил не пользоваться чисто-текстовыми паролями для аутентификации целый набор конфигурационых файлов необходимо было отредактировать -- rlogind, telnetd, ftpd, sshd, и т.д. PAM решал проблемы скрывая детали данного механизма аутентификации за обычным библиотечным интерфейсом. Управляемый единственным системным конфигурационным файлом, приложение выбирало особый механизм аутентификации динамически загружая подходящую разделяемую библиотеку. PAM широко используется в Sun Solaris и некоторых дистрибутивах Linux.

Factotum добивается тех же целей применяя подход с агентом. Factotum является единственным процессом который нуждается в способностях создавать, так чтобы все сетевые серверы могли запускаться как недоверные пользователи (Plan 9 none или Unix nobody), которые значительно снижают ущерб если сервер бажный или скомпрометирован. Фактически, если factotum будет реализован в среде Unix, c аналогом с утройстваcapability Plan9, уязвимым программам типа su и login не нужно будет устанавливать setuid бит.

Некоторые другие системы, такие как Password Safe [Schn], хранят многочисленные пароли в зашифрованном файле, так что пользователю нужно запомнить единственный пароль. Наше решение secstore отличается от него, помещая хранилище в труднодоступное место в сети, так что зашифрованный файл меньне подвержен риску быть украденным для последующей атаки по словарю и так же он доступен когда пользователь работает с несколькими компьютерами. В отличии от системы Microsoft Passport [Micr] хранящейудостоверения в сети, но сосредоточены на одной исключительно значимой цели. Важное значение Passport состоит в установлении доверительных отношений с олайн-торговлей, выходящей за пределы нашего рассмотрения. Архитектура secstore в основном идентична архитектуре Perlman and Kaufman [Perl99] однако содержит новую технологию EKE. Подобно им, мы избрали защиту в основном от внешних атак на secstore; для дополнительной защиты файлов на сервере по желанию могут применяться распределенные техники [Ford00].

Мы сделали осознанный выбор помещая шифрование, целостность сообщений и управление ключами на уровень приложений (TLS, лежит на уровне выше 4), вместо того чтобы разместить на 3-м уровне, как в IPsec. Это привело к упрощению структуры сетевого стека, легкой интеграции с приложениями и что наиболее важно, легкому сетевому администрированию, как только мы обнаружили какие приложения ведут себя непристойно по номерам TCP портов. TLS страдает (относительно IPsec) от возможности забыть TCP Reset, но мы чувствовали, что это будет адекватная сделка по рандомизации числа последовательности TCP. В стравнении с другими библиотеками TLS, Plan 9 не требует изменения приложений для смены вызовов write на sslwrite, а просто добавление нескольких новых строк кода на старте [Resc01].Мы сделали осознанный выбор помещая шифрование, целостность сообщений и управление ключами на уровень приложений (TLS, лежит на уровне выше 4), вместо того чтобы разместить на 3-м уровне, как в IPsec. Это привело к упрощению структуры сетевого стека, легкой интеграции с приложениями и что наиболее важно, легкому сетевому администрированию, как только мы обнаружили какие приложения ведут себя непристойно по номерам TCP портов. TLS страдает (относительно IPsec) от возможности забыть TCP Reset, но мы чувствовали, что это будет адекватная сделка по рандомизации числа последовательности TCP. В стравнении с другими библиотеками TLS, Plan 9 не требует изменения приложений для смены вызовов write на sslwrite, а просто добавление нескольких новых строк кода на старте [Resc01].

8. Заключение[]

Написание безопасного кода сложная задача. Атаки на стек, ошибки в логике, баги в компиляторе и операционных системах, каждая делает возможным для атакующего нарушить последовательность выполнения в сервисе. Если процесс сервера имеет преимущества привелегированного пользователя, такого как root в Unix, тогда это на руку нападающему. Factotum позволил нам заключить за решетку привелегированное испольнение в единственный процесс ядро которого состоит всего из тысячи строк кода. Проверять такой процесс, как вручную, так и автоматически намного проще и снижается число ошибок которые отражаются на всех серверах.

Реализация этих идей есть в четвертой редакции Plan 9 от Bell Labs, свободно доступной по адресу http://plan9.bell-labs.com/plan9.

9. Признательности[]

William Josephson внес реализацию изменения пароля в secstore. Мы благодарим Phil MacKenzie и Martín Abadi за полезные коментарии на ранних этапах разработки. Chuck Blake, Peter Bosch, Frans Kaashoek, Sape Mullender, и Lakshman Y. N., predominantly Dutchmen, дали полезные замечания этому документу. Russ Cox'а поддержали товарищеские отношения со стороны Fannie и John Hertz Foundation.

Ссылки[]

[Bell93] S.M. Bellovin and M. Merritt, ``Augmented Encrypted Key Exchange, Proceedings of the 1st ACM Conference on Computer and Communications Security, 1993, pp. 244 - 250.

[Boyk00] Victor Boyko, Philip MacKenzie, and Sarvar Patel, ``Provably Secure Password-Authenticated Key Exchange using Diffie-Hellman, Eurocrypt 2000, 156­171.

[RFC2246] T . Dierks and C. Allen, ``The TLS Protocol, Version 1.0, RFC 2246.

[Ford00] Warwick Ford and Burton S. Kaliski, Jr., ``Server-Assisted Generation of a Strong Secret from a Password, IEEE Fifth International Workshop on Enterprise Security, National Institute of Standards and Technology (NIST), Gaithersburg MD, June 14 - 16, 2000.

[Jabl] David P. Jablon, ``Strong Password-Only Authenticated Key Exchange, http://integritysciences.com/speke97.html.

[Kami00] Michael Kaminsky. ``Flexible Key Management with SFS Agents, Master's Thesis, MIT, May 2000.

[Mack] Philip MacKenzie, private communication.

[Mazi99] David Mazières, Michael Kaminsky, M. Frans Kaashoek and Emmett Witchel, ``Separating key management from file system security, Symposium on Operating Systems Principles, 1999, pp. 124-139.

[Micr] Microsoft Passport, http://www.passport.com/.

[Perl99] Radia Perlman and Charlie Kaufman, ``Secure Password-Based Protocol for Downloading a Private Key, Proc. 1999 Network and Distributed System Security Symposium, Internet Society, January 1999.

[Pike95] Rob Pike, Dave Presotto, Sean Dorward, Bob Flandrena, Ken Thompson, Howard Trickey, and Phil Winterbottom, ``Plan 9 from Bell Labs, Computing Systems, 8, 3, Summer 1995, pp. 221-254.

[Pike93] Rob Pike, Dave Presotto, Ken Thompson, Howard Trickey, Phil Winterbottom, ``The Use of Name Spaces in Plan 9, Operating Systems Review, 27, 2, April 1993, pp. 72-76 (reprinted from Proceedings of the 5th ACM SIGOPS European Workshop, Mont Saint-Michel, 1992, Paper nº 34).

[Resc01] Eric Rescorla, ``SSL and TLS: Designing and Building Secure Systems, Addison-Wesley, 2001. ISBN 0-201-61598-3, p. 387.

[RFC2138] C. Rigney, A. Rubens, W. Simpson, S. Willens, ``Remote Authentication Dial In User Service (RADIUS), RFC2138, April 1997.

[RiLa] Ronald L. Rivest and Butler Lampson, ``SDSI--A Simple Distributed Security Infrastructure, http://theory.lcs.mit.edu/~rivest/sdsi10.ps.

[Schn] Bruce Schneier, Password Safe, http://www.counterpane.com/passsafe.html.

[Sama96] Vipin Samar, ``Unified Login with Pluggable Authentication Modules (PAM), Proceedings of the Third ACM Conference on Computer Communications and Security, March 1996, New Delhi, India.

[Stei88] Jennifer G. Steiner, Clifford Neumann, and Jeffrey I. Schiller, ``Kerberos: An Authentication Service for Open Network Systems, Proceedings of USENIX Winter Conference, Dallas, Texas, February 1988, pp. 191­202.

[Wu98] T. Wu, ``The Secure Remote Password Protocol, Proceedings of the 1998 Internet Society Network and Distributed System Security Symposium, San Diego, CA, March 1998, pp. 97-111.

[Ylon96] Ylonen, T., ``SSH--Secure Login Connections Over the Internet, 6th USENIX Security Symposium, pp. 37-42. San Jose, CA, July 1996.

Appendix: Summary of the PAK protocol

Let q>2^160 and p>2^1024 be primes such that p=rq+1 with r not a multiple of q. Take h�УУZp* such that g==h^r is not 1. These parameters may be chosen by the NIST algorithm for DSA, and are public, fixed values. The client C knows a secret ьЅ and computes H==(H1(C, ьЅ))r and H^-1, where H1 is a hash function yielding a random element of Zp*, and H^-1 may be computed by gcd. (All arithmetic is modulo p.) The client gives H^-1 to the server S ahead of time by a private channel. To start a new connection, the client generates a random value x, computes m==g^xH, then calls the server and sends C and m. The server checks m!=0 mod p, generates random y, computes ыЙ==g^y, ьА==(mH^-1)y, and sends S, ыЙ, k==sha1("server",C,S,m,ыЙ,ьА,H-1). Next the client computes ьА=ыЙx, verifies k, and sends k´==sha1("client",C,S,m,ыЙ,ьА,H^-1). The server then verifies k´ and both sides begin using session key K==sha1("session",C,S,m,ыЙ,ьА,H^-1). In the published version of PAK, the server name S is included in the initial hash H, but doing so is inconvenient in our application, as the server may be known by various equivalent names.

MacKenzie обозначен [Mack] что эквивалентно ссылке [Boyk00] can be adapted to cover our version.

Copyright © 2002 Lucent Technologies. All rights reserved.

Источник: http://www.usenix.org/events/sec02/cox/cox_html/index.html

Advertisement