Данный текст будет являться одной из переписанных глав для учебного пособия по защите информации кафедры радиотехники и систем управления, а также, с этого учебного кода, кафедры защиты информации МФТИ (ГУ). Полностью учебник доступен на github (см. также draft releases). На хабре планирую выкладывать новые «большие» куски, во-первых, чтобы собрать полезные комментарии и замечания, во-вторых, дать сообществу больше обзорного материала по полезным и интересным темам.

Основные понятия

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

Формализация подобных действий делается через описание протокола. Протокол — описание распределённого алгоритма, в процессе выполнения которого два или более участников последовательно выполняют определённые действия и обмениваются сообщениями (Здесь и далее в этом разделе определения даны на основе [Cheremushkin:2009]).

Под участником (субъектом, стороной) протокола понимают не только людей, но и приложения, группы людей или целые организации. Формально участниками считают только тех, кто выполняет активную роль в рамках протокола. Хотя при создании и описании протоколов забывать про пассивные стороны тоже не стоит. Например, пассивный криптоаналитик формально не является участником протоколов, но многие протоколы разрабатываются с учётом защиты от таких «неучастников».

Протокол состоит из циклов (англ. round) или проходов (англ. pass). Цикл — временной интервал активности только одного участника. За исключением самого первого цикла протокола, обычно начинается приёмом сообщения, а заканчивается — отправкой.

Цикл (или проход) состоит из шагов (действий, англ. step, action) — конкретных законченных действий, выполняемых участником протокола. Например:

• генерация нового (случайного) значения;
• вычисление значений функции;
• проверка сертификатов, ключей, подписей, и др.;
• приём и отправка сообщений.

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

Можно сказать, что протокол прескрептивно описывает правила поведения каждой роли в протоколе. А сеанс это дескриптивное описание (возможно теоретически) состоявшейся в прошлом реализации протокола.

Пример описания протокола.

1. Участник с ролью «Отправитель» должен отправить участнику с ролью «Получатель» сообщение.
2. Участник с ролью «Получатель» должен принять от участника с ролью «Отправитель» сообщение.

Пример описания сеанса протокола.

1. 1-го апреля в 13:00 Алиса отправила Бобу сообщение.
2. 1-го апреля в 13:05 Боб принял от Алисы сообщение.

Защищённым протоколом или протоколом обеспечения безопасности будет называть протокол, обеспечивающий выполнение хотя бы одной защитной функции [ISO:7498-2:1989]:

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

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

Запись протоколов

Для записи протоколов, связанных с реализацией функций защиты информации, не используют выражения вроде «участник с ролью «Отправитель»», а заменяют их на краткие обозначения вроде «отправитель» или используют общепринятые экземплификанты: Алиса, Боб, Клара, Ева и т., д. При этом используют следующие соглашения.

• Алиса, Боб (от англ. A, B) — отправитель и получатель.
• Карл, Клара, Чарли (от англ. C) — равноправная третья сторона.
• Ева (от англ. eavesdropper) — пассивный криптоаналитик.
• Меллори (от англ. malicious) — активный криптоаналитик.
• Трент (от англ. trust) — доверенная сторона.

Не существует общепринятого формата записи протоколов, они могут отличаться как по внешнему виду, так и по полноте описания. Например, вот наиболее полный формат записи протокола Диффи—Хеллмана.

• Предварительный этап.
  • Все стороны выбрали общие $$ и $$.
• Проход 1.
  • Алиса генерирует случайное $$.
  • Алиса вычисляет $$.
  • Алиса отправляет Бобу $$.
• Проход 2.
  • Боб принимает от Алисы $$.
  • Боб генерирует случайное $$.
  • Боб вычисляет $$.
  • Боб отправляет Алисе $$.
  • Боб вычисляет $$.
• Проход 2.
  • Алиса принимает от Боба $$.
  • Алиса вычисляет $$.
• Результат протокола.
  • Стороны вычислили общий сеансовый ключ $$.

Теперь сравните с краткой записью того же самого протокола.

1. $$
2. $$

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

В данном пособии мы будем придерживаться промежуточного формата записи.

1. Алиса генерирует $$.
   $$.
