Breaking DRM DRM törések

Berecz László Giczi Norbert Kutasi Zoltán Szendi Péter

Vázlat

• DRM bevezetés • Analog Hole • iTunes & iTunes Store • FairPlay • FairPlay „törések”

DRM bevezetés

• DRM≈digitális jog/korlátozás kezelés • Hozzáférés kezelési technológia • Általában szellemi tulajdont képző adatokat tartalmazó fájlokon végezhető műveleteket szabályzó eljárás • Célja a kalózkodás visszaszorítása • Nem egyszerű másolásvédelem, annál összetettebb, pl. 5-ször lejátszható fájlok • Nem feltétlen a fájlt vesszük meg, hanem jogokat a rajta végrehajtható műveletekre

Pro és kontra • Kontra • Pro – Tökéletlen rendszer, mindig – Jogok és lehetőségek lesz alkalmas törés hozzá finomhangolását teszi lehetővé – Csak az illegális (pl. torrent) – Finomítható az árazás felhasználást nem nehezíti – A DRM-es anyag – Jó szándékú felhasználókat is a visszakövethető (a misuser-ig) kalózkodás felé viszi – Új lehetőségek (pl. online film – A DRM nélküli tartalom kölcsönzés) árusítás már bizonyított – Szellemi tulajdon birtokosa – A gyártóspecifikus DRM-ek az tényleges eladási számok egyes platformokon belül alapján kapná a pénzét gátolják a szabad versenyt – A tulajdonos nem rendelkezik szabadon a jogos tulajdona felett Analog Hole • Kivédhetetlen probléma az analog hole • Emberi érzékek jellemzője -> az ember analóg. • Minden rendszerben ahol emberi használatra szánt adat megjelenítésre kerül • Próbálkozások a „betömésre”: – Analóg kimenetek korlátozása (felbontás, zaj hozzáadás) – letiltás, azaz lejátszáskor a nem használt kimenetek tiltása – Megszüntetés, szabványosító testület által – Vízjelezés, csak unfair use detektálásra • Mindig lesz D->A átmenet, ha mást nem a képernyőt fel lehet venni kamerával, vagy a hangot mikrofonnal

• Analog dawn iTunes és iTunes Store

• Apple internetes on-line zene (content) áruháza, és a kliens-lejátszó • 60-70% piaci részesedés (hagyományos+online eladásokat tekintve is!) • 2003 óta 8 milliós adatbázis, 5milliárdos össz. eladás • zene, epizódok, audiobook,programok, filmek, KÖLCSÖNZÉS • 128kbps AAC-k (.m4p/a konténerekben) • DRM rendszere a FairPlay ami Apple exclusive • IPod -> csak iTunes DRM, iTunes DRM-> csak IPod = monopólium • Állítólag az Apple ellenzi a drm-et (és mégis árulja a DRM-es tartalmakat) • Egyre inkább támogatják a DRM-mentes zene árusítást

M a c & i T u n e s

8 m illió ze n e i n t e r n e t Alkalm azások , F i l m e k S t b ... i P o d H oni szerver iT unes store P r o d u c e r

P C & i T u n e s A n a l ó g D igitális adat D R M - m e l

D i g i t á l

FairPlay

3 megkötés: – Egyes számok max. 7x kiírhatóak (AAIF CD) – Max. 5. számítógépen hozzáférhetőek de akárhány iPodon (iPhone-on) – Ipod || iTunes && (PC||MAC||(Linux&&Wine)) – (illetve kevés kivétel RAZR,POKR)

A DRM ezen 3 megkötés betartását szabályozná

FairPlay • Kódja titkos... • … volt amíg vissza nem fejtették hackerek, pl. DVDJon • Még ma sem nyilvános (hivatalosan), csak a rá épülő törések használhatóak (nem hivatalosan) • Legtöbbször ezek hirdetése, leírása, terjesztése C&D-t von maga után Apple által • Pusztán a működés ismerete elég egy támadás végrehajtásához – Ez irányulhat a DRM eltávolítására – vagy egy idegen (más gyártó) technológia kompatibilissá tételére • Sook pénzért eladható titok • Nem licencelhető (titok megőrzése, eltérő technológiák, monopólium építés:)

FairPlay • Az iTunes működése: – Vásárláshoz kell account, itt első gép érvényesítés – iTunes: egyedi ID a gépnek -> küld iTunes servernek

– Vásárláskor az iT Store elküldi a választott számot a következő formátumban a vevő iTunes-ének: [Emk(zene),mk] (nyilván titkosított formában a hálózaton) – Majd iTunes mk-t kódolja a számhoz helyben generált uk-

