Повышение эффективности протоколов передачи данных, использующих криптографическую защиту

УДК 004.42

Повышение эффективности протоколов передачи данных, использующих криптографическую защиту

В.В. Бондаренко¹, А.В. Чернышова²

*¹ магистрант ст. преподаватель кафедры программной инженерии им. Л.П. Фельдмана,

Донецкий национальный технический университет,

vadimbond.2000@gmail.com

*² ст. преподаватель ст. преподаватель кафедры программной инженерии им. Л.П. Фельдмана,

Донецкий национальный технический университет,

chernyshova.alla@rambler.ru, SPIN-код: 3318-2066

Аннотация:

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

Annotation:

Bondarenko V.V., Chernyshova A.V. Improving the efficiency of data transmission protocols using cryptographic protection. The article is devoted to an urgent problem — modern trends in the field of data transmission protocols with cryptographic protection. The article identifies the advantages and disadvantages of modern data transmission protocols with cryptographic protection, searches for ways to eliminate them when designing an author's data transmission protocol with cryptographic protection for applications of a certain class. The requirements for the data transfer protocol with cryptographic protection have been formed.

Введение

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

Сегодня пользователи, работающие в интернете, задают вопросы «Насколько надежна их переписка при использовании почтовых сервисов?», «Насколько безопасны социальные сети?», «Можно ли безопасно хранить данные в облачном хранилище?». Работая удаленно, сотрудники компаний нуждаются в средствах защиты передаваемой информации при использовании ресурсов фирмы. Используя электронный документооборот, предприятие, учреждение, коммерческая фирма также использует различные способы защиты передаваемой и хранимой информации на основе существующих классических решений - безопасная аутентификация, использование защищенных протоколов передачи данных, работающих на различных уровнях относительно стека протоколов TCP/IP, применение сервисов защищённого хранилища данных. Но тем не менее, при предлагаемых разнообразных решениях по обеспечению сохранности информации, коммерческих и свободно распространяемых продуктов, направленных на защиту передаваемых по сети данных, задачи по повышению эффективности протоколов передачи данных, использующих криптографическую защиту, являются, безусловно, актуальными. Широко используемые протоколы с криптографической защитой имеют ряд достоинств. Но присутствуют и недостатки. Выполнив детальный анализ существующих на текущий момент решений на рынке протоколов с криптографической защитой, можно прийти к выводу о том, что можно изменить в архитектуре или алгоритмах реализации существующих протоколов, чтобы повысить эффективность протокола и адаптировать его, например, к определенному классу приложений, выбрав при этом утвержденные стандарты шифрования.

Анализ современных тенденций в области протоколов передачи данных с криптографической защитой

В последнее время множеству сотрудников пришлось перейти на формат удалённой деятельности, и многие наниматели рекомендовали своим работникам задействовать VPN для безопасного доступа к внутрикорпоративным сервисам.

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

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

VPN также необходим для объединения разных офисов одной и той же компании. Офисы могут быть отдалены друг от друга на большое расстояние.

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

Использование социальных сетей в публичных зонах Wi-fi без сервиса VPN может привести не только к перехвату конфиденциальной информации, но и в дальнейшем есть угроза использования данных аккаунтов в своих целях, пройдя процедуру аутентификации от имени пользователя. Утеря информации для доступа к почтовым сервисам, при незащищенной аутентификации на почтовых серверах, приведет к еще более серьёзным последствиям, так как к почтовым аккаунтам могут быть привязаны другие аккаунты web-приложений, в том числе и сервисов, используемых на предприятиях, в учреждениях, на фирмах, а также профили социальных сетей и другие почтовые аккаунты. Тогда все приложения, связанные с этим почтовым ящиком, могут быть атакованы. Но самым неприятным может быть утечка данных банковских карт, если пользователь решил оформить перевод денег кому-нибудь, подключившись к общедоступному Wi-Fi.

VPN может использоваться также для обеспечения анонимности пользователя при работе в сети Интернет. При использовании VPN затруднительно определить, какие сайты посещает пользователь, каким браузером пользуется, где находится территориально и т.д. Необходимость скрыть своё местоположение может потребоваться в путешествиях при использовании различных интернет-приложений.

