Пока по неподтверждённым данным неизвестные исследователи компьютерной безопасности смогли вскрыть (http://www.engadget.com/2010/09/14/hdcp-master-key-supposedl... мастер-ключ алгоритма HDCP (http://ru.wikipedia.org/wiki/HDCP), технологии защиты медиаконтента, разработанной корпорацией Intel и предназначенной для предотвращения незаконного копирования высококачественного видеосигнала, передаваемого через интерфейсы DVI, DisplayPort, HDMI, GVIF или UDI.
Этот ключ используется практически в каждом видеоформате для защиты передачи данных от источника к приёмнику. Данные шифруются используя ключ источника, обычно это проигрыватель BluRay или компьютер, а затем дешифруются приёмником, т.е. конечным устройством отображения (например, LCD телевизором). Защита, точнее технология DRM (digital restrictions management), должна по идее предотвращать незаконное создание копий цифрового контента.
Учитывая, что HDCP взломан, теперь более не требуется взламыв...URL: http://www.engadget.com/2010/09/14/hdcp-master-key-supposedl.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=27962
На каждый хитрый ДРМ найдется хак с винтом.
не-не, доломайте уж AACS пожалуйста, а то как же образы блю-рейные снимать!?
Что-то не спасает этот AACS копирасов от засилья рипов с пометкой BDRip. Видимо, AACS традиционно нагибает только пользователей пытающихся быть честными...
Интересно. Получается, что приёмник обязан содержать в себе мастер-ключ ?
Приемник должен содержать public key от мастера. Мастер ключ - это private key для зашифровки. Хотя ХЗ...
Вероятно, всякий кодированный поток с помощью public key можно раскодировать с помощью сопоставленного ему private key.
Ну не порите вы чуши-то, блин! Никто и никогда *данные* алгоритмами с открытыми ключами не шифрует. Это слишком затратно, и самое главное, нафиг не нужно.
а как будто хоть где-то что-то кроме паролей шифруют публичными ключами?
публичные ключи используют для передачи сессионого пароля а дальше всё синхронно...
Не путайте людей, в HDCP только симметричное шифрование. Там "private" используется в другом контексте, а защита ключей используется только за счет аппаратных возможностей (и того, что устройства должны показать, что они знают ключи, во время хэндшейка). Подробно протокол описан в педивикиях.
>Приемник должен содержать public key от мастера. Мастер ключ - это private
>key для зашифровки. Хотя ХЗ...Мастер-ключ — это та самая иголка в яйце, которой можно генерить device-private keys. Раньше все таскали ключи из конкретных устройств, их отзывали-обновляли, и война продолжалась. Это (если это он) - главный ключ ко всей криптосистеме, ее святая святых, на которой она держалась. Из него можно создавать новые device-private ключи, так что сколько не обновляй, сколько не запрещай - уже больше ничего сделать невозможно, в принципе.
Так они и его поменяют. Юзера, проклиная пиратов, будут шить свои девайсы. Сервис-центры будут завалены убитыми в хлам плеерами и теликами, причем юзерам их придется чинить из своего кармана. Пользователи дешевых девайсов в очередной раз соснут и, проклиная все на свете, потащат в СЦ на перепрошивку.Ушлые товарищи (во имя fair-use) выпустят прожку для "перекодирования" BD. Юзера ее будут покупать и сметать с магазинных полок "старые" блю-реи, чтобы посмотреть их "нахаляву". ИЧСХ число BD-образов в Сети не изменится, потому что их и так в достатке, а качать и хранить гигабайты хлама крайне накладно, даже с современными технологиями.
И как результат - все большее проникновение BD в мейнстрим. И кому это выгодно?
>Так они и его поменяют. Юзера, проклиная пиратов, будут шить свои девайсы.Вы, простите, понимаете, сколько это стоит - взять и сдать ВСЕ выпущеные устройства с HDCP назад в сервис-центры? И что платить за это будут не сервис-центры и производители (они, когда речь о таких-то деньгах, чихать хотели на половые проблемы MAFIAA с их сломавшимся DRMом), а те, кто о DRM печется. А для них такие деньги - смертный приговор, так что придется как обычно - хоронить старый бренд (HDCP), смирившись с тем, что эта схема DRM больше не работает, и много лет готовить рынок, выпуская новые устройства.
Вот и все. Ждем UltraHD, хаха.
> Интересно. Получается, что приёмник обязан содержать в себе мастер-ключ ?Ну, как уже сказали - не мастер, но - обязан.
Только вот так иногда бывает, что производитель лицензирует ключи лишь на некоторое время, а потом... Люди сталкиваются с тем, что на их устройствах новые диски не воспроизводятся.
А как диски относятся к HDCP? oO
а есть где нибудь описание практического применения этого ключа?
>>Данные шифруются используя ключ источника(BluRay-плэер, компьютер)
>>...
>>дешифруются приёмником, конечным устройством отображения (LCD телевизором)судя по всему в источниках зашит этот самый мастер-ключ(на заводе изготовителе, где штампуются диски), который шифрует контент. а паблик кей идет во всех остальных теликах и зашивается также на заводе. думается что утечка пошла от тайваньского инженера, обиженого сентябрьской премией)))
>судя по всему в источниках зашит этот самый мастер-ключ(на заводе изготовителе, где
>штампуются диски)Не путайте HDCP и AACS.
HDCP *НЕ ЗАНИМАЕТСЯ* ШИФРОВАНИЕМ BLU-RAY ДИСКОВ.
Он занимается шифрованием данных между, условнов, видеокартой и монитором. Чтобы злой пират Флинт не мог врезаться в провод и воровать картинки. :)
И в видеокартах и мониторах нет master key, в них есть device-private keys (DPK). Master key есть только у DCP LLC - компании, которая реализовала HDCP и управляет им, хранится в сейфе и бла бла бла.
А обязаны мы, скорее всего, (если не фейк) каким-нибудь китайским криптографам, которые накоммуниздили много-много device-private keys и успешно решили ту самую систему из 40 линейных уравнений, на которой все держалось.
>Флинт не мог врезаться в провод и воровать картинки. :)Флинт в стену врежется когда поймет какой поток надо сгребать непрерывно. Даже если не заниматься его расшифровкой - куда столько счастья предлагается девать?! Простой винч загнется от такого потока! Предлагается сгородить крутое Ынтерпрайзное хранилище? Сдается мне что пираты уж давно придумали дюжину менее затратных способов :)
При перекодировании фильма из BluRay MPEG2 в H.264 картинка в начале должна быть декодирована и не надо никуда ничего сохранять - все прекрасно гоняется через pipe/fifo.Так что порите чушь, никуда декодированный поток в raw виде сохрянять не надо.
>Так что порите чушь,Зачем мне пороть чушь? Ей же будет больно! (если вы не поняли, вы опубликовали призыв к действию "пороть чушь" :P). Так что это... летайте самолетами Аэрофлота, во.
>никуда декодированный поток в raw виде сохрянять не надо.
Есть некоторая разница. В упомянутоам вами случае RAW вид живет только в памяти компьютера и как раз там оно проблем не представляет, память современного компьютера оперирует ГигаБайтами в секунду и как-нить такой поток осилит (тем более что при перекодировании реальное время не жмет и ни от кодировщика не требуется выжимать FPS равный FPSу мувика в реалтайме). А вот если у вас провод с HDMI и по нему валится несколько гигабитов декодированной картинки, в реальном времени - эти гигабиты надо куда-то складывать из этого провода, очевидно? И что-то с ними делать. При том скорость потока получается достаточно большой для того чтобы Average Joe забил на попытки выгрести столько дряни на свой винч или в реалтайме перекодировать столько данных. Ну то есть какиенить "профессиональные" пираты могли бы наверное и собрать себе хранилище из нескольких дисков, но сдается мне что они давно придумали 100500 более дешевых и практичных решений по части копипи...нга с блюрея и прочих. Так, сугубо глядя на результат поиска HD в TPB...
Неужели он не меняется динамически и не обмениваются им при начале работы? Если так - позор ынтели...
контент на диске уже записан в шифрованном виде, при изменении ключа, прочесть данные будет невозможно. имхо, если динамически менять ключ, придется хранить контент в открытом виде, и шифровать/дешифровать на лету при просмотре, что совсем уже бессмысленно.
>шифровать/дешифровать на лету при просмотре, что совсем уже бессмысленно.DRM совсем бессмысленно с самого начала. Если вы видите картинку - вы ее можете содрать зиллионом разных способов. А все эти фокусы копирасов мешают только честным юзерам, которые хотят без всякой задней мысли скажем слить фильму себе на комп чтобы не угробить дорогой и нежный диск ненароком. Вообще не собираясь распостранять чего-то. Те кто собирается распостранять - вываливают бдрип не снабженный AACSом вообще. Странно, да?
> Если вы видите картинку - вы ее можете содрать зиллионом разных способов.И потерять качество.
>И потерять качествоХолодное транзисторное изображение
>И потерять качество.Да ну, бросьте. Скажем можно выгребать цифру ... например где-то ОПОСЛЯ чипа занимающегося шифрованием. Пусть он там расшифровывает себе наздоровье, а нам при этом даже не надо знать как именно это делается. Шифрование то рано или поздно в схеме монитора заканчивается т.к. не подашь шифрованный сигнал на матрицу, хоть тресни. Значит при желании поток можно снять с монитора все-равно. А т.к. это цифра - качество ровно то которое декодировалось, пардон. DRM - это заведомо обман и надувательство. Оно столь же "нужно" и "естественно" как для телеги пятое колесо.
Вообще-то схемы обмена ключами, которая была бы устойчива к атаке типа man-in-the-middle не существует в природе. Поэтому, необходима некая секретная информация, которую злоумышленник не знает...А в данном конкретном случае нет даже необходимости генерации сессионных ключей, поскольку forward secrecy обеспечивать не нужно.
>Вообще-то схемы обмена ключами, которая была бы устойчива к атаке типа man-in-the-middle
>не существует в природе.ви таки ошибаииитись -- см. SRP
Ви таки порете чушь.
Я, конечно, полный профан в шифровании, но судя по википедии SRP - это для аутенификации. А в данном случае нужен протокол для передачи данных...
Так-так, а как же алгоритм Диффи-Хеллмана?
Насколько я знаю, он как раз и позволяет безопасно обмениваться данными по незащищённой сети при отсутствии общего секретного знания у сторон взаимодействия. И реализаций в оупен сорсе полно, в той же OpenSSL, например.
Вы издеваетесь что ли? D-H используют как каноничный пример, когда рассказывают что такое MitM.Да, там потом добавляли всякие хитрости, типа "распилить на две половинки", которые усложняют дело. Их тоже обходили все.
Что-то вы меня запутали и я хочу объяснений. Для шифрования с открытым ключом нужно только два открытых ключа в общедоступном месте, два не распространяемых секретных ключа и ни какой третий man-in-the-middle больше ничего не получит в открытом виде. Где я не прав?
>Где я не прав?
>только два открытых ключа в общедоступном местеВот здесь.
Откуда ты знаешь, что открытый ключ принадлежит именно "той" стороне?
А, ну да, по фингерпринту, переданному лично. Но в данном случае, похоже, что вообще дело обходится только одной парой ключей.
А откуда ты будешь знать, что это фингерпринт "той" стороны? Откуда ты будешь знать, что злоумышленник не подменил тебе открытый ключ "той" стороны?Вот поэтому, и вырастает иерархия резличных криптографических связей. И все-равно, вся эта иерерхия упиратеся в некий "корень доверия" aka root of trust. Т.е. вся безопасность на этом уровне обеспечивается мантрой: "мы этому состоянию системы безусловно доверяем". И если кто-то смог его похачить - вся наша хитрожопая иерерхия идет прахом. Что собственно и сделали в сабже.
Ситуация, приведенная тобой это и есть root of trust. Т.е. ты безусловно доверяешь другу, который при личной встрече передал тебе отпечаток открытого ключа. Но, если твой друг по раздолбайству или находясь под воздействием терморектального криптоанализа передал тебе отпечаток злоумышленника - вся криптосхема идет лесом. И проверить этот факт ты не можешь. Ты просто веришь.
Это уже бред не относящийся к практике. Так можно сказать что любая криптосхема уязвима для MiM потому что можно информацию прямо с мозга перехватывать. Публичные ключи просто должны быть подписаны - для этого signing party и устраивают.
Это не бред, и как-раз имеет непосредственное отношение к практике. К криптографии — да относится чуть менее чем никак.Кстати, поверь, ты крайне сильно пожалеешь, что подписал ключ человека, например, если его привлекут по 282-й статье. Т.е. как минимум, объяснительную давать будешь. А как максимум — пойдешь свидетелем... Это я к тому, что при подписании ключа, ты возлагаешь часть ответственности по обеспечению своей прайвеси и безопасности на другую сторону и добровольно даешь ей неограниченное право доказывать третьей стороне подлинность твоих сообщений. Вот такие дела.
В каком месте бред ? Может мне в Intel лично слетать за их Public ключем ?
>Вы издеваетесь что ли? D-H используют как каноничный пример, когда рассказывают что
>такое MitM.Не надо голословных утверждений.
Приведите "каноничный пример", в котором протоколу диффи-хеллмана плохеет от man-in-the-middle. Я этого представить не могу.
>>Вы издеваетесь что ли? D-H используют как каноничный пример, когда рассказывают что
>>такое MitM.
>
>Не надо голословных утверждений.
>Приведите "каноничный пример", в котором протоколу диффи-хеллмана плохеет от man-in-the-middle. Я этого
>представить не могу.На этапе установки соединения вы отсылаете собеседнику свой открытый ключ. Злоумышленник его перехватывает и отсылает вместо него свой. Далее перехватывает зашифрованную своим ключем переписку, расшифровывает, читает, шифрует вашим ключем и отправляет вам. Все счастливы. Чтобы противостоять этому и созданы доверенные центры сертификации, которые позволяют проверить, действительно ли открытый ключ соответствует его владельцу.
>На этапе установки соединения вы отсылаете собеседнику свой открытый ключ. Злоумышленник его
>перехватывает и отсылает вместо него свой. Далее перехватывает зашифрованную своим ключем
>переписку, расшифровывает, читает, шифрует вашим ключем и отправляет вам. Все счастливы.
>Чтобы противостоять этому и созданы доверенные центры сертификации, которые позволяют проверить,
>действительно ли открытый ключ соответствует его владельцу.AdVv,
Какой ещё "свой открытый ключ"? Мы же про алгоритм Диффи-Хеллмана говорим.
http://en.wikipedia.org/wiki/Diffie–Hellman_problem
http://en.wikipedia.org/wiki/Diffie-hellmanАлександр Чуранов
>[оверквотинг удален]
>>Чтобы противостоять этому и созданы доверенные центры сертификации, которые позволяют проверить,
>>действительно ли открытый ключ соответствует его владельцу.
>
>AdVv,
>
>Какой ещё "свой открытый ключ"? Мы же про алгоритм Диффи-Хеллмана говорим.
>http://en.wikipedia.org/wiki/Diffie–Hellman_problem
>http://en.wikipedia.org/wiki/Diffie-hellman
>
>Александр ЧурановДа да Александр, именно о нем.
http://ru.wikipedia.org/wiki/Diffie-Hellman
Раздел "Криптографическая стойкость"
Цитата:
Необходимо отметить, что алгоритм Диффи — Хеллмана работает только на линиях связи, надёжно защищённых от модификации. Если бы он был применим на любых открытых каналах, то давно снял бы проблему распространения ключей и, возможно, заменил собой всю асимметричную криптографию. Однако, в тех случаях, когда в канале возможна модификация данных, появляется возможность атаки человек посередине. Атакующий заменяет сообщения переговоров о ключе на свои собственные и таким образом получает два ключа — свой для каждого из законных участников протокола. Далее он может перешифровывать переписку между участниками, своим ключом для каждого, и таким образом ознакомиться с их сообщениями, оставаясь незамеченным.
>Да да Александр, именно о нем.
>http://ru.wikipedia.org/wiki/Diffie-Hellman
>Раздел "Криптографическая стойкость"Действительно для защиты от MiM используется предварительно известный секрет. Например, как в G.hn: http://en.wikipedia.org/wiki/X.1035
А называть сообщение в DH "открытыми ключом" - безобразие.
>алгоритм Диффи-Хеллмана?
>Насколько я знаю, он как раз и позволяет безопасно обмениваться данными по
>незащищённой сети при отсутствии общего секретного знания уА на википедии написано "двум сторонам получить общий секретный ключ, используя незащищенный от прослушивания, но защищённый от подмены, канал связи". О чём только они там у себя в википедиях думают?!---
Кто знает, а как тогда работают устройства захвата изображения по HDMI?
Например, скриншоты и видео из приставочных игр делают ведь.
... в связи с вышесказанным, я думал DHCP давно взломали. А тут такая новость.
т.е., ключ, как и в случае с css-dvd на носителе? если так, то выводов не делают... жадность моск вынесла... вероятно, инженеры, которым была заказана разработка защиты, пытались убедить их, что это не возможно, но заказчики сначала добавляли нолики в предложение, а потом паяльник показали. Инженеры предпочли не говорить, что именно с помощью этого не хитрого прибора можно взломать, потому что этот не хитрый инструмент может быть и для других целей использован... ну нет в этом мире абсолютной защиты... и наличие диплома (даже красного) тоже не является гарантом, что обладатель его - самый гениальный чувак в этой области...
А как же в свете этой новости до сих пор на торрентах раздавались всякие BD-Rip`ы и прочие ремуксы, если ключь до сих пор не был взломан?
Вообще-то, DRM - это digital _right_ management, а "restrictions" - это дразнилка, придуманная противниками этой технологии. Я их поддерживаю, но писать нужно все-таки правильно.
По сабжу - вот и славно, вот и хорошо. Может когда-нибудь поймут бессмысленность и вредность DRM.
>Вообще-то, DRM - это digital _right_ management1. "right_s_", тогда уж
2. War is peace, freedom is slavery, ignorance is strength, amirite?
>2. War is peace, freedom is slavery, ignorance is strength, amirite?Ой, поясню, а то еще шапками закидают, и обзовут красноглазым криптопионером и онанистом на Оруэлла.
Я про то, что как вы яхту для публики назовете - так публика и запомнит. Мы уже помним что "музыка - это mp3" (и публика очень тяжело понимает что-то другое). Почему? Приучили так.
Поэтому, как раз, лучше писать не так, как предлагают идеологи DRM - а то ведь, и правда, люди запомнят что это "права", а не "ограничения". Потом замучаетесь объяснять что никакими их правами там и не пахло.
По первому пункту соглашусь, а вот по второму - нет. Переиначивание аббревиатуры - фактическая ошибка. Нельзя смешивать дразнилки и официальное название, как бы вы не относились к этому явлению.
Алсо, я не за DRM, я за корректность информации в новостях :)
Официальное название придумали маркетологи. Чтобы надувать покупателей, обманывая их относительно фактической деятельности этой "фичи". Если г-но они назовут лепетсками роз для удобства впаривания - вы как будете его называть? Вот и здесь та же история.
>По первому пункту соглашусь, а вот по второму - нет. Переиначивание аббревиатуры
>- фактическая ошибка. Нельзя смешивать дразнилки и официальное название, как бы
>вы не относились к этому явлению.Можно. И нужно.
> По первому пункту соглашусь, а вот по второму - нет. Переиначивание аббревиатуры - фактическая ошибка. Нельзя смешивать дразнилки и официальное название, как бы вы не относились к этому явлению.Поддерживать пропаганду врага, используя им разработанный PR - вот ваша фактическая ошибка. Этот проблема гораздо важнее чем проблема переиначивания аббревиатуры (хотя учительница русского языка считает наоборот, она никогда не оплатит нам убытков от поддержки этой точки зрения).
Алсо, не надо называть правильное отображения сокращения DRM в реальность "дразнилкой". Это антипиар правильной идее.
Там просили отмирорить :)
http://pavlinux.ru/HDCP_MASTER_KEY.txt
>Там просили отмирорить :)
>http://pavlinux.ru/HDCP_MASTER_KEY.txtА также "абузоустойчивый" совсем уж отмиррореный линк (магнет-ссылка для торрента) который копирасам будет весьма проблематично снести (use DHT, Luke):
magnet:?xt=urn:btih:c9f66d675415da9a0c75352eaedb1a1fdaeecda5&dn=HDCP%20MASTER%20KEY&tr=http%3A%2F%2Ftracker.openbittorrent.com%2Fannounce
Торрент найден на http://bitsnoop.com/hdcp-master-key-q17177920.html и проверен. Файл соответствует тому что содержится в оригинале :)
>>Там просили отмирорить :)
>>http://pavlinux.ru/HDCP_MASTER_KEY.txt
>
>А также "абузоустойчивый" совсем уж отмиррореный линк (магнет-ссылка для торрента) который копирасам будет весьма проблематично снестиЛучший трекер это Гугле. :)
HDCP MASTER KEY - https://docs.google.com/Doc?docid=0ARFMDESDZ0qvZGdtNjRrOXZfN...
-------
Больше прикалоло,... типа спрятались.
To generate a sink key, do the same, but with the transposed matrix.Один из первых косяков у тех кто передаёт шифры, ключи, криптоданные в табличном HEX виде.
Значит есть матричные вычисления - транспонирование, обращение, повороты,
умножение на число, которое прошито у клиента или передаётся....
я честно хз, что с этим всем делать надо, но выложил в осле
поддерживаю, еще миррор:
http://suslika.net/HDCP_MASTER_KEY.txt