CZ20003537A3 - Způsob ověřování dat - Google Patents

Abstract

Způsob ověřování dat vysílaných v digitálním vysílání, jehož podstata spočívá v organizování a ověřování dat před vysíláním do hierarchie alespoň jedné hlavní adresářové jednotky (75), vedlejší adresářové jednotky (76) a souborové jednotky (77), přičemž na data v souborové jednotce (77) se působí ověřovacím logaritmem a přidružená ověřovací hodnota (82) souboru se uloží ve vedlejší adresářové jednotce (76). Tato ověřovací hodnota (82) souboru se dále podrobí ověřovacímu algoritmu a přidružená ověřovací hodnota (79) vedlejšího adresáře se uloží v referenčním hlavním adresáři. Další aspekty řešení se týkají ověřování druhého hlavního adresáře (78) generováním druhé ověřovací hodnoty (82) a ověřování dat před začleněním do tabulek nebo úseků transportního toku.

Description

Oblast techniky

Předkládaný vynález se týká způsobu ověřování dat vysílaných v digitálním vysílacím systému.

Dosavadní stav techniky

Přenosové vysílání digitálních dat je velmi dobře známé v oblasti placených televizních systémů, kde jsou kódované audiovizuální informace vysílány, obvykle ¹⁰ prostřednictvím satelitního nebo satelitního/kabelového spojení, k množství účastníků, z nichž každý má v držení dekodér schopný dekódování vysílaného programu pro následné sledování. Jsou rovněž známé pozemní digitální přenosové systémy. Nedávno vyvinuté systémy rovněž používají přenosové spoje pro vysílání jiných dat vedle audiovizuálních dat nebo spolu s nimi, jako jsou počítačové programy nebo interaktivní aplikace, do dekodéru nebo do připojeného PC.

Určitý problém s vysíláním dat aplikací spočívá v 2Q potřebě ověřovat integritu a původ jakýchkoliv takových dat.

Protože data tohoto typu mohou být použita pro změnu konfigurace dekodéru a rovněž pro realizaci jakéhokoliv množství interaktivních aplikací, je podstatné, aby přijatá data byla jak úplná tak i identifikovaná jako pocházející ze, známého zdroje. V opačném případě mohou vzniknout provozní problémy spojené se stahováním neúplných dat a rovněž dochází k riziku, že dekodér se stane přístupným pro útoky třetích osob nebo podobně.

Předcházející pokusy o ověřování takovýchto data se soustředily na ověřování na úrovni začlenění nebo formátování ·· ···* dat v paketovém toku. Například evropská patentová přihláška EP 0752786 popisuje systém, ve kterém jsou data začleněna do sérií modulů nebo, s využitím terminologie spojené se standardem MPEG, do série tabulek nebo úseků, přičemž tyto tabulky nebo úseky jsou potom začleněny do paktů v MPEG transportním toku.

Ověřovací operace se provádějí ve vztahu k tabulkovaným datům, kde adresářová tabulka obsahující, například, seznam všech tabulek obsahujících data pro θ aplikaci společně se seznamem kontrolních hodnot sdružených s každou tabulkou pro umožnění pozdějšího ověření tabulkových dat. Adresářová tabulka sama může být označena podpisem před vysílání, takže informace v adresářové tabulce a v přidružených tabulkách nemohou být modifikovány bez změny kontrolních a podpisových hodnot.

Problém těchto známých systémů spočívá v jejích nevhodnosti pro zpracování složitějších datových organizačních struktur. Zejména použití jedné adresářové tabulky obsahující úplný seznam kontrolních hodnot pro každou přidruženou tabulku znamená, že takové systémy nemohou být snadno upraveny pro zpracování velkých nebo proměnlivých množství tabulek.

Systém je stejně tak neschopen úpravy pro umožnění 5 ověřování softwaru poskytovaného množstvím přenosových operátorů, protože jedna MPEG adresářová tabulka spojuje všechny tabulky a protože ověřovací operace se provádějí ve fázi formátování dat do tabulek pro začlenění do paketů a pro přenos. Tato operace se obvykle provádí pod kontrolou jediného operátora.

• · ··«· ·« ·»·«

Podstata vynálezu

Podle prvního aspektu předkládaného vynálezu je navržen způsob ověřování dat vysílaných v digitálním vysílacím systému, jehož podstata spočívá v tom, že data se 5 před vysíláním organizují do hierarchie s alespoň jednou hlavní adresářovou jednotkou, vedlejší adresářovou jednotkou a souborovou jednotkou, data v souboru se podrobí ověřovacímu algoritmu a přidružená ověřovací hodnota souboru se uloží v referenčním (odkazujícím) vedlejším adresáři, tato ověřovací hodnota souboru se dále podrobí ověřovacímu algoritmu a přidružená ověřovací hodnota vedlejšího adresáře se uloží v referenčním (odkazujícím) hlavním adresáři.

Oproti známým systémům, kde jeden tabulkový adresář odkazuje na všechny přidružené tabulky, zajišťuje použití vícenásobné hierarchické struktury společně s aplikací ověřovacího algoritmu v každém stupni v hierarchii bezpečnou a modulární datovou strukturu. Protože ověřovací hodnota souboru ve vedlejším adresáři se dále ověřuje ve vyšší úrovní

2Q prostřednictvím odpovídající hodnoty v hlavním adresáři, není možné změnit jeden prvek v nižší úrovni bez změny ověřovacích hodnot ve vyšší úrovni (a obráceně).

Výhodně se ověřování dat souboru provádí aplikací kontrolního algoritmu pro některá nebo pro všechna data souboru, přičemž výsledná kontrolní hodnota se uloží jako ověřovací hodnota souboru v referenčním vedlejším adresáři. Stejně tak se ověřování vedlejšího adresáře může provádět aplikací kontrolního algoritmu na ověřovací hodnotu souboru (a další data, pokud je to žádoucí), přičemž výsledná φ φ φφφφ φ

ΦΦΦ • ΦΦΦ • φφφφ • φ φ φ φ · φφφφ ·· kontrolní hodnota se uloží jako ověřovací hodnota vedlejšího adresáře v referenčním hlavním adresáři.

Lze předpokládat další provedení, například, provedení, ve kterém se data souboru kódují podle kódovacího algoritmu a kódovací klíč (nebo jeho identifikační číslo klíče) se použije jako ověřovací hodnota uložená ve vedlejším adresáři. Tento klíč souboru může být dále kódován a kódovací klíč se uloží v hlavním adresáři jako ověřovací hodnota, a podobně. Ačkoliv je možné, je toto provedení mnohem složitější pro uvedení do praxe v důsledku zvýšené složitosti operací potřebných pro generování hodnot kódovacích klíčů.

Naproti tomu použití kontrolního algoritmu pro provádění ověřování každého modulu umožňuje provedení obzvláště jednoduché a rychlé kontroly integrity každého modulu. V jednom provedení může být použit jednoduchý kontrolní algoritmus, jako je výpočet kontrolního součtu. To by ale neumožňovalo detekci zfalšování, protože je relativně jednoduché určit jak jakákoliv změna ve zprávě ovlivní kontrolní hodnotu.

Výhodně kontrolní algoritmus odpovídá algoritmu bezpečnému z hlediska šifrování (kódování), který generuje v podstatě unikátní kontrolní hodnotu z dané sady dat. Vhodné kontrolní algoritmy, které mohou být použity pro tento účel, zahrnují například algoritmus Message Digest verze 5 (MD5) nebo algoritmus Secure Hash Algorithm (SHA).

