Кратко

  • RFC 5159 опубликован в марте 2008 года как Informational RFC и зарегистрировал четыре атрибута SDP из OMA BCAST.
  • stkmstream связывал защищённое медиа с потоками Short Term Key Messages, которые следовало обрабатывать терминалу.
  • Значение на уровне медиа заменяло список уровня сессии, поэтому эффективное состояние зависело от области действия.
  • Обновление или удаление связи не показывало, какую старую версию уже применили ранее подключённые устройства.
  • Правильная ссылка на поток не подтверждала доставку ключа, право доступа, установку состояния, расшифрование или воспроизведение.
  • Номер потока был уникален лишь внутри одной SDP-сессии и не служил долговечной идентичностью.
  • bcastversion объявлял версию, но незащищённое значение могло использоваться для понижения возможностей.
  • SRTPAuthentication выбирал RCCm1, RCCm2 или RCCm3, а не выдавал результат проверки пакета.
  • SRTPROCTxRate задавал частоту передачи rollover counter со значением по умолчанию один.
  • Объявленный график не доказывал своевременное аутентифицированное получение ROC и синхронность сторон.
  • IETF и IANA зарегистрировали имена, тогда как контроль изменения их смысла остался у OMA.
  • Для реконструкции нужны версии описания, подтверждения устройств и отдельные результаты каждого криптографического перехода.

Конфигурация «сейчас» не отвечала на вопрос «что было тогда»

В широковещательной системе описание сессии могло меняться вместе с программой, способом защиты или составом потоков. stkmstream сообщал терминалу, где искать Short Term Key Messages для выбранного медиа. Если сервис переносил сообщения с потока 2 на поток 6, новая SDP могла выразить переход однозначно.

Однако публикация новой версии не стирала распространённые копии старой. Одни устройства могли обновиться сразу, другие — продолжать работать с кэшем, третьи — получить документ, но не применить его. Удаление старой связи на сервере также не подтверждало, что ни один клиент её больше не использовал.

Когда расследование смотрит только на текущую конфигурацию, оно приписывает прошлым пакетам будущую карту. Текущий stkmstream=6 не доказывает, что терминал в момент сбоя слушал шестой поток. Для ответа нужны точная версия SDP на устройстве, время получения, результат проверки целостности, вычисленная область действия и решение о подписке.

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

Переопределение создавало разные эффективные карты

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

Представим общий список из потоков 1 и 2, а у аудио — локальное значение 4. Терминал, соблюдающий правило, применит к аудио только 4. Аналитика, объединившая строки, покажет 1, 2 и 4. Архив, сохранивший только общий уровень, вообще не увидит 4. Все три системы прочитали один документ, но только первая получила эффективное состояние.

Для реконструкции следует сохранять исходную структуру и результат разрешения отдельно. Исходник позволяет проверить интерпретацию; результат показывает принятое программой решение. Один без другого не объясняет поведение.

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

Ссылка не переносила ключ через границы

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

После выбора поток должен был доставить пакеты. Сообщение должно было пройти проверки. Устройство или пользователь должны были иметь право развернуть материал. Полученный ключ следовало установить в правильный контекст. Затем SRTP должен был аутентифицироваться и расшифроваться, а приложение — воспроизвести результат.

Любая граница могла остановить цепочку, не делая SDP синтаксически неверной. Поэтому метрика «ключевой поток присутствует» не является метрикой доступности. Она показывает подготовленность карты, а не завершённость пути.

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

Объявленная криптография не была живым состоянием

SRTPAuthentication связывал числовые значения с RCCm1, RCCm2 и RCCm3. Такой выбор согласовывал ожидаемую процедуру, но конкретный пакет получал вердикт лишь после обработки с нужным ключом, счётчиком и состоянием последовательности.

SRTPROCTxRate объявлял частоту передачи rollover counter от 1 до 65535; при отсутствии значения использовалась единица. ROC расширяет короткое пространство номеров последовательности. Если приёмник пропустил или отверг важное обновление, его состояние могло разойтись с отправителем при полностью одинаковых статических параметрах.

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

Строка версии могла изменить защиту

bcastversion обозначал версию BCAST. В разделе безопасности RFC предупреждал: если значение не защищено целостностью, его можно подменить старой версией и вызвать downgrade. Строка не содержала секрет, но управляла выбором поведения.

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

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

Имя и его смысл имели разных хранителей

RFC 5159 имел статус Informational, поскольку технология происходила из Open Mobile Alliance. IETF и IANA обеспечили устойчивые имена в пространстве SDP, а OMA сохранила контроль над изменением интерпретации. Запись в реестре предотвращала коллизии, но не сертифицировала реализацию.

Позднейшая классификация мультиплексирования пометила bcastversion и stkmstream как NORMAL, а категорию двух SRTP-атрибутов оставила неопределённой. Это указание для копирования между сгруппированными медиаразделами, не оценка безопасности и не доказательство внедрения.

Упоминание предполагаемого применения с 3GPP MBMS, 3GPP2 BCMCS и DVB-H описывало контекст разработки 2008 года. Оно не доказывает эксплуатацию конкретным оператором. Развёртывание подтверждают эксплуатационные артефакты, а воспроизведение — результат на конечном устройстве.

Источники

  1. RFC 5159, HTML
  2. RFC 5159, текст
  3. Карточка RFC Editor
  4. Карточка IETF Datatracker
  5. История RFC 5159
  6. Ссылки RFC 5159
  7. Исправления RFC 5159
  8. RFC 4566
  9. RFC 8866
  10. RFC 4771
  11. RFC 3711
  12. RFC 8859
  13. RFC 5761
  14. RFC 7201
  15. RFC 5764
  16. RFC 8126
  17. Параметры SDP IANA
  18. Раскрытие IPR 2092
  19. RFC 2119
  20. RFC 8174
  21. RFC 3264
  22. Минимальная начальная спецификация
  23. О слоях реальности
  24. Приоритет работающего кода