2. Боб генерирует $$.
   Боб вычисляет $$.
   $$.
3. Алиса вычисляет $$.

Также условимся о правилах записи случая, когда активный криптоаналитик (Меллори) выдаёт себя за легального пользователя.

$$

Либо, отводя отдельный столбец для каждого участника.

$$

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

• $$, $$, $$, и т.п. — идентификаторы участников протокола: Алисы, Боба и Клары, соответственно.
• $$ (от англ. message) — сообщение в исходном виде, открытый текст вне зависимости от кодировки. То есть под $$ может пониматься и исходный текст в виде текста или, например, звука, либо уже некоторое число или массив бит, однозначно соответствующие этому сообщению.
• $$ (от англ. key) — некоторый ключ. Без дополнительных уточнений обычно обозначает секретный сеансовый ключ.
• $$ — общий секретный ключ между Алисой и Трентом (для симметричных криптосистем).
• $$ — открытый ключ Алисы (для асимметричных криптосистем).
• $$ (от англ. encrypt) — данные, зашифрованные на ключе $$.
• $$, $$ — данные, зашифрованные на ключах Алисы и Боба, соответственно.
• $$ (от англ. lifetime) — время жизни, например, сертификата.
• $$ (от англ. sign) — данные и соответствующая цифровая подпись на открытом ключе $$.
• $$, $$ (от англ. timestamp) — метки времени от соответствующих участников.
• $$, $$ (от англ. random) — случайные числа, выбранные соответствующими участниками.

Примеры использования обозначений.

• $$ или просто $$ — сообщение $$, зашифрованное ключом Боба $$.
• $$ — случайное число $$, сгенерированное Алисой и ей же подписанное. То есть в сообщении будет и случайное число (открытым текстом), и электронная подпись этого числа.
• $$ — идентификатор и ключ Алисы, метка времени и срок жизни данной записи, всё вместе подписанное открытым ключом доверенного центра (Трента). То есть фактически сертификат ключа Алисы.

Свойства безопасности протоколов

Защищённая система и, соответственно, защищённый протокол могут выполнять разные функции безопасности. Многие из этих функций или целей (англ. goals) можно сформулировать как устойчивость к определённому классу атак. Наиболее полным и актуальным считается перечисление и толкование этих целей в документе проекта AVISPA (англ. Automated Validation of Internet Security Protocols and Applications) [AVISPA], суммирующим описания из различных документов IETF (англ. Internet Engineering Task Force). Данные цели принято считать формализируемыми — то есть такими, что для отдельных протоколов есть возможность формально доказать или опровергнуть достижение этих целей.

• Аутентификация (однонаправленная).
  англ. Authentication (unicast).
  
  • (G1) Аутентификация субъекта.
    англ. Entity authentication (Peer Entity Authentication).
    
    Гарантия для одной стороны протокола через представление доказательств и / или учётных данных второй стороны, участвующей в протоколе, и того, что вторая сторона действительно участвовала в текущем сеанса протокола. Обычно делается через представления таких данных, которые могли быть сгенерированы только второй стороной. Аутентификация субъекта подразумевает, что полученные данные могут быть однозначно прослежены до субъекта протокола, что подразумевает аутентификацию источника данных.
  • (G2) Аутентификация сообщения.
    англ. Message authentication (Data Origin Authentication).
    
    Гарантия того, что полученное сообщение или фрагмент данных были созданы определённым субъектом в какое-то (обычно неуказанное) время в прошлом, и что эти данные не были повреждены или подделаны. Но без предоставления уникальности или своевременности. Аутентификация сообщений подразумевает их целостность.
  • (G3) Защита от повтора.
    англ. Replay Protection.
    
    Защита от ситуации, когда некоторая сторона запишет некоторое сообщение и воспроизведёт его позднее (возможно — в другом сеансе протокола), что приведёт к некорректной интерпретации данной стороны как аутентифицированной.