val: [Emk(zene),Euk(mk)] • uk-t pedig iTunes elküldi az iTservernek • uk-t a MAC cím, mint kulcs és egy előre beprogramozott IV segítségével AES módra titkosítva eltárolja (ó, ennek csak később kellett volna kiderülnie) valahol (persze tudható ez is...) • Új zene vásárlásnál új uk, és mk keletkezik hasonlóképpen (mk a Store-ban uk pedig az iTunes által helyben gép specifikus adatokból) • Új gép regisztrálásánál pedig a szerver elküldi az új gépnek az eddig megvett zenékhez tartozó uk-t (a többin bejelentkezéskor

frissít) /kép köv. dián/ • Az eredményképpen kapott rendszer erőssége hogy nem kell online ellenőrzés a DRM betartatásához, hanem iTunes végzi • viszont a kulcsokat helyben tárolja, ami elég kiszolgáltatottá teszi • iPod dokkoláskor a regelt gépen található iTunes összes kulcsát

letölti, másik gépről ezután nem tud csak törlés után

A lehetséges DRM törések • A mk-val való rejtést nehéz megtörni, inkább a protokoll nyújtotta esélyeket kell kihasználni • Gép érvényesítés törlése – Érvényesítés visszavonási kérelem esetén szerverről törlődik a gép egyedi ID-je, és a kulcsok helyben – Biztonsági mentés a kulcsokról->deauthorization->kulcsok vissza – Egy hatodik gép is felvehető az érvényes gépek közé (7,8,9...) – A „hackelt” gépen nem működnek az új kulcsokhoz tartozó zenék

Analóg lyuk alapú törés: 1. • CD-re kiírhatóak az anyagok (7x) • Ezek akármilyen lejátszó által értelmezhető formátumok, • így a „hagyományos” rippelős módszerrel hozzájuthatunk a zene védelem nélküli változatához (mp3,aac,wav...) • Veszteséges D->D->D, elvben hasonló a szigorúan vett analog hole alapú tőréshez 2. • iTunes-szal lejátszás, analóg kimenetre küldve • Analóg kimenetről (vagy hangkártyán belül) hanghullám rögzítő alkalmazással felvenni a zenét • D->A->D veszteséges művelet, nem csak védelem eltávolítás

Feltéve hogy ismerjük a regisztrációt: • Két -féle megközelítés létezhet 1.Megkerüljük a védelmet 2.Kihasználjuk a védelem gyengeségeit 1.Megkerüljük a védelmet: • Az iTunes-szal lejátszatjuk az anyagot • Ez leveszi az anyagról(.m4p) a titkosítást, mielőtt a megfelelő kimenetre küldené • A titkosítatlan folyamot egy megfelelő konténerbe lehet tenni • Ez lehet tömörített vagy tömörítetlen (Qtfairuse,hymn,jhymn) • Reverse engineering! Ismerni kellett a programot 2. Kihasználjuk a védelem gyengeségeit FairKeys: • elhiteti iTunesStore-ral hogy ő iTunes • újonnan érvényesítettként elkéri a user kulcsait iTStoretól • A kapott kulcsokkal dekódolja a korábban vett védett zenéket • Protokoll és reg. Ismerete szükséges, • DRM teljesen nullázódik

PyMusique: • Linux alapú program, elhiteti iTStore-ral hogy ő iTunes • ID ismeretében vagy újonnan érvényesítettként a vásárolt zenéket nem titkosítja • Így a plain mk ismeretében a zenék teljesen DRM mentesíthetőek • Nem kellett iTunes, és már nem is fog kelleni

Fontos hogy mindenhol ismerni kellett a user reg.-t, és ehhez tartozó DRM-es számokat lehetett DRM- teleníteni

Requiem • Ismeretlen hacker teljesen visszafejtette a FairPlay kódját • Saját legális DRM-es fájljaiból saját „fél-legális” DRM-mentes fájlokat csinált, veszteségmentes módszerrel A megoldását Mac platformon alkotta >7.3QT, és 7.6 iTunes mellett működését a program README-je alapján tudtam meg, ennyire: /Users/Shared/SC Info/SC Info.sidb /Users/Shared/SC Info/SC Info.sidd • fájlok tartalmát a MAC cím „elborult” verziójával mint kulccsal dekódolni, IV fix • Az egyes védett fájlok információt tartalmaznak arról, hogy a .sidb fájlban hol található a hozzá tartozó kulcs. Ezt a kulcsot kell előbb dekódolni az iTunes user ID a kulcs ID és a MAC cím egy bonyolult kombinációjával, illetve a .sidd fájlban található kódtábla segítségével. • A .m4p azaz a védett fájl priv atomjának dekódolása a kulccsal. Az iviv atom,

