Пособие «Защита информации» (МФТИ)

Secure Sockets Layer

Протокол SSL обеспечивает установление канала шифрованной связи между Web-клиентами и серверами. В последних версиях SSL, помимо этого, обеспечивается идентификация клиента: сервер знает, какие клиенты с ним работают, и наоборот. SSL также обеспечивает независимость от алгоритма шифрования, так что отпадает необходимость пользоваться одним и тем же алгоритмом RSA, основанным на применении открытых (public) ключей. Netscape в настоящее время работает над созданием Web-браузера и сервера, в которых вместо RSA используется шифровальная карточка Fortezza. Предыдущие версии SSL, слишком сильно опирались на RSA.

Протокол предоставляет такие возможности :

•server authentification

•data encription

•message integrity

Он расположен под протоколами уровня приложений (такими как HTTP,NNTP, Telnet, FTP и т.п.) и над протоколом TCP/IP. Данная стратегия позволяет SSL работать независимо .С применением SSL, одновременно на сервере и клиенте, ваши сообщения передаются в зашифрованной форме, гарантирующей приватность.

SSL использует технологии аутентификации и шифрования ,разработанные в RSA Data Security Inc. К примеру, Netscape Navigator экспортирует версию SSL,

использующую 40-битный ключ для алгоритма RC4.

Структура протокола

SSL предсталяет собой многоуровневый протокол, и на каждом уровне message может включать следующие поля:

•lenght field

•description field

•content field

Можно условно выделить несколько модулей, где каждый служит своей цели:

1)record – принимает данные в блоках произвольного размера , и выполняет следующие операции:

a)fragmentation – конвертирует данные в записи размером 16К(или менее);

b)compression – при необходимости, выполняет компрессию записей;

c)encryption – защищает данные в записи посредством шифрования и МАС;

2)alert – оповещение об ошибках;

3)change cipher – оповещение об изменении стратегии шифрования;

a)handshake – используется при открытии или возобновлении сессии.

SSL принимает сообщение(message) для передачи, фрагментирует данные (в manageable bloks) и, при необходимости, выполняет компрессию данных,применяет МАС, шифрование, а затем передает результат транспортному уровню. На приемном узле данные дешифруется, проверяются, декомпрессируются, собираются и затем доставляются клиентскому уровню.

90

Состояния сессии и соединения

SSL – протокол, ориентированный на соединение.В данном контексте под состоянием (state) принимается информация, соотносящаяся со статусом и целью пакета

Сессия SSL является серией состояний. За координацию состояний клиента и сервера отвечает SSL HandShake Protocol, тем самым позволяет механизмам состояния протоколов каждого оперировать согласованно, не взирая на то, что это состояние не является в точности параллельным.

Логически, состояние представляется дважды:

•рабочее состояние(operating)

•ожидающее состояние(pending) - в течении handshake

Кроме того, существуют дополнительные раздельные состояния чтение и запись.Когда сервер(или клиент) получает ответное сообщение change cipher spec, он переводит состояние pending read в current read. И наоборот, когда абонент посылает сообщение change cipher spec, то происходит смена состояний pending write - current write. Когда завершается handshake, клиент и сервер обмениваются сообщениями change cipher spec, а затем переходят на заново согласованный cipher spec для последующей работы.

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

•session identifier (идентификатор сессии) - произвольная последовательность байтов, выбранная сервером для определения состояния активной или возобновленной сессии

•peer sertificate(сертификат тождественности) - X.509.v3 сертификат (данный эдемент может иметь параметр null)

•compression method (метод сжатия) - алгоритм, используемый для сжатия данных до шифрования

•chipher spec (метод шифрования) - определяет основной алгоритм шифрования данных (например null, DES) и алгоритм для МАС(MD5 или SHA). Он также определяет атрибуты шифрования:

•master secret - 48-byte secret, разделяемый между сервером и клиентом

•is resumable - показывает - может ли сессия использоваться для

инициации нового соединения;

91

