|
| 1.2, Анонимуз (?), 10:23, 15/09/2010 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
не-не, доломайте уж AACS пожалуйста, а то как же образы блю-рейные снимать!?
| | |
| |
| 2.35, User294 (ok), 14:26, 15/09/2010 [^] [^^] [^^^] [ответить]
| +3 +/– |
 Что-то не спасает этот AACS копирасов от засилья рипов с пометкой BDRip. Видимо, AACS традиционно нагибает только пользователей пытающихся быть честными...
| | |
|
| 1.3, ДяДя (?), 10:24, 15/09/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Интересно. Получается, что приёмник обязан содержать в себе мастер-ключ ?
| | |
| |
| 2.4, VoDA (ok), 10:53, 15/09/2010 [^] [^^] [^^^] [ответить]
| +/– |
 Приемник должен содержать public key от мастера. Мастер ключ - это private key для зашифровки. Хотя ХЗ...
| | |
| |
| 3.19, alexanderyt (??), 12:52, 15/09/2010 [^] [^^] [^^^] [ответить]
| +/– |
Вероятно, всякий кодированный поток с помощью public key можно раскодировать с помощью сопоставленного ему private key.
| | |
| |
| 4.22, Macil (?), 13:04, 15/09/2010 [^] [^^] [^^^] [ответить]
| +/– | |
Ну не порите вы чуши-то, блин! Никто и никогда *данные* алгоритмами с открытыми ключами не шифрует. Это слишком затратно, и самое главное, нафиг не нужно.
| | |
| |
| 5.56, ТТТ (?), 19:42, 16/09/2010 [^] [^^] [^^^] [ответить]
| +/– |
а как будто хоть где-то что-то кроме паролей шифруют публичными ключами?
публичные ключи используют для передачи сессионого пароля а дальше всё синхронно...
| | |
|
|
| 3.21, Аноним (-), 13:04, 15/09/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
Не путайте людей, в HDCP только симметричное шифрование. Там "private" используется в другом контексте, а защита ключей используется только за счет аппаратных возможностей (и того, что устройства должны показать, что они знают ключи, во время хэндшейка). Подробно протокол описан в педивикиях.
| | |
| 3.26, Аноним (-), 13:15, 15/09/2010 [^] [^^] [^^^] [ответить]
| +/– |
>Приемник должен содержать public key от мастера. Мастер ключ - это private
>key для зашифровки. Хотя ХЗ...
Мастер-ключ — это та самая иголка в яйце, которой можно генерить device-private keys. Раньше все таскали ключи из конкретных устройств, их отзывали-обновляли, и война продолжалась. Это (если это он) - главный ключ ко всей криптосистеме, ее святая святых, на которой она держалась. Из него можно создавать новые device-private ключи, так что сколько не обновляй, сколько не запрещай - уже больше ничего сделать невозможно, в принципе.
| | |
| |
| 4.30, Macil (?), 13:39, 15/09/2010 [^] [^^] [^^^] [ответить]
| +/– | |
Так они и его поменяют. Юзера, проклиная пиратов, будут шить свои девайсы. Сервис-центры будут завалены убитыми в хлам плеерами и теликами, причем юзерам их придется чинить из своего кармана. Пользователи дешевых девайсов в очередной раз соснут и, проклиная все на свете, потащат в СЦ на перепрошивку.
Ушлые товарищи (во имя fair-use) выпустят прожку для "перекодирования" BD. Юзера ее будут покупать и сметать с магазинных полок "старые" блю-реи, чтобы посмотреть их "нахаляву". ИЧСХ число BD-образов в Сети не изменится, потому что их и так в достатке, а качать и хранить гигабайты хлама крайне накладно, даже с современными технологиями.
И как результат - все большее проникновение BD в мейнстрим. И кому это выгодно?
| | |
| |
| 5.40, Аноним (-), 14:53, 15/09/2010 [^] [^^] [^^^] [ответить]
| +2 +/– | |
>Так они и его поменяют. Юзера, проклиная пиратов, будут шить свои девайсы.
Вы, простите, понимаете, сколько это стоит - взять и сдать ВСЕ выпущеные устройства с HDCP назад в сервис-центры? И что платить за это будут не сервис-центры и производители (они, когда речь о таких-то деньгах, чихать хотели на половые проблемы MAFIAA с их сломавшимся DRMом), а те, кто о DRM печется. А для них такие деньги - смертный приговор, так что придется как обычно - хоронить старый бренд (HDCP), смирившись с тем, что эта схема DRM больше не работает, и много лет готовить рынок, выпуская новые устройства.
Вот и все. Ждем UltraHD, хаха.
| | |
|
|
|
| 2.11, ABATAPA (ok), 11:37, 15/09/2010 [^] [^^] [^^^] [ответить]
| +/– |
 > Интересно. Получается, что приёмник обязан содержать в себе мастер-ключ ?