illetfe a fájlnév md5 hash-e lesz az IV. • A priv atomban lévő kulccsal(~mk) és IV-vel lehet a tartalmat megkapni. Köszönöm a figyelmet!

Sony XCP DRM

Giczi Norbert

Bevezető

 Sony-BMG lemezkiadó  First 4 Internet DRM gyártó  XCP (Extended Copy Protection)  (MediaMax - SunnComm)  Audio CD védelem  52 kiadvány tartalmazza a védelmet http://cp.sonybmg.com/xcp/english/titles.html

Miért lehet érdekes pont ez a DRM technológia?  Egészen 2005. október 31-ig „nem tudtak a létezéséről” (az eladott CD-ken jelezte egy apró matrica a védelem jelenlétét)

 Mark Russinovich „fedezte fel”, miközben a rootkit felismerő programját tesztelte

 A DRM rendszert egy rootkit rejtette el a rendszer felhasználói elől

 De nem csak ez a probléma...

A CD DRM rendszerek követelményei és működési elve  A másolásvédett lemezek feleljenek meg a CD Digital Audio szabványnak (Red Book)  Így a hagyományos audio CD lejátszók olvashatják a CD-t  A számítógéppel történő másolást akadályozzák meg (a CD legyen olvashatatlan az összes programból, kivéve a DRM gyártó saját lejátszóprogramját)  Védelem típusok: passzív/aktív

XCP  Hogyan néz ki egy XCP-vel ellátott CD?

 Multisession CD − Első session: audio − Második session: adat (a DRM védelem telepítője)  A hagyományos CD lejátszók az első session tartalmát gond nélkül kezelik, az audio tartalom meghallgatható

 Passzív védelem

 A második session két adatsávot tartalmaz  Emiatt a Windows (a „Blue Book” szabvány eltérő értelmezése miatt) adat CD-nek mutatja az ilyen CD-ket (de csak azon alkalmazások számára, amelyek a Windows beépített audio CD meghajtóprogramját használják) − Így például egy Nero-nak a másolás nem akadály (direkt hozzáféréssel kezeli a CD írót) XCP – Első indítás

 Mivel aktív védelmet is megvalósít, ezért el kell indulnia/telepíteni kell a CD behelyezésekor  Windows Autorun  Letiltható  Shift billentyű nyomva tartása a CD behelyezésekor ideiglenes tiltást eredményez  Más operációs rendszer alatt nem működik  Le sem kell tiltani...

XCP – Átmeneti védelem I.

 A CD behelyezése és a DRM védelem telepítése és tényleges elindulása közötti időtartam  Már ekkor szükséges a másolásvédelem  Lehetséges megoldások: legyen azonnal működőképes a DRM azon a rendszeren → ezt azonban az USA törvényei tiltják, mert kell a felhasználó beleegyezése, az EULA elfogadása

XCP – Átmeneti védelem II.

 A telepítő a telepítési folyamat során megjeleníti az EULA szövegét, mely elfogadható vagy elutasítható  Közben az XCP figyeli a futó folyamatok listáját, bizonyos időközönként összehasonlítja azok neveit egy ~200 nevet tartalmazó feketelistával (mely a leggyakoribb CD-rippelő és -másoló alkalmazások neveit tartalmazza)  Ha talál a feketelistán szereplő futó alkalmazást, akkor figyelmezteti a felhasználót hogy zárja be a kérdéses alkalmazást, és ha nem történik semmi 30 mp elteltével kiadja a CD-t, majd a telepítő futása megszakad XCP – Átmeneti védelem III.

 Ez is kijátszható:

 „Kilőhető” a telepítőfolyamat mielőtt kiadná a CD-t  Olyan másolóprogramot kell használni, mely zárolja a CD tálcát VAGY nincs a listán  Nevezzük át a másolóprogram futtatható állományát  A feketelista idővel elavul... XCP – Lemez felismerése

 Hogyan ismeri fel a DRM rendszer, hogy a behelyezett CD lemez DRM védett?  A védett lemezen az adat session valamelyik részén egy speciális jelzés van  Csak remélhető, hogy ez nem idézi elő a védelem aktiválódását egy nem DRM-védett lemez esetén...