Výhodně se ověřování dat souboru pro množství souborů provádí prostřednictvím aplikace kontrolního algoritmu na akumulaci dat z množství souborů pro vytvoření jedné kontrolní hodnoty. Stejně tak může být ověřování mnoha • ·· · · «· • ·

Μ ···· vedlejších adresářů prováděno prostřednictvím aplikace kontrolního algoritmu na akumulaci ověřovacích hodnot souborů z množství vedlejších adresářů (a na další data, pokud je to žádoucí) pro vytvoření jedné kontrolní hodnoty.

Použití kumulativního kontrolního procesu pro pokrytí množství datových modulů (souborů, vedlejších adresářů, a podobně) v nižší vrstvě dále zjednodušuje předkládaný systém ve srovnání, například, se systémy, které ukládají seznam jednotlivých kontrolních hodnot pro každý modul. To opět systému podle vynálezu umožňuje omezit počet výpočtových kroku potřebných v každé úrovni, přičemž zároveň se snižuje velikost ověřovacích dat uložených v horní vrstvě.

V případě provedení, využívajících kontrolní algoritmus pro ověřování každé vrstvy, bude systém 15 otevřený, to znamená, že všechny kontrolní hodnoty budou čitelné až do hlavního adresáře. Protože kontrolní algoritmy jsou veřejně přístupné, mohl by třetí účastník teoreticky změnit uložená data, například na úrovni souboru, bez detekce, pokud by současně byly také změněny odpovídající

0 kontrolní hodnoty v úrovni vedlejších adresářů a hlavního adresáře.

Aby se tomu zabránilo, alespoň některá data, uložená v hlavním adresáři, se podrobí tajnému klíči kódovacího algoritmu a výsledná kódovaná hodnota se uloží v hlavním adresáři. Výhodně kódovaná hodnota odpovídá'digitálnímu podpisu. Vhodné algoritmy privátního/veřejného klíče pro tento účel zahrnují, například, RSA algoritmus.

Výhodně data, kódovaná tajným klíčem pro vytvoření podpisu uloženého v hlavním adresáři, zahrnují alespoň jednu φ* « ···· φ nebo více ověřovacích hodnot vedlejšího adresáře. Je nicméně možné za účelem uzavření systému použít pro označení podpisem v hlavním adresáři data jiná, než jsou ověřovací hodnoty vedlejších adresářů.

V alternativním provedení k vytváření podpisu může být celý hlavní adresář, nebo jeho část, jednoduše kódován nebo šifrován, přičemž přijímač má v držení ekvivalentní klíč pro dekódování kódovaných data hlavního adresáře. V tomto případě může být použito algoritmu symetrického klíče, jako Ί D ήθ a 1 σΛπ ťninc DF.H .

Jak by mělo být zcela zřejmé, ačkoliv byl ověřovací proces popsán výše ve spojení s odkazy na dvě hierarchické úrovně, mohou být podobné ověřovací kroky prováděny do nekonečna pro další odkazované soubory, vedlejší adresáře, hlavní adresáře, a podobně.

Podobně, ačkoliv výše byla struktura definována z důvodu jednoduchosti popisu jako hlavní adresář/vedlejsí adresář/soubor, nepředpokládají se žádné zvláštní vlastnosti každé jednotky ve vrstvě jiné, než že na jednotku nižší vrstvy je odkazováno dvěma jednotkami vyšších vrstev. Jak by melo být zcela zřejmé, datová struktura může mít stejně tak tvar hlavní adresář/vedlejší adresář/druhý hlavní adresář nebo tvar jakékoliv jiné další kombinace.

Následující popisovaná provedení se zaměřují na jednotku ve spodní vrstvě, to jest na kterou je odkazováno adresářem nebo vedlejším adresářem. Jak bude zcela zřejmé, ačkoliv je na ni odkazováno z vyšší vrstvy, může být tato jednotka nicméně sama adresářovou jednotkou, vedlejší adresářovou jednotkou, a podobně.

·· ♦ · · ·· ···»

V jednom provedení jedna odkazovaná jednotka obsahuje kódovanou hodnotu generovanou tajným klíčem,, přičemž ověřovací hodnota pro tuto jednotku se vypočítá na základě výsledků ověřovacího algoritmu na této kódované hodnotě a uložené v referenční (odkazující) jednotce. Zejména tedy, jako u výše popisovaného ekvivalentního provedení hlavního adresáře, může být odkazovaná jednotka označena podpisem, přičemž ověřovací hodnota pro tuto jednotku se vypočítá jako výsledek kontrolní funkce tohoto podpisu.

Odkazovaná jednotka může odpovídat, například, » souboru nebo vedlejšímu adresáři. Toto provedení je zejména upraveno pro situaci, ve které je odkazovaná jednotka hlavním adresářem pro další sadu dat, například dat odlišného původu, a ve které odkazovaná hlavní adresářová jednotka rovněž ₀ obsahuje podpis. V tomto případě muže první operátor sestavit podpisová data až do úrovně hlavního adresáře.

Potom druhý operátor může odkazovat na tato data bez znalosti kódovacího klíče, přičemž jakákoliv vazba se jednoduše ověřuje v referenční (odkazující) jednotce prostřednictvím kontrolní hodnoty podpisu v odkazovaném hlavním adresáři. Ověřování obou sad dat bude samozřejmě možné pouze pro přijímač, který má v držení potřebné klíče pro ověřování podpisů v obou hlavních adresářích.

Jak bylo popisováno výše, může být předkládaný vynález aplikován pro jakoukoliv sadu datových jednotek ve vícenásobné hierarchii. Vynález může být dokonce aplikován pro organizaci tabulek nebo paketů v transportním toku, pokud v paketovém toku může být vytvořeno více úrovní s hlavním

3Q adresářem, vedlejším adresářem, souborem, a podobně. Vynález je ale obzvláště použitelný v případě, ve kterém jednotky

A A

Aaa

AAAA A

A A

AA AAA* odpovídají sadě datových souborů začleněných v datových tabulkách nebo úsecích, přičemž tyto tabulky se dále začleňují do datových paketů pro vytvoření transportního toku.

Oproti ověřování na úrovni paketů nebo tabulek umožňuje toto provedení úplnou nezávislost mezi sestavou ověřených dat a jejím začleněním v transportním toku a rovněž usnadňuje dodávání softwaru z různých zdrojů do transportního toku kontrolovaného jedním přenosovým operátorem. Data l*“¹ ověřená podle tohoto provedení mohou být dokonce vysílání po různých vysílacích cestách (například dvousměrnou telekomunikační linkou nebo satelitní linkou) s využitím alternativních formátů začlenění pro vysílání dat.

Datové jednotky výhodně odpovídají datovým objektům formátovaným podle standardu DSMCC. V jednom provedení jsou potom datové objekty začleňovány do tabulek a paketů odpovídajících standardu MPEG.

Podle druhého aspektu předkládaného vynálezu je

2o navržen způsob ověřování první a druhé sady propojených datových jednotek vysílaných v digitálním vysílacím systému, jehož podstata přitom spočívá v tom, že alespoň jedna jednotka z první sady jednotek obsahuje podpis generovaný tajným klíčem aplikovaným na tuto první jednotku, přičemž alespoň tato hodnota podpisu se ověřuje ověřovacím algoritmem a ověřovací hodnota se uloží v jednotce v druhé sadě jednotek, která odkazuje na tuto první jednotku.