Ну, как уже сказали - не мастер, но - обязан.
Только вот так иногда бывает, что производитель лицензирует ключи лишь на некоторое время, а потом... Люди сталкиваются с тем, что на их устройствах новые диски не воспроизводятся.
| | |
|
| 1.6, i (??), 11:11, 15/09/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
а есть где нибудь описание практического применения этого ключа?
| | |
| 1.7, daevy (ok), 11:14, 15/09/2010 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
 >>Данные шифруются используя ключ источника(BluRay-плэер, компьютер)
>>...
>>дешифруются приёмником, конечным устройством отображения (LCD телевизором)
судя по всему в источниках зашит этот самый мастер-ключ(на заводе изготовителе, где штампуются диски), который шифрует контент. а паблик кей идет во всех остальных теликах и зашивается также на заводе. думается что утечка пошла от тайваньского инженера, обиженого сентябрьской премией)))
| | |
| |
| 2.27, Аноним (-), 13:22, 15/09/2010 [^] [^^] [^^^] [ответить]
| +3 +/– |
>судя по всему в источниках зашит этот самый мастер-ключ(на заводе изготовителе, где
>штампуются диски)
Не путайте HDCP и AACS.
HDCP *НЕ ЗАНИМАЕТСЯ* ШИФРОВАНИЕМ BLU-RAY ДИСКОВ.
Он занимается шифрованием данных между, условнов, видеокартой и монитором. Чтобы злой пират Флинт не мог врезаться в провод и воровать картинки. :)
И в видеокартах и мониторах нет master key, в них есть device-private keys (DPK). Master key есть только у DCP LLC - компании, которая реализовала HDCP и управляет им, хранится в сейфе и бла бла бла.
А обязаны мы, скорее всего, (если не фейк) каким-нибудь китайским криптографам, которые накоммуниздили много-много device-private keys и успешно решили ту самую систему из 40 линейных уравнений, на которой все держалось.
| | |
| |
| 3.36, User294 (ok), 14:30, 15/09/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>Флинт не мог врезаться в провод и воровать картинки. :)
Флинт в стену врежется когда поймет какой поток надо сгребать непрерывно. Даже если не заниматься его расшифровкой - куда столько счастья предлагается девать?! Простой винч загнется от такого потока! Предлагается сгородить крутое Ынтерпрайзное хранилище? Сдается мне что пираты уж давно придумали дюжину менее затратных способов :)
| | |
| |
| 4.51, Аноним (-), 01:25, 16/09/2010 [^] [^^] [^^^] [ответить]
| +1 +/– | |
При перекодировании фильма из BluRay MPEG2 в H.264 картинка в начале должна быть декодирована и не надо никуда ничего сохранять - все прекрасно гоняется через pipe/fifo.
Так что порите чушь, никуда декодированный поток в raw виде сохрянять не надо.
| | |
| |
| 5.53, User294 (ok), 12:23, 16/09/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>Так что порите чушь,
Зачем мне пороть чушь? Ей же будет больно! (если вы не поняли, вы опубликовали призыв к действию "пороть чушь" :P). Так что это... летайте самолетами Аэрофлота, во.
>никуда декодированный поток в raw виде сохрянять не надо.
Есть некоторая разница. В упомянутоам вами случае RAW вид живет только в памяти компьютера и как раз там оно проблем не представляет, память современного компьютера оперирует ГигаБайтами в секунду и как-нить такой поток осилит (тем более что при перекодировании реальное время не жмет и ни от кодировщика не требуется выжимать FPS равный FPSу мувика в реалтайме). А вот если у вас провод с HDMI и по нему валится несколько гигабитов декодированной картинки, в реальном времени - эти гигабиты надо куда-то складывать из этого провода, очевидно? И что-то с ними делать. При том скорость потока получается достаточно большой для того чтобы Average Joe забил на попытки выгрести столько дряни на свой винч или в реалтайме перекодировать столько данных. Ну то есть какиенить "профессиональные" пираты могли бы наверное и собрать себе хранилище из нескольких дисков, но сдается мне что они давно придумали 100500 более дешевых и практичных решений по части копипи...нга с блюрея и прочих. Так, сугубо глядя на результат поиска HD в TPB...
| | |
|
|
|
|
| 1.8, Аноним (-), 11:25, 15/09/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Неужели он не меняется динамически и не обмениваются им при начале работы? Если так - позор ынтели...
| | |
| |
| 2.14, daevy (ok), 11:48, 15/09/2010 [^] [^^] [^^^] [ответить]
| +/– |
контент на диске уже записан в шифрованном виде, при изменении ключа, прочесть данные будет невозможно. имхо, если динамически менять ключ, придется хранить контент в открытом виде, и шифровать/дешифровать на лету при просмотре, что совсем уже бессмысленно.
| | |
| |
| 3.37, User294 (ok), 14:34, 15/09/2010 [^] [^^] [^^^] [ответить]
| +2 +/– | |
>шифровать/дешифровать на лету при просмотре, что совсем уже бессмысленно.
DRM совсем бессмысленно с самого начала. Если вы видите картинку - вы ее можете содрать зиллионом разных способов. А все эти фокусы копирасов мешают только честным юзерам, которые хотят без всякой задней мысли скажем слить фильму себе на комп чтобы не угробить дорогой и нежный диск ненароком. Вообще не собираясь распостранять чего-то. Те кто собирается распостранять - вываливают бдрип не снабженный AACSом вообще. Странно, да?
| | |
| |
| 4.50, Аноним (-), 22:06, 15/09/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> Если вы видите картинку - вы ее можете содрать зиллионом разных способов.
И потерять качество.
| | |
| |
| 5.58, User294 (ok), 12:21, 17/09/2010 [^] [^^] [^^^] [ответить]
| –1 +/– | |
>И потерять качество.
Да ну, бросьте. Скажем можно выгребать цифру ... например где-то ОПОСЛЯ чипа занимающегося шифрованием. Пусть он там расшифровывает себе наздоровье, а нам при этом даже не надо знать как именно это делается. Шифрование то рано или поздно в схеме монитора заканчивается т.к. не подашь шифрованный сигнал на матрицу, хоть тресни. Значит при желании поток можно снять с монитора все-равно. А т.к. это цифра - качество ровно то которое декодировалось, пардон. DRM - это заведомо обман и надувательство. Оно столь же "нужно" и "естественно" как для телеги пятое колесо.
| | |
|
|
|
| 2.15, Macil (?), 11:50, 15/09/2010 [^] [^^] [^^^] [ответить]
| +/– | |
Вообще-то схемы обмена ключами, которая была бы устойчива к атаке типа man-in-the-middle не существует в природе. Поэтому, необходима некая секретная информация, которую злоумышленник не знает...
А в данном конкретном случае нет даже необходимости генерации сессионных ключей, поскольку forward secrecy обеспечивать не нужно.
| | |
| |
| 3.16, pavel_simple (ok), 12:05, 15/09/2010 [^] [^^] [^^^] [ответить]
| +/– |
 >Вообще-то схемы обмена ключами, которая была бы устойчива к атаке типа man-in-the-middle
