40. Сертификат открытого ключа X.509. Жизненный цикл.

Вопрос: Сертификат открытого ключа. Назначение. Содержание. Жизненный цикл.

Источник: Яковлев, Коржик. Гл. 8, §8.6.

Назначение: привязать открытый ключ к личности (или организации) и подтвердить эту привязку подписью CA.

Содержание сертификата X.509 v3:

— Версия (v1/v2/v3)

— Серийный номер

— Алгоритм подписи CA

— Имя CA (Issuer)

— Период действия (Not Before / Not After)

— Имя владельца (Subject)

— Открытый ключ владельца (SubjectPublicKeyInfo)

— Расширения X.509 v3: KeyUsage, SubjectAltName, BasicConstraints и др.

— Подпись CA

Жизненный цикл:

1. Запрос (CSR — Certificate Signing Request)

2. Верификация личности в RA

3. Выдача сертификата CA

4. Публикация в репозитории

5. Использование (верификация цепочки доверия, проверка CRL/OCSP)

6. Обновление (до истечения срока) или Отзыв (при компрометации)

7. Уничтожение / архивирование

41. Протокол ike в ipSec.

Вопрос: Протокол обмена ключами IKE в стеке протоколов IPSec.

Источник: Яковлев, Коржик. Гл. 9 «Протоколы распределения ключей», §9.1.

IPSec (RFC 4301) — стандарт защиты IP-трафика. IKE (Internet Key Exchange) — протокол автоматического согласования ключей и параметров SA (Security Association).

Фазы IKEv2 (RFC 7296):

Фаза 1 — IKE_SA_INIT:

• Согласование алгоритмов (шифрования, PRF, DH группы, ЦП)

• Обмен DH (g^a, g^b) → общий секрет g^{ab}

• Обмен nonce (N_A, N_B)

• Выработка ключей: SKEYSEED = prf(N_A|N_B, g^{ab})

• Из SKEYSEED выводятся: SK_e (шифрование IKE), SK_a (аутентификация IKE), SK_d (для дочерних SA)

Фаза 2 — IKE_AUTH:

• Аутентификация сторон (сертификатом или PSK)

• Согласование IPSec SA (дочерних) с ключами для ESP/AH

Принцип PFS (Perfect Forward Secrecy):

DH-обмен выполняется заново для каждой SA → компрометация одного ключа не раскрывает прошлые сессии.

42. Требования к безопасности в протоколе sigma.

Вопрос: Требования к безопасности распределения ключа в протоколе SIGMA.

Источник: Яковлев, Коржик. Гл. 9, §9.2.

SIGMA (SIGn-and-MAc) — протокол Хуго Красновски, лежит в основе IKE.

Требования безопасности:

1. Взаимная аутентификация: обе стороны доказывают свою личность.

2. Согласование ключа (Key Agreement): общий секрет вырабатывается так, что ни одна из сторон не навязывает его в одностороннем порядке.

3. Perfect Forward Secrecy: DH-эфемерные ключи → компрометация долгосрочных ключей не раскрывает прошлые сеансы.

4. Защита от атак повтора: nonce и порядковые номера.

5. Анонимность / защита идентификатора: идентификаторы сторон защищены шифрованием (только после установки DH-сессии).

Протокол SIGMA (упрощённо):

A → B: g^a

B → A: g^b, SIG_B(g^a, g^b), MAC_K(B)

A → B: SIG_A(g^a, g^b), MAC_K(A)

Подпись привязывает DH-значения к идентификатору (защита от атаки замены ключа). MAC связывает идентификатор с ключом (защита от атаки замены сертификата).

43. Криптографическая защита в tls 1.3. Протокол квитирования.

Вопрос: Криптографическая защита в протоколе TLS 1.3. Протокол квитирования (Handshake).

Источник: Яковлев, Коржик. Гл. 9, §9.3.

TLS 1.3 (RFC 8446) — значительно упрощён по сравнению с TLS 1.2.

Поддерживаемые алгоритмы в TLS 1.3:

— Шифросюиты: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256.

— Обмен ключами: только ECDHE и DHE (нет статических RSA, RC4, и т.п.).

— Аутентификация: RSA-PSS, ECDSA, Ed25519.

Протокол квитирования TLS 1.3 (1 RTT):

1) ClientHello: поддерживаемые шифросюиты, ключ DH g^a, nonce.

2) ServerHello: выбранная шифросюита, ключ DH g^b, nonce. После этого сервер сразу переходит к шифрованию!

3) {Certificate, CertificateVerify, Finished} — всё зашифровано. Сервер аутентифицирует себя.

4) {Finished} от клиента — клиент подтверждает.

5) Данные передаются зашифрованными record-layer.

Всё после ServerHello шифруется — идентификаторы скрыты. 1-RTT вместо 2-RTT в TLS 1.2. 0-RTT (early data) опционально.