Пояснительная записка (1209803), страница 3

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 3)

Обращение к экземплярам класса происходит по принципу:

[\\computerName\nameSpace][:className][.keyProperty1=value1] где:

• computerName – имя компьютера на котором исполняется приложение;

• nameSpace – пространство имен;

• className – имя выбранного класса;

• keyProperty1=value1 – свойство объекта.

Для получения объектов и обращения к ним, в WMI применяется SQL подобный язык – WQL (Windows Management Instrumentation Query Language).

Он представляет из себя инструмент для выборки данных по определённым параметрам. Изменение значений через данные запросы не предусмотрено, так, как оно реализовано через сам механизм WMI.

Данный язык поддерживает следующие операторы:

• оператор SELECT – выбор полей;

• оператор FROM – объект к которому обращен запрос;

• оператор WHERE – набор параметров, по которым необходимо сделать фильтрацию и выборку.

Далее приведены примеры запросов:

Запрос списка подключенных flash – накопителей:

SELECT * FROM Win32_DiskDrive WHERE InterfaceType='USB';

Запрос информации о конфигурации сетевых адаптеров

SELECT * FROM Win32_NetworkAdapterConfiguration;

Данный инструмент позволяет реализовать функции, которые в дальнейшем будут затронуты при реализации взаимодействия с flash - накопителями.

2.4 Алгоритм шифрования файлов и данных

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

Шифрование методом замены, заключается в замене исходных символов на символы таблицы шифрозамены, сгенерированной на основе определенного алгоритмом закона. К примеру алгоритм Цезаря предлагает сдвиг алфавита на три символа влево. Сдвинутые символы перемещаются в конец алфавита. Таким образом мы получим следующую таблицу шифрозамены приведенную на рисунке 2.12.

Рисунок 2.12 – Алгоритм Цезаря

Шифрование методом перестановки, предлагает расстановку номеров последовательности в таблице шифрозамены по случайному принципу, что приведено на рисунке 2.13.

Рисунок 2.13 – Таблица шифрозамены для типа перестановки

Так же существуют комбинированные шифры. В основе комбинированных шифров лежат «сети Фейстеля» которые разработал в 1971 году Хорст Фейстель. На рисунке 2.14 приведена схема ячейки сети Фейстеля.

Рисунок 2.14 – Ячейка Фейстеля

На рисунке 2.15. приведена Сеть Фейстеля для шифрования сообщения и расшифровки. Как наглядно видно, они идентичны, но различаются последовательностью действий.

Рисунок 2.15 – Сеть Фейстеля

К комбинированным шифрам относятся такие алгоритмы как: DES и ГОСТ 28147-89.

Алгоритм DES (Data Encryption Standard, стандарт шифрования данных) является федеральным стандартом шифрования США. Был разработан для применения во всех несекретных правительственных каналов связи. На данный момент был заменен алгоритмом AES. Принцип данного алгоритма заключается в разбиении сообщения на блоки по 64 бита и последующем шифровании с помощью одного и того де ключа шифрования. Алгоритм шифрования приведен на рисунке 2.16.

Рисунок 2.16 – Схема шифрования блока DES

Алгоритм ГОСТ-28147-89, это советский и российский стандарт шифрования с симметричным ключом. Был введен в эксплуатацию в1990 году. В основу алгоритма положены методы замены, перестановки и гаммирования. Исходное сообщение разделяется на блоки по 64 бита, но если длина сообщения не кратна чем 64 бита, то сообщений дополняется недостающими битами до полного размера. Длина ключа в алгоритме ГОСТ-28147-89 равна 256 бит. На рисунке 2.17 приведена схема алгоритма шифрования ГОСТ-28147-89.

Рисунок 2.17 – Схема шифрования блока ГОСТ-28147-89

В таблице 2.1 проведено сравнение основных функций

Таблица 2.1 – Сравнение алгоритмов DES и ГОСТ-28147-89:

Так, как у алгоритма ГОСТ-28147-89 наибольшая длина ключа и больше проходов при шифровании чем у DES, для разработки проекта был выбран алгоритм ГОСТ-28147-89.

Поскольку разработка будет происходить на языке C#, то необходимо найти библиотеку криптографических средств содержащую реализацию алгоритма ГОСТ-28147-89 для последующей реализации проекта. Для языка C# есть две библиотеки с реализованным алгоритмом ГОСТ-28147-89:

• криптоПро .NET– Основана на решении КриптоПро CSP, которое прошло сертификацию ФСБ в 2016 году. Распространяется коммерчески.

• bouncyCastle – Библиотека разработанная сторонними разработчиками для языков C# и Java. Открытое распространение.

Библиотека BouncyCastle предоставляет довольно удобный API для выполнения криптографических преобразований. Лицензия данной библиотеки разрешает её свободное использование как в коммерческих, так и в некоммерческих проектах. Она содержит большое количество разных криптографических средств, что предоставляет большой выбор любого средства при необходимости.

Для реализации алгоритма ГОСТ-28147-89, была выбрана библиотека BouncyCastle, так, как она бесплатно предоставляет весь необходимый функционал и удобна для использования.

3 Проектирование приложения

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

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

В процессе проектирования были разработаны модели диаграмм использования, классов, последовательности, базы данных, компонентов и развёртывания.

3.1 Диаграммы вариантов использования

Диаграмма вариантов использования позволяет спроектировать все возможные функции, вызываемые пользователем из приложения.

На рисунке 3.1 представлена контекстная диаграмма вариантов использования.

Рисунок 3.1 – Контекстная диаграмма вариантов использования

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

Рисунок 3.2 – Диаграмма вариантов использования – Авторизация в приложении

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

На рисунке 3.3 представлена диаграмма просмотра событий приложения

Рисунок 3.3 – Диаграмма вариантов использования – События приложения

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

Рисунок 3.4 – Диаграмма вариантов использования – Шифрования носителя

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

Рисунок 3.5 – Диаграмма вариантов использования – Расшифровка носителя

3.2 Диаграмма классов

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

При разработке приложения было решено выделить всю логику клиентских приложений в отдельную библиотеку «DataEntity», что позволило минимизировать жесткую связь самих приложений с классами библиотеки. Сама библиотека была разделена на пространства имен. Пространство имен AppLogic представляет весь набор логики приложений. Пространство имен Models содержит модели и контекст данных, построенные по подходу Code First для использования технологии Entity Framework. Пространство имен UI содержит формы. Большинство форм не имеет логики, а ссылается на класс из AppLogic с логикой, предназначенной для данной формы. Пространство имен UI.Controls содержит основной визуальны интерфейс, который будет использован в клиентских приложениях.

Для предварительного проектирования составлена диаграмма классов анализа, изображенная на рисунке 3.6.

Рисунок 3.6 – Диаграмма классов анализа

3.3 Диаграмма последовательности

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

Одним из основных механизмов приложения является механизм авторизации. На Рисунке 3.7 представлена последовательность вызова методов для авторизации пользователя.

Рисунок 3.7 – Авторизация пользователя

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

Рисунок 3.8 – Создание суперпользователя

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

Характеристики

Список файлов ВКР