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

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

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

Отметим, что вероятность того что хеш-сумма произвольно взятого файла будет совпадать с случайным значением байта равна (1 / 2 ^ (8n)), где n – количество байт. Для n=1 эта величина равна 1/256, для n=2 эта величина равна уже 1/65536.

Очевидно, что чем меньше эта вероятность, тем больше файлов необходимо поместить в базу данных для возможности передачи случайных данных произвольной длины.

С другой стороны, чем больше рассматриваемая выше вероятность, тем больше скорость передачи данных, однако существенным недостатком является то, что скорость увеличивается линейно, тогда как потребность количестве файлов экспоненциально [5].

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

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

2.3 Практическое применение метода

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

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

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

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

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

В данной работе в качестве канала передачи сообщений используется сайт Радикал-Фото, предназначенный для хранения изображений.

3 Проектирование системы

Проектирование является неотъемлемой частью процесса разработки любого крупного программного обеспечения. Существует два основных подхода к проектированию – структурный и объектно-ориентированный. Их основное отличие заключается в принципах декомпозиции и структурной организации элементов (компонентов, модулей) системы. Согласно этим принципам система представляет собой структуру, состоящую из четко выраженных модулей, связанных между собой определенными отношениями. При использовании структурного подхода (первый вид декомпозиции) выполняется функциональная (процедурная, алгоритмическая) декомпозиция системы, т. е. она представляется в виде иерархии (дерева) взаимосвязанных функций. На высшем уровне система представляется единым целым с наивысшей степенью абстракции и по мере детализации (добавления уровней) разбивается на функциональные компоненты с более конкретным содержанием. Второй вид декомпозиции – объектно-ориентированный. В рамках этого подхода система разбивается на набор объектов, соответствующих объектам реального мира, взаимодействующих между собой путем посылки сообщений.

В дальнейшем проектирование разрабатываемого программного обеспечения будет производиться с помощью объектно-ориентированного подхода, с использованием языка UML. Унифицированный язык моделирования (UML) в настоящий момент является стандартом де-факто при описании (документирования) результатов проектирования и разработки объектно-ориентированных систем.

3.1 Функциональная модель системы

Одним из основных видов диаграмм, применяемых для функционального описания систем, являются диаграммы вариантов использования. Их разработка необходима для:

• определения общих границы и контекста моделируемой предметной области;

• формулирования общих требований к функциональному поведению проектируемой системы;

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

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

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

В ходе анализа проектируемой системы были выделены следующие актеры:

• отправитель;

• получатель.

Далее, под пользователем понимается отправитель или получатель, в зависимости от варианта использования.

Варианты использования, определенные при формировании контекстной диаграммы:

• создание хеш-сообщения;

• чтение хеш-сообщения;

• расчет значений хеш-функций для файла;

• добавление источника файлов.

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

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

Для более детального понимания конкретных вариантов использования используются диаграммы декомпозиции. На рисунке 3.2 представлена диаграмма декомпозиции для варианта использования "Создание хеш-сообщения".

При создании стеганографического сообщения происходит выполнение следующих действий:

• ввод данных пользователем;

• кодирование данных при необходимости;

• подбор файлов с подходящими хеш-суммами.

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

Рисунок 3.2 – Диаграмма декомпозиции варианта
использования "Создание хеш-сообщения"

Следующей диаграммой является диаграмма декомпозиции варианта использования «Чтение хеш-сообщения", представленная на рисунке 3.3

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

Рисунок 3.3 – Диаграмма декомпозиции для варианта использования
"Чтение хеш-сообщения"

3.2 Информационная модель системы

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

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

Построение этой модели необходимо:

• для выявления внутренней архитектуры (определения подсистем и основных классов);

• для поиска альтернативных вариантов реализации системы (подсистем) и выбора основного;

• для уточнения всех требований (функциональных и нефункциональных).

3.2.1 Диаграмма классов анализа

Класс анализа – это укрупненная абстракция, которая на концептуальном уровне (без точного определения атрибутов и операций) описывает некоторый фрагмент системы.

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

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

На рисунке 3.4 представлена диаграмма классов анализа проектируемой системы. В ее составе присутствуют несколько видов классов:

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

• управляющие классы реализуют непосредственно логику приложения, классы более высокого уровня абстракции, такие как "Создать сообщение" и "Чтение сообщения" используют классы более низкого уровня, такие как "Криптография", отвечающего за вычисление хеш-функций файлов, или "Соединение с БД", выполняющего роль посредника в обмене данными между приложением и базой данных;

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

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

3.2.2 Проектирование базы данных

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

Правильно спроектированная база данных позволяет эффективно выполнять запросы по чтению и изменению данных.

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

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

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

Таблица "Сообщения" (таблица 3.1) предназначена для хранения данных о сообщениях, создаваемых пользователями. Логическое поле is_send указывает, было ли сообщение отправлено. Информация о составе сообщения хранится в других таблицах, записи которых имеют ссылку на идентификатор конкретного сообщения.

Таблица 3.1 –Таблица базы данных Messages (Сообщения)

Таблица "Значения тегов" (таблица 3.2) представляет собой набор записей о тегах, значения которых необходимы для изменения хеш-сумм изображений.

Таблица 3.2 –Таблица базы данных Tag_values (Значения тегов)

Таблица "Коллекции тегов" (таблица 3.3) необходима для группировки записей из таблицы "Значения тегов". В составе коллекции могут находиться несколько тегов разного типа.

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

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