>не существует в природе.
ви таки ошибаииитись -- см. SRP
| | |
| |
| 4.24, mine (ok), 13:08, 15/09/2010 [^] [^^] [^^^] [ответить]
| +/– |
 Я, конечно, полный профан в шифровании, но судя по википедии SRP - это для аутенификации. А в данном случае нужен протокол для передачи данных...
| | |
|
| 3.28, Александр Чуранов (?), 13:29, 15/09/2010 [^] [^^] [^^^] [ответить]
| +/– |
 Так-так, а как же алгоритм Диффи-Хеллмана?
Насколько я знаю, он как раз и позволяет безопасно обмениваться данными по незащищённой сети при отсутствии общего секретного знания у сторон взаимодействия. И реализаций в оупен сорсе полно, в той же OpenSSL, например.
| | |
| |
| 4.29, Аноним (-), 13:33, 15/09/2010 [^] [^^] [^^^] [ответить]
| +/– | |
Вы издеваетесь что ли? D-H используют как каноничный пример, когда рассказывают что такое MitM.
Да, там потом добавляли всякие хитрости, типа "распилить на две половинки", которые усложняют дело. Их тоже обходили все.
| | |
| |
| 5.31, Анон (?), 13:42, 15/09/2010 [^] [^^] [^^^] [ответить]
| +/– |
 Что-то вы меня запутали и я хочу объяснений. Для шифрования с открытым ключом нужно только два открытых ключа в общедоступном месте, два не распространяемых секретных ключа и ни какой третий man-in-the-middle больше ничего не получит в открытом виде. Где я не прав?
