Token signing public key что за сертификат
Сертификаты подписи токена
Серверам федерации требуются сертификаты для подписи маркеров, чтобы предотвратить изменение или подделка маркеров безопасности злоумышленниками при попытке получить несанкционированный доступ к федеративным ресурсам. Пара закрытого и открытого ключей, используемая с сертификатами для подписи маркеров, является наиболее важным механизмом проверки любой Федеративной связи, так как эти ключи подтверждают, что маркер безопасности был выдан действительным сервером федерации партнера и что маркер не был изменен во время передачи.
Требования к сертификатам для подписи маркера
Сертификат для подписи маркера должен соответствовать следующим требованиям для работы с AD FS.
Для успешного подписания маркера безопасности сертификата подписи маркера сертификат подписи маркера должен содержать закрытый ключ.
Учетная запись службы AD FS должна иметь доступ к закрытому ключу сертификата для подписи маркера в личном хранилище локального компьютера. Это выполняется программой установки. Вы также можете использовать оснастку управления AD FS, чтобы обеспечить этот доступ, если впоследствии вы измените сертификат подписи маркера.
Инфраструктура открытых ключей (PKI) не рекомендуется совместно использовать закрытый ключ для нескольких целей. Поэтому не используйте сертификат связи служб, установленный на сервере федерации в качестве сертификата для подписи маркера.
Использование сертификатов для подписи маркера на разных участниках
Каждый сертификат для подписи маркера содержит криптографические закрытые ключи и открытые ключи, которые используются для цифровой подписи (с помощью закрытого ключа) маркера безопасности. Позже, после получения сервером федерации партнера, эти ключи проверяют подлинность (с помощью открытого ключа) зашифрованного маркера безопасности.
Так как каждый маркер безопасности имеет цифровую подпись партнера по учетным записям, партнер по ресурсам может проверить, что маркер безопасности на самом деле выдан партнером по учетной записи и что он не был изменен. Цифровые подписи проверяются частью открытого ключа сертификата для подписи маркера партнера. После проверки подписи сервер федерации ресурсов создает собственный маркер безопасности для своей организации и подписывает маркер безопасности с помощью собственного сертификата для подписи маркера.
Для партнерских сред Федерации, когда центр сертификации выдает сертификат для подписи маркера, убедитесь, что:
Списки отзыва сертификатов (CRL) сертификата доступны для проверяющих сторон и веб-серверов, которые доверяют серверу федерации.
Сертификат корневого ЦС является доверенным для проверяющих сторон и веб-серверов, которые доверяют серверу федерации.
Веб-сервер в партнере по ресурсам использует открытый ключ сертификата для подписи маркера, чтобы убедиться, что маркер безопасности подписан сервером федерации ресурсов. Затем веб-сервер обеспечивает соответствующий доступ к клиенту.
Рекомендации по развертыванию сертификатов для подписи маркеров
При развертывании первого сервера федерации в новой установке AD FS необходимо получить сертификат подписи маркера и установить его в личное хранилище сертификатов локального компьютера на этом сервере федерации. Сертификат для подписи маркера можно получить, запросив его из центра сертификации предприятия или из общедоступного центра сертификации или создав самозаверяющий сертификат.
Закрытый ключ из одного сертификата для подписи маркера является общим для всех серверов федерации в ферме.
В среде фермы серверов федерации все серверы федерации используют один и тот же сертификат подписи маркера. Вы можете установить один сертификат подписи маркера из центра сертификации на сервере федерации, а затем экспортировать закрытый ключ, если выданный сертификат помечен как экспортируемый.
Как показано на следующем рисунке, закрытый ключ из одного сертификата подписи маркера может быть общим для всех серверов федерации в ферме. Этот параметр — по сравнению со следующим параметром «уникальный сертификат подписи токена» — сокращает затраты, если вы планируете получить сертификат для подписи маркера из общедоступного центра сертификации.
Сведения об установке сертификата при использовании служб сертификации Майкрософт в качестве ЦС предприятия см. в статье iis 7,0: создание сертификата сервера домена в iis 7,0.
Сведения об установке сертификата из общедоступного ЦС см. в разделе IIS 7,0: запрос сертификата Интернет-сервера.
Токены PKCS#11: сертификаты и закрытые ключи
Токены PKCS#11 выполняют не только криптографические функции (генерация ключевых пар, формирование и проверка электронной подписи и другие), но и являются хранилищем для публичных (открытых, PUBLIC KEY) и приватных (закрытых, PRIVATE KEY) ключей. На токене также могут храниться сертификаты. Как правило, на токене хранятся личные сертификаты вместе с ключевой парой. При этом на токене может храниться несколько личных сертификатов.
Встает дилемма, как определить какой закрытый ключ (да и открытый тоже) соответствует тому или иному сертификату.
Такое соответствие, как правило, устанавливается путем задание идентичных параметров CKA_ID и/или CKA_LABEL для тройки объектов: сертификата (CKO_CERTIFICATE), публичного ключа (CKO_PUBLIC_KEY) и приватного ключа (CKO_PRIVATE_KEY).
Возникает вопрос – как задавать эти значения, чтобы, по крайней мере, не возникла коллизия, и насколько это безопасно с точки зрения получения корректного результата.
Наиболее распространенный способ задания CKA_ID – это использование значения хэш-функции от значения открытого ключа. Именно такой способ для связывания тройки объектов используется в проекте NSS (Network Security Services). При этом в качестве хэш-функции используется алгоритм SHA1. С учетом того, что на токене реально будет храниться едва ли больше десятка личных сертификатов, то с точки зрения появления коллизии этот способ является хорошим. Вместе с тем CKA_ID для этой тройки могут устанавливаться в любой момент и любое значение. Именно в этом и состоит вся проблема. Если бы RFC или Рекомендации ТК-26 требовали установки параметра CKA_ID в момент появления объекта на токене (например, при генерации ключевой пары CKM_GOSTR3410_KEY_GEN_PAIR) и его нельзя было бы изменить, то на этом данное повествование можно было бы завершить. К сожалению, это не так. Как уже было сказано, CKA_ID можно установить в любой момент с любым значением. Таким образом, всегда существует вероятность, что сертификат окажется связанным с чужим приватным ключом. Не нужно объяснять, к каким это приведет последствиям.
А вообще, существует ли строгий математический алгоритм, который позволяет связать тройку CKO_CERTIFICATE x CKO_PRIVATE_KEY x CKO_PUBLIC_KEY в единое целое?
Да, такой алгоритм на базе криптографических механизмов (CKM_) токена существует. Связка сертификата и публичного ключа проверяется легко и просто. Берутся значение открытого ключа и его параметров из сертификата и сравниваются и аналогичными значениями публичного ключа.
Что касается сертификата и приватного ключа, то до недавнего времени этот алгоритм выглядел следующим образом. С помощью приватного ключа формируется подпись под некоторым текстом (например, «поиск закрытого ключа»), а затем с помощью открытого ключа, полученного из сертификата, проверяется корректность полученной подписи. Если подпись корректна, значит, мы получили закрытый ключ для выбранного сертификата. Если нет, то выбирается следующий закрытый ключ на токене.
Все, мы теперь не зависим ни от CKA_ID, ни от CKA_LABEL.
Но вот появляется документ «МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ. Расширение PKCS#11 для использования российских стандартов ГОСТ Р 34.10-2012, ГОСТ Р 34.11-2012, ГОСТ Р 34.12-2015 и ГОСТ Р 34.13-2015», в котором появляется новый механизм CKM_GOSTR3410_PUBLIC_KEY_DERIVE — механизм создания открытого ключа из закрытого. Данный механизм используется в C_DeriveKey. Теперь поиск закрытого ключа для сертификата значительно упрощается. Достаточно получить список закрытых ключей на токене, затем для каждого закрытого ключа получить открытый ключ:
А далее сравниваем значения полученного публичного ключа, со значениями публичного ключа в сертификате.
Применение любого из этих алгоритмов избавляет от необходимости следить за значениями CKA_ID/CKA_LABEL и делает использованием сертификатов и приватных ключей, хранящихся на токенах PKCS#11, и надежным и безопасным.
Использование механизма CKM_GOSTR3410_PUBLIC_KEY_DERIVE предполагает его реализацию на том или другом токене. Посмотреть список реализованных механизмов удобно с помощью утилиты p11conf:
Список доступных механизмов можно посмотреть следующим образом:
Добавление сертификата подписи токенов
Для серверов федерации в службы федерации Active Directory (AD FS) (AD FS) требуются сертификаты для подписи маркеров, чтобы предотвратить изменение или подделка маркеров безопасности злоумышленниками при попытке получить несанкционированный доступ к федеративным ресурсам. Каждый сертификат для подписи маркера содержит криптографические закрытые ключи и открытые ключи, которые используются для цифровой подписи (с помощью закрытого ключа) маркера безопасности. Позже, после получения этих ключей сервером федерации партнера, они проверяют подлинность (с помощью открытого ключа) зашифрованного маркера безопасности.
Сертификаты, используемые для подписи маркера, крайне важны для стабильности служба федерации. Поскольку потери или незапланированные удаления любых сертификатов, настроенных для этой цели, могут нарушить работу службы, следует создать резервную копию всех сертификатов, настроенных для этой цели.
Сертификат для подписи маркера должен быть связан с доверенным корнем в служба федерации. Для добавления сертификата подписи маркера в оснастку управления AD FS из экспортированного файла можно использовать следующую процедуру.
Для выполнения этой процедуры требуется членство в группе Администраторы или в эквивалентной группе на локальном компьютере. Просмотрите сведения об использовании соответствующих учетных записей и членстве в группах в локальной группе и группах домена по умолчанию (
Добавление сертификата для подписи маркера
На начальном экране введитеAD FS управлениеи нажмите клавишу ВВОД.
В дереве консоли дважды щелкните Служба, а затем щелкните Сертификаты.
В диалоговом окне Выбор файла сертификата перейдите к файлу сертификата, который необходимо добавить, выберите файл сертификата и нажмите кнопку Открыть.
Token-Signing Certificates
Federation servers require token-signing certificates to prevent attackers from altering or counterfeiting security tokens in an attempt to gain unauthorized access to federated resources. The private/public key pairing that is used with token-signing certificates is the most important validation mechanism of any federated partnership because these keys verify that a security token was issued by a valid partner federation server and that the token was not modified during transit.
Token-signing certificate requirements
A token-signing certificate must meet the following requirements to work with AD FS:
For a token-signing certificate to successfully sign a security token, the token-signing certificate must contain a private key.
The AD FS service account must have access to the token-signing certificate’s private key in the personal store of the local computer. This is taken care of by Setup. You can also use the AD FS Management snap-in to ensure this access if you subsequently change the token-signing certificate.
It is a public key infrastructure (PKI) best practice to not share the private key for multiple purposes. Therefore, do not use the service communication certificate that you installed on the federation server as the token-signing certificate.
How token-signing certificates are used across partners
Every token-signing certificate contains cryptographic private keys and public keys that are used to digitally sign (by means of the private key) a security token. Later, after they are received by a partner federation server, these keys validate the authenticity (by means of the public key) of the encrypted security token.
Because each security token is digitally signed by the account partner, the resource partner can verify that the security token was in fact issued by the account partner and that it was not modified. Digital signatures are verified by the public key portion of a partner’s token-signing certificate. After the signature is verified, the resource federation server generates its own security token for its organization and it signs the security token with its own token-signing certificate.
For federation partner environments, when the token-signing certificate has been issued by a CA, ensure that:
The certificate revocation lists (CRLs) of the certificate are accessible to relying parties and Web servers that trust the federation server.
The root CA certificate is trusted by the relying parties and Web servers that trust the federation server.
The Web server in the resource partner uses the public key of the token-signing certificate to verify that the security token is signed by the resource federation server. The Web server then allows the appropriate access to the client.
Deployment considerations for token-signing certificates
When you deploy the first federation server in a new AD FS installation, you must obtain a token-signing certificate and install it in the local computer personal certificate store on that federation server. You can obtain a token-signing certificate by requesting one from an enterprise CA or a public CA or by creating a self-signed certificate.
A private key from one token-signing certificate is shared among all the federation servers in a farm.
In a federation server farm environment, we recommend that all federation servers share (or reuse) the same token-signing certificate. You can install a single token-signing certificate from a CA on a federation server and then export the private key, as long as the issued certificate is marked as exportable.
As shown in the following illustration, the private key from a single token-signing certificate can be shared to all the federation servers in a farm. This option—compared to the following «unique token-signing certificate» option—reduces costs if you plan to obtain a token-signing certificate from a public CA.
For information about installing a certificate when you use Microsoft Certificate Services as your enterprise CA, see IISВ 7.0: Create a Domain Server Certificate in IISВ 7.0.
For information about installing a certificate from a public CA, see IISВ 7.0: Request an Internet Server Certificate.
For information about installing a self-signed certificate, see IISВ 7.0: Create a Self-Signed Server Certificate in IISВ 7.0.
Аутентификация на сетевом оборудовании через SSH с помощью публичных ключей
По умолчанию инженеры подключаются к сетевому оборудованию с помощью имени пользователя и пароля. По протоколу Telnet учетные данные пользователя передаются в открытом виде, а по протоколу SSH в зашифрованном. Чтобы не передавать секретную часть по сети, используется аутентификация по публичным ключам. При такой аутентификации публичный ключ пользователя заранее прописывается пользователю на оборудовании. Секретный ключ по сети не передается.
Это руководство поможет вам быстро начать использовать публичные ключи для аутентификации при подключении к сетевому оборудованию по протоколу SSH. Руководство применимо как для Windows, так и для Mac OS X. Я постарался сделать его максимально простым и информативным. Оно не перегружено, но отвечает на основные вопросы:
Содержание
Введение
Кроме стандартной аутентификации по паролю (password/keyboard) в протоколе SSH существует также аутентификация по публичному ключу (RSA).
Аутентификация с помощью RSA-ключей состоит из нескольких этапов:
Документ Secure Shell Configuration Guide, Cisco IOS Release 15E:
Secure Shell Configuration Guide, Cisco IOS Release 15E
Restrictions for Secure Shell Version 2 Support
Rivest, Shamir, and Adleman (RSA) key generation is an SSH server-side requirement. Devices that act as SSH clients need not generate RSA keys.
Попытка ввести данные DSA-ключа:
Создание публичного RSA-ключа
Пару RSA-ключей можно создать с помощью различных утилит: SecureCRT, PuTTYgen или любым другим ПО. При создании ключа можно задать Passphrase (защита ключа с помощью пароля).
Генерирование RSA-пары в SecureCRT
SecureCRT → Tools → Create Public Key…:
Чуть-чуть теории → кнопка “Next >”:
Тип сертификата RSA/DSA → Выбираем RSA → кнопка “Next >”:
Пароль шифрования для секретного ключа (необязательно, можно оставить пустым и не шифровать) + Комментарий → кнопка “Next >”:
Выбираем длину ключа (в версии SecureCRT 6.1.0 максимальная длина ключа равна 2048 бит, в версии 8.5.4 — 16 384 бит):
Генерирование ключа → кнопка “Next >”:
Для генерирования случайных чисел нужно просит поводить мышкой в рамках окна.
Сохранение пары ключей → Выбор места хранения → Выбор формата сохраняемого ключа (VanDuke Private format, OpenSSH legacy, OpenSSH new) → кнопка “Finish”:
SecureCRT спрашивает, делать ли данный ключ ключом по умолчанию для SecureCRT:
Генерирование RSA-пары в PuTTYgen
Выбираем параметры (тип пары: RSA; битная размерность ключа: 2048; по желанию задаём Passphrase (защита ключа с помощью пароля)) → Generate:
Для гарантирования случайных чисел просит поводить мышкой в рамках окна. Это защита от псевдослучайных чисел.
Сохраняем RSA-ключи → Кнопка «Save private key»:
Обратите внимание: RSA-ключи, сохраненные в частном формате в одном ПО, нельзя использовать в ПО другого производителя. То есть пара RSA-ключей, созданных в PuTTYgen и сохраненных в формате Putty Private Key, не подходит для использования в SecureCRT, и наоборот. PuTTY поддерживает только формат Putty Private Key. Универсальным решением для распространения ключей является конвертирование ключей в формат OpenSSH (Смотри ссылку 2: “Conversion from Putty to SecureCRT with auth. keys”). Т. к. SecureCRT свободно работает с форматом OpenSSH. А ПО PuTTYgen преобразует формат OpenSSH в формат Putty Private Key.
Конвертирование RSA-ключа из формата Putty Private Key (PuTTY) в формат OpenSSH (SecureCRT)
Чтобы использовать в SecureCRT RSA-ключи, которые сгенерированы в PuTTYgen и сохранены в формате Putty Private Key (*.ppk), экспортируем их с помощью PuTTYgen в формат OpenSSH:
Конвертирование RSA-ключа из формата VanDyke Private Key (SecureCRT) в формат Putty Private Key (PuTTY)
Чтобы использовать в PuTTY RSA-ключи, которые сгенерированы в SecureCRT и сохранены в формате VanDyke Private Key (файл публичного ключа — *.pub, файл секретного ключа *. (без расширения)), экспортируем их с помощью SecureCRT в формат OpenSSH, а затем с помощью PuTTYgen экспортируем в формат Putty Private Key (*.ppk):
Генерирование публичных ключей на MAC OS X средствами операционной системы
Будем использовать встроенную утилиту ssh-keygen (man ssh-keygen).
Генерируем RSA-ключ с длиной 2048 бит с указанием имени ключа, путем к папке с местом хранения ключа:
Во время выполнения программа спросит пароль для защиты RSA-ключа:
Генерируем RSA-ключ с длиной 4096 бит в с указанием имени ключа, путем к папке с местом хранения ключа, пароль задаем в явном виде в параметрах генерации ключа (-N «cisco»):
Не рекомендуемые параметры генерации ключей: ненадёжный ключ длиной 1024 бита, с указанием имени ключа, путем к папке с местом хранения ключа, пароль задаем в явном виде в параметрах генерации ключа (-N «» – без пароля):
Итак, мы создали три ключа в с указанием имен ключей и указанием места хранения ключей (по умолчанию все ключи сохраняются в /Users/[Username]/.ssh).
По умолчанию, при подключении по SSH с аутентификацией по публичному ключу, происходит последовательный перебор всех публичных ключей, которые хранятся в папке /Users/[Username]/.ssh.
Ключ R6: переименуем ключ в “id_rsa” (по умолчанию имя файла генерируемого ключа “id_rsa”) и перенесем в папку с SSH-ключами (
/.ssh/) (Т. е. выполним все действия, чтобы ключ R6 использовался как основной ключ для подключений по SSH по умолчанию):
Преобразуем публичный OpenSSH-ключ в формат RFC4716 (экспорт в Cisco IOS):
Применение публичного ключа на оборудовании
Как на различном оборудовании привязать открытый ключ к пользователю?
Процесс привязки публичного ключа к пользователю не стандартный и меняется от оборудования к оборудованию, поэтому приведены примеры для каждого типа оборудования, которое чаще всего применяется в сети.
Cisco IOS XE, Catalyst (с версии 15.1 и выше), IOS
Cisco ASA
Весь ключ вставляем в одну строчку (OpenSSH формат).
Маршрутизаторы и коммутаторы Huawei
Типы форматов ключей, импортируемых на Huawei:
“The SecureCRT and PuTTY generate RSA keys in PEM format.”
“The OpenSSH generates RSA keys in OpenSSH format.”
“The OpenSSL generates RSA keys in DER format.”
По умолчанию — в шестнадцатеричном виде:
Примечание: оборудование Huawei поддерживает не только ключи в формате RSA, но и другие форматы:
Можно жестко задать тип аутентификации для пользователя по SSH:
То есть мы разрешаем доступ с помощью либо пароля, либо публичных и приватных ключей, либо и того, и другого.
Huawei USG (6000)
Конфигурация полностью аналогична настройкам на маршрутизаторе, но имеет некоторые особенности.
По умолчанию уровень привилегий после журналирования с использованием сертификатов равен 0 и повышению не поддается. Поэтому уровень приоритета задается с помощью
Cisco Nexus 9.3
Вариант 1: предустанавливаем файл публичного ключа на устройство и привязываем файл публичного ключа к пользователю.
Вариант 2: копируем публичный ключ пользователю:
Использование секретного ключа для подключения по SSH
Этот раздел посвящен настройке SSH-клиентов для аутентификации по RSA-ключам на сетевом оборудовании (или другом оборудовании, при условии, что оборудование и ПО поддерживает аутентификацию по публичным ключам).
Мы рассмотрим настройку использования публичного ключа в самых популярных программах: SecureCRT и PuTTY.
SecureCRT
В окне настроек SSH есть список Authentication. В нём необходимо увеличить приоритет PublicKey до самого высокого — сделать верхним в списке.
Затем перейдите в параметры PublicKey и выберите файл приватного ключа. Самый верхний переключатель позволяет использовать глобальные настройки секретного ключа или сеансовые настройки — другой секретный ключ (ключ не по умолчанию) — только для этого подключения.
Настраиваем глобальный публичный ключ: в меню Options → Global options → Категория SSH2.
PuTTY
В настройках SSH (Connection → SSH → Auth) в поле “Private key file for authentication” укажите файл Putty Private Key (*.ppk):
MAC OS X
Настройка стандартного клиента для использования публичных ключей:
Как упростить работу с SSH на MAC OS X:
Заполняется таким образом:
Примечание: у меня некорректно настроено подключение по умолчанию (как правильно, я не знаю), потому что подключение к хосту R6 (10.31.73.31) выполняется очень долго. Рекомендуется указать сразу указать путь к ключу по умолчанию.
Пример подключения по ssh используя публичные ключи и файл config:
Заключение
RSA-ключи могут использоваться для замены аутентификации по паролю, но не во всех случаях:
На некотором оборудовании одному пользователю может соответствовать несколько пар публичных ключей, на другом оборудовании одному пользователю соответствует только один публичный ключ.
Также разнятся форматы, в которых хранится пара из публичного и секретного ключа. Но это руководство поможет вам экспортировать ключи в разные форматы.
Сегодня оптимально использовать ключи длиной 2048 бит, но для некоторого оборудования это максимально возможная длина ключа (быть может, в новых прошивках это исправят). Например:
Рекомендуется использовать публичные ключи для замены паролей, если пароли вводятся с помощью скриптов (пример: autologon в SecureCRT).
Рекомендуется использовать публичные ключи для защиты от передачи пароля по сети.
Некоторое ПО по умолчанию использует публичные ключи для аутентификации по SSH вместо пароля (пример: Ansible).