DVB. Часть 17. Шифрование

[dil]

Остальные части

Ну вот мы и подошли к главному вопросу современности.

Краткий ответ: нет, нельзя :)

Подробный ответ: общего способа расшифровать и посмотреть произвольную зашифрованную DVB-программу не существует.

Точнее сказать, сейчас не существует. Вычислительная техника развивается довольно быстро, и то, что во времена принятия стандартов DVB считалось практически нереализуемым, сегодня уже вполне реально. Так, например, ключи от DES при наличии открытого и шифрованного текста находятся перебором за несколько часов. Конечно, на специально заточенном для этого оборудовании, но стОит оно сравнительно мало и доступно, в общем-то, любому желающему.

Я не удивлюсь, если в будущем будет изобретён способ расшифровывать любую программу. Но на сегодня, повторяю, такого способа нет. Так что если вам будут предлагать, скажем, "универсальную карточку НТВ+, которая открывает все программы и будет работать всегда" - это однозначный развод. Кстати, и просто клонированная карточка НТВ+ - это на сегодняшний день тоже миф.

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



Я буду излагать детали шифрования снизу вверх - от шифрования TS-пакетов к методам доставки ключей.

Применительно к шифрованию контента (то есть, аудио- и видеоданных) в DVB используется специальный термин - скремблирование (scrambling), который я и буду употреблять далее, чтобы отличить его от других разновидностей шифрования.

Стандартные служебные таблицы (кроме EIT) в соответствии с ISO 13818-1 должны передаваться в нескремблированном виде . К приватным (не определённым в стандартах) таблицам это не относится, но на практике они также передаются нескремблированными. Конечно, в самих передаваемых приватных данных шифрование применяться может.

Теоретически скремблирование данных может осуществляться на двух уровнях: в PES-пакетах и в TS-пакетах. Для этого в заголовках PES- и TS-пакетов стандартом предусмотрены специальные двухбитовые поля - PES_scrambling_control и transport_scrambling_control, соответственно. 0 в этом поле означает, что данные в пакете нескремблированные, остальные три значения и собственно методы скремблирования в ISO 13818-1 не определены. Скремблированию подвергаются только данные в теле пакетов, но не заголовки.

На практике, однако, в DVB скремблирование применяется только на уровне TS-пакетов. Более того, для скремблирования применяется один-единственный алгоритм - CSA (Common Scrambling Algorithm).

Алгоритм этот был разработан Европейским Институтом Телекоммуникационных стандартов (European Telecommunications Standards Institute, ETSI) и утверждён DVB-консорциумом. Алгоритм защищён патентами, поэтому микросхемы для аппратного дескремблирования производятся небольшим числом лицензированных производителей.

Долгое время в качестве дополнительного средства защиты от несанкционированного просмотра защищённых программ CSA держался в секрете, но примерно в 2002 году были окончательно выяснены его детали, и в интернете были опубликованы первые программные реализации. Впоследствии они были серьёзно доработаны, но в связи с существенным использованием побитовых операций на процессорах общего назначения эти реализации всё равно далеко не так эффективны, как на специализированных микросхемах. Дескремблирование пары потоков от одной программы в реальном времени требует примерно 800-мегагерцового Pentium'а III.

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

Формально в CSA ключи 64-битовые, но фактически значащими там являются только 48 битов. Четвертый и восьмой октеты всегда являются арифметическими суммами трёх предшествующих октетов (с отбрасыванием переполнения). С чем связано такое явное ослабление криптостойкости, мне неизвестно. Возможно, это такая зачаточная контрольная сумма.

Шифрование каждого отдельного TS-пакета осуществляется независимо от других, что позволяет приёмнику начать дешифрование с произвольного пакета, и соответственно, воспроизведение программы - с ближайшего PES-пакета в потоке.

Итак, чтобы посмотреть зашифрованную программу, необходимо дескремблировать потоки от неё. В ресивере для этого используется аппаратный дескремблер, на компьютере он может быть аппаратным или программным, но в любом случае ему нужно указать:
а) какие потоки дескремблировать (номера их PID'ов, определяемые приёмником из Program Map Table от текущей программы)
б) ключ дескремблирования, обычно называемый CW (control word, управляющее слово).

CW обычно меняются раз в 5-10 секунд (хотя бывают и исключения), что делает их подбор совершенно неэффективным методом несанкционированного просмотра шифрованных программ.