XCP – Aktív védelem I.

 Az XCP saját lejátszójával játszható csak le a CD  Egyszerű kezelőfelület  „Extra tartalom”: album borító, dalszövegek, link az előadó weboldalára, kapcsolódó reklám, stb.  3 darab másolat készíthető a CD-ről (az XCP saját másolóprogramjával)  A rippelés lehetséges (természetesen az XCP saját programjával), de csak DRM-et támogató formátumba (Windows Media Audio → lásd Microsoft DRM)  Hordozható lejátszóra másolhatók a számok (de van kivétel), másik PC-re nem XCP – Aktív védelem II.

 Feketelista alapú, mint az átmeneti védelem  Ha feketelistán szereplő futó alkalmazást talál a rendszerben és ez az alkalmazás olvasni próbál a CD bármelyik audiosávjáról, akkor véletlen zajt fog továbbítani számára az audio adatfolyam helyett  Megvalósítása egy filter driver segítségével történik, mely az optikai meghajtó driverének viselkedését módosítja

XCP – Az „extra” tartalomról bővebben I.  A CD behelyezésekor az XCP felveszi a kapcsolatot a connected.sonymusic.com címen található szerverrel, elküldve a lemez egyedi azonosítóját egy GET kéréssel

XCP – Az „extra” tartalomról bővebben II.  Naplózható a felhasználó gépének IP címe, az időpont, az album azonosítója  Ezek az adatok felhasználhatók a felhasználó zenehallgatási szokásainak feltérképezésére  Képeket (album borító, stb.) és bannereket kap a lejátszó a GET kérésre válaszként a webszervertől  Ezen tulajdonsága miatt az XCP-t napokon belül felvették a spyware kategóriába a nagyobb antivírus gyártók...

XCP – A lejátszó támadása

 Rollback attack (3 darabnál több másolat készítése a cél)  Mentsük el a rendszer állapotát másolás előtt  Másoljuk le 1-3-szor a CD-t  Állítsuk vissza a rendszer állapotát − A mentés/visszaállítás egy virtuális géppel könnyedén megtehető

XCP – Sony vs. Apple

 Nincs hivatalos támogatás iPod-okhoz  Üzleti okok: Sony XCP vs. Apple FairPlay  Kerülőút: rippelés WMA formátumba → WMP-rel kiírjuk audio CD-re → rippelés iTunes-szal → másolás iPod-ra  Van más megoldás? Van egy passzív kódrészlet az XCP kódjában, amely a DRMS- ből (DVD Jon) származik (a forrás megjelölése nélkül), mely képes (lenne) FairPlay DRM- védett AAC fájlokba kódolni... XCP – Védekezés a védelem eltávolítása ellen  A felhasználó a szokványos rendszeradminisztrációs eszközökkel eltávolíthatja a feltelepített programokat – mi történik, ha így tesz az XCP esetében is?  Semmi, mert nem lehet eltávolítani...  Mert nem is „látszik”...  Mert rootkit rejti el az XCP jelenlétét a rendszerben  „$sys$” prefixszel kezdődő, XCP-hez tartozó fájlokat, könyvtárakat, regisztrációs adatbázis kulcsokat és folyamatokat rejt el egy speciális kernel módú rootkit

XCP – A rootkit megvalósításának hibái  Minden $sys$ prefixszel kezdődő fájlt, könyvtárat, stb. elrejt → ideális „búvóhely” más malware-ek számára  Nem megfelelően ellenőrzött input paraméterek az „eltérített” rendszerhívások végrehajtása során → BSOD  A memóriából való törlés (unload) közben más folyamat még meghívhatja a rootkit által átirányított rendszerhívást → nem érvényes

címen lévő függvény fog hívni → BSOD XCP – Botrány

 Minderről az EULA egy szót sem ejt  Mark blogja → sajtóhír → botrány  Jogi útra terelik az ügyet  Eredmény: a Sony-BMG a honlapján elérhetővé tett egy eltávolító programot  Azonban ennek letöltése csak előzetes regisztráció után vált elérhetővé − Kötelezően meg kell adnia a felhasználónak néhány személyes adatát − E-mailben érkezik egy megerősítő levél, melyben egy újabb link található: újabb űrlapot kell kitölteni XCP - Hivatalos eltávolítási mód

 Az eltávolító program személyre szabott, később és más gépen nem használható újra (mindig újat kell kérni)  Használata újabb biztonsági rést nyit a rendszeren  Az eltávolítás után a rendszeren marad az eltávolító program egyik komponense − Tetszőleges kód futtatásának lehetősége − Külön parancs a rendszer újraindítására

XCP – Eredmények

 Univerzális eltávolító program  A DRM-védett CD-k ingyenes cseréje  Az XCP DRM technológia ma már nincs használatban...

