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

Однако контейнеры этим не исчерпываются. Совместно с двумя разгильдяями очень талантливыми студентами (а именно с lancerx и с PavelBatusov) мы решили разработать простенький just4fun-проектик информационного сокрытия в электронных документах.

Ссылка на то, что получилось (не судите строго): pdf.stego.su
(примеры PDF можно взять здесь)

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

О чем все это?

Как-то раз за чашкой кофе, рассуждая о стеганографии, мы задались вопросом: "Можно ли в электронные текстовые документы вкраплять какую-нибудь дополнительную стороннюю информацию таким образом, чтобы визуально сами документы никак не изменились?". Так появился наш маленький «стеганографический кружок».

Оказывается можно.

Вот далеко не полный список.

1. OpenDocument Format (ODT) — он же ISO/IEC 26300-1:2015, он же, кстати, не много не мало государственный стандарт (sic!) ГОСТ Р ИСО/МЭК 26300-2010. Если говорить на пальцах, то протокол представляет собой zip-архив из xml'ек. Кто не верит может установить LibreOffice, создать произвольный документ «example.odt», переименовать его в «пример.zip» и убедиться что так оно и есть. Пространство для творчества с вкраплением посторонней информации — масса.
2. Office Open XML (OOXL, он же DOCX, он же ISO/IEC IS 29500:2008) — ответ Чемберлену от Microsoft. C точки зрения информационного сокрытия те же яйца, только в профиль. DOCX представляет собой тоже zip архив с xml'ками, только по другому организованные.
3. DjVu (от французского «дежавю») — очень интересный протокол для сокрытия. В DjVu используется алгоритм JB2, который ищет повторяющиеся символы и сохраняет их изображение только один раз. Соотвественно есть ряд идей:
   
   • Выбрать множество всех похожих символов и выбрать один с помощью хеш-стеганографии.
   • Выбирать два символа вместо одного. Первый символ считать передающим 0, а второй символ считать передающим 1. С помощью «чередования» можно передавать сокрытую информцию.
   • Скрывать данные внутри самой картинки, обозначающей символ в DjVU, с помощью LSB.
   
   
4. FictionBook (fb2) — это xml. Однако может содержать binary тег, внутри которого — картинка. Далее сокрытие в самой картинке. Можно так же попытаться вставлять пробелы и иные символы за пределами тегов или внутри самих тегов.

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

1. этот формат не редактируем — следовательно нет проблем при перезаписи (Ну… на самом деле тоже редактируем, но все же чаще PDF используют как «нередактируемый» формат)
2. этот формат достаточно просто устроен — об этом чуть ниже
3. этот формат достаточно популярен

Как это работает?

Наколеночную приблуду мы назвали SHP, что расшифровывается как Simple Hide to Pdf. Simple – потому что простое; Hide – потому что скрывает; и “to PDF” – потому что работает только с PDF документами.

Для ликбеза пару абзацев про протокол ISO 32000:2008, который и есть PDF.
Документ состоит из объектов (так называемые obj) в конце документа есть xref-таблица, которая перечисляет все необходимые объекты. Каждый объект имеет номер и ревизию… Да, именно так, pdf поддерживает различные ревизии! На самом деле PDF — это мини-система управления версиями! ;)) Вот только в жизни что-то не прижилось…

PDF-документ образуется объектами разных типов:

• логические переменные
• числа (целые и дробные)
• строки
• массивы
• словари
• потоки
• комментарии

Если говорить грубо, то структура PDF следующая:

• заголовок
• объекты (obj данные)
• xref-таблица
• трейлер (содержит информацию об объектах, с которых нужно начать чтение файлов)

Немного изучив PDF стандарт навскидку можно предложить следующие методы сокрытия.

1. Каждый объект чередовать определенным способом, тем самым меняя структуру документа. Мы с ребятами называли это «структурной стеганографией», так как вы меняете структуру документа, не меняя содержимое. Если у вас n объектов, то у вас в итоге возможно n! различных упорядочиваний, следовательно вы можете передать не более log₂(n!) бит данных. Идея интересная, но мы отложили её до лучших времен.
2. Можно поиграться с версиями самих файлов. В старые (не используемые) версии вносить сокрытую информацию. Одноко мы посмотрели 1000 различных pdf'ок и во всех не было ни одного файла с ревизией больше 0...
3. Можно найти различные способы внесения данных, предусмотренные протоколом, которые не отображаются для пользователя.

Самым простым способом пункта 3 являются… комментарии. Вот уж не знаю для кого это оставили; может быть это наследие PostScript, который «юридически» является языком программирования (как, LaTeX) и, соответственно, в его синтаксисе предусмотренны строки комментариев, как в любом ЯП. С точки зрения «рафинированной» стеганографии — это, конечно, не секьюрно. Однако предполагаемому противнику нужно знать о факте сокрытия…

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

Вкрапление данных:

1. пользователь подает на вход SHP системы сам PDF документ, сообщение для сокрытия и некий пароль;
2. SHP по паролю вычисляет стегоключ и криптоключ. Информация в сообщении сжимается и шифруется с помощью криптоключа;
   
3. с помощью стегоключа информация вкрапляется в pdf документ;
4. на выходе из SHP системы пользователь получает pdf документ с вкраплеными данными.

Извлечение данных:

1. пользователь подает на вход системы pdf и пароль;
2. система аналогичным образом по паролю вычисляет стегоключ и криптоключ;
3. система извлекает данные по стегоключу;
4. расшифровывает данные с помощью криптоключа и разжимает их;
5. выдает сообщение пользователю.