Рассмотрим принцип работы VPN.

VPN–соединение - это можно сказать «туннель» между пользователем и сервером. Каждый узел кодирует данные перед тем, как они попадут в «туннель».

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

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

Рисунок 1 – Как работает VPN

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

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

Рассмотрим популярные протоколы VPN.

РРТР – Point-to-Point Tunneling Protocol [2], использует два соединения – одно для управления, другое – для инкапсуляции данных, поддерживается всеми операционными системами, не требует много вычислительных мощностей, но обладает плохой защищенностью. Используемые методы шифрования этого протокола устарели, есть ошибки в реализации протокола от Microsoft. Нет шифрования по умолчанию, на взлом требуется менее суток. Протокол считается менее защищенным, чем IPSec. Используется, когда защита данных не очень важна или когда нет других вариантов.

РРТР анализировали с точки зрения безопасности. В протоколе были обнаружены уязвимости, связанные с используемым протоколом аутентификации PPP, протоколом MPPE и интеграции между аутентификациями MPPE и PPP для установки сессионного ключа. Уязвимости РРТР:

- MSCHAP-v1 ненадёжен;

- MSCHAP-v2 уязвим для словарной атаки;

- при использовании MSCHAP-v1, MPPE использует одинаковый RC4 сессионный ключ для шифрования информационного потока в обоих направлениях;

- MPPE использует RC4 поток для шифрования. Отсутствует метод для аутентификации цифрового потока и поэтому этот поток уязвим для атаки, делающей фальсификацию битов. [3]

L2TP – Layer 2 Tunneling Protocol - Протокол L2TP расширяет модель PPP, позволяя размещение терминальных точек L2 и PPP в различных физических устройствах, подключенных к сети с коммутацией пакетов [4]. Рассматриваемый протокол более эффективен для построения виртуальных сетей, но более требователен к вычислительным ресурсам, стандартно не включает шифрование. Он работает вместе с другими протоколами, чаще всего с IPSec. Используется интернет-провайдерами и пользователями в корпоративных целях.

IPSec – Internet Protocol Security [5] - ряд протоколов и стандартов для безопасных подключений. Достоинствами IPSec являются хорошая архитектура и надежность алгоритмов. Недостатками IPSec являются сложность в настройке, из чего следует понижение защищённости при неверной настройке; для этого требуется большое количество вычислительных возможностей, но данный недостаток компенсируется аппаратным ускорением алгоритма шифрования AES. Он часто используется в совмещении с другими методами.

SSL – Secure Sockets Layer & TLS – Безопасность транспортного уровня - это группа методов, которая включает протоколы TLS, SSL и другие средства защиты. Преимущество протокола заключается в том, что он свободно передается большинством общедоступных сетей. Недостатком протокола является довольно низкая производительность, сложность в настройке и необходимость установки дополнительного программного обеспечения. Протокол SSL используется на веб-сайтах, URL-адреса которых начинаются с https.

Некоторые реализации VPN: OpenVPN [6], Microsoft SSTP [7]. OpenVPN имеет открытый исходный код, реализован практически для каждой платформы и является достаточно безопасным. Он выполняет функцию безопасного туннеля для трансляции информации через один TCP/UDP порт. Главное преимущество OpenVPN состоит в легкости инсталляции и настройки, что является редким случаем для таких инструментов. OpenVPN соединяет клиент/серверную архитектуру. Он должен быть поставлен на все узлы VPN сети, там, где один узел должен быть сервером, а другие - клиентами. VPN шлюзы объединяют один и тот же ключ для дешифрования и шифрования информации при размещении статических ключей. В этом случае изменение настройки будет простым, но при этом появится затруднённость передачи и безопасности ключа. Если кто-то завладеет этим ключом - он сможет декодировать данные.

Для того чтобы это избежать, следует применить инфраструктуру открытых ключей (PKI). При этом каждый узел управляет двумя ключами: закрытый ключ доступный только его хозяину и открытый ключ, известный всем. Данную подсистему использует OpenSSL, соединённый в OpenVPN, для аутентификации VPN узлов до того, как начать передачу закодированных данных.

