Комментарии 38
Как я понимаю, это требования к форматам контейнеров, на основании соответствия которым можно будет делать вывод о защите видеоданных в контейнере по уровню I или уровню II.
У меня есть такие вопросы:
1. Некоторые IP-камеры вместе с видео передают еще и аудио. Почему в стандарте не предусмотрена возможность защищать от случайных или намеренных искажений еще и аудио?
2. Существуют ли стандартизованные на сей день контейнеры, в которые требуемую согласно уровню I электронную подпись можно поместить уже сейчас без поломки читающего их ПО? [подозреваю, что в MPEG-TS будет достаточно отдельного PID'а]
3. Определение опорного кадра в стандарте отличается от общепринятого — так и задумано? Существенное изменение картинки вовсе не обязательно. Некоторые камеры расставляют опорные кадры (в понимании стандарта H.264) просто периодически. IMHO, если такое отличие не задумано, лучше будет делегировать определение опорного кадра стандарту на используемый видеокодек.
4. «Номер последнего опорного кадра для сжатых кадров» — что туда полагается писать, если речь идет о потоке без опорных кадров (H.264 такое допускает — ошибки «самозалечиваются» при декодировании с любого кадра)? Или следует признать, что такие потоки не могут быть защищены по уровню защиты I?
5. «Источники видеоинформации должны иметь техническую защиту, исключающую возможность съема и/или подмены закрытого ключа» — правильно ли я понимаю, что я не должен иметь возможность его перегенерировать (заменить на новый случайный, неизвестный мне), даже зная пароль для настройки?
6. Почему стандарт не предусматривает техническую защиту от несанкционированного изменения показаний часов?
У меня есть такие вопросы:
1. Некоторые IP-камеры вместе с видео передают еще и аудио. Почему в стандарте не предусмотрена возможность защищать от случайных или намеренных искажений еще и аудио?
2. Существуют ли стандартизованные на сей день контейнеры, в которые требуемую согласно уровню I электронную подпись можно поместить уже сейчас без поломки читающего их ПО? [подозреваю, что в MPEG-TS будет достаточно отдельного PID'а]
3. Определение опорного кадра в стандарте отличается от общепринятого — так и задумано? Существенное изменение картинки вовсе не обязательно. Некоторые камеры расставляют опорные кадры (в понимании стандарта H.264) просто периодически. IMHO, если такое отличие не задумано, лучше будет делегировать определение опорного кадра стандарту на используемый видеокодек.
4. «Номер последнего опорного кадра для сжатых кадров» — что туда полагается писать, если речь идет о потоке без опорных кадров (H.264 такое допускает — ошибки «самозалечиваются» при декодировании с любого кадра)? Или следует признать, что такие потоки не могут быть защищены по уровню защиты I?
5. «Источники видеоинформации должны иметь техническую защиту, исключающую возможность съема и/или подмены закрытого ключа» — правильно ли я понимаю, что я не должен иметь возможность его перегенерировать (заменить на новый случайный, неизвестный мне), даже зная пароль для настройки?
6. Почему стандарт не предусматривает техническую защиту от несанкционированного изменения показаний часов?
+1
1. Некоторые IP-камеры вместе с видео передают еще и аудио. Почему в стандарте не предусмотрена возможность защищать от случайных или намеренных искажений еще и аудио?
+1, тем более, что описанные механизмы защиты оперируют зажатыми блоками любых данных, а следовательно без потери общности можно рассматривать и видеоданные, и аудиоданные, и даже потоки метаинформации.
2. Существуют ли стандартизованные на сей день контейнеры, в которые требуемую согласно уровню I электронную подпись можно поместить уже сейчас без поломки читающего их ПО? [подозреваю, что в MPEG-TS будет достаточно отдельного PID'а]
Вопрос интересный, но исключительно с академической точки зрения. Стандарт применяется прежде всего к внутренним хранилищам информации (архивам), а там, как правило специализированные форматы, где без труда можно предусмотреть место для метаинформации, коей является вся дополнительная информация, определенная данным стандартом.
3. Определение опорного кадра в стандарте отличается от общепринятого — так и задумано? Существенное изменение картинки вовсе не обязательно. Некоторые камеры расставляют опорные кадры (в понимании стандарта H.264) просто периодически. IMHO, если такое отличие не задумано, лучше будет делегировать определение опорного кадра стандарту на используемый видеокодек.
Никакого скрытого смысла нет, поэтому предложите Ваше определение, обсудим здесь и включим в следующую редакцию.
4. «Номер последнего опорного кадра для сжатых кадров» — что туда полагается писать, если речь идет о потоке без опорных кадров (H.264 такое допускает — ошибки «самозалечиваются» при декодировании с любого кадра)? Или следует признать, что такие потоки не могут быть защищены по уровню защиты I?
Ситуация, когда все кадры опорные, допустима и даже является обычным делом в случае использования, например, MJPEG. В таком случае номер последнего опорного кадра будет равен просто номеру текущего блока и никаких препятствий для сертификации по уровню защиты I нет.
5. «Источники видеоинформации должны иметь техническую защиту, исключающую возможность съема и/или подмены закрытого ключа» — правильно ли я понимаю, что я не должен иметь возможность его перегенерировать (заменить на новый случайный, неизвестный мне), даже зная пароль для настройки?
Не совсем так. Здесь имеется в виду лишь то, что управление ключами — это особая процедура, а защита ключей крайне важна, т.к. любые несанкционированные действия в отношении них ставят под угрозу все другие принятые меры. Порядок управления ключами должен регламентировать отдельными документами, возможно ведомственными. Например, для критически важных категорированных объектов к процедуре смены ключей допускается только персонал службы безопасности или I отдела, а для обычных коммерческих объектов — это может делать специалист службы безопасности или IT.
6. Почему стандарт не предусматривает техническую защиту от несанкционированного изменения показаний часов?
Здравое зерно тут есть, но пока не очень понимаю, что и как прописать. Смена системного времени действительно может оказаться угрозой. Нужна ли аппаратная защита или достаточно просто фиксации факта смены времени — вопрос открытый для обсуждения.
+2
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. Тогда при использовании ключевых кадров можно его смело выставлять и подписывать.
0
Как я уже говорил, вопрос ухудшения качества изображений из-за компрессии-декомпрессии мы рассмотрели в ГОСТ Р 54830-2011 Системы охранные телевизионные. Компрессия оцифрованных видеоданных. Общие технические требования и методы оценки алгоритмов.
+1
Ну тогда это вообще замечательно! Достаточно потребовать, чтобы ухудшение качества изображения на кадрах, попадающих в защищаемую группу, при декодировании, начиная с указанного кадра, укладывалось в таблицу 1 из этого ГОСТа, согласно заявленному классу кодека по этому же ГОСТу. Для систем, использующих ключевые кадры в смысле «возможность декодирования его и всех последующих», это требование выполняется тривиальным образом, если указать непосредственно предшествующий ключевой кадр. А для систем без ключевых кадров получено полезное обобщение.
+1
Нужна ли аппаратная защита или достаточно просто фиксации факта смены времени — вопрос открытый для обсуждения.
Думаю, тут уместен такой же подход, как и к смене ключа, который Вы уже описали, отвечая на пункт 5.
+1
А зачем вообще такая защита нужна? Для уверенности владельца, что никто не искажает информацию или чтобы эта информация могла быть реальным доказательством в суде?
А какое время должно быть? Универсальное или локальное?
А вообще хорошая инициатива, молодцы!
5.5.1.2 Информации о времени передачи должна содержать:
а) время (часы, минуты)
б) дата (день, месяц, год)
в) разницу между UTC и локальным временем
А какое время должно быть? Универсальное или локальное?
А вообще хорошая инициатива, молодцы!
0
Предполагается, что системы видеонаблюдения, сертифицированные на соответствие данному стандарту, будут записывать видеоматериалы, пригодные для применения в качестве доказательной базы в суде. Однако, соответствие данному стандарту является необходимым, но не обязательным условием. Помимо подлинности данных важным аспектом также является качество этих данных, т.к. достаточность этого качества для того, чтобы идентифицировать объекты (людей и проч.) на видеоматериалах. Такой стандарт был также нами разработан и введен в 2012 году.
Внутри системы используется как правило локальное время.
А какое время должно быть? Универсальное или локальное?
Внутри системы используется как правило локальное время.
+1
5.5.1.1 Требования к нумерации группы кадров:
а) Группы кадров должны нумероваться последовательно по возрастанию.
б) Нумерация должна начинаться с 1.
в) Шаг нумерации равен 1.
Где начало нумерации?
Предположим, у меня отдельно камера и отдельно регистратор, который пишет видео на SD-карту и при этом добавляет подпись. Каждый час он создает новый файл. Вопрос — при этом номер группы кадров сбрасывается?
0
Думаю, да, ибо защита привязывается к файлу, а не к потоку в целом. То есть, кто пишет файл, тот и определяет нумерацию — в вашем случае регистратор. Но в целом вопрос вполне логичный — во-первых, необходим механизм ссылки на предыдущий файл, для возможности защищённой склейки. А во-вторых, чисто теоретически может возникнуть видеофайл с переполнением счётчика кадров — и эту ситуацию тоже надо обрабатывать.
+1
А я думаю, что начало нумерации не имеет значения. Например, в наших системах видеонаблюдения мы используем собственное хранилище для потоковых данных, которое вообще не предполагает наличие файлов — это единое виртуальное пространство, сформированное на базе разделов жестких дисков и, возможно, больших файлов, емкость которых объединяется.
Основная идея, которая закладывалась в нумерацию состоит в том, чтобы гарантировать, что данные идут последовательно и никто не менял порядок их следования. Ведь это, как вы понимаете, может существенно изменить расклад событий при рассмотрении спорных вопросов на суде:)
Основная идея, которая закладывалась в нумерацию состоит в том, чтобы гарантировать, что данные идут последовательно и никто не менял порядок их следования. Ведь это, как вы понимаете, может существенно изменить расклад событий при рассмотрении спорных вопросов на суде:)
+1
Ну можно и не сбрасывать, согласен. Но остальные вопросы — про ссылку на предыдущий файл и переполнение счётчика — остаются открытыми. Более того, если не сбрасывать счётчик при начале нового файла, то переполнение становится более вероятным.
0
1. Если есть понятие «файла», то логично, во первых, каждый файл начинать с опорного кадра, во вторых, не вижу ничего плохого в том, чтобы для каждого нового файла начинать нумерацию заново.
2. Переполнение счетчика — это совершенно нормальная ситуация. Главное, чтобы считывающая подсистема понимала, что MAX_ULONGLONG+1 равно 0.
2. Переполнение счетчика — это совершенно нормальная ситуация. Главное, чтобы считывающая подсистема понимала, что MAX_ULONGLONG+1 равно 0.
+2
НЛО прилетело и опубликовало эту надпись здесь
А что есть «случайное и преднамеренного искажения»?
Тут никакого подвоха нет:)
Случайное искажение — искажение, вызванное какими-то внешними причинами или неаккуратными действиями пользователя. Как правило случайные искажения возникают в случае частичного выхода из строя НДЖМ (появления плохих секторов и проч.).
Преднамеренное искажение — искажение, вызванное злонамеренными действиями.
Например, есть ситуации когда на видео нельзя увидеть детали без предварительной обработки.
Этот вопрос выходит за рамки данного стандарта, но действительно является очень важным. В прошлом году нами был разработан и введен в действие приказом Росстандарта ГОСТ по компрессии оцифрованных видеоданных, который как раз вводит метрики для оценки качества изображений с точки зрения возможности их последующего использования в целях криминалистических исследований.
Еще в стандарте нет упоминания про геоданные (GPS/ГЛОНАС).
Спасибо за идею, учтем!
+1
НЛО прилетело и опубликовало эту надпись здесь
Для удобства просмотра в суде с вашей системы будут снимать видеоматериал компетентные органы, в распоряжении которых будет весь архив и они смогут убедиться, что он подлинный.
Обратите внимание, что стандарт гарантирует подлинность архива внутри системы видеонаблюдения, а не подлинность экспортированных из нее фрагментов.
Обратите внимание, что стандарт гарантирует подлинность архива внутри системы видеонаблюдения, а не подлинность экспортированных из нее фрагментов.
+1
НЛО прилетело и опубликовало эту надпись здесь
Они смогут убедиться, что её не подменили без нашего ведома. А так имея закрытый ключ мы можем записать что угодно. Грубо говоря, подписанная ЭЦП запись эквивалентна запечатанному пакету с видеокассетой, с подписью на нем «всё что снято на этой кассете подтверждаю». Это если не иметь в виду ситуации, когда закрытый ключ владельцу системы неизвестен.
+1
Это все здорово, дело нужное, вот только после ввода этого ГОСТа скорее всего обычные записи с доступных камер наблюдения просто перестанут принимать в суде. Будут требовать записей с сертифицированных ФСБ устройств. И стоит такие железячки будут на порядок больше обычных систем.
0
Вот уже несколько лет ГОСТы в нашей стране носят рекомендательный характер. Чтобы обязать суды принимать в качестве доказательства только видео с сертифицированных систем нужно выстроить еще сложную систему нормативных актов. Эта бюрократия выходит за рамки (лично наших) технических компетенций.
В любом случае считаю, что сертификация пойдет только на пользу оздоровлению нашей судебной системы. Я лично буду чувствовать себя более защищенным, понимая, что нельзя просто так схватить на улице, а потом «снять видео», на котором я типа сделал что-то противозаконное, но и лицо не очень видно, да и время съемки вызывает сомнения.
В любом случае считаю, что сертификация пойдет только на пользу оздоровлению нашей судебной системы. Я лично буду чувствовать себя более защищенным, понимая, что нельзя просто так схватить на улице, а потом «снять видео», на котором я типа сделал что-то противозаконное, но и лицо не очень видно, да и время съемки вызывает сомнения.
0
А что мешает «просто так схватить на улице, а потом «снять видео», на котором я типа сделал что-то противозаконное» на сертифицированную ФСБ камеру с ЭЦП? Разве по ГОСТу она 4К разрешением и обладает идеальной четкостью в любых условиях? Вон на Дурова наснимали, хватило чтоб сбежал бедняга.
0
В любом случае считаю, что сертификация пойдет только на пользу оздоровлению нашей судебной системы.
Обязательная сертификация методик и средств, применяемых для получения доказательств, – зло. Рано или поздно это приведет к тому, что данные с сертифицированного устройства будут считаться достаточно достоверными и не будут дополнительно проверяться из-за самого факта наличия сертификата, а для опровержения доказательств обвинения, полученных с использованием сертифицированных средств, стороне защиты нужно будет привлечь специалиста, у которого имеется не менее сертифицированное средство. А такой специалист будет работать… в государственных судебно-экспертных учреждениях, поскольку негосударственным организациям возиться с сертификацией криминалистической техники не очень и нужно (а по закону такой работник государственного судебно-экспертного учреждения не может выполнять поручения не от руководства, т. е. по факту он не сможет участвовать в уголовных делах по инициативе стороны защиты).
Во всех странах, где была прямо или косвенно введена сертификация криминалистической техники, негосударственная судебно-экспертная деятельность умерла.
Я лично буду чувствовать себя более защищенным, понимая, что нельзя просто так схватить на улице, а потом «снять видео», на котором я типа сделал что-то противозаконное, но и лицо не очень видно, да и время съемки вызывает сомнения.
Поэтому для защиты от таких вот ситуаций нужно отменять любые аттестации, сертификации и любое лицензирование, чтобы у стороны защиты была возможность привлечь специалиста по своей инициативе, а такому специалисту не заявили отвод по формальному основанию. Таким образом, убедительность доказательства будет подтверждаться не бумажкой (сертификатом), а результатами исследования этого доказательства специалистом.
+2
Просто орфография. «Видеоконтейнер» слитно.
+2
НЛО прилетело и опубликовало эту надпись здесь
Собственно и для этого можно частично использовать. Если вы вашу запись защитили подобным образом, а потом её «отфотошопили» недоброжелатели, то можно доказать что это фейк. Если вашей ЭЦП доверяют.
0
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Общественное обсуждение проекта ГОСТ по защите оцифрованных видеоданных от случайного и преднамеренного искажения