СПОСОБ И СИСТЕМА ЗАЩИТЫ ПОДЛИННОСТИ ВИДЕО, ГЕНЕРИРУЕМЫХ МОДЕЛЬЮ МАШИННОГО ОБУЧЕНИЯ Российский патент 2025 года по МПК G06F21/16 G06T1/00 

ОБЛАСТЬ ТЕХНИКИ

[0001] Заявленное решение относится к области информационных технологий, а именно к средствам защиты цифровых данных для целей подтверждения их подлинности.

УРОВЕНЬ ТЕХНИКИ

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

[0003] Одна из необходимостей в применении такого рода механизма направлена на препятствовании присваивании авторства создаваемых ИИ видео. Другая проблема связана с защитой видео от сторонних дополнительных изменений или модификаций, искажающих первоначально сгенерированное ИИ видео, что впоследствии может использоваться как ложные сведения, порочащие создателей таких моделей в части возможности генерирования видео запрещенного или непристойного содержания. При этом изменению со стороны злоумышленника могут быть подвержены:

1. Целиком видеоинформация.

2. Отдельные последовательности кадров либо отдельные кадры.

3. Содержимое самих кадров либо содержимое групп кадров.

[0004] Одним из примеров защиты видео в уровне техники предлагается использовать своего рода цифровые подписи, встраиваемые в видео, которые являются невидимыми для человеческого глаза и могут быть получены только с помощью последующей расшифровки защищенных видео с помощью их алгоритмического извлечения (см. статью «Использование стеганографических и криптографических средств для защиты видеофайлов» // Б.С. Маркин, А.В. Чернышова, 2014, URL: http://ea.donntu.ru:8080/bitstream/123456789/26611/1/%D1%81%D1%82%D0%B0%D1%82%D1%8C%D1%8F%201.pdf). Согласно известному решению создание подписи выполняется в пространственной области путем незначительного изменения уровня интенсивности пикселей изображения. Известна диссертационная работа «Модель и метод защиты видеоинформации от угроз нарушения целостности с использованием стеганографии» // Р.Ю. Мартимов. Недостатком данных подходов является то, что внедряемая подпись не может однозначно идентифицироваться с данным видео - отсутствует некий хеш видео или его аналог. При определенных условиях данную подпись можно извлечь из одного видеофайла и перенести в другой.

[0005] Известен способ криптообработки любых цифровых данных, в том числе и имеющегося цифрового видео, средствами компьютерной техники, в результате которого, например, по ГОСТ Р 34.10-2012 [1] и ГОСТ Р 34.11-2012 [2] данные видео подписываются так называемой цифровой электронной подписью (ЭП).

[0006] Известен способ внедрения и передачи информации в видеоизображении в патенте RU 2608150 С2. Техническим результатом является обеспечение минимизации искажений видеоизображения, в которое осуществляется внедрение, при обеспечении стегостойкости системы передачи информации. Предложен способ скрытой передачи данных в видеоизображении по стандарту MPEG-2 (Н.262), основанный на изменении менее значащих бит кадра видеоизображения значениями двумерной нелинейной кодовой комбинации, несущей в себе скрытно передаваемую информацию. Формирование стеганографического канала начинают с обработки встраиваемых данных, включающей шифрование и модуляцию псевдослучайным сигналом, в качестве которого выбирают двумерные нелинейные сигналы Франка-Уолша и/или Франка-Крестенсона. Одновременно с формированием стегосигнала выбирают кадры для его встраивания, полагая пригодными все 1-кадры, а также В- и Р-кадры. Данные стегоканала встраивают только в те коэффициенты ДКП, которые расположены в окрестности правой диагонали матрицы коэффициентов ДКП, записываемых в JPEG-файл и дополненных системной информацией и универсальными таблицами Хаффмана путем сложения по модулю два битов коэффициентов ДКП.

[0007] Недостатком данного подхода является то, что осуществляемое внедрение информации не имеет возможности подтверждения авторства и что внедряемая подпись не может однозначно идентифицироваться с данным видео.

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

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

[0009] Техническим результатом является повышение эффективности защиты генерируемых ИИ видео для целей определения их подлинности.

[0010] Дополнительным техническим результатом является возможность определения неизменности видео на основании встраиваемой защитной информации.

[0011] В предпочтительном варианте осуществления изобретения заявлен способ защиты подлинности видео, генерируемых на основании текстового запроса моделью машинного обучения, содержащий этапы, на которых:

a) получают данные пользовательского ввода для генерирования видео;

b) генерируют видеофайл с помощью модели машинного обучения;

c) фиксируют по меньшей мере один тип данных пользовательского ввода, выбираемый из группы: время ввода, ID пользователя, или текстовый запрос;

d) извлекают из сгенерированного видеофайла ключевые I-кадры в формате JPG;

e) извлекают из полученных I-кадров блоки значений коэффициентов дискретного косинусного преобразования (ДКП) для по меньшей мере одной составляющей изображения, выбираемой из группы: яркостная (Y), цветная (Cb- и Cr-) составляющих изображения;