| | |
| |
| 6.32, Macil (?), 13:51, 15/09/2010 [^] [^^] [^^^] [ответить]
| +/– |
>Где я не прав?
>только два открытых ключа в общедоступном месте
Вот здесь.
Откуда ты знаешь, что открытый ключ принадлежит именно "той" стороне?
| | |
| |
| 7.34, Анон (?), 14:15, 15/09/2010 [^] [^^] [^^^] [ответить]
| +/– |
А, ну да, по фингерпринту, переданному лично. Но в данном случае, похоже, что вообще дело обходится только одной парой ключей.
| | |
| |
| 8.43, Macil (?), 16:34, 15/09/2010 [^] [^^] [^^^] [ответить] | +2 +/– | А откуда ты будешь знать, что это фингерпринт той стороны Откуда ты будешь зн... текст свёрнут, показать | | |
| |
| 9.44, аноним (?), 17:07, 15/09/2010 [^] [^^] [^^^] [ответить] | +/– | Это уже бред не относящийся к практике Так можно сказать что любая криптосхема ... текст свёрнут, показать | | |
| |
| 10.49, Macil (?), 21:00, 15/09/2010 [^] [^^] [^^^] [ответить] | +1 +/– | Это не бред, и как-раз имеет непосредственное отношение к практике К криптограф... текст свёрнут, показать | | |
|
|
|
|
|
| 5.59, Александр Чуранов (?), 03:37, 18/09/2010 [^] [^^] [^^^] [ответить]
| +/– |
>Вы издеваетесь что ли? D-H используют как каноничный пример, когда рассказывают что
>такое MitM.
Не надо голословных утверждений.
Приведите "каноничный пример", в котором протоколу диффи-хеллмана плохеет от man-in-the-middle. Я этого представить не могу.
| | |
| |
| 6.60, AdVv (ok), 10:28, 20/09/2010 [^] [^^] [^^^] [ответить]
| +/– |
 >>Вы издеваетесь что ли? D-H используют как каноничный пример, когда рассказывают что