• Аутентификация при рассылке по многим адресам или при подключении к службе подписки/уведомления.
  англ. Authentication in Multicast or via a Subscribe / Notify Service.
  
  • (G4) Явная аутентификация получателя.
    англ. Implicit Destination Authentication.
    
    Протокол должен гарантировать, что отправленное сообщение доступно для чтения только легальным получателям. То есть только легальные авторизованные участники будут иметь доступ к актуальной информации, многоадресному сообщению или сеансу групповой связи. Включает в себя группы рассылки с очень динамичным членством.
  • (G5) Аутентификация источника.
    англ. Source Authentication.
    
    Легальные получатели смогут аутентифицировать источник и содержание информации или группового общения. Включает случаи, когда члены группы не доверяют друг другу.
• (G6) Авторизация (третьей доверенной стороной).
  англ. Authorization (by a Trusted Third Party).
  
  Гарантия возможности авторизовать (в терминах протокола) одного субъекта на доступ к ресурсу другого с помощью третьей доверенной стороны. Подразумевает, что владелец ресурса может не иметь собственных списков доступа (англ. Access Control List, ACL)) и полагается на таковые у доверенной стороны.
• Совместная генерация ключа.
  англ. Key Agreement Properties.
  
  • (G7) Аутентификация ключа.
    англ. Key authentication.
    
    Гарантия для одного из субъектов, что только легальные пользователи могут получить доступ к конкретному секретному ключу.
  • (G8) Подтверждение владения ключом.
    англ. Key confirmation (Key Proof of Possession).
    
    Гарантия для одного из субъектов, что другой субъект действительно владеет конкретным секретным ключом (либо информацией, необходимой для получения такого ключа).
  • (G9) Совершенная прямая секретность.
    англ. Perfect Forward Secrecy (PFS).
    
    Гарантия того, что компрометация мастер-ключей в будущем не приведёт к компрометации сессионных ключей уже прошедших сеансов протокола.
  • (G10) Формирование новых ключей.
    англ. Fresh Key Derivation.
    
    Гарантия возможности создать новые сессионные ключи для каждого сеанса протокола.
  • (G11) Защищённая возможность договориться о параметрах безопасности.
    англ. Secure capabilities negotiation (Resistance against Downgrading and Negotiation Attacks).
    
    Гарантия не только того, что легальные стороны имеют возможность договориться о параметрах безопасности, но и того, что нелегальная сторона не вмешалась в протокол и не привела к выбору предпочтительных ей (возможно — наиболее слабых) параметров безопасности.
• (G12) Конфиденциальность (секретность).
  англ. Confidentiality (Secrecy).
  
  Гарантия, что конкретный элемент данных (часть передаваемого сообщения) остаётся неизвестным для злоумышленника. В данной цели не рассматривается секретность сеансового ключа, проверка подлинности ключа или надёжность долговременных мастер-ключей.
• Анонимность.
  англ. Anonymity.
  
  • (G13) Защита идентификаторов от прослушивания (несвязываемость).
    англ. Identity Protection against Eavesdroppers.
    
    Гарантия, что злоумышленник (подслушивающий) не состоянии связать обмен сообщениями субъектом с его реальной личностью.
  • (G14) Защита идентификаторов от других участников.
    англ. Identity Protection against Peer.
    
    Гарантия, что участник переписки не в состоянии связать обмен сообщениями субъекта с реальной личностью, но только с некоторым псевдонимом.
• (G15) Ограниченная защита от атак отказа в обслуживании.
  англ. (Limited) Denial-of-Service (DoS) Resistance.
  
  Гарантия, что протокол следует определённым принципам, уменьшающих вероятность (усложняющих использование) отдельных классов атак отказа в обслуживании.
• (G16) Неизменность отправителя.
  англ. Sender Invariance.
  
  Гарантия для одной из сторон, что источник сообщения остался таким же, как тот, который начал общение, хотя фактическая идентификация источника не важна для получателя.
• Неотрекаемость.
  англ. Non-repudiation.
  
  • (G17) Подотчётность.
    англ. Accountability.
    
    Гарантия возможности отслеживания действий субъектов над объектами.
  • (G18) Доказательство происхождения.
    англ. Proof of Origin.
    
    Гарантия неопровержимости доказательств источника сообщения.
  • (G19) Доказательство доставки.
    англ. Proof of Delivery.
    
    Гарантия неопровержимости доказательств факта получения сообщения.
