АСПЕКТЫ ПРОВЕРКИ ПОДЛИНОСТИ СООБЩЕНИЙ КЛИЕНТОМ WEB-ПРИЛОЖЕНИЯ С ИСПОЛЬЗОВАНИЕМ ТЕХНОЛОГИИ COMET  

Тюлькин Михаил Валерьевич

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

E-mail:

Капгер Игорь Владимирович

начальник отдела информационной безопасности, Пермская печатная фабрика - филиал ФГУП "Гознак", г. Пермь

E-mail:

Кротов Лев Николаевич

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

E-mail:

Кротова Елена Львовна

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

E-mail:

ASPECTS OF AUTHENTICATION OF MESSAGE OF CLIENT WEB-APPLICATIONS USING COMET

Mikhail Tyulkin

Graduate Student, State National Research Politechnical University of Perm, Perm

Igor Kapger

Head of Information Security, The Perm printing factory - branch of GOZNAK, Perm

Lev Krotov

Ph.D. in Physics and Mathematics, Associate Professor of State National Research Politechnical University of Perm, Perm

Elena Krotova

Candidate Physics and Mathematics, Associate Professor of State National Research Politechnical University of Perm, Perm

  АННОТАЦИЯ

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

ABSTRACT

This article examines aspects of the message authentication in web-application received by the client from the server-side application that uses comet-server as the transport of such messages. An attempt was made to develop a tool for checking messages received from the comet-server based cryptographic hash functions in a non-trivial environment as the user's browser via a scripting language JavaScript.

Ключевые слова: модель Comet; web-приложение; Comet-сервер; проверка подлинности; хеш-функция; JavaScript.

Keywords: Comet model; web-application; Comet-server; authentication; hash function; JavaScript.  

