- •Общая часть
- •1.1 Проблема защиты информации
- •1.1.2 Комплексный подход к обеспечению информационной безопасности
- •1.2 Понятие информации
- •1.2.1 Классификация информации
- •1.2.2 В теории управления
- •1.2.3 Информация в материальном мире
- •1.2.4 Информация в человеческом обществе
- •1.2.5 Хранение информации
- •1.2.6 Передача информации
- •1.2.7 Обработка информации
- •1.2.8 Информация в науке
- •1.2.9 Теория информации
- •1.2.10 Теория алгоритмов
- •1.2.11 Дезинформация
- •1.2.12 Ошибка
- •1.3 Мобильные устройства
- •1.3.1 Смартфоны и сотовые телефоны
- •1.3.2 Смартфоны и коммуникаторы
- •1.3.3 История смартфонов и коммуникаторов
- •1.3.4 Смартфоны и вредоносные программы
- •1.3.5 Операционные системы
- •1.3.6 Операционная система iOs
- •1.4 Xcode
- •1.5 Криптография
- •1.5.1 Терминология
- •1.5.2 История
- •1.5.3 Современная криптография
- •1.5.4 Ssl протокол
- •1.5.4.1 История и развитие
- •1.5.4.2 Аутентификация и обмен ключами
- •1.5.4.3 Протокол записи
- •1.5.4.4 Безопасность
- •1.5.4.5 Алгоритмы, использующиеся в ssl
- •1.5.5.1 Алгоритм
- •1.5.6 Hmac код
- •1.5.6.1 Криптографический ключ
- •1.5.6.2 Вопросы использования
- •1.5.6.3 Безопасность
- •1.5.7 Advanced Encryption Standard (aes)
- •1.5.7.1 Шифрование
- •1.5.7.2 Алгоритм обработки ключа
- •1.5.8 Uuid стандарт
- •2 Специальная часть
- •2.1 Общая постановка задачи
- •2.1.1 Описание входных и выходных данных проекта
- •2.1.2 Схема работы комплекса
- •2.1.3 Описание комплекса программ
- •2.1.4 Описание набора данных
- •2.2 Описание проблемной программы №1
- •2.2.1 Блок-схема алгоритма проблемной программы №1
- •2.2.2 Таблица идентификаторов проблемной программы №1
- •2.3 Описание проблемной программы №2
- •2.3.1 Блок-схема алгоритма проблемной программы №2
- •2.3.2 Таблица идентификаторов проблемной программы
- •2.4 Организация производства
- •2.4.1 Руководство оператора
- •2.4.1.1 Назначение приложения
- •2.4.1.2 Комплекс технических средств
- •2.4.1.3 Выполнение проекта
- •2.4.1.4 Сообщения оператору
- •2.4.2 Формы входных и выходных документов
- •3 Экономическая часть
- •3.1 Расчет условного числа операторов.
- •3.2 Расчет трудоемкости создания программного продукта
- •3.3 Расчет заработной платы программиста
- •3.4 Затраты на расходные материалы
- •3.5 Общехозяйственные расходы
- •3.6. Затраты на электроэнергию за год
- •3.7 Смета затрат на разработку программного продукта
- •4. Охрана труда
- •4.1 Гарантии прав работников на безопасность и охрану труда
- •4.2 Права и обязанности работника и работодателя в области безопасности и охраны труда
- •4.3 Санитарно-эпидемиологические требования к размещению и эксплуатации пк, ПлПк, ноутбуков и вт
- •4.4 Производственное освещение
- •4.5 Производственная вентиляция
- •4.6 Методика испытания изолятора
- •4.6.1 Измерение сопротивления изоляции.
- •4.6.2 Производится испытание повышенным напряжением промышленной частоты (50 Гц).
- •4.7 Контроль под рабочим напряжением.
1.5.4.1 История и развитие
Протокол SSL был изначально разработан компанией Netscape Communications. Версия 1.0 никогда не была обнародована. Версии 2.0 была выпущена в феврале 1995 года, но "содержала много недостатков по безопасности, которые привели к разработке SSL версии 3.0" SSL версии 3.0, выпущенная в 1996 году, послужила основой для создания протокола TLS 1.0, стандарт протокола Internet Engineering Task Force (IETF), который впервые был определен в RFC 2246 в январе 1999 года. Visa, Master Card, American Express и многие другие организации, работающие с интернет-деньгами, имеют лицензию на использование протокола SSL для коммерческих целей в сети Интернет. SSL работает модульным способом. Тем самым SSL расширяемо в соответствии с проектом о поддержке прямой и обратной совместимости и переговорам между соединениями в одноранговой сети.
1.5.4.2 Аутентификация и обмен ключами
SSL поддерживает 3 типа аутентификации:
- аутентификация обеих сторон (клиент — сервер);
- аутентификация сервера с неаутентифицированным клиентом;
- полная анонимность.
Если сервер аутентифицирован, то его сообщение сертификации должно обеспечить верную сертификационную цепочку, ведущую к приемлемому центру сертификации. Проще говоря, аутентифицированный клиент должен предоставить допустимый сертификат серверу. Каждая сторона отвечает за проверку того, что сертификат другой стороны еще не истек и не был отменен. Всякий раз, когда сервер аутентифицируется, канал устойчив (безопасен) к попытке перехвата данных между веб-сервером и браузером, но полностью анонимная сессия по своей сути уязвима к такой атаке. Анонимный сервер не может аутентифицировать клиента. Главная цель процесса обмена ключами — это создание секрета клиента (pre_master_secret), известного только клиенту и серверу. Секрет (pre_master_secret) используется для создания общего секрета (master_secret). Общий секрет необходим для того чтобы создать сообщение для проверки сертификата, ключей шифрования, секрета MAC (message authentication code) и сообщения «finished». При посылке верного сообщения «finished», тем самым стороны докажут что они знают верный секрет (pre_master_secret).
Анонимный обмен ключами. Полностью анонимная сессия может быть установлена при использовании алгоритма RSA или Диффи-Хеллмана для создания ключей обмена. В случае использования RSA клиент шифрует секрет (pre_master_secret) с помощью открытого ключа несертифицированного сервера. Открытый ключ клиент узнает из сообщения обмена ключами от сервера. Результат посылается в сообщении обмена ключами от клиента. Поскольку перехватчик не знает закрытого ключа сервера, то ему будет невозможно расшифровать секрет (pre_master_secret). При использовании алгоритма Диффи-Хеллмана открытые параметры сервера содержатся в сообщении обмена ключами от сервера, и клиенту посылают в сообщении обмена ключами. Перехватчик, который не знает приватных значений, не сможет найти секрет (pre_master_secret).
Аутентификация и обмен ключами при использовании RSA. В этом случае обмен ключами и аутентификация сервера может быть скомбинирована. Открытый ключ также может содержаться в сертификате сервера или может быть использован временный ключ RSA, который посылается в сообщении обмена ключами от сервера. Когда используется временный ключ RSA, сообщения обмена подписываются server’s RSA или сертификат DSS. Сигнатура включает текущее значение сообщения Client_Hello.random, таким образом старые сигнатуры и старые временные ключи не могут повторяться. Сервер может использовать временный ключ RSA только однажды для создания сессии. После проверки сертификата сервера клиент шифрует секрет (pre_master_secret) при помощи открытого ключа сервера. После успешного декодирования секрета (pre_master_secret) создается сообщение «finished», тем самым сервер демонстрирует, что он знает частный ключ соответствующий сертификату сервера.
Когда RSA используется для обмена ключами, для аутентификации клиента используется сообщение проверки сертификата клиента. Клиент подписывается значением, вычисленным из master_secret и всех предшествующих сообщений протокола рукопожатия. Эти сообщения рукопожатия включают сертификат сервера, который ставит в соответствие сигнатуре сервера, сообщение Server_Hello.random, которому ставит в соответствие сигнатуру текущему сообщению рукопожатия.
Аутентификация и обмен ключами при использовании Diffie-Hellman. В этом случае сервер может также поддерживать содержащий конкретные параметры алгоритм Диффи-Хеллмана или может использовать сообщения обмена ключами от сервера для посылки набора временных параметров подписанных сертификатами DSS или RSA. Временные параметры хэшируются с сообщением hello.random перед подписанием, для того чтобы злоумышленник не смог совершить повтор старых параметров. В любом случае клиент может проверить сертификат или сигнатуру, для уверенности, что параметры принадлежат серверу.
Если клиент имеет сертификат, содержащий параметры алгоритма Diffie-Hellman, то сертификат также содержит информацию требуемую для того чтобы завершить обмен ключами. Заметим, что в этом случае клиент и сервер должны будут сгенерировать те же Diffie-Hellman результаты (pre_master_secret), каждый раз когда они устанавливают соединение.