f) получают последовательность низкочастотных коэффицентов ДКП (DC-коэффициенты) по всем I-кадрам по всем блокам яркостной составляющей, и рассчитывают хэш-функцию от полученной последовательности DC-коэффициентов;

g) по заданному ключу определяют I-кадры, блоки коэффициентов ДКП и позиции коэффициентов ДКП внутри блоков, исключая в блоках DC-коэффициенты ДКП, используемые на этапе f);

h) формируют вложение для защиты сгенерированного видео, состоящее из последовательности, включающей: время ввода, ID пользователя, текстовый запрос, значение хеш-функции, полученной на этапе f);

i) выполняют формирование зашифрованной последовательности с помощью шифрования данных, полученных на этапе h), закрытым ключом;

j) осуществляют встраивание в коэффициенты ДКП кадров в формате JPG из I-кадров сгенерированного видео, определенные на этапе g), значений хеш-функции, полученной на этапе f), и зашифрованной последовательности, полученной на этапе i);

k) предоставляют защищенное видео пользователю.

[0012] В одном из частных примеров осуществления на этапе d) дополнительно извлекаются Р-кадры и/или В-кадры.

[0013] В одном из частных примеров осуществления на этапе d) выполняется извлечение блоков для встраивания информации по меньшей мере одной из Y-, Cb- и Cr-составляющих кадров сгенерированного видео.

[0014] В другом частном примере осуществления на этапе f) последовательность DC-коэффициентов состоит из коэффициентов ДКП одной из Y-, Cb- и Cr-составляющих кадров сгенерированного видео.

[0015] В другом частном примере осуществления на этапе f) хеш-функцию рассчитывают по меньшей мере по одному высокочастотному коэффициенту ДКП (АС-коэффициент) и/или DC-коэффициенту ДКП, по меньшей мере одной из Y-, Cb- и Cr-составляющих кадров сгенерированного видео.

[0016] В другом частном примере осуществления на этапе g) по заданному ключу определяют блоки коэффициентов ДКП и позиции коэффициентов ДКП внутри блоков, включающие в себя любые АС-коэффициенты и DC-коэффициенты ДКП, по меньшей мере одной из Y-, Cb- и Cr-составляющих кадров сгенерированного видео, исключая используемые на этапе е).

[0017] В другом частном примере осуществления на этапе с) дополнительно формируется сжатые изображения одного или нескольких кадров из сгенерированного видео.

[0018] В другом частном примере осуществления на основании сжатых изображений кадров формируется последовательность байт, которая добавляется к данным на этапе g) при формировании вложения.

[0019] В другом частном примере осуществления видео генерируется по стандарту Н.262 или Н.264.

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

[0021] Фиг. 1 иллюстрирует общий вид способа защиты видео.

[0022] Фиг. 2 иллюстрирует блок-схему заявленного способа.

[0023] Фиг. 3А иллюстрирует пример блоков с коэффициентами ДКП, соотнесенных с блоками пикселей некоторого кадра из видео.

[0024] Фиг. 3Б иллюстрирует позиции коэффициентов ДКП в блоке некоторого кадра из видео.

[0025] Фиг. 3В иллюстрирует пример значений коэффициентов ДКП на разных позициях в блоке некоторого кадра из видео.

[0026] Фиг. 4 иллюстрирует пример определения коэффициентов ДКП в некотором кадре из видео для встраивания защитной информации.

[0027] Фиг. 5 иллюстрирует пример изменения коэффициентов ДКП кадров видео после встраивания защитной информации.

[0028] Фиг. 6 иллюстрирует пример вложения и его частей в виде последовательности байт.

[0029] Фиг. 7 иллюстрирует вид вычислительного устройства.

ОСУЩЕСТВЛЕНИЕ ИЗОБРЕТЕНИЯ

[0030] На Фиг. 1 представлена общая схема заявленного решения, которое реализовано с помощью обработки поступающих пользовательских запросов (110), представляющих собой текстовое описание генерируемого видео. В области ИИ такие текстовые запросы, описывающие объект генерирования для модели машинного обучения, также называют «промпт». Запрос от пользователя (110) может передаваться через API (120), реализованный в веб-браузере или мессенджере (например, Telegram), обеспечивающий последующий обмен данными непосредственно с моделью генерирования видео (130) (например, Kandinsky) пользователем (110) и модулем защиты видео (140).

[0031] Модуль защиты видео (140) может быть реализован на базе внешнего программно-аппаратного комплекса, например, сервера или удаленной АРМ, обеспечивающий функционал по обработке поступающих видео (121), сгенерированных моделью (130). Модуль (140) может также находится в одном исполняющем контуре совместно с моделью (130), например, сервере или облачном вычислительном узле.

[0032] По факту работы модуля защиты видео (140) в первично генерируемые видео (121) внедряется защитная информация, содержащая зашифрованное вложение, позволяющее установить по меньшей мере авторство видео, как созданного с помощью модели (130), а также идентификатор пользователя, сформировавшего запрос, и сам текст запроса. Впоследствии защищенное видео (141) передается пользователю (110) через API (120), например, посредством отображения/воспроизведение видео (141) в веб-браузере или мессенджере.