Вот, собственно, и все.

Если пользователь введет некорректный пароль, SHP некорректно вычислит стегоключ и криптоключ. Поэтому пользователь может быть уверен, что не зная пароля никто другой саму информацию из pdf не получит.

Тем, кто не заметил в начале долгочита, даю ещё раз ссылку на нашу наколенную web-платформочку: pdf.stego.su
(Как видите вместо стандартного черного цвета в Django мы выбрали влюбленных жаб. Да, мы просто гении дизайна!)

Для чего это нужно?

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

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

В одном из своих прошлых постов я рассказал о 15 практических целей стеганографии (и информационного сокрытия).
По сути стеганография в документах (и в частности в PDF документах) в той или иной мере может быть применима для всех задач.

Однако наиболее интересных всего 4.5 задачи.

0.5 Незаметная передача информации & Скрытое хранение информации.

Как уже писали — не секьюрно! Однако против киберблондинок точно сработает. Для более серьезной стеганографии требуется придумать хороший алгоритм стеганографического вкрапления как такового. Поэтому эту задачу мы засчитываем за 0.5, а не за 1.

К тому же использование электронных документов нельзя считать робастной стеганографией потому, что при преобразовании (например: pdf -> odt) информация теряется.

Единственное, где идея незаметной передачи может быть востребована, это в закрытых протоколах. Своего рода «security through obscurity», только в стеганографии.

1.5 Защита исключительного права

Все больше набирает оборот продажа электронных журналов; различной аналитики и прочих платных подписок. Возникает вопрос: можно ли как-то защитить продаваемый контент? Чтобы публикующим в сети персонажам неповадно было?..

Можно попробовать в рассылаемый документ вкраплять информацию о получателе. Например: e-mail и номер платежной карты, IP, логин при регистрации в интернет-магазине, мобильный телефон и т.д. Для секьюрности и соблюдения законодательства можно вкраплять это в виде хешей (+соль) или просто вкраплять какой-либо номер (ID'шник в системе),
таким образом этот номер что-то скажет только владельцу системы.

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

Разумеется возникает ряд вопросов.

1. Можно ли извлечь метку?
2. Можно ли подделать метку и «подставить» другого пользователя?

Если использовать SHP то эту задачу следовало бы так же засчитать за 0.5, а не за 1.0…

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

Суть «многофакторной стеганографии» в следующем: если хотя бы одна метка сохраниться мы можем взять персонажа за яйца, мы можем определить, кто именно опубликовал данный платный контент. В Японии это актуально.

2.5 Защита подлинности документа.

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

Однако, есть штатный механизм, который делает то же самое! (по крайней мере и в рамках протокола PDF)
Поэтому мы опоздали >__<
Но можно аналогичные рассуждения применить к другим форматам?

3.5 Децентрализированная СЭДО.

В принципе «неотчуждаемость» сокрытых данных можно использовать
для децентрализированных систем электронного документооборота (СЭДО).

Вот только нужно ли?
Понятно, что это очень удобно; peer-2-peer и вообще — модно!
Самый главный цимес — неотчуждаемость от документа.
В современных СЭДО подписанный документ подписан только если он внутри СЭДО.
Если вы его извлечете и передатите по почте сторонней организации у которой не стоит решение вашего СЭДО, то вы просто передадите файл.

Современный рынок СЭДО напоминают месседжеры. Если вы на Skype, а Вася на Telegram, то либо вам нужно установить Telegram, либо Васе Skype… А вот представте себе протокол вкрапления информации (или совокупность протоколов вкрапления для каждого протокола электронных документов).

Единый для всех! Общий!

Если бы этот протокол вкрапления и извлечения подписей был бы един, так же как едины SMTP и IMAP для всех почтовиков, это было бы гораздо удобнее.

Хотя я — не специалист по СЭДО. Если здесь есть спецы, то прошу уделить время и написать в комментах, что вы думаете по этому поводу.

Востребована ли данная идея?

4.5 Водяной знак в DLP-системах.

Представте, что у вас есть режимный или «полурежимный» объект (да, бывают и такие). У вас есть информация, которую вы бы не хотели пускать во вне, например внутренняя документация какого-либо продукта.Вы вкрапляете определенную метку (или метку из определенного множества). Если документ идет «во вне» системы, то DLP (Data Leak Prevention) проверяет наличие метки. Если метки нет – документ проходит; если есть – система поднимает alert.

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

К тому же от одного типа «утечки» это однозначно поможет – от непреднамеренной. Бывают случаи, когда нечаянно пересылаются такие документы, которые лучше бы не пересылать (надеюсь, это печальное свойство присуще только «полурежимным», а не режимным объектам...)

Подводим итоги

.

Мы убедились, что сокрытие данных в документах – это вполне реальная штука.
… Ну и узнали много нового, так как много где поковырялись...

Конечно, есть ряд вопросов.
Возможно ли сделать это сокрытие стеганографически стойким? Что будет, если пользователь переведет все из pdf, скажем, в jpeg?.. Удалится ли сокрытая информация? Насколько это критично? Решит ли эту проблему многофакторная стеганография?

Применим ли статистический подход для анализа качества системы? То есть если система защищает в 90% случаях, а в 10% не защищает, то разумно ли (как в криптографии) говорить, что система не защищает совсем? Или, может быть, есть бизнес-кейсы, когда и 90% будет достаточно для получения определенной пользы?..

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

Еще раз ссылка на портал: pdf.stego.su
(+ примеры PDF для опытов, кому лень искать)
(заранее приносим извенения за возможный хабраэффект)