Microsoft SSTP – протокол туннелирования защищенных сокетов SCTP по определению является протоколом прикладного уровня. Он предназначен для синхронного обмена данными между двумя программами и позволяет использовать несколько конечных точек приложения через одно сетевое соединение между одноранговыми узлами. Это позволяет эффективно использовать коммуникационные ресурсы, доступные в сети.

Протокол SSTP основан на SSL вместо РРТР или IPSec и использует TCP-порт 443 (или другие, как реализовано в Ideco UTM) для ретрансляции трафика SSTP. Хотя он тесно связан с SSL, прямое сравнение между SSL и SMTP невозможно, поскольку, в отличие от SSL, SSTP - это просто протокол туннелирования. Есть много причин выбрать SSL, а не IPSec в качестве основы для SSTP. IPSec нацелен на поддержку VPN-соединения, поэтому SSL стал лучшей основой для разработки STP, поскольку он поддерживает роуминг.

Более подробно о существующих протоколах передачи данных с криптографической защитой можно ознакомиться в статье [8].

Выявление недостатков и уязвимостей существующих алгоритмов защиты в сетях передачи данных

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

Атака на защищенный протокол - это попытка проанализировать протокольные сообщения и/или выполнить действия, не предусмотренные протоколом, с целью разрушения предъявленных или обусловливаемых свойств протокола.

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

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

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

MitM «Атака посередине» [9] (man-in-the-middle attack). Класс атак, при которых преступник повторяет и подменяет текст сообщений, проходящих между двумя или более пользователями протокола, а пользователи не догадываются о том, что переписка «прослушивается» считая, что они общаются лично друг с другом без участия третьего лица. Протоколы, которые не осуществляют обоюдную аутентификацию сторон, беззащитны для этой атаки (цель G1). Традиционный пример атаки такого класса – атака на протокол Диффи—Хеллмана.

Повторная атака с повторной передачей [9]. Класс атак, при которых преступник фиксирует все письма, проходящие в одном сеансе протокола, а затем дублирует их в новом, под видом одного из участников первого сеанса. Наглядными примерами протоколов, к которым применима эта атака, являются протоколы Wu-Lan и протокол Shamir keyless protocol.

Атака подмены типа TF [9]. Класс атак, при которых злоумышленник, используя сообщение, переданное в сеансе локального протокола, создает уникальное, передавая его на другом раунде протокола под образом сообщения другого типа (с другой целью). Например, протоколы Wide-Mouth Frog, Denning—Sako, Yahalom и Otway—Riis уязвимы для таких атак.

PS Атака параллельного сеанса [10] - это атака, при которой преступник инициирует некоторое количество параллельных сеансов протокола, чтобы использовать сообщения из одного сеанса в другом. Наглядным примером протокола, восприимчивого для этого класса атак, считается симметричный вариант Нидхэма— Шредера.

Атака STS с известным одноразовым ключом [10] – это атака на протокол повторной передачи, организованная на знании одноразового секретного ключа.

Атака KN с использованием известного сеансового ключа. [10]

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

Атака UKS с неизвестным сеансовым ключом [10] – это атака, состоящая в попытке получить информацию о долгосрочном ключе или любую другую ключевую информацию, которая позволяет создавать вновь сеансовые ключи для других сеансов протокола.

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

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

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

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

Одним из первых алгоритмом назначения открытого ключа был предложен Хеллманом М. Э. и Диффи У. в 1976 году. [11] Для его реализации участники должны договориться о большом значении простого числа p и обуславливаемого компонента α мультипликативной группы Z ∗ p = = {1, 2, . . ., p − 1}. Чтобы сгенерировать общий ключ k, они должны сформировать некоторые числа x, 1 ≤ x ≤ p − 2 и y, 1 ≤ y 6 ≤ − 2 соответственно. После этого они могут начать общение посредством сообщения. Протокол DH:

Рисунок 2 – Пример обмена сообщениями

Искомый общий ключ теперь вычисляется по формуле