Инфраструктуры открытых ключей и стандарт Х.5О9

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

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

Сертификат открытого ключа (PKC – public-key certificate) представляет собой защищенный от постороннего вмешательство набор данных, который свидетельствует о связи открытого ключа с конечным пользователем. Чтобы обеспечить такую связь, одна или несколько третьих сторон ручаются за идентичность пользователя. Третьи стороны, называемые удостоверяющими центрами (CA – certificate authority), выдают пользователю сертификат, который содержит имя пользователя, открытый ключ и другую идентификационную информацию. Имея цифровую подпись удостоверяющего центра, эти сертификаты теперь могут передаваться и храниться.

Сертификат открытого ключа

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

Находят применение различные виды сертификатов. Некоторые из них, такие как Pretty Good Privacy (PGP) связаны с определенным приложением, в данном случае PGP. Другие популярные сертификаты, такие как SET и Internet Protocol Security (IPSec), являются сертификатами специфического назначения. Наиболее широко распространенным форматом сертификатов является стандарт Х.509 версии 3 Международного союза по телекоммуникациям. Первоначально стандарт Х.509 был опубликован в 1988 г. как часть рекомендаций Х.500. С тех пор он дважды пересматривался в 1993 г. и в 1995 г. Документ RFC 2459, описывающий основные

92

положения стандарта Х.509, был опубликован в 1999 г. Группой инженерной поддержки Internet (IETF). Хотя документ RFC 2459 был адресован Internet-сообществу, ряд его положений может быть применен и в корпоративной практике.

Версия	v1, v2, v3
Регистрационный номер сертификата	v1, v2, v3
Идентификатор алгоритма подписи	v1, v2, v3
Имя эмитента	v1, v2, v3
Действительность (не ранее/не позднее)	v1, v2, v3
Имя субъекта	v1, v2, v3
Информация об открытом ключе субъекта	v1, v2, v3
Уникальный идентификатор эмитента	v2, v3
Уникальный идентификатор субъекта	v2, v3
Расширения	v3
Подпись	v1, v2, v3

Рис. Структура сертификата Х.509

Все версии сертификатов Х.509 содержат следующие поля:

■Version (Версия). Это поле различается для разных версий сертификатов, таких как версия 1, версия 2 и версия 3. Поле версии также будет использоваться и в последующих версиях.

■Certificate Serial Number (Регистрационный номер сертификата). Это поле содержит целочисленное значение, уникальное для каждого сертификата; оно создается удостоверяющим центром.

■Signature Algorithm Identifier (Идентификатор алгоритма подписи). Это поле определяет идентификатор алгоритма, используемого для подписи сертификата, а также содержит соответствующие параметры.

■Issuer Name (Имя эмитента). Это поле идентифицирует отличительное имя (DN

— distinguished name) удостоверяющего центра, который создал и подписал данный сертификат.

■Validity (Not Before/After) (Действительность (не ранее/не позднее)). Это поле содержит два значения типа дата/время: недействителен до и недействителен после. Эти значения определяют период, на протяжении которого данный сертификат считается действительным, если не будет отменен. Запись может иметь следующие форматы: время в формате UTC – универсального синхронизированного времени {yymmddhhmmssz) или обобщенного времени (yyyymrnddhhmmssz).

■Subject Name (Имя субъекта). Это поле идентифицирует отличительное имя конечной сущности, на которую ссылается этот сертификат, т.е. сущности, которая владеет соответствующим секретным ключом. Это поле должно иметь значение, если только в расширении для версии 3 не используется альтернативное имя.

■Subject Public Key Information (Информация об открытом ключе субъекта).

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

Уникальные идентификаторы

Сертификаты версий 2 и 3 могут содержать уникальные идентификаторы, которые относятся к субъекту и эмитенту. Эти поля предназначены для того, чтобы учесть возможность многократного использования этих имен в течение определенного времени. RFC 2459 рекомендует, чтобы имена не использовались многократно для различных объектов, а также чтобы Internet-сертификаты не использовали уникальные