Podle třetího aspektu předkládaného vynálezu je navržen způsob ověřování dat vysílaných v digitálním vysílacím systému, jehož podstata spočívá v tom, že data se ···· * organizují v sériích datových souborů, přičemž ověřování se provádí mezi soubory nezávisle na a před fází nebo fázemi formátování a začleňování dat použitých digitálním vysílacím systémem pro přípravu dat pro vysílaní v paketovém transportním toku.

Ověřování může být prováděno zejména před formátováním do tabulek nebo úseků, přičemž tabulky se potom začleňují do datových paketů v transportním paketovém toku.

Jak bylo zmiňováno výše, použití ověřovacího procesu aplikovaného před přípravou dat pro vysílání má ten účinek, že data potom mohou být směrována do přijímače jakýmkoliv počtem kanálů, jako je přenosový kanál nebo telekomunikační kanál, bez změny ověřovacího procesu. Stejně tak, jakmile přijímač nebo dekodér již obnovil datové soubory z formátu sdruženého s vysílací cestou, může být provedeno ověření na těchto datech nezávisle na zvoleném režimu vysílání.

Jakýkoliv nebo všechny znaky prvního aspektu předkládaného vynálezu a jeho výhodných provedení mohou být samozřejmě kombinovány s druhým a se třetím aspektem vynálezu.

Předkládaný vynález byl popsán výše ve spojení s kroky pro generování ověřovacích dat před vysíláním. Vynález ale ve svých obecných a výhodných provedeních stejně tak platí pro obrácené kroky prováděné v přijímači pro ověřování těchto dat.

V nejobecnějších aspektech může být předkládaný vynález aplikován pro jakýkoliv digitální vysílací systém. Vynález je ale obzvláště výhodně aplikován pro digitální televizní systém a zejména pro datové moduly nesoucí • · ··· · · • · · ► · · >· ··♦· aplikační software pro použití v přijímači/dekodéru digitálního televizního systému.

Zde použitý termín digitální vysílací systém zahrnuje jakýkoliv vysílací systém pro vysílání nebo přenos, například, primárně audiovizuálních nebo multimediálních digitálních dat. Ačkoliv je předkládaný vynález zejména využitelný pro přenosový (vzduchem) digitální televizní systém, může být tento vynález rovněž použitelný pro pevnou telekomunikační síť pro multimediální internetovské aplikace, pro uzavřený televizní okruh a podobně. Jak by mělo být zcela zřejmé, zde použitý termín digitální televizní systém zahrnuje například jakýkoliv satelitní, pozemní, kabelový nebo jiný systém.

Termín přijímač/dekodér nebo dekodér používaný v tomto popisu může zahrnovat přijímač pro přijímání bud' kódovaných nebo nekódovaných signálů, například televizních a/nebo rádiových signálů, které mohou být přenášeny nebo vysílány nějakým dalším prostředkem. Tento termín může rovněž zahrnovat dekodér pro dekódování přijímaných signálů. Provedení takovýchto přijímačů/dekodérů mohou zahrnovat dekodér integrální s přijímačem pro dekódování přijímaných signálů, například, v nastavovací řídící skříni (STB), nebo takový dekodér, který funguje v kombinaci s fyzicky samostatným přijímačem, nebo takový dekodér, který zahrnuje přídavné funkce, jako je webový prohlížeč, a/nebo je integrován s dalšími zařízeními, jako je videorekordér nebo televize.

Termín MPEG označuje standardy datového přenosu, vyvinuté Mezinárodní Standardizační Organizací v pracovní skupině Expertní skupina pro film a zejména, ale ne ···· 9 ·· ···· výhradně, standard MPEG-2 vyvinutý pro digitální televizní aplikace a definovaný v dokumentech ISO 13818-1, ISO 13818-2, ISO 13818-3 a ISO 13818-4. V kontextu s touto přihláškou předkládaného vynálezu tento termín zahrnuje všechny varianty, modifikace nebo rozvinutí MPEG formátů použitelných pro oblast digitálního datového přenosu.

Termín DSMCC označuje standardy formátování datových souborů, popsané v MPEG dokumentech a v aktuálním dokumentu

ISO 13816-6.

v následujícím popisu budou pouze prostřednictvím příkladu popsána výhodná provedení předkládaného vynálezu ve spojení s odkazy na připojené výkresy.

Přehled obrázků na výkresech 15

Obr.l znázorňuje schematický náčrtek digitálního televizního systému pro použití s předkládaným vynálezem;

Obr. 2 znázorňuje strukturu dekodéru systému podle ^Obr- ^1;

Obr. 3 znázorňuje strukturu množství komponentů uvnitř MPEG přenosového transportního toku;

Obr. 4 znázorňuje rozdělení softwarové aplikace na množství MPEG tabulek;

Obr. 5 znázorňuje vztah mezi DSMCC datovými soubory a případně vytvořenými MPEG tabulkami;