Чтобы обеспечить смену ключей на ходу, без перерывов в дешифровании, в дескремблере может одновременно находиться два ключа, так называемые чётный (even) и нечётный (odd). Каким из этих двух ключей надо дескремблировать очередной TS-пакет, определяется по значению вышеописанного поля transport_scrambling_control. 2 означает, что пакет заскремблирован чётным ключом, 3 - что нечётным.

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

После дескремблирования тела пакета соответствующим ключом поле в заголовке заменяется на 0, и пакет вставляется обратно в поток. Пакет, у которого поле transport_scrambling_control равно 0, считается незашифрованным и дескремблером никак не обрабатывается и не изменяется. Это позволяет пропускать транспортный поток последовательно через несколько дескремблеров, и если один из них расшифрует некоторый пакет, то дальше этот пакет изменяться не будет.

О том, откуда берутся CW и как они попадают в дескремблер, в следующем выпуске.

Comments

[to-the-future.livejournal.com]

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

[dil.livejournal.com]

тут есть одно но. в общем случае отсутствует канал обратной связи, поэтому с сеансами напряжёнка.

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

[to-the-future.livejournal.com]

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

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

[to-the-future.livejournal.com]

Все это не решает проблемы кей-шаринга. Ее можно решить единственным способом: засунув в карту вообще всю криптографию. То есть карточка должна уметь расшифровывать вообще весь видеопоток и никуда наружу ключ не выдавать.

Думаю, это дело ближайших нескольких лет.

[to-the-future.livejournal.com]

PS: Если за эти несколько лет спутниковое телевидение не перейдет полностью на IP, конечно.

[dil.livejournal.com]

увы, это нарушает стройную идеологию стандарта Common Interface :)
засовывание всей криптографии в CAM-модули уже имеет место быть, но плохо помогает, потому что их вскрывать на несколько порядков проще, чем смарт-карты. а у самих карт на расшифровку потока не хватает пропускной способности, там фактически последовательный порт на несколько тысяч бит/с.

[to-the-future.livejournal.com]

Я так понимаю, ключ вылавливается в коммуникации между картой и CAM?

[dil.livejournal.com]

который CW - да, там. CAM вылавливает из потока ECM-сообщения, содержащие зашифрованные CW, и передаёт их в карту, карта их расшифровывает и отдаёт обратно в CAM. CAM засовывает их в дескремблер.

есть модули, которые картой не пользуются, а расшифровывают всё сами. но они легко вскрываются и из них программатором вычитывается флэш :) поэтому в основном всё-таки карты используются.

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

[jerom.livejournal.com]

А рассматривается ли серьёзно дешифрация в статике, когда, скажем, 2-3 часа потока у нас уже записаны и теперь есть неограниченное время их дешифровку?

[dil.livejournal.com]

Ну как.. Для подбора ключа при известном алгоритме нужен как минимум один экземпляр криптованного текста и соответствующего ему открытого. Вот с последним напряжёнка. CSA шифрует блоками по 8 байт. Иногда некоторые из них могут быть известны, но не все. Поэтому придётся проверять много вариантов ключа, дешифровать им, как минимум, несколько пакетов и смотреть, получилось ли что-то похожее на MPEG. А используется ключ обычно всего несколько секунд.
То есть, чисто теоретически это возможно, но очень уж медленно и печально.

Говорят, что некоторые ресиверы умеют разносить во времени запись и дескремблирование. То есть, они записывают скрэмблированный поток и вместе с ним соответствующий поток ECM. А потом показывают записанное, скармливая ECM в смарт-карту, получая из неё CW и дескремблируя ими поток. Ничего невозможного я в этом не вижу, но своими глазами не видел, поэтому не уверен, что оно действительно реализовано.

[lleri.livejournal.com]

>Формально в CSA ключи 64-битовые, но фактически значащими там являются только 48 битов. Четвертый и восьмой октеты всегда являются арифметическими суммами трёх предшествующих октетов (с отбрасыванием переполнения). С чем связано такое явное ослабление криптостойкости, мне неизвестно. Возможно, это такая зачаточная контрольная сумма.

Не знаю, связано ли это, но отдельные микросхемы декодирования вообще не обращают внимания на 4 и 8 байты.

[dil.livejournal.com]

как это вообще не обращают, если они используются в процессе декодирования?

[lleri.livejournal.com]

Для процесса дескремблирования они НЕ используются. Это действительно аналог контрольной суммы. Их использование зависит только от микросхемы дескремблирования - она может брать их во внимание или вычислять сама.