XCP – Tanulságok

 "Most people, I think, don't even know what a rootkit is, so why should they care about it?" - Thomas Hesse, a Sony-BMG egyik magas beosztású vezetője  A felhasználó joga, hogy irányíthassa és megvédje a rendszerét a biztonsági problémáktól és a privacy ellen irányuló támadásoktól...

DVD, HD DVD, Blu-Ray Előadó: Kutasi Zoltán

Tartalom

• DVD – CSS • HD DVD/Blu-Ray – HDCP – AACS – ROM-Mark – BD+

CSS

• Content Scrambling System • Eleinte zárt forráskód • Célok: – A média megtekintésének korlátozása (csak hitelesített eszközökön) – Néhány további korlátozás (régiókódolás, felvételkészítés megakadályozása, fast-forward tiltása) – Minimális mértékben a kalózkodás meggátolása • Működés:

– Disk Key (KDISK), Title Key (KTITLE) a lemezen, titkosítva (40bit)

– Egy rejtett szektorban 409 verzióban ott van DK(N)

– Minden KPLAYER kulccsal ugyanaz a megfejtett érték (más módon)

– A helyes értéket a KDISK hashével ellenőrzik (szintén a lemezen)

– Ezután a KTITLE dekódolása következik – Adatok 2048 byteos szektorokra tagolódnak

– Minden szektornak van külön KSECTOR kulcsa (a lemezen van nyílt szövegként)

CSS

• Mindhárom előbbi dekódoló funkció tartalmaz Pszeudo-Random byte Generátort

– DA: LFSR17: - LFRS25: - Seed: KPLAYER

– DB: LFSR17: - LFRS25: inv Seed: KDISK

– DC: LFSR17: inv LFRS25: - Seed: KSECTOR XOR KTITLE – Az invertálás 2 byte kimenet után történik – A kimeneteket 8-bites összeadó várja (a carry-t megőrizzük)

• KDISK és KTITLE dekódolásánál – 5 bytenyi pszeudo-randomot generálunk – Beadjuk a Key-Mangling Stage-nek • Dekódolás

CSS

Támadás (Jon Johansen, MoRe): • Valaki postolja a DeCSS programot (1999-10) – Valószínűleg visszafejtettek egy PC-s DVD lejátszót (Xing, Cinemaster) – Egyesek szerint egyszerre legalább 5en dolgoztak rajta (több forrásból van visszafejtve a kód) – Célja: Linuxon is lehessen DVD-t nézni (és ne kelljen fizetni) – Pár nap alatt innentől a CSS teljesen összeomlik: publikálják a 409 “titkos” kulcsot • Az ipar felől hatalmas nyomás – Vállalati titoknak nyilvánítják, majd Digital Millennium Copyright Act – Mindenhonnan töröltetik a forráskódot – Perrel fenyegetnek, és perelnek is (71 ember ellen sikeresen), már azért is, hogy linkelik – Válaszul a NETen robbanásszerű ütemben kezd terjedni a kód (fórumok, képek, pólók, stb...) – Meddig ér el az érdekeltek keze ? – "The court finds that someone who buys a DVD film that has been legally produced has legal access to the film. Something else would apply if the film had been an illegal ... pirate copy"

CSS

Támadások (Frank A. Stevenson – 1999-11): • Brute Force (240) – USA Export törvények miatt rövid kulcsok (40bit) • 6byte LFSR Output (216) – Kell 6 byte az LFSR-17 outputjából (nem túl életszerű) – Tippeljük meg az LFSR-17 kezdeti állapotát – Shifteljünk ki 3byte-ot – Tippünkből és ebből ismert LFSR-17 mostani állapota – Shifteljünk ki még 3byte-ot, és ellenőrizzünk – Ha nem jó a tipp, vissza az egész, és újra • 5byte LFSR Output – Ugyanaz, mint előbb, csak először 2byteot shiftelünk ki – LFSR-17 állapotából már csak a legelső bit hiányzik (2*8=16) – Probáljuk ki mindkettőt • Léptessük vissza LFSR-25-öt 2byte-al (16 ütem) • Azt az állapotot válasszuk, ahol a 4.bit 0 • Léptessünk ki 3byteot, és ellenőrizzük a tippünket LFST-17-en

• Mindkettőnek van más variánsa CSS

Támadások (Frank A. Stevenson – 1999-11): • Mangled Output (28) – Megfejthetünk 5byte-ot az LFSRekből (ami mondjuk felhasználható az egyel előbbihez) – Tippeljük meg K5-öt