Рисунок 3 – Искомого общего ключа

Слабость: отсутствие аутентификации сторон.

Протокол МТИ. Интересный подход к защите протокола DH от атаки «противник в середине» был предложен Т. Мацумото, И. Такашима и X. Иман (Matsumoto T., Takashima Y., Imai H.) в 1986 г. Они предложили серию протоколов, предполагающих наличие у абонентов открытых ключей и использующих различные модификации процедуры выработки общего ключа.

Рассмотрим протокол МТИ/А0. Предположим, что участники А и В имеют секретные ключи a, 1 ≤ a ≤ p − 2, и b, 1 ≤ b ≤ p − 2, соответственно и публикуют свои открытые ключи βA = α a mod p и βB = α b mod p. Для выработки общего секретного ключа k они должны сгенерировать случайные числа x, 1 ≤ x ≤ p−2, и y, 1 ≤ y ≤ p−2, соответственно, а затем обменяться следующими сообщениями:

Рисунок 4 – Пример обмена сообщениями

Теперь участники А и В вычисляют общий ключ k = α×(xb+ya) mod p по формулам.

Рисунок 5 – Вычисление общего ключа

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

Протокол STS. Попытка построения аутентифицированного протокола на базе DH была предпринята в протоколе STS (station-to-station), созданном У. Диффи (W. Diffie), П. Ван Ооршотом (P. Van Oorschot) и М. Вейнером (M. Wiener) в 1992 г.

Рисунок 6 – Пример обмена сообщениями

Здесь SigA и SigB — цифровые подписи пользователей А и В соответственно, k = α xy mod p — искомый общий ключ.

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

Шифрование значений подписей пользователей с помощью симметричного алгоритма E введено для того, чтобы обеспечить взаимное подтверждение правильности вычисления значения ключа, так как при неверно вычисленном ключе невозможно получить верные значения цифровых подписей. Модифицированный протокол STS. В 2004 г. К. Бойд и А. Матура предложили следующую модификацию протокола STS:

Рисунок 7 – Пример обмена сообщениями по протоколу STS

где k0 = f(k) — ключевой параметр хеш-функции, вычисляемый как значение некоторой функции от результирующего сеансового ключа k = α xy mod p.

Атака: для данной версии протокола можно применить двустороннюю атаку с неизвестным общим ключом (bilateral unknown key-share attack, BUKS attack):

Рисунок 8 – Алгоритм атаки

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

Данная атака не представляет реальной опасности, так как при этом нарушитель не будет знать секретного ключа k = α xy mod p и поэтому не сможет читать передаваемые сообщения, передаваемые от А к В. Однако в результате участник А не будет ничего подозревать и примет участника С за В.

Для повышения защищенности можно расширить протокол за счет использования двухфакторной аутентификации при вводе пароля пользователя и при вводе ключа разблокировки личности, например, через отправку кода подтверждения на e-mail адрес. А также за счет введения в реализацию клиента правил, не позволяющих генерировать простой пароль. При этом e-mail адреса для аутентификации на ресурсе могут храниться на сервере ресурса и задаваться при регистрации на конкретном ресурсе. А e-mail, используемый для разблокировки личности, может храниться в зашифрованном виде вместе с кодом разблокировки, чтобы исключить возможность подмены e-mail адреса на адрес злоумышленника. В таком случае e-mail, необходимый для активации кода разблокировки личности, может задаваться при первом запуске приложения. Оба типа e-mail адресов могут быть изменены при активации кода разблокировки личности. [12]

Также можно генерировать QR-код, хеш которого будет зашифрован и передаваться пользователю, у которого на другом устройстве будет ключ для расшифровки картинки, а из этой картинки будет формироваться ключ для шифрования информации между двумя пользователями. [13]

Формирование требований к протоколу передачи данных с криптографической защитой

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

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

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

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

- использование безопасной аутентификации пользователей на основе двухфакторной аутентификации с использованием криптографических алгоритмов;

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

- использование разовых ключей симметричного алгоритма для шифрования сессий между участниками обмена;

- использование алгоритмов с открытым ключом для защиты ключа симметричного алгоритма шифрования;

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