>>такое MitM.
>
>Не надо голословных утверждений.
>Приведите "каноничный пример", в котором протоколу диффи-хеллмана плохеет от man-in-the-middle. Я этого
>представить не могу.
На этапе установки соединения вы отсылаете собеседнику свой открытый ключ. Злоумышленник его перехватывает и отсылает вместо него свой. Далее перехватывает зашифрованную своим ключем переписку, расшифровывает, читает, шифрует вашим ключем и отправляет вам. Все счастливы. Чтобы противостоять этому и созданы доверенные центры сертификации, которые позволяют проверить, действительно ли открытый ключ соответствует его владельцу.
| | |
| |
| 7.62, Александр Чуранов (?), 16:25, 23/09/2010 [^] [^^] [^^^] [ответить]
| +/– |
>На этапе установки соединения вы отсылаете собеседнику свой открытый ключ. Злоумышленник его
>перехватывает и отсылает вместо него свой. Далее перехватывает зашифрованную своим ключем
>переписку, расшифровывает, читает, шифрует вашим ключем и отправляет вам. Все счастливы.
>Чтобы противостоять этому и созданы доверенные центры сертификации, которые позволяют проверить,
>действительно ли открытый ключ соответствует его владельцу.
AdVv,
Какой ещё "свой открытый ключ"? Мы же про алгоритм Диффи-Хеллмана говорим.
http://en.wikipedia.org/wiki/Diffie–Hellman_problem
http://en.wikipedia.org/wiki/Diffie-hellman
Александр Чуранов
| | |
| |
| 8.63, AdVv (ok), 17:16, 23/09/2010 [^] [^^] [^^^] [ответить] | +/– | gt оверквотинг удален Да да Александр, именно о нем http ru wikipedia org ... текст свёрнут, показать | | |
|
|
|
|
| 4.61, Andrey Mitrofanov (?), 11:25, 20/09/2010 [^] [^^] [^^^] [ответить]
| +/– |
>алгоритм Диффи-Хеллмана?
>Насколько я знаю, он как раз и позволяет безопасно обмениваться данными по
>незащищённой сети при отсутствии общего секретного знания у
А на википедии написано "двум сторонам получить общий секретный ключ, используя незащищенный от прослушивания, но защищённый от подмены, канал связи". О чём только они там у себя в википедиях думают?!---
| | |
|
|
|
| 1.10, Nas_tradamus (ok), 11:37, 15/09/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Кто знает, а как тогда работают устройства захвата изображения по HDMI?
Например, скриншоты и видео из приставочных игр делают ведь.
| | |
| 1.13, Андрей (??), 11:43, 15/09/2010 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
т.е., ключ, как и в случае с css-dvd на носителе? если так, то выводов не делают... жадность моск вынесла... вероятно, инженеры, которым была заказана разработка защиты, пытались убедить их, что это не возможно, но заказчики сначала добавляли нолики в предложение, а потом паяльник показали. Инженеры предпочли не говорить, что именно с помощью этого не хитрого прибора можно взломать, потому что этот не хитрый инструмент может быть и для других целей использован... ну нет в этом мире абсолютной защиты... и наличие диплома (даже красного) тоже не является гарантом, что обладатель его - самый гениальный чувак в этой области...
| | |
| 1.17, luckym (ok), 12:21, 15/09/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 А как же в свете этой новости до сих пор на торрентах раздавались всякие BD-Rip'ы и прочие ремуксы, если ключь до сих пор не был взломан?
| | |
| 1.18, Аноним (-), 12:40, 15/09/2010 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Вообще-то, DRM - это digital _right_ management, а "restrictions" - это дразнилка, придуманная противниками этой технологии. Я их поддерживаю, но писать нужно все-таки правильно.
По сабжу - вот и славно, вот и хорошо. Может когда-нибудь поймут бессмысленность и вредность DRM.
| | |
| |
| 2.23, Аноним (-), 13:07, 15/09/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>Вообще-то, DRM - это digital _right_ management
1. "right_s_", тогда уж
2. War is peace, freedom is slavery, ignorance is strength, amirite?
| | |
| |
| 3.25, Аноним (-), 13:10, 15/09/2010 [^] [^^] [^^^] [ответить]
| +1 +/– | |
>2. War is peace, freedom is slavery, ignorance is strength, amirite?
Ой, поясню, а то еще шапками закидают, и обзовут красноглазым криптопионером и онанистом на Оруэлла.
Я про то, что как вы яхту для публики назовете - так публика и запомнит. Мы уже помним что "музыка - это mp3" (и публика очень тяжело понимает что-то другое). Почему? Приучили так.
Поэтому, как раз, лучше писать не так, как предлагают идеологи DRM - а то ведь, и правда, люди запомнят что это "права", а не "ограничения". Потом замучаетесь объяснять что никакими их правами там и не пахло.
| | |
| |
| 4.33, Аноним (-), 13:52, 15/09/2010 [^] [^^] [^^^] [ответить]
| –2 +/– |
По первому пункту соглашусь, а вот по второму - нет. Переиначивание аббревиатуры - фактическая ошибка. Нельзя смешивать дразнилки и официальное название, как бы вы не относились к этому явлению.
Алсо, я не за DRM, я за корректность информации в новостях :)
| | |
| |
| 5.39, User294 (ok), 14:42, 15/09/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
Официальное название придумали маркетологи. Чтобы надувать покупателей, обманывая их относительно фактической деятельности этой "фичи". Если г-но они назовут лепетсками роз для удобства впаривания - вы как будете его называть? Вот и здесь та же история.
| | |
| 5.45, аноним (?), 17:08, 15/09/2010 [^] [^^] [^^^] [ответить]
| +/– |
>По первому пункту соглашусь, а вот по второму - нет. Переиначивание аббревиатуры
>- фактическая ошибка. Нельзя смешивать дразнилки и официальное название, как бы
>вы не относились к этому явлению.
Можно. И нужно.
| | |
| 5.54, szh (ok), 13:32, 16/09/2010 [^] [^^] [^^^] [ответить]
| +/– |
 > По первому пункту соглашусь, а вот по второму - нет. Переиначивание аббревиатуры - фактическая ошибка. Нельзя смешивать дразнилки и официальное название, как бы вы не относились к этому явлению.