93

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

■Issuer Unique Identifier (Уникальный идентификатор эмитента). Это необязательное поле содержит уникальный идентификатор, который используется для однозначного представления имени Х.500 удостоверяющего центра в случаях, когда одно и то же имя многократно используется в течение некоторого времени различными сущностями. Это поле может использоваться только в сертификатах версии 2 и версии 3, а его использование не рекомендуется RFC 2459.

■Subject Unique Identifier (Уникальный идентификатор субъекта). Это необязательное поле содержит уникальный идентификатор, который используется для однозначного представления имени Х.500 владельца сертификата, если одно и то же имя в течение некоторого времени многократно используется различными сущностями. Это поле может использоваться только в сертификатах версий 2 и 3, его использование не рекомендуется RFC 2459.

Стандартные расширения сертификатов версии 3

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

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

Следующие стандартные поля расширения сертификата имеются только в сертификатах версии 3:

■Authority Key Identifier (Идентификатор ключа удостоверяющего центра). Это расширение используется для различения многочисленных ключей подписи сертификатов одного и того же удостоверяющего центра. Удостоверяющий центр предоставляет уникальный идентификатор ключа или предоставляет указатель на другой сертификат, который может удостоверять ключ эмитента. RFC 2459 обязывает использовать это поле для любого сертификата, который не является самоподписывающимся.

■Subject Key Identifier (Идентификатор ключа субъекта). Это расширение используется для различения многочисленных ключей подписи сертификатов одного и того же владельца сертификата. Владелец предоставляет уникальный идентификатор ключа либо предоставляет указатель на другой сертификат, который может удостоверять ключ эмитента. RFC 2459 обязывает использовать это поле для всех подписываемых удостоверяющим центром сертификатов, а также рекомендует применять его для конечных сущностей.

■Key Usage (Использование ключа). Это расширение применяется для задания ограничений на операции, которые могут выполняться с открытым ключом в составе этого сертификата. К таким операциям относятся: цифровая подпись, подпись сертификата, подпись списка отмены сертификатов (CRL — certificate revocation list), шифрование ключа, шифрование данных и согласование ключей Диффи-Хеллмана. Это поле может быть помечено как критичное или как некритичное. Если оно помечено как

94

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

■Extended Key Usage (Расширенное использование ключа). Это расширение может быть использовано в дополнение или вместо поля расширения «Использование ключа», чтобы определить одно или несколько применений открытого ключа, который удостоверяет данный сертификат. Это расширение дает возможность сертификату взаимодействовать с различными протоколами и приложениями [такими как аутентификация сервером, аутентификация клиентом, отметки времени и другие функции протокола Transport Layer Security (TLS)]. RFC 2459 указывает, что это поле может быть помечено как критичное; или некритичное.

■CRL Distribution Point (Пункт распространения списков отмены сертификатов). Это расширение задает унифицированный идентификатор ресурса (URI) для указания местоположения структуры списков отмены сертификатов, содержащей информацию об отмене данного сертификата. RFC 2459 рекомендует, чтобы это поле было помечено как некритичное, хотя при этом рекомендуется, чтобы удостоверяющий центр и приложения поддерживали это расширение.

■Private Key Usage Period (Период использования секретного ключа). Подобно полю действительности сертификата, это расширение указывает период времени использования секретного ключа, ассоциированного с открытым ключом в данном сертификате. При отсутствии этого расширения период действия секретного ключа совпадает с периодом действия открытого ключа. RFC 2459 рекомендует не применять это расширение.

■Certificate Policies (Политики для сертификата). Это расширение задает политики и необязательную уточняющую информацию, которую удостоверяющий центр связывает с сертификатом. Если это расширение помечено как критичное, обрабатывающее приложение должно придерживаться, по крайней мере, одной из указанных политик, иначе сертификат не будет применяться. Чтобы способствовать совместимости, RFC 2459 рекомендует не использовать это поле, а указывать два возможных спецификатора: заявление о практике сертификации (CPS —certification practice statement) и извещение пользователя. Спецификатор CPS содержит указатель на заявление о практике сертификации, которое применяется к этому сертификату. Извещение может состоять из ссылки на уведомление или явного уведомления (или из того и другого), которые, в свою очередь, предоставляют текстовое сообщение относительно политики, требуемой для данного сертификата.