Obr. 6 znázorňuje vztah klient server (obslužný kanál, správce sítě, jak je definován v kontextu DSMCC;

• · · ' · ···· · ·· ♦«·· ·· ·».

Obr.7 znázorňuje ověřené adresářové, vedlejší adresářové a souborové objekty v tomto provedení vynálezu.

Příklady provedeni vynálezu 5

Celkový přehled digitálního televizního systému i podle předkládaného vynálezu je znázorněn na obr. 1. Předkládaný vynález zahrnuje většinou běžný digitální televizní systém 2., který využívá známý MPEG-2 kompresní systém pro vysílání komprimovaných digitálních signálů.

Přesněji MPEG-2 komprimátor 3 ve vysílacím centru přijímá tok digitálního signálu (obvykle tok video signálů). Komprimátor 2 je spojen s multiplexorem a kodérem 4. prostřednictvím spojení 5.·

Multiplexor 4. přijímá množství dalších vstupních signálů, sestavuje transportní tok a vysílá komprimované digitální signály do vysílače 2 vysílacího centra přes spojení 7_, které samozřejmě může být představováno velkým množstvím různých forem včetně telekomunikačních linek.

Vysílač 6 vysílá elektromagnetické signály přes vzestupné spojení 2 směrem k satelitnímu odpovídači 2/ kde jsou tyto signály elektronicky zpracovány a vysílány přes teoretické sestupné spojení 10 do pozemního přijímače 12, běžně ve formě parabolické antény vlastněné nebo pronajímané koncovým uživatelem. Signály přijímané přijímačem 12 jsou vysílány do integrovaného přijímače/dekodéru 13 vlastněného nebo pronajímaného koncovým uživatelem a spojeného s televizním zařízením 14 koncového uživatele. Přijimač/dekodér 13 dekóduje komprimovaný MPEG-2 signál na televizní signál pro televizní zařízení .14.

ΦΦΦΦ β • ♦ ♦ · φ • φ · · · · · • · · · t φ ·· ··♦· «·ι

Jiné transportní kanály pro vysílání dat jsou samozřejmě možné, jako je pozemní přenos, kabelové vysílání, kombinované satelitní a kabelové spoje, telefonní sítě a podobně.

Ve vícekanálovém systému, multiplexor 4. zpracovává audio a video informace přijímané z množství paralelních zdrojů a interaguje s vysílačem 6, pro přenos informace po odpovídajícím počtu kanálů. Vedle audiovizuální informace, mohou být zprávy nebo aplikace nebo jakýkoliv jiný druh digitálních dat zaváděny do některých nebo do všech těchto kanálů, proloženě s vysílanou digitální audio a video informací. V takovém případě tok digitálních dat ve formě, například, softwarových souborů a zpráv ve formátu DSM-CC, bude komprimován a paketován do MPEG formátu prostřednictvím komprimátoru 3. Stahování softwarových modulů bude popsáno podrobněji níže.

Systém 15 podmíněného přístupu je spojen s multiplexorem 4. a přijímačem/dekodérem 13 a je umístěn částečně ve vysílacím centru a částečně v dekodéru. Tento systém umožňuje koncovému uživateli přístup k digitálním televizním vysíláním (přenosům) od jednoho nebo více dodavatelů (poskytovatelů) vysílání. Inteligentní karta, schopná dekódování zpráv týkajících se komerčních nabídek (to jest jeden nebo několik televizních programů, které jsou prodávány dodavatelem vysílání), může být vložena do přijímače/dekodéru 13. S použitím dekodéru 13 a inteligentní karty může koncový uživatel nakupovat komerčně nabízené vysílané událostí buď v módu předplacení nebo v módu platby za shlédnutí. V praxi dekodér může být konfigurován pro _ „ · · · · · · φ « ···* · ·· ···* ·* ··· zpracování řídicích systémů s vícenásobným přístupem, například konstrukce Simulcrypt nebo Multicrypt.

Jak bylo zmiňováno výše, programy vysílané systémem jsou kódovány v multiplexoru 4., přičemž podmínky a kódovací klíče, aplikované na daný přenos, jsou určovány systémem 15 podmíněného přístupu. Vysílání kódovaných dat tímto způsobem je velmi dobře známé v oblasti placených TV systémů. Obvykle jsou kódovaná data vysílána společně s řídícím slovem pro dekódování těchto dat, přičemž řídící slovo je samo kódováno prostřednictvím tak zvaného exploatačního klíče a vysíláno v kódované formě.

Kódovaná (šifrovaná) data a kódované (šifrované) řídící slovo jsou potom přijímána dekodérem 13, který má přístup k ekvivalentu exploatačního klíče, který je uložen na inteligentní kartě vložené do dekodéru, pro dekódování kódovaného řídícího slova a potom pro dekódování vysílaných dat. Předplacený účastník bude přijímat, například, v přenášené měsíční EMM (opravňovací ovládací zpráva) exploatační klíč potřebný pro dekódování kódovaného řídícího slova a tak pro umožnění sledování vysílání. Vedle jejich použití pro dekódování audiovizuální televizních programů mohou být podobné exploatační klíče generovány a vysílány pro použití při ověřování dalších dat, jako jsou softwarové moduly, jak bude popsáno níže.

Interaktivní systém 16, rovněž spojený s multíplexorem 4. a přijímačem/dekodérem 13 a opět umístěný částečně ve vysílacím centru a částečně v dekodéru, umožňuje koncovému uživateli interagovat s různými aplikacemi přes modemový zpětný kanál 17 . Modemový zpětný kanál 17 může být rovněž využit pro komunikace použité v systému 15 podmíněného ···« « ·· ···* ·· * přístupu. Interaktivní systém 16 může být použit, například, pro umožnění divákovi komunikovat bezprostředně s vysílacím centrem pro požadavek o autorizaci sledování určité události, stažení aplikace a podobně.

Ve spojení s odkazy na obr. 2 budou nyní stručně popsány prvky přijímače/dekodéru 13, nebo nastavovací řídící skříně (STB - set top box), upravitelného pro použití v předkládaném vynálezu. Prvky znázorněné na tomto obrázku budou popsány ve spojení s odkazy na funkční bloky.

Πλ L· λχ A v» 1 T

Ljcz nuctO u_ x >> LiUiii. uu. j u · ntrální řídící jednotku 20 obsahující přidružené paměťové prvky a upravenou pro příjem vstupních dat ze sériového rozhraní 21, paralelního rozhraní 22 a modemu 23 (spojeného s modemovým zpětným kanálem 17 podle obr. 1).

Dekodér 13 je navíc upraven pro přijímání vstupů z infra-červeného dálkového ovládání 25 přes řídící jednotku 26 a z přepojovacích kontaktů 24 na předním panelu dekodéru. Dekodér rovněž má dvě zařízení 27, 28 pro čtení inteligentních karet, která jsou upravena pro čtení bankovních inteligentních karet 29 respektive účastnických inteligentních karet 30. Zařízení 28 pro čtení účastnických inteligentních karet zabírá s vloženou účastnickou inteligentní kartou 30 a s jednotkou 29 podmíněného přístupu pro dodání potřebného řídícího slova do čemultiplexoru/dekódovacího zařízení 30 pro umožnění dekódování kódovaného vysílaného signálu. Dekodér 13 rovněž obsahuje běžný ladič 31 (tuner) a demodulátor 32 pro příjem a demodulaci satelitního vysílání před filtrováním a demultiplexováním zařízením 30.

**«·

Zpracování dat uvnitř dekodéru je realizováno prostřednictvím centrální řídící jednotky 20. Softwarová architektura této řídící jednotky odpovídá virtuálnímu počítači interagujícímu s operačním systémem nižší úrovně, který je realizován v hardwarových součástkách dekodéru.

V následujícím popisu bude nyní ve spojení s odkazy na obr. 3 a obr. 4 popsána paketová struktura dat uvnitř přenášeného MPEG transportního toku vysílaného z vysílače do dekodéru. Jak bude zcela zřejmé, ačkoliv se popis zaměří na tabulkový formát použitý ve standardu MPEG, platí stejné principy stejně i pro jiné formáty paketovaných datových toků.

Jak je zejména patrné z obr. 3, obsahuje MPEG bitový tok přístupovou tabulku (PAT) 40 programů mající identifikátor paketu (PID) s hodnotou 0. PAT obsahuje odkazy na mapovací tabulky (PMT) 41 programů pro množství programů. Každý PMT obsahuje odkaz na PID toků audio MPEG tabulek 42 a video MPEG tabulek 43 pro daný program. Paket mající PID nula, to jest přístupová tabulka 40 programů, zajišťuje vstupní bod pro veškerý MPEG přístup.

Za účelem stahování aplikací a dat pro tyto aplikace jsou definovány nové typy toků a příslušná PMT rovněž obsahuje odkazy na PID toků aplikačních MPEG tabulek 44 (nebo jejich úseků) a datových MPEG tabulek 45 (nebo jejich úseků). I když ve skutečnosti může být v některých případech výhodné definovat samostatné typy toků pro proveditelný aplikační software a data pro zpracování tímto softwarem, není to nijak podstatné. V jiných provedeních data a strojový kód mohou být sestaveny do jednoho toku, ke kterému se přistupuje přes PMT, jak bylo popsáno.

4 • Φ • · • ΦΦΦ « · · Φ Φ • · 9 9 4 9 4

4 4 4 4

9449 49 *

Φ

ΦΦ 4

Jak je patrné z obr. 4, aby byla stažena, například, aplikace uvnitř toku 44, je aplikace 46 rozdělena do modulů 47, z nichž každý je tvořen MPEG tabulkou. Některé z těchto tabulek zahrnují jeden úsek, zatímco jiné mohou být tvořeny množstvím úseků 48. Typický úsek 48 má záhlaví, které obsahuje jedno-bytový identifikátor (TID) 50 tabulky, číslo 51 úseku pro tento úsek v tabulce, celkový počet 52 úseků v této tabulce a dvou-bytové TID rozšíření 53. Každý úsek rovněž obsahuje datovou část 54 a CRC 55. Pro určitý modul nebo tabulku 47 mají všechny úseky 48, tvořící tuto tabulku 47, stejný TID 50 a stejné TID rozšíření 53. Pro určitou aplikaci 46 mají všechny tabulky, tvořící tuto aplikaci 46, stejný TID 50, ale odlišná příslušná TID rozšíření.

Pro každou aplikaci 46 je použita jedna MPEG tabulka jako adresářová tabulka 56. Tato adresářová tabulka 56 ma ve svém záhlaví stejný TID jako ostatní tabulky 47 tvořící aplikaci. Adresářová tabulka má ale předem stanovené TID rozšíření nula pro identifikaci účelu a v důsledku této skutečnosti je pouze jedna tabulka potřebná pro informaci v adresáři. Všechny ostatní tabulky 47 budou obvykle mít nenulové TID rozšíření a jsou sestaveny z množství sdružených úseků 48. Záhlaví adresářové tabulky rovněž obsahuje číslo verze aplikace, která má být stažena.

Jak je opět patrné z obr. 3, PAT 40, PMT 41 a aplikační a datové komponenty 44., 45 toku jsou cyklicky vysílány. Každá aplikace, která je vysílána, má příslušný předem stanovený TID. Pro stažení aplikace je MPEG tabulka, mající příslušné TID a TID rozšíření nula, stažena do přijímače/dekodéru. To je adresářová tabulka pro požadovanou ³⁰ aplikaci. Data v adresáři se potom zpracují dekodérem pro · · * • · « · · • · * ·· ··· určeni TID rozšíření tabulek tvořících požadovanou aplikaci. Potom může být stažena jakákoliv požadovaná tabulka, mající stejné TID jako adresářová tabulka a mající TID rozšíření určené z adresáře.

Dekodér je uspořádán pro kontrolu adresářové tabulky pro jakékoliv její aktualizování. To může být prováděno opětovným periodickým stahováním adresářové tabulky, například každých 30 sekund, nebo jednu nebo pět minut, a porovnáním čísla verze s předtím staženou adresářovou tabulkou. Pokud čerstvě stažené číslo verze je číslo pozdější verze, pak jsou tabulky sdružené s předcházející adresářovou tabulkou vymazány a tabulky sdružené s novou verzí adresářové tabulky jsou staženy a sestaveny.

V alternativním uspořádání je příchozí bitový tok filtrován s použitím masky, odpovídající TID, TID rozšíření a číslu verze, s hodnotami nastavenými pro TID aplikace, TID rozšíření nula a číslo verze o jednu větší než je číslo verze aktuálně staženého adresáře. Podle toho tedy může být detekován přírůstek čísla verze, přičemž jakmile je detekován, je stažen adresář a aplikace je aktualizována, jak bylo popisováno výše. Pokud má být aplikace ukončena, je vysílán prázdný adresář s následujícím číslem verze, ale bez jakýchkoliv modulů uvedených v seznamu adresáře. V odezvě na přijetí takového prázdného adresáře, je dekodér 13 naprogramován pro vymazání této aplikace.

V praxi mohou být software a počítačové programy pro realizaci aplikací v dekodéru zaváděny přes kteroukoliv z částí dekodéru, zejména v datovém toku přijímaném přes satelitní linku, jak bylo popisováno, ale rovněž přes sériový port, linku pro inteligentní kartu, a podobně. Takový ·««« software může zahrnovat vysokoúrovňové aplikace použité pro realizaci interaktivních aplikací uvnitř dekodéru, jako jsou internetovské prohlížeče, kviz aplikace, programové průvodce, a podobně Software může být rovněž stahován pro změnu pracovního uspořádání softwaru dekodéru, například prostřednictvím oprav nebo podobně.

Aplikace mohou být rovněž stahovány přes dekodér a vysílány do PC, nebo podobně, spojeného s dekodérem. V takovém případě dekodér působí jako komunikační směrovací kanál pro software, který jc případně spouštěn na připojeném zařízení. Kromě směrovací funkce může dekodér rovněž fungovat pro přeměnu MPEG paketovaných dat před směrováním do PC na počítačový software souboru, organizovaný například podle protokolu DSMCC (viz níže).

V předcházejícím popisu byla opatření, realizovaná pro ověření úplnosti a původu aplikačních dat, zaměřena na ověřování tabulek v MPEG paketovém toku. Přesněji je u běžných systémů kontrolní funkce aplikována na každý z individuálních úseků 48 před vysíláním a výsledná kontrolní hodnota nebo podpis pro každý úsek je uložena v seznamu v adresářové tabulce 56 vyslané do dekodéru. Porovnání kontrolní hodnoty následně vypočítané dekodérem s kontrolní hodnotou uloženou v adresáři pro přijatý úsek umožňuje ověření integrity přijatého úseku.

Data uvnitř adresáře 40 mohou být stejně tak podrobena kontrolnímu procesu pro generování další ověřovací hodnoty nebo podpisu pro adresářovou tabulku 40. Navíc může být tato ověřovací hodnota kódována (šifrována) prostřednictvím privátního klíče a může být uložena v • « •· *··♦ • * • · ···· · • ·· adresářové tabulce. Pouze ty dekodéry, které mají v držení odpovídající veřejný klíč, mohou ověřovat podpis.

Na rozdíl od takovýchto běžných systémů se předkládaný vynález týká prostředku pro zabezpečení a ověření aplikačních dat organizovaných ve vícenásobné hierarchii datových souborů nebo objektů na úrovni aplikace. To bude mnohem srozumitelnější z obr. 5, který znázorňuje vztah mezi daty organizovanými v sadě DSMCC U-U datových souborů 60 v sestavené aplikaci 46 a začleněnými uvnitř sady MPEG tabulek

Λ H

I .

Před vysíláním jsou datové soubory sestaveny do aplikace 46 a potom jsou formátovány prostřednictvím MPEG komprimátoru do MPEG tabulek nebo modulů 4 7, jak bylo popisováno výše, včetně záhlaví 49 specifického pro MPEG paketový tok a obsahujícího ID tabulky, číslo verze, a podobně. Tyto tabulky jsou potom začleněny MPEG komprimátorem do MPEG paketů. Jak bude zcela zřejmé, nemusí být pevný vztah mezi daty organizovanými v datových souborech 61 a případnými MPEG tabulkami 47. Po přijetí a filtrování dekodérem jsou záhlaví paketů vypuštěna a série tabulek jsou obnoveny z užitečných obsahů přenášených paketů. Potom jsou záhlaví 49 tabulek vypuštěna a aplikace 46 je obnovena z užitečných obsahů tabulek 47.

DSMCC formát pro datové soubory je standard upravený speciálně pro použití v multimediálních sítích, který definuje série formátů zpráv a relačních příkazů pro komunikaci mezi uživatelem typu klient 7 0, uživatelem typu server 71 (obslužný kanál), a správcem 72 síťových zdrojů, jak je patrné na obr. 6. Správce 72 síťových zdrojů může být považován za logickou entitu pracující pro správu přidělování * · ·· ♦♦·* ··«· ♦ at

999 zdrojů uvnitř sítě. Ačkoliv byl původně zamýšlen pro použití ve spojení s dvousměrnou komunikací v síti, zaměřily se nedávné realizace DSM-CC standardu na jeho využití pro účely jednosměrného přenosu.

Komunikace mezi klientem a serverem je nastavena prostřednictvím sérií relací, přičemž první série zpráv je vyměňována mezi uživatelem (klientem 70 nebo serverem 71) a správcem 72 sítě, aby se konfiguroval klient a/nebo server pro komunikaci. Takové zprávy jsou formátovány podle tak zvaného DSMCC 0-N (uživatel - síť) protokolu. Podskupina tohoto protokolu byla definována speciálně pro přenosové stahování dat.

Jakmile již byla vytvořena komunikační linka, jsou mezi klientem 70 a serverem 71 následně vyměňovány zprávy podle DSMCC U-U (uživatel - uživatel) protokolu. Sekvence zpráv tohoto typu odpovídá datovým souborům 60 podle obr. 5.

V případě DSMCC U-U zpráv jsou data organizována v sériích zpráv 61 seskupených podle protokolu BIOP nebo Broadcast InterOrb Protocol.

Každá zpráva nebo objekt 61 zahrnuje záhlaví 62, pod-záhlaví 63 a užitečný obsah 64 obsahující samotná data. Podle protokolu BIOP záhlaví kromě jiného obsahuje indikaci o typu zprávy a verzi protokolu BIOP, zatímco pod-záhlaví identifikuje typ objektu a další informace, které mají být definovány architektem systému.

Datové objekty 64 uvnitř užitečného obsahu DSMCC U-U souborů mohou být obecně definovány jako jeden ze tří typů: adresářové objekty, souborové objekty a objekty toku.

Adresářové soubory definují hlavní adresáře nebo vedlejší »*·· * ·· ·»·· ·· · adresáře použité pro odkazování na série přidružených souborových objektů obsahujících vlastní aplikační data.

Objekty toku mohou být použity pro umožnění vytvoření dočasného vztahu mezi daty, obsaženými v datových souborech, a samotným MPEG paketovým tokem. To může být využito, například, v případě interaktivních aplikací obsažených v datových souborech a zkonstruovaných tak, aby byly synchronizovány se základními video nebo audio toky přijímanými a zpracovávanými dekodérem. Jak bylo zmiňováno výše, jinak zde nemusí být žádný vztah mezi MPEG paketovanými daty a datovými soubory.

Oproti MPEG tabulkám, kde jeden adresář odkazuje na sadu tabulek s pouze jednou úrovní hierarchie, mohou být datové soubory 60 organizovány v mnohem složitějším hierarchickém uspořádání. Jako u souborů uložených v PC nebo serveru, může hlavní adresář odkazovat na jeden nebo více vedlejších adresářů (podadresářů), které dále odkazují na druhou úroveň datových souborů. Mohou být dokonce vytvářeny

2Q odkazy na druhý hlavní adresář sdružený s další sadou aplikačních dat.

Na obr. 7 je znázorněn příklad struktury souborů pro sadu datových souborů nebo jednotek. Hlavní adresář DIR AO 75 odkazuje na skupinu vedlejší adresářů Al až A4 7 6. Každý vedlejší adresář 76 odkazuje na jednu nebo více sad přidružených souborových objektů 77. Pro jednoduchost je znázorněna pouze jedna skupina objektových souborů Fl, F2 a tak dále, sdružených s vedlejším adresářem A4. V praxi může být každým vedlejším adresářem Al až A4 odkazováno na množství skupin objektových souborů.

« · ·· ··»·

V« · · φ • · »

Uvnitř každého adresáře a vedlejšího adresáře je začleněna sada ověřovacích kroků pro soubory spojené s tímto adresářem. S odkazem na hlavní adresář 75 zahrnuje pod-záhlaví 63 kontrolní hodnotu získanou aplikací kontrolního algoritmu na některá nebo na všechna data uložená v souborech Al až A4 vedlejších adresářů 7 6. Použitým kontrolním algoritmem může být jakýkoliv známý typ algoritmu, jako je například algoritmus Message Digest MD5.

V jednom provedení může být tento algoritmus aplikován na každý přidružený soubor nebo vedlejší adresář individuálně a před vysíláním se do hlavního adresáře 25 uloží seznam kontrolních hodnot pro každý vedlejší adresář 76. Ačkoliv ale takovéto řešení umožňuje zvýšený stupeň kontrolního rozlišení ve smyslu ověření každého vedlejšího adresáře, může být řešení spíše neúčinné ve smyslu doby zpracování, potřebné pro dekodér, aby vypočítal odpovídající podpisy.

Podle toho tedy pod-záhlaví 63 adresáře 75 výhodně zahrnuje kumulativní kontrolní hodnotu 21/ vypočítanou aplikací MD5 kontrolního algoritmu na kombinované úseky 63, pod-záhlaví a užitečného obsahu vedlejšího adresáře 21/ to jest bez záhlaví 62. Přesněji jsou do tohoto kontrolního výpočtu zahrnuty kontrolní hodnoty 82 obsažené uvnitř vedlejších adresářů 76 a odkazující na vrstvu souborových objektů 12·

V případě vedlejšího adresáře A4, znázorněného na obr. 7, tento vedlejší adresář sám odkazuje na sadu souborových objektů F1 až F_n 22- V tomto případě kumulativní kontrolní hodnota 82 je vytvářena pro kombinované obsahy souborových objektů 21- Tato hodnota je začleněna do ·· *··· ·* ··' kontrolního procesu, čímž vzniká kontrolní hodnota 79. Není tedy možné změnit jakýkoliv ze souborových objektů 77 bez změny kontrolní hodnoty 82 vedlejšího adresáře 76, což by dále změnilo kontrolní hodnotu 79 adresáře 75.

V prezentovaném případě je kombinovaná kontrolní hodnota vypočítána pro všechny z vedlejších adresářů Al až A4 odkazovaných v adresáři. Tato kontrolní hodnota se uloží společně s identifikátorem skupiny vedlejších adresářů, ze kterých byla data použita. V jiných provedeních mohou být série kombinovaných nebo individuálních kontrolních hodnot a odpovídající identifikátory uloženy v pod-záhlaví adresáře.

Například druhá sada vedlejších adresářů, rovněž sdružená s hlavním adresářem, ale týkající se odlišné sady dat nebo strojového kódu, může být rovněž seskupena dohromady a kumulativní kontrolní hodnota může být vypočítána pro tyto vedlejší adresáře vypočítané a uložené v pod-záhlaví hlavního adresáře. Jedna kontrolní hodnota, sdružená s jedním adresářem, může být stejně tak uložena v pod-záhlaví hlavního adresáře.

Ověření skupin individuálních datových souborů nezabrání samozřejmě hlavnímu adresáři (nebo vlastně jakémukoliv jinému souboru) v tom, aby rovněž odkazoval na neplatné nebo nekontrolované datové soubory, ale absence platnosti takového souboru bude muset být vzata do úvahy při jakýchkoliv operacích s tímto souborem. V tomto ohledu nemusí být například nutné ověřovat objekty toku.

Použití kontrolní funkce v tomto případě primárně umožňuje dekodéru ověřovat integritu nebo úplnost stahovaných datových souborů. V případě, například, chyby nebo poškození ·· φ · » φφ φφφφ

Φφφ φ * φ ·· φφφ ve vysílání neposkytne operace kumulativního kontrolního algoritmu na přijatých závislých souborech stejný výsledek jako kontrolní hodnota pro tyto soubory, uložená v hlavním adresáři. Dekodér potom bude upozorněn na přítomnost případných chyb ve stahovaných datech a bude opětovně stahovat chybové datové soubory.

Jak by mělo být zcela zřejmé, v případě kontrolního algoritmu se výpočet kontrolní hodnoty provádí podle veřejně známých sérií výpočtových kroků a proto tedy kdokoliv může θ generovat kontrolní hodnotu pro danou sadu datových souborů. Není tedy za obvyklých okolností možné ověřit původ takových datových souborů jednoduchým ověřením kontrolních hodnot.

Pro překonání tohoto problému je vypočítána hodnota podpisu pro hlavní adresář 75 s použitím hodnoty tajného klíče známého pouze operátorovi. Tento klíč může odpovídat klíči získanému prostřednictvím algoritmu symetrického klíče, jako je algoritmus Data Encryption Standard nebo DES. Výhodně se ale použije algoritmu privátního/veřejného klíče, jako je algoritmus Rivest, Shamir a Alteman nebo RSA, přičemž ⁰ operátor odpovědný za vytváření datových souborů vlastní hodnotu privátního klíče a hodnoty veřejných klíčů mají v držení dekodéry.

Jak je znázorněno na obr. 7, hlavní adresář 7 5 zahrnuje magické číslo nebo identifikátor klíče či spíše číslo 80 klíče, které bude identifikovat dekodéru veřejný klíč, který má být použit v ověřovací fázi společně s vypočítanou hodnotou 81 podpisu, generovanou s využitím privátního klíče operátora. V tomto případě je hodnota 81.

q podpisu generována aplikací privátního klíče, drženého operátorem, na některá nebo všechna data uvnitř adresáře 75, ··· fr · •· ···« • · · výhodně zahrnující data užitečného obsahu 64 a/nebo kumulativní kontrolní hodnotu nebo hodnoty 7 9. Dekodér potom může ověřit tuto hodnotu 81 podpisu s využitím odpovídajícího veřejného klíče identifikovaného číslem 80 klíče.

V tomto příkladu jsou data v adresáři 75 nekódovaná a privátní klíč je jednoduše použít pro zajištění hodnoty podpisu, ověřitelné prostřednictvím veřejného klíče. V alternativních provedeních může být některá část nebo celý obsah adresáře kódován prostřednictvím privátního klíče a potom dekódován prostřednictvím příslušného veřejného klíče.

V každém případě generování hodnoty podpisu nebo bloku kódovaného kódu použitím tajného klíče umožňuje dekodéru ověřovat integritu a původ adresáře 75 a tudíž rovněž integritu a původ souborů odkazovaných tímto hlavním adresářem. Protože kumulativní kontrolní hodnoty pro odkazované soubory jsou začleněny do výpočtu hodnoty 81 podpisu, není možné změnit tyto hodnoty, aniž by to nebylo detekováno v ověřovací fázi. Protože každá kontrolní hodnota je obecně unikátní pro danou sadu dat, nemělo by tudíž být možné změnit obsah jakýchkoliv závislých kontrolovaných souborů bez změny jejich charakteristické kontrolní hodnoty a tím výsledné hodnoty podpisu adresáře.

Hlavní adresář 7 5, vedlejší adresáře 76 a souborové objekty 77 jsou všechny generovány jedním přenosovým operátorem systému, indikovaným zde jako operátor A. V tomto případě tyto soubory budou všechny mít známý a ověřitelný společný původ.

Ale v závislosti na aplikaci, která má být realizována, může být stejně tak učiněn odkaz na sadu ··· · * 9

9 • · ·· ···· datových souborů sdružených s druhým operátorem Β. V tomto případě vedlejší adresář 76 obsahuje odkaz na hlavní adresář DIR B0 78 druhé sady datových souborů. Je rovněž možné předpokládat spojení mezi datovými soubory z různých zdrojů na jiných úrovních, například hierarchii souborů, ve které první vedlejší adresář v jedné sadě souborů odkazuje na vedlejší adresář v druhé sadě dat, a podobně.

Jako u hlavního adresáře DIR A0 pro operátora A, obsahuje hlavní adresář DIR B0 78 jednu nebo více kumulativních kódových kontrolních hodnot 84 sdružených s jim přidruženými vedlejšími adresáři (nejsou znázorněny), číslo 85 klíče, identifikující veřejný klíč operátora B, který má být použit v ověřovacím kroku, a hodnotu 86 podpisu, generovanou odpovídajícím privátním klíčem operátora.

Kontrolní hodnota pro tento adresář se vypočítá s použitím kontrolní hodnoty 84 a hodnoty 86 podpisu v pod-záhlaví adresáře a rovněž s použitím dat užitečného obsahu adresáře 7 8. Tato kontrolní hodnota se potom uloží ve vedlejším adresáři A4, což umožní provádění ověřování integrity dat v adresářové tabulce.

V důsledku skutečností, že hodnota 86 podpisu a kontrolní hodnoty 84 jsou začleněny do výpočtu kontrolní hodnota 83, může být rovněž předpokládána integrita zbytku datových souborů odkazovaných hlavním adresářem 78, protože žádný z těchto závislých souborů nemůže být měněn bez změny kontrolní hodnoty 84 a hlavně hodnoty 86 podpisu. Protože hodnota 86 podpisu je vypočítatelná pouze osobou mající v držení privátní klíč operátora, lze předpokládat integritu všech souborů odkazovaných adresářem 78 za předpokladu, že • · • ·*Α · * * • A ·· ··♦· odpovídající kontrolní hodnoty jsou vypočítány pro další závislé vedlejší adresáře a souborové objekty.

Tímto způsobem mohou být aplikační data, týkající se proveditelných programů nebo podobně, generovaných druhým 5 operátorem, propojena s aplikacemi sdruženými s prvním operátorem, a to bezpečně a spolehlivě.

Je zřejmé, ze je možné vytvořit množství variací, zejména pro omezení kontrolovaných nebo podpisových dat v každé fázi. Zejména v případě podpisové nebo kontrolní hodnoty v adresáři nebo vedlejším adresáři, použité pro ověření datového souboru nižší úrovně, lze tuto podpisovou nebo kontrolní hodnotu adresáře generovat s použitím pouze kontrolní hodnoty nižší úrovně a žádných dalších dat.

Například kombinovaná kontrolní hodnota 79 v adresáři

A0 75 může být generována s použitím kombinovaných kontrolních hodnot 82, 83 každého z vedlejších adresářů Al až A4 76. Protože tyto hodnoty jsou stejně tak unikátní jako data v užitečných obsazích vedlejšího adresáře, bude

2Q kombinovaná kontrolní hodnota 79. stále unikátní pro příslušné vedlejší adresáře. Navíc lze stále předpokládat integritu souborových objektů 77 a adresáře 78 nižší úrovně, protože kontrolní hodnoty 82 jsou stále používány pro výpočet.

Stejně tak může být kontrolní hodnota 82, vypočítaná pro ověření adresáře BO 78, vypočítána jednoduše použitím hodnoty 86 podpisu. Protože ta je závislá na a unikátně sdružená s kontrolními hodnotami 84, které jsou dále závislé na souborech další úrovně, lze stále předpokládat integritu celých sad datových souborů odkazovaných adresářem 78.

Claims (26)

1. PATENTOVÉ NÁROKY

   Φ 9 «φφφ · φφφ «φ «φφφ φ * φφ

   1. Způsob ověřování dat vysílaných v digitálním vysílacím systému, vyznačující se tím, že data se před vysíláním organizují do hierarchie s alespoň jednou hlavní adresářovou jednotkou, vedlejší adresářovou jednotkou a souborovou jednotkou, data v souboru se podrobí ověřovacímu algoritmu a přidružená ověřovací hodnota souboru se uloží v referenčním vedlejším adresáři, tato ověřovací hodnota souboru se dále podrobí ověřovacímu algoritmu a přidružená ověřovací hodnota vedlejšího adresáře se uloží v referenčním hlavním adresáři,
2. 2. Způsob podle nároku 1, vyznačující se tím, že se provádí ověřování souborových dat aplikací kontrolního algoritmu na některá nebo všechna souborová data, přičemž výsledná kontrolní hodnota se uloží jako ověřovací hodnota souboru v referenčním vedlejším adresáři.
3. 3. Způsob podle nároku 2, vyznačující se tím, že kontrolní algoritmus odpovídá z šifrovacího hlediska bezpečnému algoritmu, který generuje v podstatě unikátní kontrolní hodnotu z dané sady dat.
4. 4. Způsob podle kteréhokoliv z předcházejících nároků, vyznačující se tím, že se provádí ověřování souborových dat pro množství souborů aplikováním kontrolního algoritmu na akumulaci dat z množství souborů pro vytvoření jedné kontrolní hodnoty.
5. 5. Způsob podle kteréhokoliv z předcházejících nároků, vyznačující se tím, že se provádí ověřování vedlejšího adresáře aplikováním kontrolního algoritmu na alespoň ověřovací hodnotu souboru, přičemž výsledná kontrolní hodnota ··· »· φ·· • · ♦ φ φφφ φ φ ♦ · • φφ ·Φ·Φ se uloží jako ověřovací hodnota vedlejšího adresáře v referenčním hlavním adresáři.
6. 6. Způsob podle kteréhokoliv z předcházejících nároků, vyznačující se tím, že se provádí ověřování množství 5 vedlejších adresářů aplikováním kontrolního algoritmu na akumulací ověřovacích hodnot souborů z množství vedlejších adresářů pro vytvoření jedné kontrolní hodnoty.
7. 7. Způsob podle kteréhokoliv z předcházejících nároků, ]_0 vyznačující se tím, že alespoň na některá z dat, uložených v hlavním adresáři, se působí tajným klíčem kódovacího algoritmu a výsledná kódovaná hodnota se uloží v hlavním adresáři.
8. 8. Způsob podle nároku 7, vyznačující se tím, že kódovaná

   15 data odpovídají digitálnímu podpisu generovanému s použitím privátního klíče kódovacího algoritmu, přičemž tento podpis je ověřitelný prostřednictvím použití odpovídajícího veřejného klíče.

   2Q
