## Криптографические токены (смарт-карты)
**Криптографический токен** — аппаратное устройство, предназначенное для безопасного хранения закрытых ключей, цифровых сертификатов и выполнения криптографических операций. Примеры: Рутокен, JaCarta, eToken.
> [!summary] Простыми словами
> Криптографический токен — это “цифровой сейф” в виде флешки. Внутри него хранится ваш закрытый ключ, который невозможно скопировать или извлечь. Для подписи или аутентификации токен выполняет операцию внутри себя и возвращает только результат.
### Ключевые свойства токенов
| Свойство | Описание | Значение для безопасности |
| — | — | — |
| **Неизвлекаемость ключа** | Закрытый ключ не может быть экспортирован из токена | Защита от кражи ключа даже при компрометации компьютера |
| **Защита от подбора** | Блокировка токена после нескольких неудачных попыток ввода PIN | Защита от брутфорс-атак |
| **Аппаратное выполнение операций** | Подпись и шифрование выполняются внутри чипа токена | Исключение утечки ключа через память процесса |
| **Двухфакторная аутентификация** | Требуется физическое наличие токена + знание PIN | Повышение стойкости аутентификации |
### Стандарты и интерфейсы
– **PKCS#11** — кроссплатформенный API для работы с криптографическими токенами.
– **Microsoft CSP/KSP** — криптопровайдеры Windows для интеграции токенов с ОС.
– **PC/SC** — стандарт взаимодействия с смарт-картами через USB-ридеры.
## Протокол аутентификации Kerberos
**Kerberos** — сетевой протокол аутентификации, использующий симметричную криптографию и доверенную третью сторону (KDC — Key Distribution Center) для проверки подлинности пользователей и служб в домене.
### Основные компоненты Kerberos
| Компонент | Назначение |
| — | — |
| **KDC (Key Distribution Center)** | Доверенный сервер, выдающий билеты (TGT и service tickets). В Active Directory роль KDC выполняет контроллер домена. |
| **TGT (Ticket-Granting Ticket)** | Билет, выдаваемый пользователю после успешной аутентификации. Используется для получения билетов к конкретным службам. |
| **Service Ticket** | Билет для доступа к конкретной службе (файловый сервер, почта, веб-приложение). |
| **Authenticator** | Одноразовый токен с временной меткой, доказывающий, что предъявитель билета — его законный владелец. |
### Стандартный поток аутентификации Kerberos (по паролю)
“`mermaid
sequenceDiagram
participant C as Клиент
participant KDC as KDC (DC)
participant S as Сервер службы
C->>KDC: AS-REQ (имя пользователя)
KDC->>C: AS-REP (TGT, зашифрованный ключом пользователя)
C->>KDC: TGS-REQ (TGT + запрос к службе)
KDC->>C: TGS-REP (Service Ticket)
C->>S: AP-REQ (Service Ticket + Authenticator)
S->>C: AP-REP (опционально, для взаимной аутентификации)
“`
> [!note] Примечание При аутентификации по паролю ключ пользователя выводится из пароля (через хеш-функцию). Это делает протокол уязвимым к атакам на слабые пароли.
## Расширение PKINIT: Kerberos по сертификатам
**PKINIT (Public Key Cryptography for Initial Authentication in Kerberos)** — расширение протокола Kerberos, позволяющее выполнять начальную аутентификацию с использованием асимметричной криптографии (сертификатов) вместо пароля.
### Поток аутентификации с PKINIT
“`mermaid
sequenceDiagram
participant C as Клиент с токеном
participant KDC as KDC (DC)
C->>KDC: AS-REQ (сертификат пользователя + подпись)
KDC->>KDC: Проверка сертификата пользователя (цепочка, статус отзыва)
KDC->>KDC: Проверка сертификата контроллера домена
KDC->>C: AS-REP (TGT, зашифрованный открытым ключом пользователя)
Note right of C: Дальнейший поток идентичен стандартному Kerberos
“`
### Требования к сертификатам для PKINIT
|Сторона|Требования к сертификату|
|—|—|
|**Пользователь**|- Расширение `Client Authentication` (OID `1.3.6.1.5.5.7.3.2`)
– Закрытый ключ должен быть неизвлекаемым (храниться на токене)
– Сертификат должен быть выпущен доверенным ЦС|
|**Контроллер домена**|- Расширение `Server Authentication` (OID `1.3.6.1.5.5.7.3.1`)
– Расширение `KDC` (OID `1.3.6.1.5.2.3.5`)
– Сертификат должен быть установлен в хранилище компьютера|
> [!attention] Важно Для успешной аутентификации по смарт-карте оба сертификата (пользователя и контроллера домена) должны быть действительны, не отозваны и выпущены ЦС, которому доверяет противоположная сторона.
## Интеграция смарт-карт с Active Directory
Для организации входа в домен по смарт-карте необходимо:
1. **Выпустить сертификаты** по соответствующим шаблонам (“Пользователь со смарт-картой”, “Проверка подлинности контроллера домена”).
2. **Настроить учётную запись пользователя**: установить флаг “Для интерактивного входа в сеть нужна смарт-карта”.
3. **Настроить групповую политику**: включить требование смарт-карты для интерактивного входа.
4. **Установить драйверы токена** на клиентских машинах и контроллерах домена.
> [!summary] Простыми словами Вход по смарт-карте заменяет пароль на “физический ключ + код доступа”. Даже если злоумышленник узнает ваш PIN, без самого токена он не войдёт в систему. А если токен украдут — без PIN он бесполезен.