В web-приложениях (далее приложениях) с моделью взаимодействия Comet между браузером пользователя (далее клиентом) и серверной частью приложения (далее сервером) с использованием Comet-сервера информация от сервера может пересылаться клиенту по двум основным каналам [4, c. 3]: а)по HTTP протоколу напрямую, как ответ на посланный клиентом HTTP запрос [5]; б)по прочим протоколам прикладного уровня, таким как WebSocket [8], или сетевого уровня TCP или UDP через Comet-сервер, с которым клиент предварительно устанавливает соединение на начальном этапе работы с приложением. Второй путь чаще используется для следующих двух целей [4, c. 2]: а)передача спонтанно возникающей информации, момент появления которой на сервере клиент не может отследить, чтобы послать запрос на сервер; б)разгрузка первого канала, чтобы освободить клиента от постоянного опроса сервера на предмет наличия новой информации и тем самым снизить нагрузку на сервер. Comet-сервер представляет собой высоконагружаемое исполняемое приложение, изначально рассчитанное на передачу траффика с большой скоростью большой аудитории клиентов, которые в текущий момент времени работают с web-приложением. Если аудитория пользователей очень большая Comet-сервер может выноситься на отдельную серверную ЭВМ, подключенную к широкополосным каналам связи. Использование Comet-сервера позволяет разработчику создавать web-приложения, скорость работы которых приближается к режиму реального времени, причем одновременно с большой аудиторией клиентов. Примерами таких приложений могут служить финансовые биржи, социальные сети, онлайн игры и др. Однако нередко возникает ситуация, когда аудитория клиентов создает нагрузку, с которой сервер разработчика уже не справляется, а разработчик не может внедрить собственный Comet-сервер по ряду причин, в том числе и финансовых. В такой ситуации для потребностей данного разработчика привлекается стороннее лицо, которое может предоставить услуги своего Comet-сервера. Определим первого как потребителя услуг, а второго как поставщика услуг. Арендуя Comet-сервер у третьей стороны и, тем самым, возлагая на поставщика роль посредника в передаче информации через Comet-сервер, потребитель не может гарантировать своим клиентам достоверность пересылаемых сообщений по данному каналу, потому что не может контролировать действия поставщика. Для разрешения такой проблемы потребителю необходимо ввести способ противодействия модификации данных, но, поскольку потребитель не может влиять на действия поставщика, то ему потребуется метод, позволяющий определить модификацию пересылаемого сообщения. В криптографии для такой цели служат криптографические однонаправленные хеш-функции с примесью каких-либо ключевых данных к сообщению [2, c. 37, 52], позволяющие создать цифровой отпечаток сообщения с высокой степенью уникальности. Алгоритм подписи сообщений применительно к данной проблеме можно поделить на следующие шаги: а)сервер генерирует псевдослучайную достаточно длинную оказию, которая станет ключевыми данными; б)при установке связи с клиентом по HTTP сервер напрямую передает клиенту данную оказию ; в)при отправке сообщения через Comet-сервер поставщика сервер вычисляет цифровой отпечаток  сообщения  с примесью данной оказии , заданной хеш-функцией , ; г)затем сервер передает клиенту  и  через Comet-сервер; д)получив эти данные, клиент заново вычисляет цифровой отпечаток сообщения . Если полученный отпечаток  и вычисленный отпечаток  совпадают, значит, сообщение  было доставлено без модификации со стороны поставщика во время передачи. Чтобы поставщику иметь возможность легально менять содержимое сообщений, ему необходимо вычислять корректную цифровую подпись для каждого сообщения, что очень затруднительно сделать без ключевой оказии , которая не передается по линиям связи доступным ему. Дополнительно, для защиты от нахождения оказии методом полного перебора, сервер потребителя может периодически генерировать новую оказию и рассылать её клиентам по HTTP протоколу. Наиболее распространёнными хеш-функциями, набор реализаций которых имеется почти в любой ОС (в частности ОС семейства UNIX, которая распространена как серверная ОС), являются MD5, SHA-1, SHA-256, SHA-512 и RIPEMD-160 [3, с. 107]. Если серверная часть приложения имеет доступ к данным реализациям в ОС, поскольку среда её выполнения изначально подразумевает такой доступ или инструменты его реализующие, то клиентская часть приложения, которая выполняется в браузере конечного пользователя, не имеет такого доступа, так как любой браузер изначально не предоставляет таких возможностей, поскольку как приложение проектируется под совершенно иные задачи. Однако браузер предоставляет расширение своих возможностей посредством выполнения кода клиента, который может быть написан на скриптовом языке программирования JavaScript, либо посредством flash-элементов или java-апплетов, выполнение которых производится в среде, интегрируемой с браузером. Чтобы решить в какой среде производить обработку поступающих сообщений, необходимо рассмотреть пути поступления сообщения к клиенту, т. е. в браузер пользователя, которых существует всего три: а)в среду выполнения JavaScript через протокол WebSocket средствами браузера [7]; б)в flash-элемент посредством сетевого сокета, который создает данный элемент, а из него сообщение может быть передано в JavaScript; в)аналогично в java-апплет посредством сетевого сокета с возможной дальнейшей передачей в JavaScript. Исходя из рассмотренных выше данных, можно заключить, что проверка цифровой подписи в JavaScript будет универсальна и независима ни от способов доставки сообщения от Comet-сервера клиенту, ни от необходимости наличия дополнительного программного обеспечения у конечного пользователя. После выбора среды, в которой осуществляется проверка, необходимо выбрать хеш-функцию из представленного набора, которая будет использоваться в данной проверке и будет наиболее подходящей для данной задачи. Основными требованиями, предъявляемыми к такой хеш-функции, являются стойкость к коллизиям и высокая скорость выполнения. Поскольку все обозначенные функции создавались как стойкие к коллизиям с расчетом на создание уникальных цифровых отпечатков, то основным критерием выбора становится скорость их выполнения в такой нетривиальной среде для криптографических задач как JavaScript. Для оценки скорости выполнения обозначенных хеш-функций была создана экспериментальная html-страница с внедренным JavaScript кодом данных функций и одной тысячей псевдослучайно сгенерированных сообщений псевдослучайной длины от 1 до 65535 байт для имитационного моделирования непредсказуемой передачи сообщений через Comet-сервер, информация большего объема обычно передается клиенту по HTTP протоколу. Суммарный объем сообщений составил 31930822 байта. Данная страница и скрипт, генерирующий её, доступны для свободного ознакомления [1]. JavaScript код на странице последовательно каждой хеш-функцией вычисляет цифровые отпечатки всех сообщений на странице с замером затраченного времени. Код данных хеш-функций был взят из готовой реализации для JavaScript разработанной специалистом в области защиты информации Полом Джонстоном [6]. Скорость расчета цифровых отпечатков каждой функций проверялась на ЭВМ со следующей конфигурацией: а)  процессор – Intel(R) Core(TM)2 Quad CPU Q6700 @ 2.66 МГц; б)  оперативная память – DDR3-1333 (667 МГц) 1 Гб Hynix HMT112U6TFR8C-H9 х 3; в)  ОС – Windows 7 32-битная. И в следующих браузерах наиболее свежей версии на момент написания статьи: а)  Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.10.229 Version/11.62 б)  Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20100101 Firefox/11.0 в)  Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.151 Safari/535.19 Браузер Internet Explorer не участвовал в эксперименте, поскольку его JavaScript ядро очень примитивно и для него требуется реализация данных функций на VBScript языке. Полученные результаты представлены в таблице 1. Таблица 1 Затраченное время на расчет цифрового отпечатка данных Браузер Время, затраченное хеш-функцией, мс MD5 SHA-1 SHA-256 SHA-512 RIPEMD-160 Opera 6451 8566 12487 25492 22985 FireFox 3838 4742 4748 5639 8450 Chrome 12650 15632 22422 38273 25420 Поделив суммарный объем обработанных данных на каждое значение в таблице 1, получим количество обработанных байт в 1 мс. для каждого алгоритма. Результат данной операции представлен в таблице 2. Таблица 2 Скорость обработки данных в зависимости от браузера Браузер Количество байт, обрабатываемых за 1 мс MD5 SHA-1 SHA-256 SHA-512 RIPEMD-160 Opera 4949,748 3727,623 2557,125 1252,582 1389,203 FireFox 8319,651 6733,619 6725,110 5662,497 3778,796 Chrome 2524,176 2042,657 1424,084 834,2911 1256,130   Найдя среднее арифметическое по столбцам, можно получить скорость алгоритма независимо от браузера, итоговый результат отражен в таблице 3. Таблица 3 Скорость обработки данных независимо от браузера Среднее количество байт, обрабатываемых за 1 мс MD5 SHA-1 SHA-256 SHA-512 RIPEMD-160 5264,525 4167,967 3568,773 2583,123 2141,376   Как заметно из таблицы 3, алгоритм MD5 оказался наиболее быстрым в среде выполнения JavaScript, что определяет его выбор его использования для создания цифровых отпечатков сообщений при их передаче через Comet-сервер третьей стороны.  