9. 9. Způsob podle kteréhokoliv z předcházejících nároků, vyznačující se tím, že odkazovaná jednotka obsahuje kódovanou hodnotu vytvořenou tajným klíčem, přičemž ověřovací hodnota pro tento modul se vypočítá na základě výsledků ověřovacího algoritmu na kódované hodnotě a uloží se v referenční jednotce.
10. 10. Způsob podle nároku 9, vyznačující se tím, že se vytvoří hodnota podpisu pro odkazovanou jednotku prostřednictvím kódovacího algoritmu, přičemž tato hodnota podpisu se podrobí kontrolnímu algoritmu pro vytvoření

    30 ověřovací hodnoty.

    tftftftf tf • tftf • * • tf tftftftf
11. 11. Způsob podle nároku 9 nebo 10, vyznačující se tím, že odkazovaná jednotka je vedlejším adresářem nebo souborovou j ednotkou.
12. 12. Způsob podle nároku 9 nebo 10, vyznačující se tím, že 5 odkazovaná jednotka je druhým hlavním adresářovým modulem.
13. 13. Způsob podle kteréhokoliv z předcházejících nároků, vyznačující se tím, že jednotky odpovídají sadě datových souborů, přičemž tyto datové soubory se začlení do datových

    20 tabulek nebo úseků, a přičemž tyto tabulky se potom začlení do datových paketů pro vytvoření transportního toku.