■Policy Mappings (Соответствие политик). Это расширение используется только в том случае, если субъект сертификата одновременно является удостоверяющим центром. Оно задает один или несколько идентификаторов объектов (OID — object identifiers) в составе домена удостоверяющего центра эмитента, которые должны совпадать с другой политикой в составе домена удостоверяющего центра субъекта.

■Subject Alternative Name (Альтернативное имя субъекта). Это расширение задает одно или несколько альтернативных форм имен, связанных с владельцем данного сертификата. Использование данного поля дает возможность поддерживать различные приложения, которые используют свои собственные формы имен, включая различные программы для работы с электронной почтой, средства электронного обмена данными

(EDI — Electronic Data Interchange) и IPSec. RFC 2459 указывает, что если в поле субъекта сертификата не задано отличительное имя, должно иметься одно или несколько альтернативных имен, и это расширение должно быть помечено как критичное.

■Issuer Alternative Name (Альтернативное имя эмитента). Это расширение задает одно или несколько альтернативных форм имен, ассоциированных с эмитентом данного сертификата. Как и для расширения «Альтернативное имя субъекта», использование этого поля позволяет обеспечить поддержку различными приложениями.

95

■Subject Directory Attributes (Атрибуты каталога субъекта). Это расширение может быть использовано для доставки любых значений атрибутов каталога Х.500 о субъекте данного сертификата. Оно предоставляет дополнительную идентифицирующую информацию о субъекте, которая не содержится в полях имени (например, номер телефона субъекта или его должность). RFC 2459 рекомендует пока не использовать это расширение. Однако в случае, если оно используется, RFC 2459 обязывает использовать флаг некритичности для обеспечения совместимости.

■Basic Constraints (Основные ограничения). Это расширение указывает, действует ли субъект как удостоверяющий центр, не предоставляя возможности конечным пользователям выступить в роли удостоверяющего центра. Если это поле присутствует, должна быть также задана длина пути сертификации. Длина пути сертификации ограничивает возможности по сертификации нового удостоверяющего центра (например, Verisign может уполномочить RSA Inc. действовать в качестве удостоверяющего центра, но в то же время не позволить RSA Inc. создавать новые удостоверяющие центры). RFC 2459 требует, чтобы это расширение присутствовало и было помечено как критичное для всех сертификатов удостоверяющего центра.

■Name Constraints (Ограничения на имена). Это расширение предназначено для использования только в составе сертификатов удостоверяющих центров и задает пространство имен, внутри которого должны располагаться все имена субъектов для любого последующего сертификата, который является частью этого пути сертификации. RFC 2459 требует, чтобы это расширение было помечено как критичное.

■Policy Constraints (Ограничения политик). Это расширение предназначено для использования только в составе сертификатов удостоверяющих центров, задает проверку пути к политике, запрашивая идентификаторы политик или запрещая задание соответствий политик (или и то, и другое). RFC 2459 констатирует, что это расширение может быть помечено и как критичное, и как некритичное.

Имена сущностей

В сертификате открытого ключа имена сущностей как эмитента, так и субъекта должны быть уникальными. Версии 1 и 2 сертификатов используют соглашение по присвоению отличительных имен Х.500.

