Облачная электронная подпись: инструкция по применению

Аутентификация “запрос-ответ”

Как показано на рис. 2.2, сервер генерирует случайный запрос и отправляет его пользователю А[208]. Вместо того чтобы в ответ отправить серверу пароль, пользователь А шифрует запрос при помощи ключа, известного только ему самому и серверу.

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

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

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

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

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

Аутентификация kerberos

Роджер Нидхэм и Михаэль Шредер в 1978 году впервые предложили механизм аутентификации, который базировался на шифровании, но он, к сожалению, не обеспечивал одинаковых гарантий для участвующих в коммуникации сторон [93]. Для решения этой проблемы в Массачусетском технологическом институте в 1985 году была разработана система защиты информационных систем от вторжений, дополняющая механизм Нидхэма-Шредера специальным сервисом выдачи билетов.

Она была названа Kerberos по имени трехглавого пса Цербера, охранявшего ворота в ад в греческой мифологии. Такое название было выбрано, потому что в аутентификации участвовали три стороны: пользователь, сервер, к которому желает получить доступпользователь, и сервер аутентификации, или центр распределения ключей (ЦРК).

Система Kerberos владеет секретными ключами обслуживаемых субъектов и помогает им выполнять взаимную аутентификацию. Сеанс начинается с получения пользователем Абилета для получения билета – Ticket-Granting Ticket (TGT) от ЦРК.

Когда пользователь желает получить доступ к некоторому серверу В, то сначала отправляет запрос на билет для доступа к этому серверу вместе со своим билетом TGT в ЦРК. TGT содержит информацию о сеансе регистрации пользователя А и позволяет ЦРК
оперировать, не поддерживая постоянно информацию о сеансе регистрации каждого пользователя.

В ответ на свой запроспользовательА получает зашифрованный сеансовый ключSA и билет на доступ к серверуВ. Сеансовый ключ зашифрован секретным ключом, известным только пользователю А и ЦРК. Билет на доступ к серверуВ содержит тот же самый сеансовый ключ, однако он шифруется секретным ключом, известным только серверу В и ЦРК.

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

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

Рассмотрим более подробно аутентификацию в системе Kerberos (рис. 2.4), которая выполняется за четыре шага:

1. получение пользователем билета TGT на билеты;
2. получение пользователем билета на доступ к серверу ;
3. аутентификация пользователя сервером;
4. аутентификация сервера пользователем.

Аутентификация при помощи сертификатов

В том случае, когда пользователи имеют сертификатыоткрытых ключей, необходимость в ЦРК отпадает. Это не означает, что отпадает необходимость в доверии и третьих сторонах; просто доверенной третьей стороной становится УЦ.

Аутентификацию при помощи сертификатов обеспечивают несколько распространенных протоколов, в частности, наиболее известный и широко распространенный протокол SecureSocketLayer (SSL), который применяется практически в каждом web-браузере.

Помимо него применяются протоколы Transport LayerSecurity (TLS) [142], InternetKey Exchange (IKE)

[147], S/MIME[169], PGP и OpenPGP[149]. Каждый из них немного по-своему использует сертификаты, но основные принципы – одни и те же.

Рис. 2.5 иллюстрирует типичный обмен сообщениями при аутентификации на базе сертификатов, использующий цифровые подписи [70]. Обмен соответствует стандарту аутентификации субъектов на основе криптографии с открытыми ключами[117].

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

Если серверВ поддерживает метод аутентификации, запрашиваемый пользователем А, то начинается обмен сообщениями. Сообщение Token ID уведомляет о том, что будет выполняться взаимная аутентификация, а также содержит номер версии протокола и идентификатор протокола.

Хотя этот идентификатор не обязателен, он намного упрощает процедуру и поэтому обычно используется. ПользовательА ожидает сообщение Token ВА1 от сервера В. Идентификатор протокола в Token ID позволяет пользователю А удостовериться, что серверВ отправляет ожидаемое сообщение. Token ВА1 состоит только из случайного числа ran B, это – своего рода запрос, корректным ответом должна быть цифровая подпись числа ran B.
ПользовательА подписывает ответ и отправляет свой сертификат ключа подписи, для того чтобы серверВ при помощи открытого ключа мог выполнить валидацию подписи.