14. 14. Způsob podle nároku 13, vyznačující se tím, že jednotky odpovídají datovým objektům formátovaným podle standardu

    DSMCC.
15. 15. Způsob podle nároku 13 nebo 14, vyznačující se tím, že jednotky se začlení do tabulek a paketů odpovídajících standardu MPEG.
16. 16. Způsob ověřování první a druhé sady propojených

    20 datových jednotek vysílaných v digitálním vysílacím systému, vyznačující se tím, že alespoň jedna jednotka z první sady jednotek obsahuje podpis generovaný tajným klíčem aplikovaným na tuto první jednotku, přičemž alespoň tato hodnota podpisu se ověřuje ověřovacím algoritmem a ověřovací hodnota se uloží

    25 v jednotce v druhé sadě jednotek, která odkazuje na tuto první jednotku.
17. 17. Způsob podle nároku 16, vyznačující se tím, že kódovaná hodnota odpovídá digitálnímu podpisu vytvořenému tajným klíčem působícím na alespoň některá z dat v této jednotce.

    fe fe ft • » • * ··«« · *

    * fe fe * « v • fe «··· fe I • fe * fe fe · • fe ···
18. 18. Způsob podle nároků 16 a 17, vyznačující se tím, že datové jednotky odpovídají datovým souborům začleněným v datových tabulkách nebo úsecích, přičemž tyto tabulky se potom začleňují do datových paketů pro vytvoření

    5 transportního toku.