[0033] Обмен данным в рамках реализации системы построен на стандартных принципах обмена данными, в частности с помощью вычислительной сети «Интернет», которая может быть реализована с помощью любых известных принципов, известных из уровня техники.

[0034] На Фиг. 2 представлен пример реализации заявленного способа (200) защиты генерируемых видео. На первом этапе (201) происходит получение пользовательского ввода для генерации видео моделью (130). Пользовательский ввод включает в себя текстовый запрос пользователя, ID пользователя (например, IP адрес, МАС адрес, ID регистрации и т.п.), и время текстового запроса. Эти данные фиксируются модулем защиты видео (140) для последующего формирования защитной информации для внедрения в видео.

[0035] Видеокодек Н.262 [6] входит в группу стандартов цифрового кодирования видео- и аудиосигналов MPEG-2 часть 2. Первоначально этот кодек мог кодировать видео с разрешением 720*480 точек при 30 кадрах в секунду, при дальнейшем усовершенствовании достигалось сжатие разрешения 1920*1080 точек при 30 кадрах в секунду. Сжатие основано на устранении пространственной и временной избыточностей.

[0036] Для решения задач наличия в видеопотке пространственной и временной избыточности в кодеке вводится понятие группа кадров (group of pictures - GOP), и кадры в группе делятся на три вида: основные I- (intrapictures), предсказанные Р- (predicted) и двунаправленные В- (bidirectional) кадры. I-кадры - это входная точна для декодера, они кодируются независимо в соответствии с методом, используемым в стандарте JPEG. Р- кадры кодируются на основе предсказания, путем ссылок на блоки предыдущих I- или Р- кадров. В-кадры используют ссылки на два кадра, находящихся впереди и позади них. Группа кадров всегда должна начинаться с I- кадра, по нему предсказываются Р- и В-кадры.

[0037] Количество Р- и В-кадров может варьироваться в зависимости от желаемой степени сжатия: чем больше Р- и В-кадров, тем больше сжатие, однако если 1-кадр будет закодирован ошибочно, либо произойдет потеря информации в I- кадре, то ошибка будет тянуться на всю группу кадров.

[0038] Сжатие видеоизображения происходит следующим образом. Последовательность кадров разбивается на макроблоки 16×16 отсчетов как в алгоритме JPEG и разделяются на три типа кадров: I-, Р- и В-кадры. I-кадры сжимаются с помощью алгоритма JPEG: в каждом макроблоке 16×16 отсчетов производится переход к цветовой системе YCrCb, компоненты Cr и Cb прореживаются до матриц 8×8 (удаляется каждая вторая строка и каждый второй столбец), производится дискретное косинусное преобразование (ДКП) матриц и их квантование, в заключении зиг-заг сканирование и сжатие получившейся последовательности отсчетов методом Хаффмана. Р-кадры передают уже не полностью закодированное изображение, а ошибку предсказания с учетом компенсации движения - разницу между предыдущим и последующим кадром с векторами движения.

[0039] Вектора движения рассчитываются следующим образом: каждый блок из предыдущего кадра сравнивается с блоком из следующего. Если они идентичны, то никакого движения не произошло, вектор движения отсутствует. Если нет, то блок перемещается в некоторой области поиска основного изображения, чтобы найти такое его положение, при котором среднеквадратическая разность блока и фрагмента основного изображения принимает минимальное значение. За вектор движения принимается это смещение блока по вертикали и горизонтали относительно исходного положения. В-кадры при кодировании ссылаются на два кадра: впереди и позади них. То есть в них передается информация о том, как «собрать» кадр из двух окружающих. Благодаря тому, что передается не каждый кадр по отдельности, а ссылки на основные кадры. Стандарт MPEG2 хорошо подходит для хранения фильмов, однако из-за структуры группы кадров совершенно не годится для видеомонтажа. Так же возникают проблемы со сжатием видеосюжетов с быстро движущимися объектами или с часто меняющимися планами. Объект будет размазан, а если I-кадр окажется не на моменте смены плана, то вся информация будет записана в Р-кадр, что приведет к увеличению объема файла.

[0040] Видеокодек входит Н.264 [7] в группу стандартов MPEG4 часть 10. Эта рекомендация в настоящее время является стандартом сжатия видеоизображения. Используется для записи видео высокой четкости на Blu-ray и HD DVD, является стандартом для онлайн-видеохостингов, таких как Youtube, а также стандартом в системах цифрового телевещания. По сравнению с Н.262 данный кодек обеспечивает сжатие в два раза больше при неизменном качестве видеоизображения. Достигается это благодаря существенному усложнению кодека. В данном кодеке реализовано разбиение кадра не только на макроблоки 16x16, а также 16x8, 8x16, 8x8, 8x4, 4x8, 4x4, в зависимости от наличия мелких деталей. При этом увеличивается четкость передачи мелких объектов и качество компенсация движения: обеспечивается большая точность представления векторов движения. При этом точность поиска вектора движения составляет 1/4 или 1/8 макроблока, чего не было в кодеке Н.262. Изменено внутреннее кодирование I-кадра. Кодирование так же основано на алгоритме JPEG, но с некоторыми дополнениями. Перед операцией ДКП над макроблоком производится его пространственное предсказание (intraprediction) по уже закодированным соседним макроблокам. Затем яркостные и цветоразностные отсчеты предсказанного макроблока вычитаются из соответствующих отсчетов кодируемого макроблока, и над матрицей с разностными компонентами производится ДКП.

