Разработка протокола обмена сообщениями для системы удаленного управления программным обеспечением сервера

Постановка проблемы

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

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

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

Цель

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

Анализ существующих разработок

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

Примером является проект с открытым исходным кодом ZeroMQ, который выполняет буферизацию данных, обслуживание очередей, установление и восстановление соединения. Проект написан на языке программирования С++, содержит API для многих языков программирования и обладает высокой производительностью [2].

Проекты Apache Kafka [3], Apache ActiveMQ [4] и RabbitMQ [5] обладают похожей функциональностью, однако рассчитаны на использование в крупных распределенных вычислительных системах.

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

Определение требований к протоколу

Рассматриваемый протокол передачи сообщений был спроектирован в рамках разработки системы удаленного управления программным обеспечением сервера. В качестве программно-аппаратной платформы для исполнения системы рассматривались переносимые устройства под управлением операционной системы Android и персональные вычислительные системы под управлением операционных систем Microsoft Windows, GNU/Linux и macOS.

Особенности разрабатываемого приложения, а также платформы исполнения накладывают ограничения на реализацию системы, в частности, на реализацию протокола обмена сообщениями:

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

В качестве протокола транспортного уровня был выбран TCP. Это связано с большей надежностью передачи по сравнению с UDP, а также с возможностью установки и завершения соединения. В качестве языка программирования был выбран Java, поскольку его среда выполнения доступна на всех рассматриваемых платформах.

Особенности реализации модуля взаимодействия с удаленным процессом

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

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

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

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

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

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

• получение сообщения от удаленного процесса (при обработке сообщения производится поиск программного модуля — метода программной системы, который предназначен для обработки сообщений конкретного класса);
• отправка сообщения удаленной системе (сериализует сообщение и отправляет его удаленной стороне через TCP-сокет);
• запрос на закрытие соединения (обрабатывает все входящие сообщения в очереди и закрывает TCP-соединение);
• изменение модуля предварительной обработки сообщения перед отправкой или обработкой;
• восстановление приостановленного процесса чтения.

Типы событий 4 и 5 используются при реализации создания защищенного соединения.

Процесс установления соединения, получения и обработки сообщения приведена на рисунке 1.

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

Методы обработки сообщений принимают в качестве аргумента объект сообщения и реализуют логику работы программы.

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

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

Классы спроектированной объектно-ориентированной модели модуля отправки и получения сообщений показана на рисунке показана на рисунке 2 [7].

Реализация безопасной передачи информации

Для обеспечения защищенности программной системы, использующей разработанный протокол, необходимо добавить возможность шифрования сообщений. Для этого был выбран симметричный протокол AES с длиной ключа 128 бит [8]. Для того, чтобы оба участника взаимодействия получили один и тот же ключ алгоритма AES используется ассиметричный алгоритм RSA с ключом длиной 1024 бита [9].

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

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

На следующем этапе клиент отправляет серверу пароль, идентификатор клиента — 64-битное число, известное клиенту (на платформе Android ему соответствует значение системного параметра ANDROID_ID), а также токен, полученный от сервера при предыдущем подключении. Если клиент подключается к серверу впервые и токен ему не был выделен, то соответствующее поле сообщения не передается.

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

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

Если сервер отправил сообщение об успешной инициализации соединения, обе стороны могут приступить к вычислению ключа алгоритма AES. Для этого формируется байтовый буфер, в который записывается идентификатор сессии, идентификатор клиента и токен. Сформированный буфер передается на вход хэш-функции SHA-256 [10]. Полученное 256-битное значение хэш-функции разбивается на два фрагмента по 128 бит. Первая половина является ключом алгоритма AES, вторая — вектором инициализации (IV) алгоритма. Все дальнейшие сообщения шифруются с помощью алгоритма AES.

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

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

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

Этапы установления защищенного соединения приведены на рисунке 3.

Выводы

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

Список источников

1. ГОСТ Р ИСО/МЭК 25010—2015 Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программных продуктов — Москва: Стандартинформ, 2015. — 36 с.
2. ØMQ - The Guide [Электронный ресурс]. — http://zguide.zeromq.org/page:all
3. Apache Kafka [Электронный ресурс]. https://kafka.apache.org/
4. Apache ActiveMQ — Index [Электронный ресурс]. http://activemq.apache.org/
5. RabitMQ — Messaging that just works [Электронный ресурс]. https://www.rabbitmq.com/
6. Полетаев В. А Использование средств рефлексии языка Java при реализации протоколов прикладного уровня [Текст]: / В. А. Полетаев, А. С. Кузьмичева // Информатика, управляющие системы, математическое и компьютерное моделирование в рамках III форума Инновационные перспективы Донбасса (ИУСМКМ — 2017): VIII Международная научно-техническая конференция. / Донецкий национальный технический университет — Донецк, 2017 — С. 120-124.
7. Vasian Cepa Representing Explicit Attributes in UML / Vasian Cepa, Sven Kloppenburg // 7th International Workshop on Aspect-Oriented Modeling: материалы VII международной конференции, 2 октября 2005г., г. Montego Bay, Jamaica. —, 2005.
8. Specification for the Advanced Encryption Standard (AES) [Электронный ресурс]. — https://csrc.nist.gov/csrc/media/publications/fips/197/final/documents/fips-197.pdf
9. K. Moriarty, Ed., B. Kaliski, J. Jonsson, A. Rusch RFC 8017. PKCS #1: RSA Cryptography Specifications Version 2.2 [Электрнооый ресурс]. — https://tools.ietf.org/html/rfc8017
10. D. Eastlake 3rd, T. Hansen RFC 6234. US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF) [Электронный ресурс]. — https://tools.ietf.org/html/rfc6234