Общественное обсуждение проекта ГОСТ по защите оцифрованных видеоданных от случайного и преднамеренного искажения

    Уважаемые Хабрапользователи!

    Наша компания уже несколько лет входит в состав технического комитета по стандартизации ТК-234 «Системы тревожной сигнализации и противокриминальной защиты» и является активным участником процессов стандартизации в области охранных систем. Так уж получилось, что принятие стандартов в нашей стране происходит, так сказать, «за кулисами» на основании решения достаточно скромной группы профильных экспертов. Такое положение дел нам кажется неправильным и сейчас, в ходе разработки очередного стандарта, мы решили по собственной инициативе организовать общественное обсуждение проекта ГОСТ «Системы охранные телевизионные. Защита оцифрованных видеоданных от случайного и преднамеренного искажения».

    Мы будем крайне признательны за конструктивную критику проекта, а все ценные замечания и пожелания будут внесены в очередную редакцию стандарта. Если такой опыт окажется удачным, то будем представлять на суд уважаемой Хабрааудитории все проекты всех стандартов, проходящих через ТК-234. Текст стандарта под катом.

    Введение
    Системы охранные телевизионные предназначены для использования в целях защиты людей и имущества на охраняемых объектах от преступных посягательств. Полученные оцифрованные видеоданные должны быть защищены от случайного и преднамеренного искажения. Данный стандарт позволяет упорядочить существующие и разрабатываемые методы защиты оцифрованных видеоданных, предназначенных для применения в составе систем противокриминальной защиты.
    Настоящий стандарт следует применять совместно с ГОСТ Р 51558-2008 «Средства и системы охранные телевизионные. Классификация. Общие технические требования. Методы испытаний», а также с ГОСТ Р 54830-2011«Системы охранные телевизионные. Компрессия оцифрованных видеоданных. Общие технические требования и методы оценки алгоритмов».


    НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

    Системы охранные телевизионные. Защита оцифрованных видеоданных от случайного и преднамеренного искажения.



    Общие требования

    Video surveillance systems. Protection of digital video data from accidental or deliberate distortion. General requirements

    Дата введения –

    1 Область применения

    Настоящий стандарт распространяется на цифровые системы охранные телевизионные (далее ЦСОТ) и устанавливает общие технические требования к применению различных методов защиты оцифрованных видеоданных в ЦСОТ от случайного и преднамеренного искажения.
    Настоящий стандарт определяет требования по применению различных методов защиты в оцифрованных видеоданных.
    Настоящий стандарт применяют совместно со стандартами ГОСТ Р 51558, ГОСТ 34.11-2012, ГОСТ ИСО/МЭК 17799-2005.

    2 Нормативные ссылки

    В настоящем стандарте использованы нормативные ссылки на следующие стандарты:
    ГОСТ Р 51558-2008 Средства и системы охранные телевизионные. Общие технические требования и методы испытаний.
    ГОСТ Р 54830-2011 Системы охранные телевизионные. Компрессия оцифрованных видеоданных. Классификация. Общие технические требования и методы оценки алгоритмов.
    ГОСТ Р 50922-2006 Защита информации. Основные термины и определения.
    ГОСТ Р 51275-2006 Защита информации. Объект информатизации. Факторы, воздействующие на информацию.
    ГОСТ Р 34.11-2012 Информационная технология. Криптографическая защита информации. Функция хэширования
    ГОСТ Р 34.10-2012 Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи.
    ГОСТ Р ИСО/МЭК 17799-2005 Информационная технология. Практические правила управления информационной безопасностью.
    ГОСТ Р 1.5-2004 Стандарты национальные Российской Федерации. Правила построения, изложения, оформления и обозначения.
    ГОСТ 28147-89 Системы обработки информации. Защита криптографическая. Алгоритм криптографического преобразования.
    ГОСТ 19.401-78. ЕСПД. Текст программы. Требования к содержанию и оформлению.
    ГОСТ 19.402-78. ЕСПД. Описание программы.
    ГОСТ 19.404-79. ЕСПД. Пояснительная записка. Требования к содержанию и оформлению.

    3 Термины и определения

    В настоящем стандарте применяют следующие термины с соответствующими определениями:
    3.1 видеоданные (video data), видеопоток (video stream): Аналоговый сигнал, несущий информацию о пространственно-временных параметрах изображений.
    3.2 оцифрованные видеоданные (digitized video data): Данные, полученные путем аналого-цифрового преобразования видеоданных, представляющие собой последовательность байтов в некотором формате (RGB, YUV или др.).
    3.3 формат оцифрованных видеоданных (digitized video data format); видео формат: Представление оцифрованных видеоданных, обеспечивающее их обработку цифровыми вычислительными средствами.

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

    3.4 видео контейнер (video container): формат файла или видеопотока, в котором сохраняется или передаётся видеоряд и служебная информация, предназначенная для дальнейшей обработки/анализа видеоряда, либо составная часть иного файла и контейнера, предназначенная для хранения и передачи видеоряда и служебной информации. Спецификация видео контейнера описывает способ представления передаваемых данных, может накладывать ограничения на алгоритмы их кодирования.
    3.5 целостность видеоданных (video data integrity): обеспечение достоверности и полноты информации и методов ее обработки.
    3.6 подлинность видеоданных (authenticity video data): свойство системы сохранять неизменность или обнаруживать факт несанкционированного изменения информации и атрибутов, устанавливающих авторство.
    3.7 электронная цифровая подпись, ЭЦП (signature): электронная цифровая подпись (signature), ЭЦП: Строка бит, полученная в результате процесса формирования подписи. (ИСО/МЭК 14888-1:2008 [4])

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


    3.8 закрытый ключ (private key): секретная часть пары алгоритмов асимметричного шифрования. Для ЭЦП — уникальная последовательность символов, известная владельцу сертификата ключа подписи и предназначенная для создания в электронных документах электронной цифровой подписи с использованием средств электронной цифровой подписи.
    3.9 хэш-функция (collision-resistant hash-function): Функция, отображающая строки бит в строки бит фиксированной длины и удовлетворяющая следующим свойствам:
    3.9.1 по данному значению функции сложно вычислить исходные данные, отображаемые в это значение;
    3.9.2 для заданных исходных данных сложно вычислить другие исходные данные, отображаемые в то же значение функции;
    3.9.3 сложно вычислить какую-либо пару исходных данных, отображаемых в одно и то же значение. Примечание: в настоящем стандарте в целях сохранения терминологической преемственности с действующими отечественными нормативными документами и опубликованными научно-техническими изданиями установлено, что термины «хэш-функция», «криптографическая хэш-функция», «функция хэширования» и «криптографическая функция хэширования» являются синонимами.
    3.10 контрольная сумма (check sum): Число, рассчитанное путем проведения определенных операций над входными данными, обычно используемое для проверки правильности передачи данных по каналам связи.

    Примечание: В данном стандарте термин «контрольная сумма» используется для обозначения механизма не криптографического контроля информации.

    3.11 группа кадров: определенное количество последовательных кадров видеоданных.
    3.12 сообщение (message): строка бит ограниченной длины.
    3.13 SDP (Session Description Protocol): сетевой протокол, предназначенный для описания сессии передачи потоковых данных. SDP сообщение может содержать адреса места назначения; номера UDP портов для отправителя и получателя; медиа-форматы, которые могут применяться во время сессии; время старта и остановки.
    3.14 служебная информация (overhead information): информация, добавляемая к кадру или группе кадров, содержащая нумерацию, дату и время передачи, а также другие данные, определяемые семантикой работы СОТ.
    3.15 IP-адрес (Internet Protocol аddress): последовательность битов, идентифицирующих получателя или отправителя передаваемых данных.
    3.16 UTC время (Universal Time, Coordinated): Шкала всемирного координированного времени. Шкала времени, рассчитываемая Международным бюро мер и весов и Международной службой вращения Земли так, что смещение относительно Международной шкалы атомного времени составляет целое число секунд, а относительно шкалы всемирного времени не превышает 0,9 с по ГОСТ 8.567.
    3.17 RTSP (Real-Time Streaming Protocol): протокол потоков в реальном масштабе времени. Представляет собой протокол прикладного уровня, обеспечивающий контроль доставки данных для приложений реального времени.
    3.18 локальное время (local time): время, установленное на видеоисточнике.
    3.19 опорный кадр (keyframe): кадры, в которых картинка в кадре существенно меняется.

    4 Общие положения

    Целью данного стандарта является регламентация требований к методам защиты оцифрованной видеоинформации от случайных и преднамеренных искажений в процессе их передачи и хранения.
    4.1 Выполнение методов защиты, указанных в настоящем стандарте, должно гарантировать подлинность оцифрованных видеоданных при передаче между частями СОТ и хранении.
    4.2 В настоящем стандарте не рассматриваются методы защиты от искажений, возникших в результате нарушений способов подключения, настройки аппаратуры и других физических действий.
    4.3 Применительно к оцифрованным видеоданным возможны следующие виды искажений:
    • подмена кадра или группы кадров;
    • подмена фрагмента/фрагментов отдельного кадра или группы кадров;
    • изменение порядка следования кадров или групп кадров;
    • удаление кадра или групп кадров;
    • потеря служебной информации, связанной с видеорядом;
    • искажение служебной информации, связанной с видеорядом.
    Эти искажения могут появиться в результате случайного или преднамеренного воздействия.
    В настоящем стандарте вводится понятие уровня защиты данных. Каждому уровню соответствуют свои средства и методы защиты. Уровни защиты оцифрованных видеоданных:
    • уровень I — защита от случайных и преднамеренных искажений
    • уровень II — защита от случайных искажений.

    5 Общие требования

    5.1 Методы защиты оцифрованных видеоданных от случайных или преднамеренных искажений должны разрабатываться (модернизироваться) в соответствии с требованиями настоящего стандарта, технических условий (ТУ) и/или другой технической документации на конкретные методы
    5.2 Документация, подтверждающая применяемый уровень защиты оцифрованных видеоданных от случайных или преднамеренных искажений, должна соответствовать ГОСТ 19.401, ГОСТ 19.402, ГОСТ 19.404.
    5.3 Обязательным для всех уровней защиты оцифрованных видеоданных от случайных и преднамеренных искажений является использование видео форматов/контейнеров с возможностью ресинхронизации видеопотока при поте-ре/повреждении заголовка, т.е. таких, заголовок которых начинается с маркера синхронизации, позволяющего однозначно определить следующий заголовок при повреждении предыдущего.

    Требования к защите оцифрованных видеоданных уровня II

    5.4 Уровень защиты оцифрованных видеоданных II реализуется алгоритмом рас-чета контрольной суммы.
    5.4.1 Требования к контрольной сумме:
    а) Размер регистра для вычислений должен обеспечивать вероятность ошибки не более
    б) Алгоритм расчета контрольной суммы должен обеспечивать, чтобы изменение одного бита входных данных приводило к изменению в среднем 50% битов контрольной суммы.
    Рекомендуется использовать алгоритм CRC32 [1].

    Требования к защите оцифрованных видеоданных уровня I

    5.5 Уровень защиты оцифрованных видеоданных I реализуется добавлением информации к оцифрованным видеоданным и подписанием группы кадров ЭЦП.
    5.5.1 Добавляемая информация к оцифрованным видеоданным содержит нумерацию группы кадров, информацию о времени передачи и технические характеристики видеоисточника.
    5.5.1.1 Требования к нумерации группы кадров:
    а) Группы кадров должны нумероваться последовательно по возрастанию.
    б) Нумерация должна начинаться с 1.
    в) Шаг нумерации равен 1.
    5.5.1.2 Информации о времени передачи должна содержать:
    а) время (часы, минуты)
    б) дата (день, месяц, год)
    в) разницу между UTC и локальным временем
    5.5.1.3. Требования к техническим характеристикам видеоисточника. Информация должна содержать:
    а) SDP-сообщение при передаче оцифрованных видеоданных протоколом RTSP [4]
    б) IP адрес передающей видеокамеры при передаче оцифрованных видеоданных не протоколом RTSP
    в) номер последнего опорного кадра для сжатых кадров.
    5.5.2. Требования к ЭЦП
    а) Добавление ЭЦП для каждой группы кадров оцифрованных видеоданных является обязательным.
    б) ЭЦП должна генерироваться в режиме реального времени.
    в) Расчет хэш-функции для ЭЦП должен выполняться после добавления информации в видеоданные.
    г) Формирование и проверка ЭЦП должны осуществляться по ГОСТ 34.10.
    д) Источники видеоинформации должны иметь техническую защиту, исключающую возможность съема и/или подмены закрытого ключа. Организация этой технической защиты в данном стандарте не рассматривается.

    Приложение А
    (справочное)

    [1] CRC32-IEEE 802.3 Cyclic redundancy check. Циклический избыточный код.
    [2] Philip Koopman, Tridib Chakravarty. Cyclic Redundancy Code (CRC) Polynomial Selection For Embedded Networks, 2004.
    [3] Типовые требования ФСБ России N 149/6/6-622 от 21 февраля 2008 года По организации и обеспечению функционирования шифровальных (криптографических) средств, предназначенных для защиты информации, не содержащей сведений, составляющих государственную тайну в случае их использования для обеспечения безопасности персональных данных при их обработке в информационных системах персональных данных.
    [4] RFC 2326. Real Time Streaming Protocol (RTSP), 1998.

    Смотрите также Общественное обсуждение проекта ГОСТ по компрессии оцифрованных аудиоданных.
    Нордавинд
    42,64
    Компания
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 38

      +1
      Как я понимаю, это требования к форматам контейнеров, на основании соответствия которым можно будет делать вывод о защите видеоданных в контейнере по уровню I или уровню II.

      У меня есть такие вопросы:

      1. Некоторые IP-камеры вместе с видео передают еще и аудио. Почему в стандарте не предусмотрена возможность защищать от случайных или намеренных искажений еще и аудио?

      2. Существуют ли стандартизованные на сей день контейнеры, в которые требуемую согласно уровню I электронную подпись можно поместить уже сейчас без поломки читающего их ПО? [подозреваю, что в MPEG-TS будет достаточно отдельного PID'а]

      3. Определение опорного кадра в стандарте отличается от общепринятого — так и задумано? Существенное изменение картинки вовсе не обязательно. Некоторые камеры расставляют опорные кадры (в понимании стандарта H.264) просто периодически. IMHO, если такое отличие не задумано, лучше будет делегировать определение опорного кадра стандарту на используемый видеокодек.

      4. «Номер последнего опорного кадра для сжатых кадров» — что туда полагается писать, если речь идет о потоке без опорных кадров (H.264 такое допускает — ошибки «самозалечиваются» при декодировании с любого кадра)? Или следует признать, что такие потоки не могут быть защищены по уровню защиты I?

      5. «Источники видеоинформации должны иметь техническую защиту, исключающую возможность съема и/или подмены закрытого ключа» — правильно ли я понимаю, что я не должен иметь возможность его перегенерировать (заменить на новый случайный, неизвестный мне), даже зная пароль для настройки?

      6. Почему стандарт не предусматривает техническую защиту от несанкционированного изменения показаний часов?
        +2
        1. Некоторые IP-камеры вместе с видео передают еще и аудио. Почему в стандарте не предусмотрена возможность защищать от случайных или намеренных искажений еще и аудио?

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

        2. Существуют ли стандартизованные на сей день контейнеры, в которые требуемую согласно уровню I электронную подпись можно поместить уже сейчас без поломки читающего их ПО? [подозреваю, что в MPEG-TS будет достаточно отдельного PID'а]

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

        3. Определение опорного кадра в стандарте отличается от общепринятого — так и задумано? Существенное изменение картинки вовсе не обязательно. Некоторые камеры расставляют опорные кадры (в понимании стандарта H.264) просто периодически. IMHO, если такое отличие не задумано, лучше будет делегировать определение опорного кадра стандарту на используемый видеокодек.

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

        4. «Номер последнего опорного кадра для сжатых кадров» — что туда полагается писать, если речь идет о потоке без опорных кадров (H.264 такое допускает — ошибки «самозалечиваются» при декодировании с любого кадра)? Или следует признать, что такие потоки не могут быть защищены по уровню защиты I?

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

        5. «Источники видеоинформации должны иметь техническую защиту, исключающую возможность съема и/или подмены закрытого ключа» — правильно ли я понимаю, что я не должен иметь возможность его перегенерировать (заменить на новый случайный, неизвестный мне), даже зная пароль для настройки?

        Не совсем так. Здесь имеется в виду лишь то, что управление ключами — это особая процедура, а защита ключей крайне важна, т.к. любые несанкционированные действия в отношении них ставят под угрозу все другие принятые меры. Порядок управления ключами должен регламентировать отдельными документами, возможно ведомственными. Например, для критически важных категорированных объектов к процедуре смены ключей допускается только персонал службы безопасности или I отдела, а для обычных коммерческих объектов — это может делать специалист службы безопасности или IT.

        6. Почему стандарт не предусматривает техническую защиту от несанкционированного изменения показаний часов?

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

          3.19 Опорный кадр (keyframe): Кадр построенный без учета других кадров. Может появляться в потоке по счетчику кадров или по событию.

          4. Ситуация, когда все кадры опорные, допустима и даже является обычным делом в случае использования, например, MJPEG.

          А как быть с ситуацией когда нет опорных кадров?
            0
            3.19 Опорный кадр (keyframe): Кадр построенный без учета других кадров. Может появляться в потоке по счетчику кадров или по событию.


            Формально правильно, но боюсь, не то, что нужно.

            Кадр 1: построен без учета других кадров
            Кадр 2: построен с учетом кадра 1
            Кадр 3: построен без учета других кадров
            Кадр 4: построен с учетом кадра 1

            Формально, кадр 3 является ключевым, но, если начать декодирование с него, то кадр 4 декодировать невозможно.
            0
            3. Определение опорного кадра в стандарте отличается от общепринятого — так и задумано? Существенное изменение картинки вовсе не обязательно. Некоторые камеры расставляют опорные кадры (в понимании стандарта H.264) просто периодически. IMHO, если такое отличие не задумано, лучше будет делегировать определение опорного кадра стандарту на используемый видеокодек.


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

            4. «Номер последнего опорного кадра для сжатых кадров» — что туда полагается писать, если речь идет о потоке без опорных кадров (H.264 такое допускает — ошибки «самозалечиваются» при декодировании с любого кадра)? Или следует признать, что такие потоки не могут быть защищены по уровню защиты I?

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


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

            По поводу 4 — Вы меня неправильно поняли. Имеется в виду не ситуация, когда все кадры опорные (тут действительно нет ничего сложного), а когда ни одного опорного кадра нет вообще, а поток декодировать таки возможно с любой точки (с искажениями или пропущенными кадрами в начале). Да, такое бывает — см. низ permalink.gmane.org/gmane.comp.video.ffmpeg.user/43075, где на эту тему высказывается один из разработчиков ffmpeg'а. Например, возможна ситуация, когда, начав декодирование с кадра 4321, можно получить неискаженную картинку, начиная с кадра 4330 (но невозможно восстановить кадр 4329), но получить неискаженную картинку в кадре 4330, начав декодирование позже кадра 4321, невозможно.

            Предлагается использование понятия «опорный кадр» убрать и заменить 5.5.1.3.в на следующий текст:

            наибольший номер кадра, начав декодирование с которого, можно получить достаточно точное восстановление изображения на всех кадрах, входящих в защищаемую группу
              0
              По поводу пункта 3 — правильное определение зависит от используемого видеокодека, т.е. нельзя написать ничего лучше, чем «кадр, помеченный видеокодеком как опорный в его понимании». В большинстве случаев такие кадры имеют свойство: начав декодирование с этого кадра, можно успешно декодировать его и все без исключения последующие. В нашем случае важен на самом деле факт успешного декодирования кадров, входящих в рассматриваемую группу.

              Вы правы. Думаю, действительно стоит определять опорный кадр через «возможность декодирования его и всех последующих». +1

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

              Вот здесь надо аккуратнее… Что такое «достаточно точное восстановление изображения» с точки зрения криминалистических исследований? Я предлагаю внести оговорку, что ссылка на опорный кадр указывается только в случае, если используемый кодек предполагает наличие опорных кадров.
                0
                По поводу формулировки «достаточно точное восстановление изображения» — я пытался сделать так, чтобы семантика SEI recovery point (только в виде ссылки в обратную сторону) подходила. А там есть только требование приблизительно корректного декодирования, «acceptable pictures for display», и даже флаг «после указанного в другом поле числа кадров возможно точное декодирование», который может быть снят. См. пункт D.2.7 стандарта ITU H264.

                When exact_match_flag is equal to 0, the quality of the approximation at the recovery point is chosen by the encoding process and is not specified by this Recommendation | International Standard.


                Т.е. точность восстановления изображения по сути отдается на откуп авторам реализации кодека.
                  0
                  А по поводу пригодности такого неточного декодирования для целей криминалистики — думаю, что новых проблем это не создаст, т.к. неспецифицированная потеря качества по сравнению с оригинальной сценой есть и в штатном режиме декодирования, особенно если камеру настроили на низкий битрейт. Попытка требовать от lossy-кодека восстановление кадра, на 100% идентичное тому, которое бы получилось при декодировании потока с самого начала, мне кажется, аналогична попытке быть святее папы римского. А вот указание, на сколько кадров назад надо отмотать для получения качества, хорошего с точки зрения автора кодека, IMHO, помешать не может. Если такая неопределенность не нравится, можно еще продублировать флаг exact_match_flag. Тогда при использовании ключевых кадров можно его смело выставлять и подписывать.
                    +1
                    Как я уже говорил, вопрос ухудшения качества изображений из-за компрессии-декомпрессии мы рассмотрели в ГОСТ Р 54830-2011 Системы охранные телевизионные. Компрессия оцифрованных видеоданных. Общие технические требования и методы оценки алгоритмов.
                      +1
                      Ну тогда это вообще замечательно! Достаточно потребовать, чтобы ухудшение качества изображения на кадрах, попадающих в защищаемую группу, при декодировании, начиная с указанного кадра, укладывалось в таблицу 1 из этого ГОСТа, согласно заявленному классу кодека по этому же ГОСТу. Для систем, использующих ключевые кадры в смысле «возможность декодирования его и всех последующих», это требование выполняется тривиальным образом, если указать непосредственно предшествующий ключевой кадр. А для систем без ключевых кадров получено полезное обобщение.
                        0
                        Согласен, спасибо за идею! +1
              +1
              Нужна ли аппаратная защита или достаточно просто фиксации факта смены времени — вопрос открытый для обсуждения.


              Думаю, тут уместен такой же подход, как и к смене ключа, который Вы уже описали, отвечая на пункт 5.
            0
            А зачем вообще такая защита нужна? Для уверенности владельца, что никто не искажает информацию или чтобы эта информация могла быть реальным доказательством в суде?
            5.5.1.2 Информации о времени передачи должна содержать:
            а) время (часы, минуты)
            б) дата (день, месяц, год)
            в) разницу между UTC и локальным временем

            А какое время должно быть? Универсальное или локальное?

            А вообще хорошая инициатива, молодцы!
              +1
              Предполагается, что системы видеонаблюдения, сертифицированные на соответствие данному стандарту, будут записывать видеоматериалы, пригодные для применения в качестве доказательной базы в суде. Однако, соответствие данному стандарту является необходимым, но не обязательным условием. Помимо подлинности данных важным аспектом также является качество этих данных, т.к. достаточность этого качества для того, чтобы идентифицировать объекты (людей и проч.) на видеоматериалах. Такой стандарт был также нами разработан и введен в 2012 году.

              А какое время должно быть? Универсальное или локальное?

              Внутри системы используется как правило локальное время.
                +1
                Может имеет смысл указать точно? Если что-то можно понять неправильно, то оно будет понято неправильно :(
              0
              5.5.1.1 Требования к нумерации группы кадров:
              а) Группы кадров должны нумероваться последовательно по возрастанию.
              б) Нумерация должна начинаться с 1.
              в) Шаг нумерации равен 1.


              Где начало нумерации?

              Предположим, у меня отдельно камера и отдельно регистратор, который пишет видео на SD-карту и при этом добавляет подпись. Каждый час он создает новый файл. Вопрос — при этом номер группы кадров сбрасывается?
                +1
                Думаю, да, ибо защита привязывается к файлу, а не к потоку в целом. То есть, кто пишет файл, тот и определяет нумерацию — в вашем случае регистратор. Но в целом вопрос вполне логичный — во-первых, необходим механизм ссылки на предыдущий файл, для возможности защищённой склейки. А во-вторых, чисто теоретически может возникнуть видеофайл с переполнением счётчика кадров — и эту ситуацию тоже надо обрабатывать.
                  +1
                  А я думаю, что начало нумерации не имеет значения. Например, в наших системах видеонаблюдения мы используем собственное хранилище для потоковых данных, которое вообще не предполагает наличие файлов — это единое виртуальное пространство, сформированное на базе разделов жестких дисков и, возможно, больших файлов, емкость которых объединяется.

                  Основная идея, которая закладывалась в нумерацию состоит в том, чтобы гарантировать, что данные идут последовательно и никто не менял порядок их следования. Ведь это, как вы понимаете, может существенно изменить расклад событий при рассмотрении спорных вопросов на суде:)
                    0
                    Ну можно и не сбрасывать, согласен. Но остальные вопросы — про ссылку на предыдущий файл и переполнение счётчика — остаются открытыми. Более того, если не сбрасывать счётчик при начале нового файла, то переполнение становится более вероятным.
                      +2
                      1. Если есть понятие «файла», то логично, во первых, каждый файл начинать с опорного кадра, во вторых, не вижу ничего плохого в том, чтобы для каждого нового файла начинать нумерацию заново.
                      2. Переполнение счетчика — это совершенно нормальная ситуация. Главное, чтобы считывающая подсистема понимала, что MAX_ULONGLONG+1 равно 0.
              • НЛО прилетело и опубликовало эту надпись здесь
                  +1
                  А что есть «случайное и преднамеренного искажения»?

                  Тут никакого подвоха нет:)
                  Случайное искажение — искажение, вызванное какими-то внешними причинами или неаккуратными действиями пользователя. Как правило случайные искажения возникают в случае частичного выхода из строя НДЖМ (появления плохих секторов и проч.).
                  Преднамеренное искажение — искажение, вызванное злонамеренными действиями.

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

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

                  Еще в стандарте нет упоминания про геоданные (GPS/ГЛОНАС).

                  Спасибо за идею, учтем!
                  • НЛО прилетело и опубликовало эту надпись здесь
                      +1
                      Для удобства просмотра в суде с вашей системы будут снимать видеоматериал компетентные органы, в распоряжении которых будет весь архив и они смогут убедиться, что он подлинный.
                      Обратите внимание, что стандарт гарантирует подлинность архива внутри системы видеонаблюдения, а не подлинность экспортированных из нее фрагментов.
                      • НЛО прилетело и опубликовало эту надпись здесь
                          +1
                          Они смогут убедиться, что её не подменили без нашего ведома. А так имея закрытый ключ мы можем записать что угодно. Грубо говоря, подписанная ЭЦП запись эквивалентна запечатанному пакету с видеокассетой, с подписью на нем «всё что снято на этой кассете подтверждаю». Это если не иметь в виду ситуации, когда закрытый ключ владельцу системы неизвестен.
                    0
                    Это все здорово, дело нужное, вот только после ввода этого ГОСТа скорее всего обычные записи с доступных камер наблюдения просто перестанут принимать в суде. Будут требовать записей с сертифицированных ФСБ устройств. И стоит такие железячки будут на порядок больше обычных систем.
                      0
                      Вот уже несколько лет ГОСТы в нашей стране носят рекомендательный характер. Чтобы обязать суды принимать в качестве доказательства только видео с сертифицированных систем нужно выстроить еще сложную систему нормативных актов. Эта бюрократия выходит за рамки (лично наших) технических компетенций.

                      В любом случае считаю, что сертификация пойдет только на пользу оздоровлению нашей судебной системы. Я лично буду чувствовать себя более защищенным, понимая, что нельзя просто так схватить на улице, а потом «снять видео», на котором я типа сделал что-то противозаконное, но и лицо не очень видно, да и время съемки вызывает сомнения.
                        0
                        А что мешает «просто так схватить на улице, а потом «снять видео», на котором я типа сделал что-то противозаконное» на сертифицированную ФСБ камеру с ЭЦП? Разве по ГОСТу она 4К разрешением и обладает идеальной четкостью в любых условиях? Вон на Дурова наснимали, хватило чтоб сбежал бедняга.
                          +2
                          В любом случае считаю, что сертификация пойдет только на пользу оздоровлению нашей судебной системы.


                          Обязательная сертификация методик и средств, применяемых для получения доказательств, – зло. Рано или поздно это приведет к тому, что данные с сертифицированного устройства будут считаться достаточно достоверными и не будут дополнительно проверяться из-за самого факта наличия сертификата, а для опровержения доказательств обвинения, полученных с использованием сертифицированных средств, стороне защиты нужно будет привлечь специалиста, у которого имеется не менее сертифицированное средство. А такой специалист будет работать… в государственных судебно-экспертных учреждениях, поскольку негосударственным организациям возиться с сертификацией криминалистической техники не очень и нужно (а по закону такой работник государственного судебно-экспертного учреждения не может выполнять поручения не от руководства, т. е. по факту он не сможет участвовать в уголовных делах по инициативе стороны защиты).

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

                          Я лично буду чувствовать себя более защищенным, понимая, что нельзя просто так схватить на улице, а потом «снять видео», на котором я типа сделал что-то противозаконное, но и лицо не очень видно, да и время съемки вызывает сомнения.


                          Поэтому для защиты от таких вот ситуаций нужно отменять любые аттестации, сертификации и любое лицензирование, чтобы у стороны защиты была возможность привлечь специалиста по своей инициативе, а такому специалисту не заявили отвод по формальному основанию. Таким образом, убедительность доказательства будет подтверждаться не бумажкой (сертификатом), а результатами исследования этого доказательства специалистом.
                        +2
                        Просто орфография. «Видеоконтейнер» слитно.
                          +2
                          Далее. «1. Строка битов, являющаяся подписью…»
                            0
                            +1, хорошо, что прочитал комментарии перед нажатием кнопки «Написать» :-)

                            Дополнительно: хеш-функция, хеширование и т. д. Пруфлинк.
                              0
                              UTC время


                              Избыточное обозначение: «Всемирное координированное время время». Можно написать просто: UTC.
                        • НЛО прилетело и опубликовало эту надпись здесь
                            0
                            Собственно и для этого можно частично использовать. Если вы вашу запись защитили подобным образом, а потом её «отфотошопили» недоброжелатели, то можно доказать что это фейк. Если вашей ЭЦП доверяют.
                            • НЛО прилетело и опубликовало эту надпись здесь
                                +1
                                А, в этом плане — нет, это совершенно другая задача, можно сказать противоположная. Для контакта мы изменяем оригинал, чтобы его не опознали, а тут мы защищаем оригинал, чтобы быть уверенным, что его не изменили. Вашу задачу решать можно методами стеганографии.

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

                          Самое читаемое