ПользовательА подписывает последовательность из трех элементов: свой запросran A, запрос сервера ran B и имя сервера name B. Ran A – это запросА к серверу В, гарантирующий, что пользовательА подписывает не произвольное сообщение сервера В или другого субъекта, выдающего себя за серверВ.

Получив ответ Token АВ от пользователя А, серверВ проверяет, совпадает ли значениеran B с соответствующим значением в сообщении Token ВА1, а по значению name В устанавливает, действительно ли пользовательА желает пройти аутентификацию сервера В.

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

Ответ сервера Token ВА2 состоит из заверенной цифровой подписью последовательности трех элементов: ran A, ran B и name A, где ran A – запрос, сгенерированный А, ran B – исходный запрос сервера В, а name A – имя пользователяА.

Получив ответ сервера, пользовательА убеждается, что ran A имеет то же самое значение, что и в сообщении Token АВ, а проверяя значениеname A – что серверВ намерен аутентифицировать именно его (пользователя А ).

Если какая-либо из проверок дает отрицательный результат, то и аутентификация завершается неудачно. В противном случае пользовательА проверяет подлинность сертификата сервера В и его цифровой подписи.

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

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

Аутентификация сервера пользователем

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

Этот шифртекст и является ответом сервера: KAB [время 1]. Пользователь А получает ответ сервера и расшифровывает его ключом KAB.

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

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

Система Kerberos – это мощный механизм, поддерживающий взаимную аутентификацию и аутентификацию пользователя на многих удаленных серверах. Пользователь может аутентифицировать себя в открытой сети или проверить идентичность удаленного сервера при помощи того же самого механизма, который используется для подтверждения его собственной идентичности [81].

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

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

Инициализация открытых ключей kerberos

Инициализация открытых ключей Kerberos (Kerberos Public Key Initialization – PKIINIT) вносит изменения в процедуру начального обмена с ЦРК, а все остальное оставляет без изменений [70].

В своем запросе пользователь А отправляет сертификат ключа подписи и подписанный открытый ключ. Сертификат ключа подписи пользователя А содержит имя А и открытый ключ, используемый для проверки подлинности цифровых подписей, сгенерированных пользователем А. Открытый ключ будет использоваться для управления ключами; он может быть либо ключом транспортировки ключей
( открытый ключRSA ) либо ключом согласования ключей ( открытый ключ Диффи-Хэллмана). ЦРК проверяет цифровую подпись, чтобы гарантировать, что открытый ключ принадлежит пользователю А.

Формат ответа ЦРК зависит от типа ключа пользователя А. Если пользователь А использует открытый ключ Диффи-Хэллмана, то ЦРК возвращает его подписанным при помощи открытого ключа Диффи-Хэллмана.

Пользователь проверяет цифровую подпись, чтобы убедиться, что ответ принадлежит ЦРК. И пользователь А, и ЦРК вычисляют один и тот же симметричный ключ при помощи алгоритма Диффи-Хеллмана и используют его как сеансовый ключSA.

Пользователь А может использовать и открытый ключRSA.
В этом случае ЦРК генерирует временный симметричный ключ и шифрует его при помощи открытого ключа ( RSA ) пользователя А.

Кроме того, ЦРК генерирует и заверяет цифровой подписью второй симметричный ключ, который будет использоваться как сеансовый ключSA. Затем подписанный ключ SA шифруется при помощи временного ключа и отправляется пользователю А вместе с временным ключом, зашифрованным открытым ключом ( RSA ) пользователя А.

Пользователь А может извлечь ключ SA, расшифровав сначала временный ключ при помощи своего секретного ключа ( RSA ),
а потом использовав этот временный ключ для окончательного расшифрования подписанного ключа SA.

Без сертификатаЦРК был бы необходим другой механизм аутентификации открытого ключа пользователя А. Связывание имени пользователя А с его открытым ключом подписи позволяет ЦРК аутентифицировать запрос. ЦРК полагается на удостоверяющий центр (УЦ) для подтверждения того, что пользователь А владеет секретным ключом, соответствующим открытому ключу, указанному в сертификате.

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

