защищенный канал связи что это
Принцип Доверия (Trust) в HTTPS
Сейчас уже, наверное, больше половины серверов перебрались с http на https протокол. Зачем? Ну, это мол круто, секъюрно.
В чем же заключается эта секъюрность? На эту тему уже написана куча статей, в том числе и на Хабре. Но я бы хотел добавить еще одну.
Почему решил написать
Я, вообще, по специальности Android разработчик, и не особо шарю в криптографии и протоколах защиты информации. Поэтому когда мне пришлось столкнуться с этим непосредственно, я был немного в шоке от размера пропасти в моих теоретических знаниях.
Я начал рыться в разных источниках, и оказалось, что в этой теме не так просто разобраться, и тут недостаточно просто прочитать пару статей на Хабре или Вики, при чем я нигде не встретил абсолютно исчерпывающего и понятного источника, чтобы сослаться и сказать — «Вот это Библия». Поэтому у меня это «немного разобраться» заняло кучу времени. Так вот, разобравшись, я решил поделиться этим, и написать статью для таких же новичков, как и я, или просто для людей, которым интересно зачем в строке URL иногда стоит https, а не http.
Что значит защищенный канал связи?
Чтобы канал передачи данных считался защищенным, должны выполняться 3 основные принципа:
В этой статье я хотел бы рассказать подробно только о механизме Доверия.
Что значит Доверие (Trust)?
Вы можете доверять вашему собеседнику только если точно знаете, что он — тот, за кого себя выдает.
Самый простой пример — вы знаете собеседника лично, более сложный — вы знаете кого-то кто лично знает вашего предполагаемого собеседника и этот кто-то гарантирует что собеседнику можно доверять.
Жизненный пример
Представим, Вы хотите купить квартиру.
Для этого Вы находите Риэлтора, который занимается продажей квартир.
Риэлтор говорит, что он работает с неким Застройщиком, и предлагает квартиру от этого Застройщика.
Застройщик говорит, что жилье, которое он строит будет, сдано, и те кто заплатил за него деньги Риэлтору, получит его в собственность, и легальность строительства и право собственности будет обеспечена Государством.
Итого у нас есть 4 субъекта Вы, Риэлтор, Застройщик, Государство.
Для того чтобы сделка успешно состоялась и никто никого не обманул Государство создало законы, определяющие документы, которые гарантируют легальность сделок, и механизм печати или подписи, который гарантирует подлинность этих документов.
У Вас есть примеры этих документов и печатей, вы можете их взять у Государства.
Вы имеете право требовать у Риэлтора оригиналы документов на строительство.
Риэлтор берет документы Застройщика, которые подкреплены документами Государства и убеждается, что квартиры можно продавать — они легальны.
Застройщик же в свою очередь получает документы у Государства.
Т.е. теперь вы можете смело вести диалог только с Риэлтором, основываясь на его документах, скрепленных печатями Застройщика и Государства!
Доверие в HTTPS
А теперь поменяем имена действующих лиц из Жизненного примера.
Вы = Клиент (Client)
Риэлтор = Сервер (Server)
Застройщик = Промежуточный Центр Сертификации (Intermediate CA)
Государство = Главный Центр Сертификации (Root CA)
Главный Центр Сертификации (Root Certificate Authority, CA) — общепризнанная известная компания, которой международные организации выдали полномочия заведовать сертификатами и подписями, короче этой компании доверяют все.
Она может давать некоторые полномочия Промежуточным центрам Сертификации (Intermediate CA), и они будут подписывать документы от имени Главного Центра.
Перейдем к математике
Были упомянуты слова: подпись, сертификат и т.д. Как это реализовать? В помощь приходит асимметричное шифрование.
Чтобы не вдаваться в подробности и не объяснять дискретную математику и криптографию, уясним пару вещей:
1) Коротко и о главном об асимметричном шифровании.
Есть 2 ключа — Публичный и Приватный (Public Key and Private Key). Собственно, ключи — это просто большие числа.
Если сообщение шифруется Публичным, то его может расшифровать только соответствующий ему Приватный ключ.
И наоборот:
Если сообщение шифруется Приватным, то его может расшифровать только соответствующий ему Публичный ключ.
Приватный ключ никому не дается, Публичный — собственно, публичный.
2) Цифровая подпись (Digital Signature) — это часть документа, зашифрованная Приватным ключом Подписчика (Issuer). Если ее можно расшифровать Публичным Ключом Подписчика, то можно с уверенностью утверждать, что именно Подписчик ее шифровал.
COMODO Certification Authority
Identity: COMODO Certification Authority
Verified by: COMODO Certification Authority
Expires: 31.12.29
Subject Name
C (Country): GB
ST (State): Greater Manchester
L (Locality): Salford
O (Organization): COMODO CA Limited
CN (Common Name): COMODO Certification Authority
Issuer Name
C (Country): GB
ST (State): Greater Manchester
L (Locality): Salford
O (Organization): COMODO CA Limited
CN (Common Name): COMODO Certification Authority
Issued Certificate
Version: 3
Serial Number: 4E 81 2D 8A 82 65 E0 0B 02 EE 3E 35 02 46 E5 3D
Not Valid Before: 2006-12-01
Not Valid After: 2029-12-31
Certificate Fingerprints
SHA1: 66 31 BF 9E F7 4F 9E B6 C9 D5 A6 0C BA 6A BE D1 F7 BD EF 7B
MD5: 5C 48 DC F7 42 72 EC 56 94 6D 1C CC 71 35 80 75
Public Key Info
Key Algorithm: RSA
Key Parameters: 05 00
Key Size: 2048
Key SHA1 Fingerprint: 11 E4 91 D1 C9 E4 C0 EB 9A CE CF 73 54 5D E1 F1 A8 30 3E C3
Public Key: 30 82 01 0A 02 82 01 01 00 D0 40 8B 8B 72 E3 91 1B F7 51 C1 1B 54 04 98 D3 A9 BF C1 E6 8A 5D 3B 87 FB BB 88 CE 0D E3 2F 3F 06 96 F0 A2 29 50 99 AE DB 3B A1 57 B0 74 51 71 CD ED 42 91 4D 41 FE A9 C8 D8 6A 86 77 44 BB 59 66 97 50 5E B4 D4 2C 70 44 CF DA 37 95 42 69 3C 30 C4 71 B3 52 F0 21 4D A1 D8 BA 39 7C 1C 9E A3 24 9D F2 83 16 98 AA 16 7C 43 9B 15 5B B7 AE 34 91 FE D4 62 26 18 46 9A 3F EB C1 F9 F1 90 57 EB AC 7A 0D 8B DB 72 30 6A 66 D5 E0 46 A3 70 DC 68 D9 FF 04 48 89 77 DE B5 E9 FB 67 6D 41 E9 BC 39 BD 32 D9 62 02 F1 B1 A8 3D 6E 37 9C E2 2F E2 D3 A2 26 8B C6 B8 55 43 88 E1 23 3E A5 D2 24 39 6A 47 AB 00 D4 A1 B3 A9 25 FE 0D 3F A7 1D BA D3 51 C1 0B A4 DA AC 38 EF 55 50 24 05 65 46 93 34 4F 2D 8D AD C6 D4 21 19 D2 8E CA 05 61 71 07 73 47 E5 8A 19 12 BD 04 4D CE 4E 9C A5 48 AC BB 26 F7 02 03 01 00 01
Subject Key Identifier
Key Identifier: 0B 58 E5 8B C6 4C 15 37 A4 40 A9 30 A9 21 BE 47 36 5A 56 FF
Critical: No
Key Usage
Usages: Digital signature
Critical: Yes
Basic Constraints
Certificate Authority: Yes
Max Path Length: Unlimited
Critical: Yes
Extension
Identifier: 2.5.29.31
Value: 30 40 30 3E A0 3C A0 3A 86 38 68 74 74 70 3A 2F 2F 63 72 6C 2E 63 6F 6D 6F 64 6F 63 61 2E 63 6F 6D 2F 43 4F 4D 4F 44 4F 43 65 72 74 69 66 69 63 61 74 69 6F 6E 41 75 74 68 6F 72 69 74 79 2E 63 72 6C
Critical: No
Signature
Signature Algorithm: SHA1 with RSA
Signature Parameters: 05 00
Signature: 3E 98 9E 9B F6 1B E9 D7 39 B7 78 AE 1D 72 18 49 D3 87 E4 43 82 EB 3F C9 AA F5 A8 B5 EF 55 7C 21 52 65 F9 D5 0D E1 6C F4 3E 8C 93 73 91 2E 02 C4 4E 07 71 6F C0 8F 38 61 08 A8 1E 81 0A C0 2F 20 2F 41 8B 91 DC 48 45 BC F1 C6 DE BA 76 6B 33 C8 00 2D 31 46 4C ED E7 9D CF 88 94 FF 33 C0 56 E8 24 86 26 B8 D8 38 38 DF 2A 6B DD 12 CC C7 3F 47 17 4C A2 C2 06 96 09 D6 DB FE 3F 3C 46 41 DF 58 E2 56 0F 3C 3B C1 1C 93 35 D9 38 52 AC EE C8 EC 2E 30 4E 94 35 B4 24 1F 4B 78 69 DA F2 02 38 CC 95 52 93 F0 70 25 59 9C 20 67 C4 EE F9 8B 57 61 F4 92 76 7D 3F 84 8D 55 B7 E8 E5 AC D5 F1 F5 19 56 A6 5A FB 90 1C AF 93 EB E5 1C D4 67 97 5D 04 0E BE 0B 83 A6 17 83 B9 30 12 A0 C5 33 15 05 B9 0D FB C7 05 76 E3 D8 4A 8D FC 34 17 A3 C6 21 28 BE 30 45 31 1E C7 78 BE 58 61 38 AC 3B E2 01 65
Что же происходит на каждом из субъектов
1) Начнем с Root CA
2) Этот Self Signed Certificate раздается клиентам
3) Подтверждение своей аутентичности
Если не вдаваться в детали, то этот пункт одинаков для Сервера и Промежуточных Центров Аутентификации
В итоге, имеем Self Signed Certificate на клиенте и Signed Server Certificate на сервере, т.е. клиент знает и доверяет СА и СА прогарантировал аутентичность сервера.
4) Непосредственно диалог
Теперь глянем что же происходит при обращении клиента к серверу. Для этого используем Network dump от Wireshark.
Мы видим сообщения:
Client Hello, Server Hello, Change Cipher Spec, Encrypted Handshake Message
Ниже показано, что эти сообщения с собой несут:
Как видим, вместе с Server Hello Клиенту приходит Цепочка Сертификатов Сервера (Server Certificate).
Как клиент проверяет подлинность Сертификата. Как это происходит:
1) Клиент смотрит, есть ли у него Root CA для верхнего сертификата в цепочке,
если нет — спускается по цепочке ниже, при чем каждый раз перепроверяет, действительно ли подписан сертификат предыдущим в цепочке. (Это просто — цифровая подпись нижнего должна расшифровываться публичным ключом верхнего).
Если не нашел, значит у Клиента и Сервера нет общего знакомого CA, доверять серверу нельзя.
2) если есть — Клиент берет Публичный Ключ своего сертификата и пробует расшифровать подпись сертификата, пришедшего с Сервера.
Примечание
Протокол TLS также поддерживает механизм доверия Сервера к клиенту. Как видно из рис 5, в ответ на Server Hello, может прийти сертификат клиента, и сервер тоже может удостовериться, что CA гарантировал его аутентичность.
Заключение
Итак, когда обе стороны убедились, что их собеседники — те за кого себя выдают, можно начинать диалог. При чем, сразу же есть все для дальнейшего шифрования сообщений — приватный ключ на стороне сервера, и его публичный ключ на клиенте, который был прислан с сертификатом сервера. Но в дальнейшем асимметричное шифрование используется только один раз — когда клиент шифрует пароль публичным ключом сервера, и отправляет серверу — KlientKeyExchange. Далее уже этот пароль используется для симметричного шифрования сообщений, так как оно значительно быстрее и проще асимметричного. Механизмы выбора протокола шифрования и обеспечения целостности сообщений — это огромная область математики и криптографии, но, к счастью для пользователя, она уже реализована под капотом SSL. Все что надо — чтобы на клиенте и сервере были совместимые версии SLL, шифров, криптопровайдеров.
В конце хотелось бы сказать, что протоколы безопасной коммуникации:
Но главный, и пожалуй, достаточный, аргумент за — HTTPS и TLS действительно безопасны, насколько это возможно.
Защищенный канал связи что это
В этой главе показано, как создавать защищенные коммуникационные каналы в Интернет. Эти каналы используются для подключения сетей через Интернет таким способом, чтобы информация, передаваемая через Интернет, была бы надежно защищена от чтения или модификации.
8.1 Введение
Что такое защищенный канал и для чего он применяется?
На любом из хостов, встречающихся на пути пакетов, может просмотреть их содержимое и/или изменить что-либо в них. Все это создает серьезные проблемы, тем более существенные, чем выше уровень значимости или конфиденциальности передаваемых данных.
Для решения этих проблем и применяются защищенные информационные каналы. Их можно представить себе как некий тоннель. Информация помещается с одной стороны тоннеля и прочесть ее можно только с другой стороны.
На самом деле, передаваемая информация модифицируется таким образом, чтобы их невозможно было изменить (аутентификация) или просмотреть (криптография) на пути их следования. При совместном применении этих двух механизмов обеспечивается как сокрытие информации, так и невозможность ее подмены на всем пути ее следования.
Что такое криптография?
Если один из этих компонентов держится в секрете (как правило, ключ), то просмотреть данные постороннему человеку невозможно.
Созданная таким образом электронная подпись передается вместе с данными в пункт назначения. Если данные в процессе передачи подверглись изменениям, это сразу же обнаружится: в хосте назначения будет вычислена электронная подпись от полученных данных и после сравнения с полученной подписью подмена будет обнаружена.
Операция по вычислению подписи выполняется очень быстро по сравнению с шифрованием. Тем не менее, она не может защитить данные от чтения. Поэтому ее следует применять, если важна надежность доставки, а не конфиденциальность. Для обеспечения обеих характеристик аутентификация используется совместно с криптографией.
Типы аутентификации и алгоритмы шифрования
Одним из параметров оценки прочности алгоритма является размер ключа. Чем большее количество бит содержится в ключе, тем больше можно составить всевозможных комбинаций, и тем сильнее, теоретически, данный алгоритм должен противостоять атакам.
Алгоритм Triple DES заключается в троекратном применении алгоритма DES с использованием трех различных ключей для одних и тех же данных. Это эквивалентно использованию алгоритма с ключом в 112 бит, что приводит к резкому повышению уровня безопасности по сравнению с DES. Его главным недостатком остается то, что он в два раза медленнее, чем DES (в реализации, используемой межсетевым экраном Aker).
Алгоритмы обмена ключами
В этом случае все настройки ключевой информации производятся вручную. При этом если производится замена ключей, обе стороны, между которыми образован защищенный канал, должны быть одновременно переконфигурированы
Опишем сценарий в общих чертах: для установления связи генерируется случайный ключ и он используется для шифрования и аутентификации посылаемых данных. Затем этот ключ шифруется на мастер ключе и отсылается вместе с зашифрованными данными. Когда принимающая сторона получает пакет, она расшифровывает ключ с помощью мастер ключа и использует его для расшифровки остального пакета.
Поскольку алгоритмы, используемые для аутентификации, шифрования пакета и ключа определяются отправителем и передаются как часть протокола, получателю нет нужды настраивать эти параметры в приемнике.
Основным преимуществом SKIP является возможность использования одного и того же секрета годами, не боясь его взлома нарушителем (поскольку замена ключа производится с интервалом от нескольких секунд до максимального значения в один час, в зависимости от трафика между взаимодействующими сетями).
Настоятельно рекомендуется пользоваться этой опцией при конфигурировании защищенных каналов.
Определение защищенных каналов
Для определения групп хостов используется концепция объектов, рассмотренная в главе Регистрация объектов. При определении канала можно пользоваться объектами типа «хост», «сеть» или «набор».
Кроме объектов, необходимо определить алгоритм аутентификации, и в случае необходимости, криптографический алгоритм. Ключи аутентификации и шифрования завершают перечень параметров, необходимых для описания канала.
Планирование защищенных каналов должно проводиться очень тщательно. Использование криптографии отнимает много вычислительных ресурсов. Поэтому шифрование пакетов, если это не диктуется интересами безопасности, представляется напрасной тратой ресурсов. Более того, разные алгоритмы шифрования требуют различного объема обработки, и обеспечивают различные уровни безопасности. Каждый алгоритм следует выбирать в зависимости от необходимого уровня безопасности (выше было дано описание всех алгоритмов, поддерживаемых межсетевым экраном Aker).
Примеры использования защищенных каналов
Конфигурация межсетевого экрана Aker сети 1
Защищенный канал 1 :
Направление канала: отправка
Источник: NETWORK1
Назначение: NETWORK2
Алгоритм шифрования: DES
Алгоритм аутентификации: MD5
Ключ аутентификации: X1
Ключ шифрования: X2
Защищенный канал 2 :
Направление канала: прием
Источник: NETWORK2
Назначение: NETWORK1
Алгоритм шифрования: DES
Алгоритм аутентификации: MD5
Ключ аутентификации: X3
Ключ шифрования: X4
Конфигурация межсетевого экрана Aker сети 2
Защищенный канал 1 :
Направление канала: прием
Источник: NETWORK1
Назначение: NETWORK2
Алгоритм шифрования: DES
Алгоритм аутентификации: MD5
Ключ аутентификации: X3
Ключ шифрования: X4
Защищенный канал 2 :
Направление канала: отправка
Источник: NETWORK2
Назначение: NETWORK1
Алгоритм шифрования: DES
Алгоритм аутентификации: MD5
Ключ аутентификации: X1
Ключ шифрования: X2
- ! Обратите внимание на то, что правило 1 для межсетевого экрана Aker 1 в точности совпадает с правилом 1 для межсетевого экрана Aker 2, за исключением пункта, связанного с направлением. То же касается и правила 2.
Пример конфигурации защищенного канала для подсети
В этом примере определим защищенный канал только для группы хостов в каждой из двух сетей. Кроме того, установим различные алгоритмы для каналов между этими группами.
Использование различных алгоритмов для двух направлений защищенного канала может оказаться полезным в том случае, когда ценность информации в одном направлении больше, чем в другом. В этом случае более защищенный алгоритм применяется в наиболее критическом направлении. Предположим еще, что сети 1 и 2 содержат два адреса класса В: А1.В1.0.0 и А2.В2.0.0, соответственно.
Конфигурация межсетевого экрана Aker сети 1
Защищенный канал 1 :
Направление канала: отправка
Источник: SUBNET1
Назначение: SUBNET2
Алгоритм шифрования: DES
Алгоритм аутентификации: MD5
Ключ аутентификации: X1
Ключ шифрования: X2
Защищенный канал 2 :
Направление канала: прием
Источник: SUBNET2
Назначение: SUBNET1
Алгоритм шифрования: 3DES
Алгоритм аутентификации: SHA
Ключ аутентификации: X3
Ключ шифрования: X4
Конфигурация межсетевого экрана Aker сети 2
Защищенный канал 1 :
Направление канала: отправка
Источник: SUBNET2
Назначение: SUBNET1
Алгоритм шифрования: 3DES
Алгоритм аутентификации: SHA
Ключ аутентификации: X3
Ключ шифрования: X4
Защищенный канал 2 :
Направление канала: прием
Источник: SUBNET1
Назначение: SUBNET2
Алгоритм шифрования: DES
Алгоритм аутентификации: MD5
Ключ аутентификации: X1
Ключ шифрования: X2
- ! Заметьте, что в этом случае совпадение правил возникает в двух межсетевых экранах в другом порядке: правило 1 в межсетевом экране 1 совпадает с правилом 2 в межсетевом экране 2 (с измененными направлениями), а правило 2 в экране1 совпадает с правилом 1 в экране 2 (опять с измененными направлениями). Конечно, порядок описания правил для данных примеров не имеет значения (однако, это не всегда так):
8.2 Использование графического интерфейса пользователя
Окно настройки защищенных каналов
Рекомендация: Все опции, кроме опции «deselect», доступны через инструментальное меню, расположенное в верхней части окна. В этом случае сначала надо выделить канал, нажав на нем левой клавишей мыши, а затем выбрать необходимую опцию. При добавлении или редактировании каналов появится окно свойств, описание которого приведено ниже:
Использование ручного механизма обмена ключами
Source Entities : Определяет объекты, адреса которых будут сравниваться с адресом источника IP пакетов, которые должны попадать в канал.
Destination Entities : Определяет объекты, адреса которых будут сравниваться с адресом назначения IP пакетов, которые должны попадать в канал.
Comment: Поле комментариев.
Direction of the channel: Определяет направление канала. Эта опция может принимать два значения: отправка ( send ) или ( receive прием. За деталями обращайтесь к разделу этой главы Введение.
SPI: (Security Parameter Index) Это уникальное число, используемое приемником, которое идентифицирует потоки. Оно должно превышать 255 и обязательно различаться для каждого канала, направленного к тому же приемнику.
Ключ аутентификации: Это ключ, используемый при аутентификации. Он должен быть записан в шестнадцатеричном формате. Максимальный размер ключа зависит от используемого алгоритма: 32 знака для MD5 и 40 знаков для SHA. Рекомендуется использовать максимально допустимое количество знаков.
Тип аутентификации: Это поле определяет, какой алгоритм аутентификации будет применяться. Возможны два алгоритма: MD5 или SHA. Аутентификация с шифрованием, использующим DES
Это окно полностью совпадает с окном для предыдущего элемента меню за исключением двух полей:
Size of the initialization vector: Это размер в битах вектора инициализации, который применяется в алгоритме DES. Этот вектор генерируется системой автоматически для каждого посылаемого пакета. Рекомендуется использование варианта с 64 битами.
Key: Это ключ, который будет применяться для шифрования пакетов. Он обязательно должен быть шестнадцатеричным числом с 16 знаками. Аутентификация с шифрованием, использующим Triple DES (3DES)
В этом окне добавляются 4 новых поля по сравнению с окном только аутентификация :
Size of the initialization vector: то размер в битах вектора инициализации, который применяется в алгоритме 3DES. Этот вектор генерируется системой автоматически для каждого посылаемого пакета. Рекомендуется использование варианта с 64 битами.
Ключ 1: Это ключ, применяемый при первом преобразовании в алгоритме 3DES. Он обязательно должен быть шестнадцатеричным числом с 16 знаками.
Ключ 2: Это ключ, применяемый при втором преобразовании в алгоритме 3DES. Он обязательно должен быть шестнадцатеричным числом с 16 знаками.
Ключ 3: Это ключ, применяемый при третьем преобразовании в алгоритме 3DES. Он обязательно должен быть шестнадцатеричным числом с 16 знаками.
Использование SKIP для обмена ключей
В протоколе SKIP вся информация, связанная с алгоритмами аутентификации и шифрования, конфигурируется только в хосте, посылающем пакеты. В хосте, который принимает пакеты, необходимо лишь описать объекты источника и назначения и общий секрет.
В обоих случаях появится следующее окно (при настройках на хосте приемнике ненужные поля будут недоступны):
Источник: Определяет объекты, адреса которых будут сравниваться с адресом источника IP пакетов, которые должны попадать в канал.
Приемник : Определяет объекты, адреса которых будут сравниваться с адресом назначения источника IP пакетов, которые должны попадать в канал.
Комментарии: Поле комментариев.
Направление канала: Определяет направление канала. Эта опция может принимать два значения: отправка ( send ) или ( receive) прием. За деталями обращайтесь к разделу этой главы Введение.
Алгоритм шифрования ключа: Это алгоритм, применяемый для шифрования посылаемого в пакете ключа сеанса. Рекомендуется пользоваться 3DES.
Общий секрет: Это секрет, который будет использоваться для генерации мастер ключей (за деталями обращайтесь к разделу этой главы Введение ).Секрет должен быть одинаков для обоих межсетевых экранов по обе стороны канала. Он обязательно должен быть шестнадцатеричным числом с 64 знаками. Кроме этих полей, существуют две кнопки, облегчающие настройку секрета в обоих межсетевых экранах, отвечающего за шифрование и дешифрование в защищенном потоке:
Загрузить секрет: Эта кнопка позволяет прочесть значение из ASCII файла в поле общего секрета. Этот файл должен состоять только из одной строки длиной 64 символа.
Сохранить секрет: Эта кнопка позволяет записать содержимое поля общего секрета в ASCII файл. Переписанный файл будет иметь только одну строку длиной 64 символа. При нажатии какой-либо из этих кнопок появляется окно, позволяющее выбрать имя файла, в котором следует сохранить или считать секрет.
8.3 Использование интерфейса командной строки
Этот интерфейс обладает теми же возможностями, что и графический интерфейс, за исключением того, что он не позволяет описывать комментарии или указывать больше одного объекта для источника или назначения.
Путь к программе : /etc/firewall/fwcripto
Пример 1 : (Просмотр таблицы защищенных каналов)
Пример 2 : (Удаление третьего элемента)
Пример 3 : (Добавление элемента с ручным обменом ключей и шифрованием DES в конец таблицы)
Пример 4 : (Добавление элемента с обменом ключей через SKIP в начало таблицы)