19. 19. Způsob ověřování dat vysílaných v digitálním vysílacím systému, vyznačující se tím, že data se organizují v sériích datových souborů, přičemž ověřování se provádí mezi soubory nezávisle na a před fází nebo fázemi formátování a začleňování dat použitých digitálním vysílacím systémem pro přípravu dat pro vysílaní v paketovém transportním toku.
20. 20. Způsob podle nároku 19, vyznačující se tím, že ověřování dat se provádí před začleněním dat do sérií tabulek, přičemž tyto tabulky se potom začleňují do datových paketů v transportním paketovém toku.
21. 21. Způsob podle kteréhokoliv z předcházejících nároků, vyznačující se tím, že digitální vysílací systém odpovídá digitálnímu televiznímu systému.
22. 22. Způsob ověřování přijatých dat vyslaných v digitálním vysílacím systému podle kteréhokoliv z nároků 1 až 15, vyznačující se tím, že přijímací dekodér působí na data v souboru ověřovacím algoritmem a porovnává výslednou hodnotu s

    25 ověřovací hodnotou, uloženou v referenčním vedlejším adresáři, a rovněž působí na alespoň ověřovací hodnotu souboru, uloženou ve vedlejším adresáři, ověřovacím algoritmem a porovnává následnou výslednou hodnotu s přidruženou ověřovací hodnotou vedlejšího adresáře, uloženou „„ v referenčním hlavním adresáři.

    • · « · » • * β
23. 23. Způsob ověřování přijatých dat vyslaných v digitálním vysílacím systému podle kteréhokoliv z nároků 16 až 18, vyznačující se tím, že dekodér ověřuje hodnotu podpisu v první jednotce s použitím přidruženého veřejného klíče a

    5 rovněž ověřuje ověřovací hodnotu, uloženou v jednotce v druhé sadě modulů, s použitím ověřovacího algoritmu působícího na alespoň hodnotu podpisu.
24. 24. Způsob ověřování přijatých dat vyslaných v digitálním vysílacím systému podle kteréhokoliv z nároků 19 až 21, vyznačující se tím, že kro!

    k ověřování dat se orovádí do sestavení souborových dat dekodérem ze začleněných a formátovaných dat vysílaných digitálním vysílacím systémem.
25. 25. Způsob ověřování dat vysílaných v digitálním vysílacím systému v podstatě podle zde uvedeného popisu.
26. 26, Způsob ověřování přijatých dat vyslaných v digitálním vysílacím systému v podstatě podle zde uvedeného popisu.