Многофакторная аутентификация

В последнее время всё чаще применяется так называемая расширенная, или многофакторная, аутентификация. Она построена на совместном использовании нескольких факторов аутентификации. Это значительно повышает защищённость системы.

В качестве примера можно привести использование SIM-карт в мобильных телефонах. Субъект вставляет аппаратно свою карту (устройство аутентификации) в телефон и при включении вводит свой PIN-код (пароль).

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

Можно привести сравнительную таблицу:

Наиболее используемые биометрические атрибуты и соответствующие системы

• Отпечатки пальцев. Такие сканеры имеют небольшой размер, универсальны, относительно недороги. Биологическая повторяемость отпечатка пальца составляет 10⁻⁵ %. В настоящее время пропагандируются правоохранительными органами из-за крупных ассигнований в электронные архивы отпечатков пальцев.
• Геометрия руки. Соответствующие устройства используются, когда из-за грязи или травм трудно применять сканеры пальцев. Биологическая повторяемость геометрии руки около 2 %.
• Радужная оболочка глаза. Данные устройства обладают наивысшей точностью. Теоретическая вероятность совпадения двух радужных оболочек составляет 1 из 10⁷⁸.
• Термический образ лица. Системы позволяют идентифицировать человека на расстоянии до десятков метров. В комбинации с поиском данных по базе данных такие системы используются для опознания авторизованных сотрудников и отсеивания посторонних. Однако при изменении освещенности сканеры лица имеют относительно высокий процент ошибок.
• Распознавание по лицу. Системы на основе данного подхода позволяют идентифицировать персону в определенных условиях с погрешностью не более 3 %. В зависимости от метода позволяют идентифицировать человека на расстояниях от полуметра до нескольких десятков метров. Данный метод удобен тем, что он позволяет реализацию штатными средствами (веб-камера и т. п.). Более сложные методы требуют более изощренных устройств. Некоторые (не все) методы обладают недостатком подмены: можно провести идентификацию подменив лицо реального человека на его фотографию.
• Голос. Проверка голоса удобна для использования в телекоммуникационных приложениях. Необходимые для этого 16-разрядная звуковая плата и конденсаторный микрофон стоят менее 25 $. Вероятность ошибки составляет 2 — 5 %. Данная технология подходит для верификации по голосу по телефонным каналам связи, она более надежна по сравнению с частотным набором личного номера. Сейчас развиваются направления идентификации личности и его состояния по голосу — возбужден, болен, говорит правду, не в себе и т. д.
• Ввод с клавиатуры. Здесь при вводе, например, пароля отслеживаются скорость и интервалы между нажатиями.
• Подпись. Для контроля рукописной подписи используются дигитайзеры

В то же время биометрическая аутентификация имеет ряд недостатков:

1. Биометрический шаблон сравнивается не с результатом первоначальной обработки характеристик пользователя, а с тем, что пришло к месту сравнения. За время пути может много чего произойти.
2. База шаблонов может быть изменена злоумышленником.
3. Следует учитывать разницу между применением биометрии на контролируемой территории, под бдительным оком охраны, и в «полевых» условиях, когда, например, к устройству сканирования могут поднести муляж и т. п.
4. Некоторые биометрические данные человека меняются (как в результате старения, так и травм, ожогов, порезов, болезни, ампутации и т. д.), так что база шаблонов нуждается в постоянном сопровождении, а это создает определенные проблемы и для пользователей, и для администраторов.
5. Если у Вас крадут биометрические данные или их компрометируют, то это, как правило, на всю жизнь. Пароли, при всей их ненадежности, в крайнем случае можно сменить. Палец, глаз или голос сменить нельзя, по крайней мере быстро.
6. Биометрические характеристики являются уникальными идентификаторами, но их нельзя сохранить в секрете.

Настройка двухфакторной аутентификации в домене windows

Теоретическая часть:

Служба каталога Active Directory поддерживает возможность аутентификации с помощью смарт-карты и токена, начиная с Windows 2000. Она заложена в расширении PKINIT (public key initialization — инициализация открытого ключа) для протокола Kerberos RFC 4556 .