[0041] В кодере предусмотрено девять направлений внутреннего предсказания. Так же изменены методы устранения временной избыточности. Р- и В-кадры, при их формировании, могут ссылаться на несколько кадров (более двух). Энтропийное кодирование Хаффмана заменено более сложным и ресурсозатратным контекстным адаптивным двоичным арифметическим кодером (Context Adaptive Binary Arithmetic Coder, CABAC). Каждый новый кодек и каждое нововведение основываются на увеличении мощности компьютеров.

[0042] Далее на этапе (202) модель (130) осуществляет генерацию видео (121) согласно пользовательскому запросу и передает его в модуль защиты видео (140). Видео формируется в формате Н.262 или Н.264. Данные форматы видео кодируют изображения кадров в формате JPG (или JPEG) [3-5]. При поступлении в модуль (140) сгенерированного видео (121) в формате Н.262 или Н.264 из него извлекаются I-кадры. Данные кадры представляют собой изображение в формате JPG. На этапе (203) выполняется извлечение из JPG-изображения кадров видео блоков значений коэффициентов дискретного косинусного преобразования (ДКП) для яркостной (Y) и цветных (Cb (относительная голубизна) и Cr (относительная краснота) составляющих изображения.

[0043] На Фиг. 3А представлен пример кадра из видео и получения блоков с коэффициентами дискретного косинусного преобразования (ДКП). При кодировании в JPEG исходного кадра (изображение представленного виде пикселей в формате RGB) данные коэффициенты получаются следующим образом. Полученное изображение разбивается на цветовые каналы. Полученные каналы изображения (121) разбиваются на блоки (300₁-300_n) размерностью 8×8 пикселей. Количество блоков (300₁-300_n) зависит от разрешения сгенерированного изображения (121) или размера растрового изображения. Например, для изображения размера 1920×1080 пикселей количество блоков составит 240 по горизонтали и 135 по вертикали.

[0044] Каждый блок (300₁-300_n) подвергается дискретному косинусному преобразованию (ДКП), являющемся разновидностью дискретного преобразования Фурье. При этом, каждый из блоков (300₁-300_n) содержит один DC коэффициент (301₁) на позиции (0,0) внутри блока и 63 АС коэффициента (301₂-301₆₄) на других позициях внутри блока. DC-коэффициент является усредненным значением всех значений внутри блока как это примерно изображено на Фиг. 3В.

[0045] На Фиг. 3Б представлен пример позиционирования ДКП коэффициентов внутри блока для кадров видео. DC коэффициенты также еще называют низкочастотные коэффициенты. В текущем описании позиция внутри блока (0,0) так же обозначается как 1-ая позиция. Позиции обозначаются со 2-ой по 64-ю позицию.

[0046] Сам кадр (изображение) в формате JPEG представляет собой сжатое хранение упомянутых выше коэффициентов ДКП. Таким образом, на этапе (203) происходит извлечение этих блоков коэффициентов ДКП напрямую из данных изображения, кодированных в формате JPEG.

[0047] На этапе (204) выполняется хеширование последовательности DC коэффициентов. Для этого берутся все значения DC коэффициентов в блоках во всех I- кадрах и к ним применяется выбранный алгоритм хеширования, например, SHA-256, SHA- 512 и т.п.

[0048] Как показано на Фиг. 4 на этапе (205) с помощью выбранного ключа (seed) определяются 1-кадры и внутри них АС коэффициенты в блоках (300₁-300_n) для последующего внедрения защитной информации. Берется исходная упорядоченная последовательность (401) кадров (F) из сгенерированного видео, внутри кадров блоков коэффициентов ДКП (X1, Х2) и позиций самих коэффициентов внутри блоков (Y1, Y2): {F-(Х1, Х2)-(Y1, Y2)}. Где F - номер кадра в видео, (X1, Х2) - координата блока коэффициентов ДКП внутри изображения: , Н_{изо6ражения} - высота изображения, W_{изображения} - ширина изображения; (Y1, Y2) - координаты позиций коэффициентов ДКП внутри блоков: На Фиг. 3Б представлен пример таких позиций. Далее выбранная последовательность (401) АС коэффициентов перемешивается с помощью заданного ключа, впоследствии формируя новую последовательность (402) АС коэффициентов.

[0049] На этапе (206) выполняется формирование защитного вложения. Вложение состоит из открытой части (нешифрованной) и шифрованной части. Шифрованная часть представляет собой шифрованную последовательность данных, включающую в себя следующие данные: время ввода, ID пользователя, текстовый запрос (промпт-запрос), значение хеш-функции, полученной на этапе (204), и дополнительную текстовую информацию (например, обозначение «Я модель Сбера»). Открытая часть может включать в себя такую информацию как: проверочное число, хеш последовательности выбранных коэффициентов ДКП, контрольное число целостности шифрованного вложения. Пример такого вложения представлен на Фиг. 6.

[0050] В одном из частных вариантов изобретения встраиванию подлежат произвольные данные, произвольного размера, меняющиеся в зависимости от запроса или его условий. В этом случае, при извлечение данных, изначально не известен их количество и их размер. Для возможности их извлечения в начало данных шифрованной части вставляются следующие данные: количество различных данных в фиксированном количестве первых бит, размер каждого из вложений в фиксированном количестве последующих бит. На Фиг. 6 приведен пример такого вложения. В начале шифрованной части вложения располагается количество данных - 3 данных: хеш видео; текстовая информация, включающая в себя фиксированную текстовую фразу, ID пользователя, время запроса, «промпт» запроса; сжатый кадр видео. Под количество данных отведено первые 32 бита шифрованной части вложения. Далее располагаются размеры данных - 64 байта на хеш; 163 байта на текстовую информацию, 3756 байт на сжатый кадр видео. Под каждый размер отводится следующие 32 бита шифрованной части вложения.

[0051] Дополнительно защитное вложение может включать сжатое изображение некоторого кадра (например, первого) из сгенерированное видео (121), которое переводится в последовательность байт, добавляемую к последовательности байт остальных данных. Полученное вложение на этапе (206) подписывается закрытым ключом на этапе (207), формируя тем самым часть защитного вложения. Полученная шифрованная последовательность байт представляет в виде последовательности бит.

[0052] Далее на этапе (208) выполняется встраивание информации в последовательность коэффициентов ДКП из 1-кадров, полученную на этапе (205).

[0053] Сначала встраиванию подлежит информация в открытом виде (не шифрованная). Это информация может включать в себя такую последовательность данных как: проверочное число, хеш последовательности DC-коэффициентов (полученный на этапе (204)), контрольное число целостности защитного вложения, например, рассчитанного по алгоритму CRC16, CRC32, CRC64 или любому другому алгоритму расчета контрольной суммы или хеширования. Данная информация представляется в виде последовательности бит.

[0054] Далее встраиванию подлежит защитное вложение, полученного на этапе (207). Защищенное видео (141) с внедренной на этапе (208) информацией отображается / воспроизводится на этапе (209) на устройстве пользователя.

[0055] Вложение на этапе (208) встраивается непосредственно в выбранные на этапе (205) АС коэффициенты блоков (300₁ - 300_n), входящих в перемешанную последовательность (402).

[0056] Пример кодирования вложения внутрь видео файла показана на Фиг. 5. При выполнении данного шага формируется перемешанная последовательность кадров видео, блоков коэффициентов ДКП и самих позиций коэффициентов внутри блоков. На Фиг. 5 первый бит встраивается в кадр №14, блок (31, 70), в коэффициент на позиции (1, 0). Второй бит встраивается в кадр №21 в блок (8, 69), в коэффициент на позиции (0, 2) и так далее. Встраивание осуществляется как остаток от деления значения коэффициента ДКП на 2. Другими словами, если остаток от деления на 2 равен 0, то это означает, что в коэффициент встроен бит со значением 0. Если остаток от деления на 2 равен 1, то это означает, что в коэффициент встроен бит со значением 1. Если текущее значение коэффициента ДКП не дает нужный остаток, то это значение увеличивается или уменьшается на 1.

[0057] Как показано в примере на Фиг. 5 первый бит встраиваемой информации равен 1. Значение коэффициента в кадре №14, в блоке (31, 70), на позиции (1, 0) является 17. Остаток от деления 17 на 2 равен 1. Остаток совпадает со значением встраиваемого бита. Второй бит встраиваемой информации равен 0. Значение коэффициента в кадре №21, в блоке (8, 69), на позиции (0, 2) является 23. Остаток от деления 23 на 2 равен 1. Остаток не совпадает со значением встраиваемого бита. Меняем значение 23 вычитая из него 1. Значение стало равным 22. Остаток от деления 22 на 2 теперь равен 0, что совпадает со значением встраиваемого бита.

[0058] Встраивание информации может производиться по принципу кодирования информации в наименьший значимый бит (НЗБ) в блоках ДКП коэффициентов. НЗБ - последний бит в битовом виде, изменение которого наименьшим образом меняет само значение.

[0059] Пример кодирования в блок ДКП коэффициентов на Фиг. 3В:

[0060] Рассмотрим пример встраивания текстовой информации. Текст для встраивания: SBER - 01010011 01000010 01000101 01010010. Рассмотрим встраивание буквы «S» - 01010011. Идет встраивание слева направо: 0-1-0-1 и т.д.

Поэтому значение меняется на 1 и принимает битовый вид 00000111. Другими словами, 6 заменяется на 7.

- Шаг 3. Третий бит от «S»=0 и он встраивается в коэффициент ДКП со значением 3. НЗБ для 3 равен 1 (00000011). Необходимо встроить 0 от «S», а для 3 НЗБ=1. Поэтому это значение меняется на 0 и принимает битовый вид 00000010. Другими словами, 3 заменяется на 2.

Данный процесс продолжается до встраивания всех требуемых бит. В итоге формируется матрица ДКП коэффициентов с закодированной информацией в части изменения выбранных АС коэффициентов.

[0061] Итоговая внедряемая последовательность защитных данных может иметь следующий вид: [проверочное число (например, 537), хеш DC-коэффициентов, контрольное число целостности шифрованного вложения, шифрованное вложение]. Данные в шифрованном вложении могут представлять собой следующую последовательность: [количество вложений (например, 3), размер 1-го вложения, размер 2-го вложения, размер 3-го вложения, хеш DC-коэффициентов, текст («Я модель Сберај»), миниатюра кадра видео (сильно сжатое изображение кадра из видео)].

[0062] В байтовом виде это будет выглядеть следующим образом: 00000219ac3eb891bc32652a83b4ff62cc2e49de3293d99e24ae8907e90c96b55cb5578a78d78e887f5f436f6b9b989c6896b689e986s64a3509ee90fcaј, где 00000219 - байтовый вид числа 537, ac3eb891bc32652a83b4ff62cc2e49de32 - байтовый вид хеша, 93d99e24 - байтовый вид значения контрольного числа CRC32 равное числу 2480512548, далее шифрованные данные. На Фиг. 6 представлен пример байтовой последовательности, подлежащей вложению. Эта последовательность представляется в виде битовой последовательности.

[0063] Полученные новые значения коэффициентов ДКП (Фиг. 5) сжимаются (кодируются) по стандарту JPEG, формируют новый 1-кадр видео, сохраняются в виде нового файла видео.

[0064] При встраивании данной последовательности в выбранные кадры и ДКП коэффициенты полученное видео (141) остается визуально неотличимым от первоначально сгенерированного видео (121). Даже малые изменения пикселей любого кадра ведет к изменению коэффициентов ДКП этого кадра, что разрушает встроенное вложение. Любая перестановка оригинальных кадров местами также разрушает встроенное вложение. Этот факт позволяет в последующем выполнить проверку целостности встраиваемой защитной информации для подтверждения, что видео (141) является подлинным, т.е. созданным с помощью модели (130), и что оно не было изменено в любой части его содержания.

[0065] Далее рассмотрим процесс извлечения вложенной информации при проверке защищенного видео (141).

[0066] Аналогично этапам (203)-(205) происходит получение значения хеша DC-коэффициентов кадров видео (хеш видео) и последовательность кадров и коэффициентов ДКП в которые потенциально было выполнено встраивание информации.

[0067] Далее выполняется следующий алгоритм.

[0068] Шаг 1. Извлекаются первые 4 байта для получения контрольного числа. Выполняется проверка, что данное число является исходным контрольным числом. Если число совпадает - продолжается извлечение. Если нет - формируется сообщение, что цифровая подпись не обнаружена или разрушена.

[0069] Шаг 2. Извлекаются следующие 64 байта. Это хеш DC-коэффициентов кадров видео. Полученное значение сверяется с фактическим хешом DC-коэффициентов. Если хеш совпадает - продолжается извлечение. Если нет - выводим сообщение, что цифровая подпись не обнаружена или разрушена.

[0070] Шаг 3. Извлекаются следующие 4 байта, что позволяет получить контрольное число шифрованного вложения.

[0071] Шаг 4. Извлекается шифрованное вложение. Все дальнейшие биты во вложении относятся к шифрованному вложению. На данном этапе размер вложения является неизвестным. Однако, в первом блоке шифрованного вложения - это 256 байт для RSA, находятся длины вложений. Извлекаются первые 256 байт. Выполняется их расшифровка на открытом (публичном) ключе. Первые 4 байта в этом блоке это количество вложений - в примере на Фиг. 6 содержится 3 вложения. Каждые следующие 4 байта это размер каждого из этих вложений. В них находятся числа 64, 163 и 3756. Если размер любого вложения больше 30000 (ограничение на максимальное вложение), значит блок шифротекста изменен, в связи с чем формируется сообщение что цифровая подпись не обнаружена или разрушена. В противном случае получаются потенциальные размеры вложений и продолжатся извлечение.

[0072] Далее определяется размер шифрованного вложения. В соответствии с примером на Фиг. 6 полученные 64 байта размер первого вложения, что является хешом DC-коэффициентов кадров видео, далее 163 байта размер второго вложения - это размер текста. Размер третьего вложения 3756 байт - это миниатюра первого кадра видео (сжатый кадр). Тогда общий размер шифрованного вложения: 64+163+3756=3983 (само вложение); добавляется 4 байта на количество вложений и еще 3 раза по 4 байта на их длины. В итоге получается следующее: 64+163+3756+4+3*4=3999 байт. Поскольку блок шифрования имеет размер 256, то в приведенном примере 3999//256=16 целых блоков шифрования, что равно 4096 байт шифрованного вложения.

[0073] Извлекаются 4096 байт, по которым считается контрольное число CRC32. Если значения совпало с контрольным числом, полученным на шаге 3, то извлечение продолжается. Если нет - формируется сообщение, что цифровая подпись не обнаружена или разрушена.

[0074] Расшифровка 4096 байт. Из первого блока, как было указано выше, получается количество вложений, их длины и сами вложения. Выполняется разбивка расшифрованной последовательности байт по количествам байт каждого вложения. Получаются исходные вложения.

[0075] Выполняется сверка хеша из расшифрованных данных с хешом из вложения (который уже сравнен с фактическим на шаге 2). Если хеши совпали - выводится сообщение что цифровая подпись подтверждена, отображается извлеченная информация - хеш DC-коэффициентов видео, текст, и миниатюра первого кадра сгенерированного видео. Если нет - выводится сообщение, что цифровая подпись не обнаружена или разрушена.

[0076] На Фиг. 7 представлен общий вид вычислительного устройства (500), пригодного для выполнения способа (200). Устройство (500) может представлять собой, например, сервер или иной тип вычислительного устройства, который может применяться для реализации заявленного технического решения, в том числе: смартфон, планшет, ноутбук, компьютер и т.п. Устройство (500) может также входить в состав облачной вычислительной платформы.

[0077] В общем случае вычислительное устройство (500) содержит объединенные общей шиной информационного обмена один или несколько процессоров (501), средства памяти, такие как ОЗУ (502) и ПЗУ (503), интерфейсы ввода / вывода (504), устройства ввода / вывода (505), и устройство для сетевого взаимодействия (506).

[0078] Процессор (501) (или несколько процессоров, многоядерный процессор) могут выбираться из ассортимента устройств, широко применяемых в текущее время, например, компаний IntelФ, AMDФ, AppleФ, Samsung ExynosФ, MediaTEKФ, Qualcomm SnapdragonФ и т.п. В качестве процессора (401) может также применяться графический процессор, например, Nvidia, AMD, Graphcore и пр.

[0079] ОЗУ (502) представляет собой оперативную память и предназначено для хранения исполняемых процессором (501) машиночитаемых инструкций для выполнение необходимых операций по логической обработке данных. ОЗУ (502), как правило, содержит исполняемые инструкции операционной системы и соответствующих программных компонент (приложения, программные модули и т.п.).

[0080] ПЗУ (503) представляет собой одно или более устройств постоянного хранения данных, например, жесткий диск (HDD), твердотельный накопитель данных (SSD), флэш- память (EEPROM, NAND и т.п.), оптические носители информации (CD-R/RW, DVD-R/RW, BlueRay Disc, MD) и др.

[0081] Для организации работы компонентов устройства (500) и организации работы внешних подключаемых устройств применяются различные виды интерфейсов В/В (504). Выбор соответствующих интерфейсов зависит от конкретного исполнения вычислительного устройства, которые могут представлять собой, не ограничиваясь: PCI, AGP, PS/2, IrDa, FireWire, LPT, COM, SATA, IDE, Lightning, USB (2.0, 3.0, 3.1, micro, mini, type C), TRS/Audio jack (2.5, 3.5, 6.35), HDMI, DVI, VGA, Display Port, RJ45, RS232 и т.п.

[0082] Для обеспечения взаимодействия пользователя с вычислительным устройством (500) применяются различные средства (505) В/В информации, например, клавиатура, дисплей (монитор), сенсорный дисплей, тач-пад, джойстик, манипулятор мышь, световое перо, стилус, сенсорная панель, трекбол, динамики, микрофон, средства дополненной реальности, оптические сенсоры, планшет, световые индикаторы, проектор, камера, средства биометрической идентификации (сканер сетчатки глаза, сканер отпечатков пальцев, модуль распознавания голоса) и т.п.

[0083] Средство сетевого взаимодействия (506) обеспечивает передачу данных устройством (500) посредством внутренней или внешней вычислительной сети, например, Интранет, Интернет, ЛВС и т.п. В качестве одного или более средств (506) может использоваться, но не ограничиваться: Ethernet карта, GSM модем, GPRS модем, LTE модем, 5G модем, модуль спутниковой связи, NFC модуль, Bluetooth и/или BLE модуль, Wi-Fi модуль и др.

[0084] Дополнительно могут применяться также средства спутниковой навигации в составе устройства (500), например, GPS, ГЛОНАСС, BeiDou, Galileo.

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

Источники информации:

1. ГОСТ Р 34.10-2012. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи. https://rst.gov.ru:8443/file-service/file/load/1699366979620

2. ГОСТ Р 34.11-2012. Криптографическая защита информации. Функция хэширования. https://rst.gov.ru:8443/file-service/file/load/1699367414693

3. Hamilton, Eric: JPEG File Interchange Format, Version 1.02. 1 September 1992.

4. Recommendation ITU-T T.871: Information technology - Digital compression and coding of continuous-tone still images: JPEG File Interchange Format (JFIF). Approved 14 May 2011; posted 11 September 2012.

5. Recommendation ITU-T T.81: Information technology - Digital compression and coding of continuous-tone still images - Requirements and guidelines. Approved 18 September 1992; posted 14 April 2004.

6. H.262/MPEG-2 Part 2: «ISO/IEC 13818-2:2013 - Information technology - Generic coding of moving pictures and associated audio information: Video». ISO. https://www.iso.org/standard/61152.html. Доступность: 24 July 2024.

7. MPEG-4, Advanced Video Coding (Part 10) (H.264) (Full draft). Sustainability of Digital Formats. Washington, D.C.: Library of Congress. December 5, 2011.

https://www.loc.gov/preservation/digital/formats/fdd/fdd000081.shtml. Доступность: 24 July 2024.

Изобретение относится к средствам защиты цифровых данных для целей подтверждения их подлинности. Техническим результатом является повышение эффективности защиты генерируемых искусственным интеллектом видео для целей определения их подлинности. Способ защиты подлинности видео, генерируемых на основании текстового запроса моделью машинного обучения, содержит этапы, на которых: получают данные пользовательского ввода для генерирования видео; генерируют видеофайл с помощью модели машинного обучения; фиксируют данные пользовательского ввода: время ввода, ID пользователя или текстовый запрос; извлекают из сгенерированного видеофайла ключевые I-кадры в формате JPG; формируют вложение для защиты сгенерированного видео, состоящее из указанных данных; формируют зашифрованную последовательность с помощью шифрования данных вложения; осуществляют встраивание в коэффициенты дискретного косинусного преобразования кадров в формате JPG из I-кадров сгенерированного видео, определенных ранее, значений хеш-функции и зашифрованной последовательности; предоставляют защищенное видео пользователю. 2 н. и 8 з.п. ф-лы, 9 ил.

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

a) получают данные пользовательского ввода для генерирования видео;

