Аутентификация по аппаратным токенам в дистрибутивах Альт (Павел Волнейкин, OSSDEVCONF-2017)

Короткая ссылка: 20170924D

Докладчик: Павел Волнейкин

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

Видео

on youtube

Посмотрели доклад? Понравился? Напишите комментарий! Не согласны? Тем более напишите.

Презентация

Thesis

Состав и настройка программного обеспечения

Набор программ, имеющих отношение к аутентификации по аппаратным токенам, довольно большой. В него мы включаем:

собственно модуль аутентификации — pam_pkcs11.so;
криптографическую библиотеку libcrypto.so (OpenSSL);
дополнения к криптографической библиотеке, реализующие разные

   способы шифрования (engines);

модули доступа к токену (различные реализации PKCS\#11);
модули и библиотеки, реализующие различные способы установки

   соответствия между записанными на токене данными и учётными
   записями пользователей;

служба, обеспечивающая раздельный, низкоуровневый доступ к токену

   (обычно по по USB);

служба, следящая за такими событиями, как подключение и удаление

   токена;

программы, выполняющиеся как реакция на указанные события;
программа, управляющая пользовательскими сеансами;
программа-гритер, предоставляющая диалог входа в систему.

Нетрудно догадаться, что взаимосвязанная настройка всего этого комплекса программ — задача совсем не простая. Поэтому в первую очередь мы подумали о том, как упростить её решение. При этом ориентировались сразу на два сценария настройки: настройка, выполняемая администратором системы и предварительная настройка, выполняемая на этапе подготовки образа дистрибутива и его установки. Последнее связано с тем, что Альт является не только системой для конечного пользователя, но и платформой для изготовления дистрибутивов.

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

В итоге, у нас получились следующие группы параметров:

взаимодействие с определённой моделью токенов;
отображение сертификатов на имена пользователей;
доверие и проверка сертификатов;
прочие параметры PKCS\#11, включая политику взаимодействия с

   токеном (ожидание подключения, запрос PIN-кода и т.\,п.);

политика входа в систему (без использования токена / с

   обязательным использованием токена и т.\,д.);

отслеживание состояния токена и реакция на события;
настройка автоматической регистрации учётных записей.

Почти для всех этих групп определённый набор конечных параметров задаётся теперь отдельным файлом, а общая конфигурация определяется выбором того или иного файла для каждой из них (через \Q{control}). Это позволяет легко добавлять новые варианты конфигурации и поставлять их в пакетах. Исключение пока составляет настройка набора доверенных сертификатов и шифров.

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

Как можно видеть, даже после группировки количество параметров остаётся довольно значительным, и следовательно, в таком виде процедура настройки аутентификации по аппаратным токенам представляет ещё известную трудность для пользователя. Чтобы ещё больше упростить её, был написан модуль Альтератора alteratorauth-token. Главные из перечисленных выше параметров представлены в нём в наглядном виде, а другая часть параметров скрыта и поставлена во взаимно-однозначную связь с видимыми. Модуль представляет интерес не только для конечных пользователей и администраторов систем, но и для разработчиков дистрибутивов, поскольку он полностью готов для встраивания в инсталлятор и поддерживает передачу параметров для преднастройки.

Предварительная конфигурация во время установки ОС

Что такое преднастройка в Альтераторе и для чего она может понадобится?

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

С необходимостью реализовать преднастройку мы столкнулись тогда, когда подключили \Q{alteratorauth-token} к инсталлятору. Тогда мы обратили внимание, что молуль инсталлятора отличается от обычного молуля тем, что его диалоговое окно играет роль предложения по настройке системы, а не обычную роль индикаторной панели, рассказывающей о текущем состоянии системы. Это наверняка справедливо для любого модуля инсталлятора, но для нашего усугублялось тем, что в нём для режима инсталлятора нельзя было ограничиться одним единственным набором значений по умолчанию. Было ясно, например, что, в зависимости от целевого назначения дистрибутива и аудитории, будет уместно предложить пользователю включить схему аутентификации для определённой модели или семейства токенов.

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

О типовых задачах и вариантах настройки аутентификации

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

Первое, что мы постарались обеспечить, это возможность включить такой режим, при котором наличие токена было бы обязательным для нормального использования системы. По-сути, это — возможность шире задействовать потенциал первого из двух факторов аутентификации. Исключение было сделано для пользователей с повышенными правами (администраторов) — для них мы предусмотрительно оставили возможность войти в систему без использования токена, по одному только паролю. Совершение входа по токену, тем не менее, делает обязательным его наличие во время сеанса работы и для этой категории пользователей. Извлечение токена сопровождается временной блокировкой сеанса. Для возобновления работы необходимо подключить токен и ввести верный PIN-код.

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

Несколько слов о том, какие способы идентификации пользователей доступны. Прежде всего это сличение по сертификату. Оно основано на поиске записанного на токене сертификата в содержимом файлов .ssh/authorized_keys в домашних директориях пользователей. И хотя ясно, что прямой поиск работает неоптимально, но на мой взгляд, этот вариант вполне оправдан для систем с небольшим количеством пользователей, поскольку очень прост в настройке. А иногда даже не требует дополнительной настройки, поскольку файл authorized_keys часто уже присутствует и содержит нужные данные. Аналогичная процедура поиска выполняется также для файлов в директории .eid/ и подходит для случая, когда удалённый доступ по сертификату к системе не предоставляется.

Кроме сличения сертификатов существует много, я бы сказал, прямых, способов идентификации пользователей. Общей чертой их является то, что имя пользователя берётся непосредственно из того или другого поля сертификата. В самом простом случае это поле CN (common name). Среди других вариантов можно указать поле subject и адрес электронной почты. Однако я должен сказать, что кажущаяся простота использования этих способов обманчива: на самом деле использование этих вариантов связано с большими рисками и должно сопровождаться повышенным вниманием к фактической достоверности записанной на токене информации, а значит, очень высокими требованиями к надёжности её источника. Это означает, что записанное, например, в поле CN имя пользователя должно фактически соответствовать одному, конкретному человеку (или группе людей). В противном случае мы рискуем предоставить постороннему человеку доступ с правами иного лица.

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

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

Предложение начать новый сеанс должно, конечно, сопровождаться автоматической установкой имени пользователя. Реализация этого действия потребовала определённой доработки программы-гритера — диалогового окна входа в систему. Благодаря этой доработке, процедура аутентификации по токену теперь сводится только ко вводу PIN-кода.

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

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

Под настройкой шифров я имею в виду включение и выключение поддержки алгоритмов ГОСТ. Пока это единственный, относящийся к шифрам параметр, который у нас реализован. Главный же недостаток реализации заключается в том, что включение и выключение производится через общесистемную конфигурацию, хотя конфигурационный модуль имеет вполне ясное назначение, связанное с аутентификацией. Причина такого недостатка состоит в том, что модуль аутентификации использует библиотеку crypto OpenSSL с настройками по умолчанию. Я думаю, что мы должны исправить этот момент\footnote{Исправлено в pam_pkcs 0.6.9alt16}.

Второй недостаток касается работы с набором доверенных сертификатов. Здесь ситуация следующая: автоматическое добавление сертификатов в число доверенных реализовано только для набора корневых сертификатов ГОСТ, и при этом, оно выполняется однократно — при включении поддержки шифрования по ГОСТ. Механизма обновления списка доверенных сертификатов пока не предусмотрено. Также, для добавления прочих сертификатов, не входящих в набор корневых сертификатов ГОСТ, никаких инструментов не предусмотрено (вручную это сделать, конечно, можно). Предложения по улучшению ситуации приветствуются.

Автоматическая регистрация учётных записей

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

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

Регистрация учётной записи производится прозрачно для пользователя, в ходе самой аутентификации. Говоря более строго: после аутентификации, но до запуска сеанса работы. Запись регистрируется один раз, в том случае, когда она отсутствует, а затем доступ к ней предоставляется обычным образом.

Для надёжности описанной процедуры есть одно условие: уникальность записи. Для этого, во-первых, доверие к источнику информации должно касаться не только формальной подлинности записанных на токене данных, но и фактической их подлинности, т.\,е. соответствия одному, конкретному человеку (или группе людей). Об этом я уже упоминал, когда рассказывал о прямых способах идентификации. И тот факт, что вычисление имени пользователя может быть весьма «непрямым», не отменяет повышенных требований к уровню доверия. Оно, повторяю, должно быть очень высоким. Второе, что мы должны обеспечить — это уникальное соответствие результата вычисления исходным, идентифицирующим пользователя, данным. Теперь уже для того, чтобы всегда предоставлять одному и тому же человеку доступ именно к его данным в локальной системе, а не к пустой, вновь созданной записи. Иными словами, мы не должны ошибиться в б{о}льшую сторону, считая, что каждый новый сертификат — это всегда новый пользователь. Пользователь, обычно, имеет право обновить свой сертификат и, в ряде случаев, обязан периодически делать это.

Требование уникальности имени пользователя, однако, может входить и входит в противоречие с конфиденциальностью личных данных пользователя. Именно с таким вариантом мы столкнулись, когда выбрали в качестве основы имени пользователя поле СНИЛС сертификата (имеется в виду сертификат ГОСТ). Ясно, что даже если этот конкретный СНИЛС ничего не говорит лично мне, то я всё равно имею возможность использовать его не по назначению, просто потому, что знаю, что это — действительный номер. Это нехорошо. И поэтому мы приняли решение прятать действительный номер за хеш-суммой. Конечно эта мера в известной степени нарушает уникальность имени пользователя, и значит, мы рискуем открыть доступ постороннему. Но на сегодняшний день, ничего лучше для апробации механизма автоматической регистрации учётных записей мы не придумали.

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

Заключение

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

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

Примечания и ссылки

Аутентификация по аппаратным токенам в дистрибутивах Альт (Павел Волнейкин, OSSDEVCONF-2017)!.jpg

Plays:43 Comments:0