Протокол Kerberos был специально разработан для того, чтобы обеспечить надежную аутентификацию пользователей. Он может использовать централизованное хранение аутентификационных данных и является основой для построения механизмов Single Sing-On. Протокол основан на ключевой сущности Ticket (билет).

Ticket (билет) является зашифрованным пакетом данных, который выдается доверенным центром аутентификации, в терминах протокола Kerberos — Key Distribution Center (KDC, центр распределения ключей).

Когда пользователь выполняет первичную аутентификацию после успешного подтверждения его подлинности, KDC выдает первичное удостоверение пользователя для доступа к сетевым ресурсам — Ticket Granting Ticket (TGT).

В дальнейшем при обращении к отдельным ресурсам сети, пользователь, предъявляет TGT, получает от KDC удостоверение для доступа к конкретному сетевому ресурсу — Ticket Granting Service (TGS).

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

Расширение PKINIT позволяет использовать двухфакторную аутентификацию по токенам или смарт-картам на этапе предаутентификации Kerberos.

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

Все контроллеры доменов должны иметь установленный сертификат Domain Controller Authentication, или Kerberos Authentication, т. к. реализуется процесс взаимной аутентификации клиента и сервера.

Практика:

Приступим к настройке.

Сделаем так, чтобы в домен под вашей учетной записью можно было зайти только по предъявлению токена и зная PIN-код.

Для демонстрации мы будем использовать Рутокен ЭЦП PKI производства компании «Актив».

1 Этап — Настройка домена Первым делом установим службы сертификации.

Дисклеймер.

Эта статья не является туториалом по внедрению корпоративного PKI. Вопросы проектирования, разворачивания и грамотного применения PKI тут не рассматриваются ввиду необъятности этой темы.

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

Задача центра сертификации — подтверждать подлинность ключей шифрования с помощью сертификатов электронной подписи.

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

Удостоверяющий центр, выдающий сертификаты для использования смарт-карт или токенов, должен быть помещен в хранилище NT Authority.

Зайдите в Диспетчер сервера и выберите «Добавить роли и компоненты».

При добавлении ролей сервера выберите «Службы сертификации Active Directory» (Microsoft категорически рекомендует не делать это на контроллере домена, дабы не огрести проблем с производительностью). В открывшемся окне выберите «Добавить компоненты» и выберите пункт «Центр сертификации».

На странице для подтверждения установки компонентов нажмите «Установить».

2 Этап — Настройка входа в домен с помощью токена

Для входа в систему нам понадобится сертификат, который содержит идентификаторы Smart Card Logon и Client Authentication.

Сертификат для смарт-карт или токенов также должен содержать UPN пользователя (суффикс имени участника-пользователя). По умолчанию суффиксом имени участника-пользователя для учетной записи является DNS-имя домена, которое содержит учетную запись пользователя.

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

В сертификате должен быть указан путь к точке распространения списка отзыва сертификатов (CRL distribution point). Такой файл содержит список сертификатов с указанием серийного номера сертификата, даты отзыва и причины отзыва. Он используется для передачи сведений об отозванных сертификатах пользователям, компьютерам и приложениям, пытающимся проверить подлинность сертификата.

Настроим установленные службы сертификации. В правом верхнем углу нажмите на желтый треугольник с восклицательным знаком и щелкните «Настроить службы сертификации…».

В окне «Учетные данные» выберите необходимые учетные данные пользователя для настройки роли. Выберите «Центр сертификации».

Выберите «ЦС предприятия».

ЦС предприятия интегрированы с AD. Они публикуют сертификаты и списки отзыва сертификатов в AD.

Укажите тип «Корневой ЦС».

На следующем этапе выберите «Создать новый закрытый ключ».

Выберите период действия сертификата.

3 этап — Добавление шаблонов сертификатов

Для добавления шаблонов сертификатов откройте Панель управления, выберите пункт «Администрирование» и откройте Центр сертификации.

Щелкните по названию папки «Шаблоны сертификатов», выберите пункт «Управление».

Щелкните по названию шаблона «Пользователь со смарт-картой» и выберите пункт «Скопировать шаблон». На следующих скриншотах показано, какие параметры в окне «Свойства нового шаблона» необходимо изменить.