• (G20) Защищённое временное свойство.
  англ. Safety Temporal Property.
  
  Гарантия возможности доказать, что факт нахождения системы в одном из состояний означает, что некогда в прошлом система хотя бы раз находилась в некотором другом состоянии. Например, что получение субъектом доступа к ресурсу означает, что некогда в прошлом субъект успешно оплатил данный доступ.

Примеры свойств безопасности, реализуемыми различными протоколами приведены в таблице.

Классификация протоколов

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

• Классификация по числу участников протокола:
  • двусторонний,
  • трёхсторонний и т. п.,
  • многосторонний.
• Классификация по числу передаваемых сообщений:
  • интерактивный (с наличием взаимного обмена сообщениями);
  • неинтерактивный (с однократной передачей сообщений), часто называется схемами. Определение не совсем полное. Любая схема предполагает как минимум два этапа. На первом предварительном этапе доверенный центр распределяет некоторую информацию между одноранговыми участниками. На втором этапе (конкретные сеансы протокола) участники обмениваются этой информацией, получая исходный секрет или новый секретный сеансовый ключ. Причём обмен информацией может идти более чем между двумя участниками. Однако после взаимного обмена информацией дополнительных проходов для выполнения целей схемы не требуется.
• Классификация по числу проходов (раундов):
• Классификация по используемым криптографическим системам:
  • на основе только симметричных криптосистем;
  • на основе в том числе асимметричных криптосистем.
• Классификация по защищённым свойствам протокола:
  • (G1) обеспечивает или нет аутентификацию первой, второй стороны протокола и т. д.;
  • (G2) обеспечивает или нет аутентификацию сообщений;
  • (G3) обеспечивает или нет защиту от повторов;
  • и т. п.
• Классификация по типам участников:
  • одноранговый, когда все участники могут выполнять любые роли в рамках протокола;
  • с доверенным посредником, когда в протоколе всегда участвует третья доверенная сторона;
  • с доверенным арбитром, когда в протоколе может участвовать третья доверенная сторона, если остальные участники не пришли к согласию.

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

• Классификация по целевому назначению протокола:
  • … обеспечения целостности,
  • … цифровой подписи,
  • … идентификации,
  • … конфиденциальности,
  • … распределения ключей,
  • … и т. п.
• Классификация по «полноте» выполняемых функций:
  • примитивные, используются как базовый компонент при построении прикладных протоколов;
  • промежуточные;
  • прикладные, предназначены для решения практических задач.

Классификацию по целевому предназначению можно также переформулировать в виде классификации по защищённым свойствам протокола, для обеспечения которых он разрабатывался. При этом нужно будет выделить «основные свойства» (например, G10 — формирование новых ключей), а большую часть остальных отнести к дополнительным (например, G7 — аутентификация ключа, и G8 — подтверждение владения ключом). Определение того, какие именно из свойств «основные», а какие «дополнительные», будет создавать неоднозначность классификации по целевому назначению протокола. Если же все свойства протокола назвать «основными», то такая классификация станет слишком детальной.

Классификация по «полноте» выполняемых функций проблематична из-за того, что ни один протокол нельзя назвать в полной мере «прикладным». Любой протокол сам по себе это лишь часть некоторой информационной (или организационной) системы, которая как раз и выполняет требуемую пользователями функцию. Однако можно говорить о том, что отдельные протоколы (например, TLS) являются протоколами более высокого уровня, чем протоколы, например, Диффи—Хеллмана, так как последний часто выступает составной частью того же протокола TLS.

Атаки на протоколы

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

Под атакой на защищённый протокол понимается попытка проведения анализа сообщений протокола и/или выполнения непредусмотренных протоколом действий для нарушения заявленных или подразумеваемых свойств протокола. (Используется модифицированное определение из [Cheremushkin:2009]. Отличие в том, что Черёмушкин в своём определении не описывает, что такое «нарушение работы протокола» и оставляет двусмысленными случаи нарушения, например, свойств G9/PFS и G20/STP.)

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