– Visszafelé haladjunk egészen LK0-ig – Ellenőrzés, ha rossz a tipp, akkor újra 25 • KDISK hash támadása (2 ) – Építsünk táblázatot K2-ről, C2 és B1 indexelésével – Tippeljük meg LFSR-17 állapotát – Számítások az ábrából: K1, B5, K5 – A táblázat segítségével kiszámítjuk LSFR-25 első 2 állapotát, valamint 2 lehetséges 5. állapotát – Ehhez hozzárendelhető C1,2,3,4,5 egyértelműen (224) – K2-t fejezzük ki B4, K4, B3, K3, B2 segítségével – Ellenőrízzük K2-t, valamint az így kijött C1,2,3,4,5 állapotot a hash értékével – PIII 450MHz, 64MB memória: <18sec HDCP

• High-bandwidth Digital Content Protection • Fejlesztő: Intel Corporation • Cél: Digitális jel védelme DVI/HDMI/DisplayPort/… kapcsolatokon • DRM vagy nem ? – “HDCP is not a DRM. It is Content Protection”. – DRM: korlátozzuk a tartalom lejátszási körülményeit (ki, mit, hol, mikor, mennyiszer,…) • HDCP-vel védett jel nem utazhat védtelen csatornán (hol) • Kompromittálódott eszközök végleges visszavonása (ki, mit) – Analog Hole, Analog Dawn • Működés: – Eszköz authentikáció, és kulcscsere – A tartalom titkosítása – Kulcs-visszavonás (Key Revocation List a Lemezen)

HDCP

Eszköz authentikáció, és kulcscsere:

• Minden A eszközhöz igényelni kell

– vA - Key Selection Vector (KSV) - publikus “kulcs” - 40bit (20bit 0, 20 bit 1)

– uA - Eszköz privát kulcsa (kulcsvektor) – 40*56bit • Az algoritmus

nA: 64 bites nonce K=K’: Osztott titok

vX (dot product) uY Z/256Z-feletti műveletek

HDCP

Támadások (Scott Crosby): – Az osztott titok generálása teljesen lineáris (Blom-séma) – A mester-titok megfejthető • TFH a publikus kulcsokból a privát kulcsok jól definiált módon keletkeznek (T transzformáció) • TFH a központi szervezet N⊆M⊆Z/256Z publikus kulcstérből választ • T reprezentálható egy 40x40-es mátrixszal (S) (tehát lineáris) • Gyűjtsünk 40 olyan kulcspárt (u,v), ami független, és így a publikus kulcsok kifeszítik a lehetséges kulcsok terét (N)

• Oldjuk meg a következő egyenletrendszert: U=SV, ahol minden művelet Z/256Z-feletti – Hamisított kulcspárok • Vegyünk egy random KSV-t (V), majd U=SV • Parrotting attack – Végső soron: Lehallgatás, Klónozás, Hamisítás, KRL kikerülés, mindez RealTime

HDCP

Támadások (Keith Irwin): • Rögzítés – A fogadó fél semmilyen vizsgálatot nem végez az adóval, nem is járul hozzá a protokollhoz – A védett tartalom rögzíthető, és később lejátszható (de csak ugyanazon a fogadón/repeateren) – Hátránya: tömörítetlen 1080p videoanyag • XOR with Black – A titkosító modul pszeudo-véletlen csupán – Ha a küldő és a fogadó megegyezik, csupán a véletlen szám a változó – A véletlen szám is pszeudo random generálódik (Timer Attack) – Egy ismert titokkal (fekete kép) XOR-oljuk össze • Offline Brute Force – 56 bites kulcs ma már kicsi, offline törhető – A központ nem fog tudni a kompromittálódásról Támadások (Niels Ferguson): • Nem tudni, mivel jogi okok miatt nem publikálja (DMCA)

HD DVD/Blu-Ray

• Két egymással harcoló formátum (volt) a DVD leváltására

AACS

• Advanced Access Control System • Fejlesztők: Disney, Intel, Microsoft, Matsushita (Panasonic), Warner Bros., IBM, Toshiba, Sony • Bonyolult rendszer, kriptográfusok fejlesztették • Célok: – Tartalom titkosítása nyilvános kriptográfiai algoritmusokkal (AES, SHA, CMAC, X9.31, ECDSA) – A tartalomhoz való hozzáférés csak szerződött felek implementációival – Kompromittálódott kulcsok visszavonhatósága (MKB – Media Key Block) – A tartalom megtekintésének, és felvételének meghatározott korlátozása – Többféle vízjelezési technika (Audio, Video) – Robusztus, rugalmas (Audio, Video, Optikai Lemezek) – A digitális átállás segítése (ITC – Image Constrain Token, DOT – Digital Only Token) – Új szolgáltatási típusok (Online Transaction Support, Managed Copy) • Visszavonás – HRL - Host Revocation List (pl. WinDVD x.y) – DRL - Drive Revocation List (pl. X-Box HD DVD Drive) – CRL - Content Revocation List (konkrét film)