b) генерируют видеофайл с помощью модели машинного обучения;

c) фиксируют по меньшей мере один тип данных пользовательского ввода, выбираемый из группы: время ввода, ID пользователя или текстовый запрос;

d) извлекают из сгенерированного видеофайла ключевые I-кадры в формате JPG;

e) извлекают из полученных I-кадров блоки значений коэффициентов дискретного косинусного преобразования (ДКП) для по меньшей мере одной составляющей изображения, выбираемой из группы: яркостная (Y), цветная (Cb- и Cr-) составляющие изображения;

f) получают последовательность низкочастотных коэффициентов ДКП (DC-коэффициенты) по всем I-кадрам по всем блокам яркостной составляющей и рассчитывают хеш-функцию от полученной последовательности DC-коэффициентов;

g) по заданному ключу определяют I-кадры, блоки коэффициентов ДКП и позиции коэффициентов ДКП внутри блоков, исключая в блоках DC-коэффициенты ДКП, используемые на этапе f);

h) формируют вложение для защиты сгенерированного видео, состоящее из последовательности, включающей: время ввода, ID пользователя, текстовый запрос, значение хеш-функции, полученной на этапе f);

i) выполняют формирование зашифрованной последовательности с помощью шифрования данных, полученных на этапе h), закрытым ключом;