В случае успешной атаки на подразумеваемые свойства будем уточнять, что успешна атака на использование протокола в некоторой системе. Это будет говорить, разумеется, не о недостатках самого протокола, но о неверном выборе протокола (или его настроек) авторами системы.

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

• MitM «Атака посередине»
  англ. man-in-the-middle attack
  
  Класс атак, в котором злоумышленник ретранслирует и, при необходимости, изменяет все сообщения, проходящие между двумя и более участниками протокола, причём последние не знают о существовании злоумышленника, считая, что общаются непосредственно друг с другом. К данной атаке уязвимы все протоколы, которые не реализуют взаимную аутентификацию сторон (цель G1). Классическим примером атаки данного класса является атака на протокол Диффи—Хеллмана.
• Replay Атака с повторной передачей
  англ. replay attack
  
  Класс атак, в котором злоумышленник записывает все сообщения, проходящие в одном сеансе протокола, а далее повторяет их в новом, выдавая себя за одного из участников первого сеанса. Примерами протоколов, к которым применима данная атака, являются протоколы Ву-Лама и бесключевой протокол Шамира.
• TF Атака подмены типа
  англ. type flaw attack
  
  Класс атак, в котором злоумышленник используя переданное в легальном сеансе протокола сообщение конструирует новое, передавая его на другом проходе (раунде) протокола под видом сообщения другого типа (с другим предназначением). К таким атакам уязвимы, например, протоколы Wide-Mouth Frog, Деннинга—Сако, Yahalom и Отвей—Рииса.
• PS Атака с параллельными сеансами
  англ. parallel-session attack
  
  Класс атак, в котором злоумышленник инициирует несколько одновременных сеансов протокола с целью использования сообщений из одного сеанса в другом. Примером протокола, уязвимого к данному классу атак, является симметричный вариант Нидхема—Шрёдера.
• STS Атака с известным разовым ключом
  англ. short-term secret attack
• KN Атака с известным сеансовым ключом
  англ. known-key attack
  
  Классы атак, в которых злоумышленник получает доступ к временным секретам, используемых в протоколах (например, новым сеансовым ключам), после чего может обеспечить, например, аутентификацию или хотя бы установление сессии от имени одной из сторон протокола.
• UKS Атака с неизвестным сеансовым ключом
  англ. unknown key-share attack
  
  Класс атак на протоколы с аутентификацией ключа, в которых злоумышленник получает возможность доказать одной из сторон владение ключом (с помощью, например, повтора сообщения из легального сеанса), хотя сам ключ злоумышленник не знает. К такому классу атак уязвим, например, симметричный протокол Нидхема-Шрёдера.

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

С другой стороны, следует предполагать, что сеансовые ключи, получаемые в рамках сеансов протоколов, через некоторое время (однако, много большее времени самого сеанса связи) будут получены злоумышленником (классы атак STS и KN). А через значительно более время злоумышленник сможет получить и доступ к «мастер»-ключам — ключам длительного использования, так что протоколы с генерацией сеансовых ключей должны разрабатываться в том числе со свойством G9/PFS.

(Дальше идут разделы с описанием конкретных протоколов.)

Ссылки

• [ISO 7498-2:1989] ISO 7498-2:1989. Information processing systems — Open Systems Interconnection — Basic Reference Model — Part 2: Security Architecture: Standard / ISO/IEC JTC 1 Information technology. — 02.1989. — URL: www.iso.org/standard/15841.html.
• [AVISPA] Automated Validation of Internet Security Protocols and
  Applications (AVISPA): IST-2001-39252. Deliverable 6.1 ’List of Selected Problems’. Properties (Goals). — 2003. — URL: www.avispa-project.org/delivs/6.1/d6-1/node3.html
• [Cheremushkin] Черёмушкин А. В. Криптографические протоколы: основные свойства и уязвимости // Прикладная дискретная математика. — 2009. — нояб. — вып. 2. — с. 115—150. — URL: cyberleninka.ru/article/n/kriptograficheskie-protokoly-osnovnye-svoystva-i-uyazvimosti.pdf.

Послесловие

Автор будет благодарен за фактические и другие замечания к тексту. Презентация и текст подготовлены во многом по замечательной лекции Черёмушкина (ссылка выше).