Список литературы:

1.Материалы для эксперимента, описываемого в статье. Апрель 2012. URL: http://learn-about.me/test_js_speed.rar (дата обращения: 06.04.2012).

2.Шнайер Б. Прикладная криптография. Протоколы, алгоритмы, исходные тексты на языке Си - М.: Триумф, 2002. – 816 с. - ISBN 5-89392-055-4.

3.Фергюсон Н., Шнайер Б. Практическая криптография :Пер. с англ. – М.: Издательский дом “Вильямс”, 2005. – 424 с.: ил. – Парал. тит. англ. ISBN 5-8459-0733-0.

4.Crane D., McCarthy P. Comet and Reverse Ajax: The Next-Generation Ajax 2.0, 2008. – 142 с. - ISBN 978-1-59059-998-3.

5.Hypertext Transfer Protocol -- HTTP/1.1. Июнь 1999. URL: http://www.w3.org/Protocols/rfc2616/rfc2616.html (дата обращения: 06.04.2012).

6.Paj's Home: Cryptography: JavaScript MD5. Май 2011. URL: http://pajhome.org.uk/crypt/md5/ (дата обращения: 06.04.2012).

7.The WebSocket API. Декабрь 2011. URL: http://www.w3.org/TR/websockets/ (дата обращения: 06.04.2012).

8.The WebSocket Protocol. Декабрь 2011. URL: http://tools.ietf.org/html/rfc6455 (дата обращения: 06.04.2012).