- обеспечение контроля целостности передаваемых данных с помощью электронно-цифровой подписи;

- использование дополнительных средств защиты, обеспечивающих более надежный обмен ключами (токены, QR-коды);

- возможность использования «арбитра» при генерации ключей для проверки целостности данных;

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

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

Выводы

В статье приведен анализ современных тенденций в области протоколов передачи данных с криптографической защитой. Рассмотрены популярные протоколы VPN, такие как PPTP, L2TP, IPSec, SSL/TLS, OpenVPN, Microsoft SSTP. Выявлены их достоинства и недостатки, а также уязвимости к различным типам атак.

Проанализированы классы атак на криптографические протоколы, включая атаки «человек посередине», повторные атаки, атаки подмены типа, атаки параллельного сеанса и другие. Рассмотрены примеры уязвимостей в известных протоколах, таких как Диффи-Хеллман, МТИ, STS и их модификациях.

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

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

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

Литература

1. Криптография и безопасность сетей / У. Столлингс. – 4-е изд. – М.: «Вильямс», 2011. – 592 с.

2. Point-to-Point Tunneling Protocol (PPTP) [Electronic resource] / Internet resource. – Access mode: datatracker / URL: https://datatracker.ietf.org/doc/html/rfc2637. – Screen title.

3. PPTP Vulnerability [Electronic resource] / Internet resource. – Access mode: sans / URL: https://www.sans.org/reading-room/whitepapers/vpns/paper/505. – Screen title.

4. Layer Two Tunneling Protocol "L2TP" [Electronic resource] / Internet resource. – Access mode: datatracker / URL: https://datatracker.ietf.org/doc/html/rfc2661. – Screen title.

5. Security Architecture for the Internet Protocol [Electronic resource] / Internet resource. – Access mode: datatracker / URL: https://datatracker.ietf.org/doc/html/rfc4301. – Screen title.

6. OpenVPN [Electronic resource] / Internet resource. – Access mode: openvpn / URL: https://openvpn.net/. – Screen title.

7. Microsoft SSTP [Electronic resource] / Internet resource. – Access mode: microsoft / URL: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc731352(v=ws.10). – Screen title.

8. Бондаренко В.В., Чернышова А.В. Анализ протоколов передачи данных с криптографической защитой // Программная инженерия: методы и технологии разработки информационно-вычислительных систем (ПИИВС2023): Сборник материалов V Международной научно-практической конференции, г. Донецк, 30 ноября – 01 декабря 2023 г. – Донецк: Донецкий национальный технический университет, 2023. – С. 85-91.

9. Mao, W. Modern Cryptography: Theory and Practice / W. Mao. – Hewlett-Packard Company, 2004. – 648 p.

10. Menezes, A.J. Handbook of Applied Cryptography / A.J. Menezes, P.C. van Oorschot, S.A. Vanstone. – CRC Press, 1996. – 816 p.

11. New directions in cryptography / W. Diffie, M.E. Hellman // IEEE Transactions on Information Theory. – 1976. – Vol. 22, No. 6. – P. 644–654.

12. Пат. 281668 Российская Федерация, МПК H04L 9/08 (2006.01). Способ аутентификации пользователя в информационной системе / Чернышова А.В., Бондаренко В.В.; заявитель и патентообладатель Донецкий национальный технический университет. – № 2023110979; заявл. 20.04.2023; опубл. 12.09.2023, Бюл. № 26. – 13 с.

13. Пат. 283221 Российская Федерация, МПК H04L 9/08 (2006.01). Способ обмена ключевой информацией между пользователями информационной системы / Чернышова А.В., Бондаренко В.В.; заявитель и патентообладатель Донецкий национальный технический университет. – № 2023110980; заявл. 20.04.2023; опубл. 26.10.2023, Бюл. № 31. – 13 с.

Ключевые слова: VPN, протокол, атака, шифрование, аутентификация, PPTP, L2TP, IPSec, SSL.

Keywords: VPN, protocols, attack, encryption, authentication, PPTP, L2TP, IPSec, SSL.