AACS

Működés:

• Device Keys (Kd) – n*128bit – Gyártás során minden lejátszó kap 253 (22+21+20…+1) db-ot (~mestertitok)

– Ezek segítségével számíthatjuk ki a Media Key-t (Km) – Device Number (d), Path Number (p) • Media Key Block (MKB) – 4*i byte – A lemezen található, az AACS LA hozza létre

– Különböző lejátszók Kd-jéből ugyanazt a Km-et hozza létre

– Kompromittálódás esetén frissítik, úgy, hogy a kompromittálódott fél ne tudja kiszámítani helyesen Km-et • Subset-Difference Tree – Hatalmas mesterkulcsokat tartalmazó fa (+részfák), levelei az eszközök

– 1 egyedi kulcsa van minden eszköznek, a Leaf Key (Kl) – Egyik eszköz sem tudja kiszámítani a fában hozzá vezető út kulcsait,

de a többit igen (ezekhez kap Kd-ket) – Minden magasabb szinten levő kulcsból számíthatóak az alacsonyabbak (hash)

– Ha vissza kell vonni egy Kl-et, Km-et kódolják vele (vagy magasabb szintű kulccsal) – Ha többet kell visszavonni, akkor felhasználják a részfákat – Subset Difference: Egy részfában a NEM visszavont eszközök halmaza

AACS

Működés:

• Processing Keys (KP) k : Device Key

S0 : 7B103C5DCB08C4E51A27B01799053BD9H AES-128D(k, s0) XOR s0 : bal gyermek node

AES-128D(k, s0+1) XOR (s0+1) : KP AES-128D(k, s0+2) XOR (s0+2) : jobb gyermek node

• Media Key (Km) – MKB két részre bontható: Subset-Difference ID (uv) és Key Data Part (C) – uv-ben tárolják, hogy a fában hol található az adott node (path number), illetve a Subset Difference-t (uv maszkok)

– Km = AES-128D(Kp, C) XOR (000000000000000000000000H || uv) • Volume ID – Címenként egy random, nem predikálható, egyedi érték a lemezen – Nem hívható le közvetlenül a lemezről , nem másolható – Később kiderült, hogy igenis predikálható (arnezami - King Kong HD DVD) • 40 00 09 18 20 06 08 41 00 20 20 20 20 20 00 00

• Gyártási idő: 2006-09-18 08:41 AACS

A dolog azonban még bonyolultabb: • Key Conversion Data (KCD)

– Egy újabb lépés, hogy megkapjuk végre a Km-t – Elvileg csak HW lejátszóknál alkalmazható, de ott sem mindegyiknél – Class-okba oszthatóak a lejátszók így

• Sequence Key (Ks, SKB) – Egy lemezen egyedi titkosítású fejléce(ke)t helyeznek el, melyeket különböző Lejátszók különböző módon bontanak ki (Media Key Variant, Volume Key Variant) – A kikerült kalózverziót kicsit jobban behatárolhatják, milyen eszközből származik, így csak azt tíltják, amelyik ténylegesen kalózkodik – Még nem használják • Usage Rules – Elvileg egyedi tartalmag esetén van szerepe – Még nem használják

AACS

Támadás (Muslix64 – 2006-12-26):

• BackupHDDVD 0.99 – beadod a Kt-t, és a lemezt, és visszafejti

• Honnan jön Kt ? – A lejátszónak a memóriában kell tárolnia – WinDVD plain text-ként tárolta !! – Ha egyszer megvan, hogy hol kell keresni…

• Nem szabad felfedni Kd-t (visszavonás miatt) – Traitor Tracing, Decryption Oracle – Megéri a központnak tiltani egyáltalán ?

• Kd-t tíltják, Kd-t publikálja a hacker, és minden eddigi lemez másolható

• Kd-t nem tíltják, a hacker nem publikálja Kd-t (nehogy a készülékét letiltsák) csak Kt-t, de ő maga hackel tovább • Később a Volume Key-eket is megtalálja a memóriában, BackupHDDVD 1.0 • Title Key-ek és Volume Key-ek árasztják el a NET-et.