Первоначально предполагалось использовать отличительные имена (DN) для идентификации сущностей в составе дерева каталога Х.500. Относительное отличительное имя (RDN — relative distinguished name) представляет собой путь от одного узла к подчиненному узлу. Полное отличительное имя представляет собой путь от корня дерева к конечному узлу, который представляет определенную сущность. Назначение каталога – предоставить инфраструктуру для уникального присвоения имен каждой взаимодействующей сущности в любом месте (что и обеспечивает их различение). В результате такого подхода имена в сертификатах Х.509 оказываются, несколько более сложными, чем хотелось бы (в сравнении скажем, с адресами электронной почты). Тем не менее, для бизнес-приложений отличительные имена и должны быть гораздо более сложными, поскольку они тесно связаны с юридическими процедурами регистрации имен, для чего недостаточно простых имен, таких как адреса электронной почты. Отличительное имя состоит из одного или нескольких относительных отличительных имен, а каждое относительное отличительное имя состоит из одного или нескольких утверждений атрибут-значение (AVA — attribute-value assertion). Каждое AVA состоит из идентификатора атрибута и соответствующей информации о его значении, например

«CountryName = US» или «CommonName = Jeff Hamilton».

Сертификаты Х.509 версии 3 предоставляют большую гибкость в использовании имен, не ограничивая применением только имен Х.500. Сущности, могут идентифицироваться по

96

одному или нескольким именам, использующим разнообразные формы имен. В стандарте Х.509 распознаются следующие формы имен:

■Адрес электронной почты Internet.

■Имя домена Internet (любое официальное имя DNS).

■Адрес электронной почты Х.400.

■Имя каталога Х.500.

■Имя стороны EDI.

■URI в Web, подтипом которого является унифицированный указатель ресурса

(URL).

■IP-адрес в Internet (используется для связывания пары открытого ключа с конечными точками Internet-соединения).

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

Модели доверия

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

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

Иерархии сертификатов

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

Преимуществом иерархии сертификатов является то, что не все стороны должны автоматически доверять всем удостоверяющим центрам. Фактически, единственным удостоверяющим центром, которому необходимо доверять, является высший в иерархии удостоверяющий центр. Из-за своего положения в иерархии этот центр обычно называют корневым удостоверяющим центром. В качестве примеров общеизвестных корневых удостоверяющих центров можно привести Verisign, Thawte и Почтовую службу США.

Перекрестная сертификация

ДОПИСАТЬ!!!

Цепочка сертификатов Х.509

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

97

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

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

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

Описанная здесь система цепочек основана на личностях, имеющих доступ ко всем сертификатам в цепочке. Как доверяющая сторона получает эти сертификаты? Один из способов для эмитента – отправить всю цепочку сертификатов при отправке одного сертификата. Это модель с проталкиванием, и которой отправитель передает получателю всю цепочку сертификатов, а получатель может немедленно проверить все сертификаты. При использовании модели с извлечением посылается только сертификат отправителя, а получатель сам извлекает сертификат удостоверяющего центра. Поскольку каждый сертификат содержит имя эмитента, получатель знает, где можно промерить сертификат. (Чтобы облегчить поиск, в версии 3 сертификатов предлагается большее число информационных полей.) Однако даже в модели с проталкиванием может возникнуть необходимость связывания сертификатов в цепочку получателем.

98

Содержание:

Моноалфавитные шифры и их криптоанализ	1-3
Полиалфавитные шифры	4-5
Блоковые и поточные шифры и тд	6-6
ГОСТ DES AES	7-16
Теория простых чисел	17-22
RSA	23-24
El Gamal	25-28
Цифровая подпись	29-33
Эллиптические кривые	34-40
Фейг-Фиат-Шамир	41-44
Русский хеш(gost3411)	45-53
3х этапный протокол Шамира	54-55
Протокол Нидхэма-Шрёдера	56-60
Протокол Диффи-Хеллмана	61-63
Протокол MTI(Мацумото-Такашима-Имаи)	64-64
Протокол STS(точка-точка)	65-66
Распространение ключей, Протокол Жиро(Girault)	67-67
Шамир и Блом	68-71
Протокол Бриккелла (Brickell)	72-72
Buffer overflow	73-75
IPSec	76-78
Kerberos	79-83
Web-аутентификация клиента(Cookie)	84-86
Код аутентификации сообщения MAC	87-89
Понятие о SSL	90-91
Сертификат X509v3	92-98