Если в списке поставщиков нет «Aktiv ruToken CSP v1.0», то необходимо установить комплект «Драйверы Рутокен для Windows».

Начиная с Windows Server 2008 R2 вместо специального провайдера от производителя можно использовать «Microsoft Base Smart Card Crypto Provider».

Для устройств Рутокен библиотека «минидрайвера», поддерживающая «Microsoft Base Smart Card Crypto Provider», распространяется через Windows Update.

Проверить установился ли «минидрайвер» на вашем сервере можно подключив Рутокен к нему и посмотрев в диспетчер устройств.

Если «минидрайвера» по каким-то причинам нет, его можно установить принудительно, инсталлировав комплект «Драйверы Рутокен для Windows», а после этого воспользоваться «Microsoft Base Smart Card Crypto Provider».

Комплект «Драйверы Рутокен для Windows» распространяется бесплатно с сайта Рутокен .

Добавьте два новых шаблона «Агент сертификации» и «Пользователь с Рутокен».

Для этого выйдите из окна «Управления шаблонами». Нажмите правой кнопкой мыши на «Шаблоны сертификатов» и выберите пункт меню «Создать» и подпункт «Выдаваемый шаблон сертификата».

Далее выберите «Агент регистрации» и «Пользователь с Rutoken» и нажмите «ОК».

Далее нам необходимо выписать сертификат администратору домена. Откройте службу «Выполнить» и укажите команду mmc. Добавьте оснастку «Сертификаты».

В окне «Оснастки диспетчера сертификатов» выберите «моей учетной записи пользователя». В окне «Добавление и удаление оснастки» подтвердите добавление сертификатов.

Выберите папку «Сертификаты».

Запросите новый сертификат. Откроется страница для регистрации сертификата. На этапе запроса сертификата выберите политику регистрации «Администратор» и нажмите «Заявка».

Таким же образом запросите сертификат для Агента регистрации.

Чтобы запросить сертификат для определенного пользователя щелкните «Сертификаты», выберите пункт «Зарегистрироваться от имени…».

В окне для запроса сертификата установите флажок «Пользователь с Рутокен».

Теперь необходимо выбрать пользователя.

В поле «Введите имена выбранных объектов» укажите имя пользователя в домене и нажмите «Проверить имя».

В окне для выбора пользователя нажмите «Заявка».

В раскрывающемся списке выберите имя токена и укажите PIN-код.

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

4 этап — Настройка учетных записей пользователей

Для настройки учетных записей откройте список пользователей и компьютеров AD.

Обзор

Справочный процесс цифровой регистрации и аутентификации Американским национальным институтом стандартов и технологий (NIST)

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

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

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

Если он или она попытается получить доступ к своему банковскому счету с другого компьютера, аутентификатор не будет присутствовать. Чтобы получить доступ, подписчик должен будет подтвердить свою личность в CSP, что может быть в форме успешного ответа на контрольный вопрос, прежде чем ему будет предоставлен доступ.

Получение пользователем билета на доступ к серверу

Когда пользователь А желает получить доступ к серверу, в своем сообщении он отправляет в ЦРК билет TGT, запрос на билет для доступа к серверу и аутентификатор.

Это сообщение имеет следующий формат: “имя А”, “имя B”, TGT: КК [“имя А”, SA, срок действия], SA [время] и называется запросом пользователя на доступ к серверу. Аутентификатор доказывает ЦРК, что пользователь А знает сеансовый ключSA. Аутентификатор состоит из текущего значения даты и времени, зашифрованного сеансовым ключом.

Шифрование защищает от возможного перехвата сторонним пользователем С билета TGT из ответа ЦРК пользователю А. Указание текущих значений даты и времени в аутентификаторе требует синхронизации компьютерных часов пользователя А и ЦРК. ЦРК может допускать некоторый разброс времени (обычно 5 мин.).

ЦРК получает запрос пользователя А на доступ к серверу В и готовит ответ. При помощи ключа ККЦРК расшифровывает билет TGT из запроса, восстанавливает сеансовый ключSA и проверяет срок действия билета TGT.

Если билет TGT – действующий, то ЦРК генерирует ключ для пользователя А и сервера В – KAB и формирует билет.