j) осуществляют встраивание в коэффициенты ДКП кадров в формате JPG из I-кадров сгенерированного видео, определенные на этапе g), значений хеш-функции, полученной на этапе f), и зашифрованной последовательности, полученной на этапе i);

k) предоставляют защищенное видео пользователю.

2. Способ по п. 1, в котором видео генерируется по стандарту Н.262 или Н.264.

3. Способ по п. 1, в котором на этапе d) дополнительно извлекаются Р-кадры и/или В-кадры.

4. Способ по п. 1, в котором на этапе d) выполняется извлечение блоков для встраивания информации по меньшей мере одной из Y-, Cb- и Cr-составляющих кадров сгенерированного видео.

5. Способ по п. 1, в котором на этапе f) последовательность DC-коэффициентов состоит из коэффициентов ДКП одной из Y-, Cb- и Cr-составляющих кадров сгенерированного видео.

6. Способ по п. 1, в котором на этапе f) хеш-функцию рассчитывают по меньшей мере по одному высокочастотному АС-коэффициенту ДКП и/или DC-коэффициенту ДКП, по меньшей мере одной из Y-, Cb- и Cr-составляющих кадров сгенерированного видео.

7. Способ по п. 1, в котором на этапе g) по заданному ключу определяют блоки коэффициентов ДКП и позиции коэффициентов ДКП внутри блоков, включающие в себя АС-коэффициенты и DC-коэффициенты ДКП, по меньшей мере одной из Y-, Cb- и Cr-составляющих кадров сгенерированного видео, исключая используемые на этапе f).

8. Способ по п. 1, в котором на этапе с) дополнительно формируются сжатые изображения одного или нескольких кадров из сгенерированного видео.

9. Способ по п. 8, в котором на основании сжатых изображений кадров формируется последовательность байт, которая добавляется к данным на этапе h) при формировании вложения.

10. Система защиты подлинности видео, генерируемых на основании текстового запроса моделью машинного обучения, содержащая по меньшей мере один процессор и по меньшей мере одну память, связанную с процессором, хранящую машиночитаемые инструкции, которые при их выполнении процессором реализуют способ по любому из пп. 1-9.