Поддерживать пропаганду врага, используя им разработанный PR - вот ваша фактическая ошибка. Этот проблема гораздо важнее чем проблема переиначивания аббревиатуры (хотя учительница русского языка считает наоборот, она никогда не оплатит нам убытков от поддержки этой точки зрения).
Алсо, не надо называть правильное отображения сокращения DRM в реальность "дразнилкой". Это антипиар правильной идее.
| | |
|
|
|
|
| |
| |
| 3.47, pavlinux (ok), 18:47, 15/09/2010 [^] [^^] [^^^] [ответить]
| +/– |
 >>Там просили отмирорить :)
>>http://pavlinux.ru/HDCP_MASTER_KEY.txt
>
>А также "абузоустойчивый" совсем уж отмиррореный линк (магнет-ссылка для торрента) который копирасам будет весьма проблематично снести
Лучший трекер это Гугле. :)
HDCP MASTER KEY - https://docs.google.com/Doc?docid=0ARFMDESDZ0qvZGdtNjRrOXZfN2Zjc3Q5ZGN0&hl=ru
-------
Больше прикалоло,... типа спрятались.
To generate a sink key, do the same, but with the transposed matrix.
Один из первых косяков у тех кто передаёт шифры, ключи, криптоданные в табличном HEX виде.
Значит есть матричные вычисления - транспонирование, обращение, повороты,
умножение на число, которое прошито у клиента или передаётся....
| | |
|
|
|