Билет шифруется секретным ключом сервера В – KB и содержит ключ KAB, имя пользователя А
и срок действия.

В ответе ЦРК указываются имя сервера В и ключ KAB, зашифрованные сеансовым ключомSA, ответ имеет следующий формат: SA [“имя В”, KAB, TICKET:

KB [“имя А”, KAB, срок действия]]. Получив ответ от ЦРК, пользователь А расшифровывает его при помощи сеансового ключа SA.

Факторы аутентификации

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

• Нечто, что нам известно, например, какая-либо секретная информация. Это тайные сведения, которыми должен обладать только авторизованный субъект. Секретом может быть некая фраза или пароль, например в виде устного сообщения, текстового представления, комбинации для замка или личного идентификационного номера (PIN). Парольный механизм может быть довольно легко воплощён и имеет низкую стоимость. Но имеет существенные недостатки: сохранить пароль в тайне зачастую бывает сложно, злоумышленники постоянно придумывают новые способы кражи, взлома и подбора пароля (см. бандитский криптоанализ, метод грубой силы). Это делает парольный механизм слабозащищённым.
• Нечто, чем мы обладаем, например, какой-либо уникальный физический объект. Здесь важно обстоятельство обладания субъектом каким-то неповторимым предметом. Это может быть личная печать, ключ от замка, для компьютера это файл данных, содержащих характеристику. Характеристика часто встраивается в особое устройство аутентификации, например, пластиковая карта, смарт-карта. Для злоумышленника заполучить такое устройство становится более сложно, чем взломать пароль, а субъект может сразу же сообщить в случае кражи устройства. Это делает данный метод более защищённым, чем парольный механизм, однако стоимость такой системы более высокая.
• Нечто, что является неотъемлемой частью нас самих — биометрика. Характеристикой является физическая особенность субъекта. Это может быть портрет, отпечаток пальца или ладони, голос или особенность глаза. С точки зрения субъекта, данный способ является наиболее простым: не надо ни запоминать пароль, ни переносить с собой устройство аутентификации. Однако биометрическая система должна обладать высокой чувствительностью, чтобы подтверждать авторизованного пользователя, но отвергать злоумышленника со схожими биометрическими параметрами. Также стоимость такой системы довольно велика. Но, несмотря на свои недостатки, биометрика остается довольно перспективным фактором.

Электронная подпись

Нормативным документом, в котором приводится определение электронной подписи(ЭП), является Федеральный Закон “№ 63 от 06.04.2021 «Об электронной подписи” (далее ФЗ-63). В статье 2 ФЗ-63 рассматриваемое понятие определяется так:

Электронная подпись — информация в электронной форме, которая присоединена к другой информации в электронной форме (подписываемой информации) или иным образом связана с такой информацией и которая используется для определения лица, подписывающего информацию.

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

Полную гарантию достоверного определения лица не дает ни один из видов ЭП, но, в случае неквалифицированной и квалифицированной ЭП, человек лично посещает специальное учреждение — Удостоверяющий Центр (УЦ), аккредитованное государством и уполномоченное для выдачи(замены) ЭП.

В случае ПЭП, об обязательности достоверной идентификации личности при выдаче(замене) ЭП часто забывают или способ определения лица вызывает много споров в технической реализации. ФЗ-63, в статье 5 пункт 2, подчеркивая важность идентификации личности, дает следующее определение простой электронной подписи:

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

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

Например, при использовании в техническом решении идентификации личности личного электронного почтового ящика, адрес почтового ящика будет открытой частью ключа, а пароль к нему — закрытой, конфиденциальной частью. ФЗ-63 обязывает строго соблюдать конфиденциальность непубличных ключей ПЭП, так как компрометация приводит к потере юридической значимости.

Возвращаясь к определению подписи, которое было дано в предыдущих абзацах, мы можем расширить определение ПЭП, раскрыв значение термина «определенное лицо»:

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

Основным и практически единственным способом юридического сопоставления человека с набором признаков, присущих данному человеку, является предъявление оригинала удостоверяющего документа, в качестве которого применяется выданное государственными органами удостоверение личности (УЛ).

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

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