AACS

Támadás (Arnezami – 2007-02-11): • Volume ID-t talál a memóriában (USB Sniffing) • Processing Key-t talál a memóriában

– Km addig van a memóriában,

amíg a VolumeID-ből ki nem számoljuk a Kvu-t – Egy korábbi programot adaptál, hogy a WinDVD-t lelassitsa, amíg keresi a Media Key-t a memóriában, és amikor megvan, akkor HALTolja – Ekkor a memóriában pontosan az a C érték van benne, amiből számolódik a Media Key – MKBv1: 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 – “You can own an Integer” • Ezzel az addigi összes HD DVD másolhatóvá válik Támadás (ATARI Vampire – 2007-02-24): • WinDVD 8 Device Key-ét találja meg a memóriában

– A WinDVD memóriatartalmának jelentős részét átküldi az AES-128D-n (ismeri KP-t) – AA 85 6A 1B A8 14 AB 99 FF DE BA 6A EF BE 1C 04 • Bejelentik a kompromittálódott kulcsok cseréjét: 2007-04-23 ??? • 2007-05-17: Megjelenése előtt kikerül a NET-re MKBv2 Processing Key-e (Matrix HD DVD BoxSet)

BD-ROM Mark

• Fizikai védelem a nagybani sokszorosítás ellen (1:1 másolás) • A lemezeken másolhatatlan elemeket helyeznek el, melyeket csak a gyári speciális eszközzel lehet felvinni • A kiírt filmek működnek, támadni sem érdemes

BD+

• Self Protecting Digital Content – A lejátszó egy Virtuális Gépet (BDVM, nem Java) futtat, ami néhány 100 soros, és 60 utasításból álló kódot futtathat a lemezről • Fejlesztő: Cryptography Research Inc. • Funkciói: – Kód transzformáció: Bizonyos részei a video Streamnek direkt el vannak rontva (vagy vízjelezve vannak), amit a kis programocska javitani képes (Fix-Up Table) – Alapvető védekezés: A lemezt a lejátszóba helyezve el tudja dönteni, hogy a lejátszó kompromittálódott (HW hack), és megakadályozza a használatot (vagy egyéb, nem perzisztens dolgot művel) – Fejlett védekezés: Natív kód futtatására lehetőséget adó eszköz, bármit tehet, ami leprogramozható (!!!) • Amint eltávolítjuk a lemezt, a lejátszó ismét alapállapotba kerül (nem kerül tiltásra)

BD+

Támadások: • Nem nyílt forráskódú, igen nehéz a törés • SlySoft AnyDVD HD (2008-03-21 (2007-10 ??)) – Azt, hogy hogyan csinálta, nem publikálta (valószínűleg reverse engineering HW+SW) – Folyamatos Support, mert a törés sosem lehet teljes (mindig más kód kerülhet futattásra és valószínűleg a VM emulálása sem teljes még) – Jelenleg a BD+ lemezek 99%-a másolható (még) • Doom9.org publikus forráskód (Oopho2ei, és még sokan mások 2008-09-25) – libbluray – Implementálni akarják a Virtuális Gépet, így a kódot leemelve a lemezről ők is futtathatják – Cél, hogy bárki megismerhesse a forráskódot, bele tudjon nyúlni – A kiindulási alap egy kompromittálódott BD+ lejátszó (többet nem mondtak, érthető)

Jelenlegi helyzet

• A DRM védelmek jelenleg csupán a vásárlók életét keserítik meg, nem a kalózokét • Minden DVD lemásolható (A CSS bedőlt) • CSS mellett működő védelmek – nem megbízhatóak, nem kompatibilisek (ARccOS) – Nem nyújtanak plussz védelmet, mert megkerülhetőek (RipGuard) • Minden HD DVD másolható – Sajnos a Blu-Ray nyerte a formátumháborút (komolyabb védelem, sokkal jobb marketing) • A legtöbb Blu-Ray másolható – AACS • Kompromittálódott SW lejátszók • Lassú visszavonási folyamat • Folyamatos hacker-oldali kulcsfrissítés (1-2 nap) – BD+ • Az egyedi kód miatt gyorsabb reagálás • Nem tartott ki 10 évig (még egyig sem) • Folyamatos hacker-oldali fejlesztés, frissítés (1-2 hét, hónap) – További védelmek aktivizálása, agresszívebb fellépés – SlySoft AnyDVD HD • Jelenleg az egyetlen olyan program, ami képes a lépést tartani • Jogilag biztos alapokon állnak (Antiguai székhely)