Digi-TV:n MHP:n turvallisuus
Tietoturvallisuus nykyaikaisessa liiketoimintaympäristössä
Tietoturvaseminaari kevät 2003
Timo Ranta-Ojala
Sisällysluettelo
1 MHP ........................................................................................................
1
2 MHP:n synty .............................................................................................2
3 MHP-digitaalivastaanotin............................................................................
4 MHP:n ominaisuuksia ................................................................................
4.1 Profiilit...........................................................................................
4.2 Arkkitehtuuri..................................................................................
4.3 Sovellukset DVB-HTML & DVB-J...............................................
4.4 Resurssienhallinta...........................................................................
5 MHP-sovelluksen tie ohjelmistofirmalta kuluttajan päätelaitteeseen.............
5.1 Laitevalmistaja ...............................................................................
5.2 Ohjelmistoyritys...............................................................................
5.3 Palveluntarjoaja................................................................................
5.4 TV-toimija.......................................................................................
5.4.1 Sovelluksen allekirjoittaminen ........................................................
5.4.2 Objektikarusellimodulien valmistaminen..........................................
5.5 TV lähetysverkko-operaattori...........................................................
5.6 Sovelluksen vastaanotto ja suoritus...................................................
5.6.1 Objektikaruselli............................................................................
5.6.2 Sovellustietotaulu (AIT)...............................................................
5.6.3 Sovelluksen allekirjoituksen ja eheyden tarkistaminen.....................
5.6.4 Sovelluksen käynnistäminen..........................................................
5.7 Paluukanava...................................................................................
5.7.1 TLS-palvelinsertifikaatit..............................................................
6 MHP:n turvallisuutta parantavat ominaisuudet...........................................
7 Pohdintaa................................................................................................
Lähteet......................................................................................................
Käytetyt lyhenteet:
ADB = Advanced Digital Broadcast
AIT = Application Information Table
DAVIC = Digital Audio-Visual Council
DVB = Digital video broadcasting
DVB-J = Java for applications
DSMCC = Digital Storage Media, Command and Control
MHP = Multimedia Home Platform
TLS = Transport Layer Security
Tiivistelmä
Digi-TV:n tietoturva on Suomessa noussut ajankohtaiseksi aiheeksi, sillä
digitaaliseen televisiotekniikkaan siirtyminen pitäisi tapahtua laajamittaisesti
vuoteen 2006 mennessä. Digi-TV vastaaottimet mahdollistavat uusien palvelujen
saannin television välityksellä, mutta samalla ne luovat uhkia niiden
ohjelmien tuottajille, palveluntarjoajille, TV-kanavatoimijoille ja kuluttajille.
MHP-yhteensopivat digivastaanottimet ovat olleet vasta muutaman vuoden markkinoilla,
joten niiden tietoturvauhat eivät ole vielä täysin tarkasti
selvillä.
MHP tekniikan suunnittelussa on pyritty sekä ohjelmisto- että rautatasolla
varmistamaan mahdollisimman korkea tietoturvan taso. MHP:n tietoturvamekanismeista
tärkeimmät ovat sovellusten allekirjoitukset, sertifikaatit, resurssien
käyttöluvat sekä AIT-sovellustietotaulut. MHP-standardin määrittelemä
sovellusten turvallisuuden varmistaminen tapahtuu joko lähettäjän
tai luotettavan kolmannen osapuolen digitaalisin allekirjoituksin.
Suurimman tietoturvauhan MHP:lle ja kuluttajille aiheuttaa paluukanava, joka
tuo muuten niin järjestelmälliseen ja hyvin suunniteltuun laite-
ja ohjelmistokokonaisuuteen arvaamattoman ulottuvuuden. Virusten, matojen
ym. syöpäläisten tunkeutumisyrityksiä on tulevaisuudessa
odotettavissa paluukanavaa pitkin. Vaikka henkilötietojen kerääminen
ja yhdistely on ilman kuluttajan lupaa perustuslailla kielletty, saattaa tulevaisuudessa
yksilönsuoja olla uhattuna.
1 MHP
MHP on avoin standardi vuorovaikutteiselle TV:lle ja multimediapalveluille.
MHP on itse asiassa laiteriippumaton yleinen ohjelmointirajapintakokoelma,
jonka välityksellä digitaaliset sovellukset voivat keskustella MHP-digivastaanottimien
kanssa. MHP:n ydin on DVB-J. Se sisältää mm. Sunin määrittelemän
virtuaalikoneen 1.1. MHP sovelluksia ovat esimerkiksi elektroniset ohjelmaoppaat,
superteksti-TV, pelit ja e-kauppasivustot.[ETS01]
Suomi on päättänyt toteuttaa digi-TV:n lisäpalvelut MHP-standardin
puitteissa, koska avoimet standardit vaikuttavat yleensä suotuisasti
laitteistojen ja ohjelmistojen turvallisuuteen. MHP:hen ovat Suomessa sitoutuneet
kaikki digi-TV toimijat ja satelliittioperaattorit NorDig sopimuksen mukaisesti
v. 2006 mennessä.[LIV02]
2 MHP:n synty
Vuonna 1993 aloitettiin DVB-projekti, johon osallistuvat suurimmat TV-yhtiöt,
lähetysverkko-operaattorit, kulutuselektroniikkavalmistajat sekä
muut TV-toiminnassa olevat tahot yli 35 maasta. Haluttiin välttää
kuvan 1A kaltaisen tilanteen syntyminen, jossa kullakin toimijalla olisi oma
tiedonsiirtoformaatti vaatien näin myös erilliset vastaanottimet.
Projektin tavoitteena oli pyrkiä luomaan yhteinen digitaalinen lähetysstandardi,
jolla kaikki ohjelmatoimijat voisivat lähettää ohjelmaansa
kaikille kuluttajille (kuva 1B). [LIV02] Muutaman vuoden päästä
havaittiin TV:n kautta välitettävien lisäpalvelujen, kuten
ohjelmatietojen, tarvitsevan oman standardin ja näin DVB-projektista
irroitettiin yksi osasto MHP:n kehittelyyn.
Kuva 1. Vertikaalisista markkinoista horisontaaliseen markkinakenttään.
3 MHP-digitaalivastaanotin
Tällä hetkellä (20.4.2003) on Suomessa myytävänä
kaksi laitetta, jolla voi digitaalisen lähetyksen lisäksi vastaanottaa
MHP-lisäpalveluita. Toinen on Sonyn Wega NX100 TV, jossa viritin on integroituna.
Toinen on ADB:n i-CAN viritin jonka resurssit ovat: CPU 166 Mhz, Flash 4 MB,
SDRAM 32 MB, video EEPROM 4 MB, paluukanava v. 92 modeemi.[ADB03]
4 MHP:n ominaisuuksia
4.1 Profiilit
Kaikkein suppein profiili on Enhanced broadcast. Profiili mahdollistaa vain
yhdensuuntaisen liikenteen eli lähetysvirran mukana lähetettyjen
palveluiden käytön.. Interactive broadcast -profiili, mahdollistaa
nimensä mukaisesti kahdensuuntaisen liikennöinnin lähetyspään
kanssa paluukanavan kautta. Nämä kaksi ensimmäistä profiilia
on määritelty MHP:n spesifikaatiossa 1.0.1. Kolmas ja viimeinen,
Internet access -profiili, on määritelty MHP:n spesifikaatiossa
1.1. Se mahdollistaa internetin käytön ja tuo laajemmin erilaisia
protokollia ja palveluita päätelaitteen ulottuville.
Kuva 2. MHP:n profiilit
4.2 Arkkitehtuuri
MHP:n arkkitehtuurikuvasta näkyy selvästi, MHP:n kerroksellisuus.
Sovellukset suorittavat ohjelmakoodiaan käyttäen ensin MHP API:n
tarjoamia palveluja. Rajapinnoista erikseen on mainittava HAVi ja DAVIC. HAVi
tarjoaa rajapintoja grafiikan esittämiseen ja DAVIC sisältää
mm. MPEG-2 ja laiteresurssien hallinnointirajapintoja[ETS01].
Sovellusmanagerin eli navigaattorin tehtävänä on tarkistaa
sovelluksen oikeellisuus ja eheys, hoitaa virhetilanteet ja poikkeukset sekä
jakaa laiteresursseja. Se myös valvoo käynnissä olevia sovelluksia
sekä käynnistää tai pysäyttää niitä
tarvittaessa.[ETS01]
Kuva 3. MHP:n arkkitehtuuri yksinkertaistettuna[MOR02]
Alla olevassa kuvassa 4. MHP-päätelaitteen rautatoteutukset on
merkitty harmaina. Vastaanottimessa oleva sovellus on ladattu lähetysvirrasta
ja parhaillaan toiminnassa (interoperable MHP application). Sovellus voi ohjata
tai vastaanottaa dataa rautatason komponenteilta DVB-J rajapintojen kautta
(katkoviivoitetut).
Toiminta on lyhyesti seuraava: Saapuva tietovirta ohjataan virittimen kautta
CA yksikköön, jossa tapahtuu salauksen purku, käyttäjätunnistukset
jne. Seuraavaksi tietovirrasta erotellaan data ja viedään MPEG-data
suoraan purkuyksikköön ja siitä edelleen näytölle.
Sovellukselle tarkoitettu data ohjataan rajapintojen kautta sovellukselle.
Käyttäjän antamat syötteet kauko-ohjaimella vaikuttavat
ohjelman toimintaan rajapintansa kautta.
Kuva 4. MHP-päätelaitteen toimintakaavio[NEW02].
4.3 Sovellukset DVB-HTML
& DVB-J
MHP-sovelluksia on kahdentyyppisiä: DVB-HTML ja DVB-J. Molempien sovellusten
nouto kanavanipun lähetysvirrasta tapahtuu myöhemmin esitetyllä
tavalla.
DVB-HTML sovellusten avulla voidaan toteuttaa internetsivustoja, jotka sopivat
TV-ympäristöön. DVB-HTML
sovellusten käytettävissä ovat XHTML, CSS 2.0,
DOM 2.0, ECMAScript ja XML-tekniikat[MOR02]. Sivuihin viitataan "paikallistajien"
(Locators) avulla kuten nettiselaimessa. esim. http & https sivuihin viitattaisiin
http:// https://.
DVB-J sovellukset
eli Xletit on kirjoitettu Javalla ja ne toimivat hyvin samantapaisesti
kuin Java-appletit web-sivuilla. Xletit ovat appletteja yksinkertaisempia
ja todennäköisesti näin turvallisempia. Xletit voidaan rajapintansa
kautta käynnistää ja pysäyttää. Xlettien kontrolloinnista
vastaa vastaanottimen sovellusmanageri. Xletin suoritus voi myös peruuntua
tai keskeytyä, jos esimerkiksi MHP vastaanottimessa suuremman prioriteetin
Xlet haluaa päästä suoritukseen. Vain yksi sovellus voi olla
kerrallaan näkyvissä ja muut sovellukset täytyy laittaa piiloon
ja keskeyttää, jotta resursseja jäisi mahdollisimman paljon
näytössä näkyvälle sovellukselle. [MOR02]
Luvussa 5 esiteltävän Xlet Pacmanpelin sijainti ja parametrit voisivat
olla sovellustietotaulussa esimerkiksi muodossa dvb://current.ait/Orgid.Appid?param=val&
4.4 Resurssienhallinta
Koska digitaalinen MHP-vastaanotin on tavallisesti varsin vaatimaton päätelaite,
jossa keskusmuistia on hyvin vähän ja kiintolevy puuttuu kokonaan,
tulee laiteresursseja hyödyntää mahdollisimman tehokkaasti.
MHP:n resurssinhallinta on päätelaitteiden valmistajien suunnittelussa
ja toteutuksessa keskeisellä sijalla. Vähäiset laiteresurssit
vaikuttavat myös siihen että ohjelmistokehittäjät pyrkivät
mahdollisimman paljon kierrättämään ohjelmakoodia laitteessa
sekä optimoimaan.
MHP-sovellusten toiminta on asiakas-palvelin tyyppistä. Monet MHP:n
ohjelmointirajapinnat perustuvat DAVICin resource notification API:lle. ResourceServer
rajapinnan avulla sovellukset voivat rekisteröidä kuuntelijan, joka
tarkkailee käytettävissä olevia resursseja. ResourceClient
rajapinnan toteuttava luokka on vastuussa sovelluksen resurssien käytöstä.[MOR02]
Resurssia käyttävä sovellus voi kieltäytyä luovuttamasta
resurssia, mutta Release() pyynnön tullessa sovelluksen on luovuttava
resurssista. Sovellus voi myös itse tarjota jotain resurssiaan toisten
sovellusten käyttöön requestRelease() -metodilla. Suorituksessa
olevalla ohjelmalla ei ole juurikaan mahdollisuutta päättää
saako se pitää resurssia itsellään vai ei. Resurssin menetys
tapahtuu mm. suuremman prioriteetin sovelluksen tullessa suoritukseen.[MOR02]
Sovelluksilla ei ole koskaan mahdollisuus viitata suoraan resurssia kontrolloivaan
Javaobjektiin. Resursseihin viittaaminen tapahtuu aina epäsuorasti ResourceProxy
-olion välityksellä jonka on implementoinut MHP laitteen valmistanut
yritys. Näin virheellisesti toimivalta ohjelmalta on helppo poistaa resurssi
käytöstä katkaisemalla vain proxyn ja resurssia hallinnoivan
objektin välinen linkki. Tämä on turvallinen ja käytännöllinen
tapa. Käytännöllinen sen vuoksi että useita syötteitä
voi yhdistää proxyyn ja näin suorittaa yhdellä metodikutsulla.
Proxy mahdollistaa myös resurssipyyntöjen teon etukäteen. [MOR02]
Seuraavat kuvasarjat esittävät miten epäsuora viittaus tarvittavaan
resurssiin tapahtuu ja miten sovellus vapauttaa käyttämänsä
resurssin.[MOR02]
5 MHP-sovelluksen tie ohjelmistofirmalta kuluttajan päätelaitteeseen
MHP:n turvallisuutta on mietitty suunnittelun alusta asti sekä ohjelmisto-
että rautatasolla. Tietoturvasta ollaan syystäkin huolissaan, sillä
MHP-sovellus kohtaa paljon välikäsiä matkallaan ohjelman valmistaneesta
yrityksestä kuluttajan MHP-päätelaitteeseen. MHP:n turvallisuutta
tarkastellaan tässä luvussa eri toimijoiden näkökulmasta.
Oletetaan että peliyritys koodaa klassisen Pacman -pelin. Yritys myy
pelin palveluntarjoajalle joka neuvottelee pelille jakelukanavan televisioyhtiöltä.
Televisioyhtiö lähettää pelin lähetysvirran mukana
kuluttajille. Kuluttajat pelaavat peliä ja pelipisteet kirjataan paluukanavan
avulla pelituloksia hallinnoivalle palvelimelle.
Allekirjoitusprosessi ja sen oikeaksi todentaminen tapahtuu kunkin toimijan
välillä, mutta on selitetty vain kertaalleen välillä TV-yhtiö
- MHP-päätelaite.
Kuva 9. MHP-sovelluksen kiertokulku toimijoiden välillä[LIV01].
5.1 Laitevalmistaja
Kukin laitevalmistaja on velvoitettu omien yhteensopivuustestien lisäksi
osallistumaan virallisen tahon (ETSI tms.) suorittamiin standardivaatimustesteihin
. Näillä testeillä varmistetaan että laite on standardien
mukainen. 
-logoa laite saa käyttää vasta kun on läpäissyt nämä
testit. [MHO]
Suomessa tällä hetkellä myytävät MHP-digivastaanottimet
ovat DVB-mallisia. Muita MHP-vastaanottimia Euroopassa ovat mm. OpenTV (esim.
Viasat Norjassa) ja MediaHighway (esim. Canal+ Norjassa). Kummatkin laitteet
noudattavat DVB-projektin luomia standardeja ja ovat näin myös MHP-yhteensopivia.[LPE01]
Uhkakuvana on, että päätelaitteen MHP-sovelluksen kaatuessa
asiakkaat syyttävät laitetta eivätkä viallista ohjelmaa.
Tämän vuoksi API:in on lisätty paljon erilaisia metodeja joiden
avulla ohjelmien kehittäjät osaavat toivottavasti koodata sellaisia
ohjelmia jotka selviytyvät kaikista potentiaalisista virhetilanteista.
5.2 Ohjelmistoyritys
Palveluntarjoaja tilaa Pacman -pelin pelifirmalta. Peliyritys koodaa pelin
Xletiksi jossa on parhaiden pisteiden tallettamiseen käytettävät
TLS -palvelimien juurisertifikaatit mukana. Yleensä pelifirmalla tulee
olla sertifikaatti hankittuna viralliselta juurisertifikaattitaholta. Sertifikaatin
saa kun sovellus täyttää tietyt reunaehdot.
5.3 Palveluntarjoaja
Palveluntarjoaja haluaa kasvattaa rahavirtojaan ja on tilannut MHP-digitaalivastaanottimessa
pelattavan Pacman-kloonin. Siltä puuttuu tarjota PC-pelien lisäksi
Palveluntarjoaja
5.4 TV-toimija
5.4.1 Sovelluksen allekirjoittaminen
Sisällön autetikointi on tärkeä osa MHP:n tietoturvaa.
Lähettäjä voi digitaalisesti allekirjoittaa sovelluksen, jotta
vastaanottaja voi olla varma siitä ettei sisältöä ole
peukaloitu. Autentikointi on riippumaton käytettävästä
siirtoprotokollasta. Ohjelmistoyrityksen on siis ensin hankittava varmenneviranomaiselta
oma sertifikaatti. Vasta tämän jälkeen pelin allekirjoitus
on mahdollista.
Autentikointi on vielä tällä hetkellä (20.4.2003)
täysin avoin, sillä "Suomessa ei ole vielä päätetty
MHP-sovellusten allekirjoittajasta. Digi-tv-toimijat ovat toistaiseksi odottaneet
kansainvälistä DVB-päätöstä MHP-allekirjoituksesta,
mitä päätöstä ei ole vielä tehty"[KON].
Allekirjoitusprosessissa syntyy kolmenlaisia tiedostoja:[MOR02]
1) Tiivistetiedostot (Hash files)
Sisältää tarkistussumman lähetyksen tiedostoista ja hakemistoista,
joilla osoitetaan ettei lähetetyn tiedon sisältö ole turmeltunut.
Kullakin hakemistotasolla lasketaan oma tiiviste, joka sijoitetaan tiedostoon
dvb.hashfile. Kaikkia tiedostoja ei tarvitse ottaa mukaan tiivisteeseen. Master
tiivistetiedosto sijaitsee juuritasolla ja sisältää tiivisteen
kaikista alihakemistojen tiivisteistä ja juuritasolta halutuista tiedostoista.
Tiivistetiedoston laskeminen voi tapahtua MD5 tai SHA-1 algoritmilla.
MD5 ei ole enää turvallinen sillä se on altis mm. syntymäpäivähyökkäykselle.
Tiivisteen laskeminen tapahtuukin yleisesti SHA-1 algoritmilla[STA03].
2) Allekirjoitustiedostot (Signature files)
Digitaalinen allekirjoitus suoritetaan juuressa olevalle master tiivistetiedostolle.
Lähettäjä salaa tiivisteen sertifikaattinsa salaisella avaimella
RSA algoritmilla. Lähettäjä laittaa allekirjoituksensa tiedostoon
dvb.signature.<id_numero> Tämä id_numero mahdollistaa hakemistorakenteen
allekirjoituksen usea eri tahon toimesta.
3) Todistustiedostot (X.509 certificate files)
Lähettäjän julkinen avain jolla digitaalinen allekirjoitus
voidaan avata sijaitsee dvb.certificate.<id_numero> -tiedostossa. Jokaisella
hakemistossa olevaa allekirjoitustiedostoa kohti täytyy olla todistustiedosto
varustettuna samalla <id_numerolla>, jotta allekirjoituksen lähettäjä
voidaan yksilöidä. Jokainen todistustiedosto täytyy myös
pystyä todistamaan oikeaksi.
Kuva 10. Sovelluksen allekirjoitusprosessi [MOR02]
Esimerkkikuvassa Pacman pelistä allekirjoitetaan kaikki punaisella korostetut
tiedostot. Katkoviivalla reunustetut tiedostot syntyvät vasta allekirjoituksen
edistyessä.
Ensin TV-toimija tarkistaa ohjelman toimivuuden ja vasta tämän
jälkeen suorittaa allekirjoituksen.
Vaiheet:
1. Allekirjoituksen suorittava sijoittaa sertifikaattinsa juurihakemistoon.
Koska esimerkissä on vain yksi allekirjoittaja, tallennetaan se tiedostoon
nimeltä dvb.certificate.1 (seuraava tallettaisi esim. dvb.certificate.2).
2. Alihakemisto(je)n tiedostoista lasketaan tiiviste SHA-1 algoritmilla aloittaen
alimman tason hakemistoista. Tulos talletetaan ko. alihakemiston tiedostoon
dvb.hashfile. Kaikkia tiedostoja ei tarvitse ottaa mukaan.
3. Ylemmän tason hakemiston tiedostoista ja sen alihakemistojen dvb.hashfile
-tiedostoista lasketaan tiivistelmä joka talletetaan ko. hakemiston dvb.hashfile
-tiedostoon. Näin jatketaan kunnes koko hakemistorakenne on käyty
läpi juureen saakka.
4. Juuriosion tiivistetiedosto eli dvb.hashfile allekirjoitetaan salaamalla
se dvb.certificate.1 tiedostosta löytyvällä julkisella avaimella
RSA algoritmilla.
5. Salattu tiivistelmä talletetaan juuriosion tiedostoon dvb.signature.1.
Nyt tiedostot taustakuva.jpg tiedostoa lukuunottamatta on allekirjoitettu.
5.4.2 Objektikarusellimodulien valmistaminen
Objektikaruselli on hyvin keskeinen osa MHP:n toimintaa, sillä se määrittelee
kuinka PC tyyppiset tiedostosysteemit lähetetään lähetysvirran
mukana. Objektikaruselli koostuu hakemistopuusta joka on jaettu 64 kt moduleihin.
Tiedostojen sijoittelu modulien sisään on järjestykseltään
täysin vapaata, kunhan 64 kt kokonaisrajaa ei ylitetä.
Alla olevassa kuvassa Pacman -pelin tiedostot on jaettu moduleihin. Yhden
karusellikierroksen aikana lähetetään kolme ykkösmodulia
ja yksi kappale muita modulejai. taustakuva.jpg on isompi kuin 64 kt,
mutta sitä ei saa pilkkoa pienempiin osiin. Pitää vain toivoa
parasta, että kuvan siirtyminen onnistuu karusellikierrosten myötä.
Sama tiedosto voi kuulua useampaan kuin yhteen moduliin ja näin karusellin
toimintaa voi halutessaan tehostaa.[MOR02]
 |
Tiedosto koko
------------------------------------
dvb.hashfile 1256 bytes
dvb.signature.1 4040 bytes
dvb.certificate.1 1932 bytes
Pacman.class 29400 bytes
Komponentit.class 14400 bytes
dvb.Pacman.perm 346 bytes
audiovideo <directory>
audiovideo/Audio.class 6430 bytes
audiovideo/Video.class 4430 bytes
audiovideo/taustakuva.jpg 78457 bytes
|
Kuva 11. Modulien muodostaminen objektikarusellia varten.
5.5 TV lähetysverkko-operaattori
Lähetyspäässä tapahtuva koko DVB-kanavanipun salaus tai
osittainen salaus varmistaa sen, että MHP-sovellukset ovat kaksinkertaisesti
turvattuja kun ne matkaavat lähetyspäästä kohti asiakkaan
MHP-päätettä. Ainut epäilys MHP-sovelluksen luotettavuudesta
kohdistuu lähettäjään. Tuleeko lähetys tarpeeksi
luotettavalta taholta? Yleensä huoli on aiheeton, sillä lähetyskapasiteettia
ei ole muilla kuin valtion tai tunnetun yrityselämän tahoilla.
Kuva 12. Lähetyspään tekniikka jossa tietovirta salataan kunkin
lähettäjän omalla CA laitteistolla ja salausalgoritmilla[WIL].
DVB pohjautuu MPEG-2 videopakkausstandardiin. Käytettävissä
on kolme erilaista lähetystietä ja kukin vaatii oman vastaanottimensa
DVB-S (satelliitti), DVB-T (antenni), DVB-C (kaapeli). MHP -sovellukset kulkevat
DVB-kanavanipussa. Kanavanipussa oleva SI-palvelutieto pitää sisällään
mm. ECM- ja EMM-viestit. MHP-palveluja voivat vastaanottaa ne, jotka omistavat
MHP-yhteensopivan digivastaanottimen sekä salauksenpurkukortin. Suomessa
päätelaitteiden salausjärjestelmäksi valittiin Conax.
Conax on Norjalainen yritys jonka pääpaikkana on Oslo. Tällä
hetkellä käytössä oleva yrityksen tuote on nimeltään
CAS5.[CON03]
Kuva 13. DVB-kanavanippu multiplexin koostamana.[LIV02]
Bittivirran nopeutta voidaan säätää dynaamisesti tarpeen
mukaan. Jos kaistaa tarvitaan enemmän jossain palvelussa se voi ottaa
kaistaa vähemmän tarvitsevilta palveluilta. Operaattori voi asettaa
maksimin kaistanleveydelle, jolloin jossain tapauksissa kuvanlaatua täytyy
heikentää jotta pysytään lähetysrajoissa. [WIL]
Lähetyspään pääsynvalvonta (CA) ja datan salaus
pitää huolen siitä, että vain palvelun maksaneet asiakkaat
voivat vastaanottaa lähetysvirran mukana saapuvaa palvelua. Lähetyssignaali
salataan otsikkotietueita lukuunottamatta salausjärjestelmävalmistajan
ei-julkisella algoritmilla, jolloin lähetyksen vastaanotto on edelleen
mahdollista, mutta ilman asianmukaista salauksen purkukorttia mitään
järjellistä palvelua ei voi vastaanottaa. Salausalgoritmit pidetään
visusti salassa sen vuoksi, sillä algoritmin murtuminen tulisi kalliiksi.
Tästä huolimatta jollain Euroopan markkina-alueilla jopa 30%:n uskotaan
käyttävän laittomasti valmistettuja älykortteja jossain
vaiheessa tulevina vuosina.[WIL]
Lähetyksen salaus tapahtuu seuraavasti. Salauksen yhteydessä CA
lisää ns. pääsynvalvontaviestejä (Conditional Access
Messages) lähetysvirtaan. Näitä viestejä on kahdenlaisia
Entitlement Control Messages (ECM) ja Entitlement Management Messages (EMM).
Nämä yhdessä kontrolloivat salatun sisällön näkyvyyttä.
Salaus- ja purkuprosessi koostuu kontrollisanasta (control word), palveluavaimesta
(service key) joka on yhteinen samassa palvelussa ja käyttäjäavaimesta
(user key).[WIL]
Kuva 14. ECM-viestin muodostaminen.
Kuva 15. EMM-viestin muodostaminen.
Kuvissa 11 ja 12 esitettiin ECM- ja EMM-viestien muodostaminen. Kun CAM-viestit
saapuvat MHP-digitaalivastaanottimelle, tutkii vastaanottimen CA ne. EMM ja
ECM -viesteille on oma yksilöllinen käsittelynsä. Alla olevassa
kuvassa on esitetty vastaanottoprosessi, jonka lopputuloksena kontrollisana
selviää ja tämän kontrollisanan avulla "sekoitettu"
palvelu saadaan "järjestykseen". Nyt asiakas voi katsoa niitä
kanavia ja käyttää niitä palveluita, jotka on kirjattu
lähetyspään asiakashallintotietokantaan.
Kuva 16. ECM- ja EMM-viestien purku päätelaitteessa
Uhkia
Kuinka lähettäjä voi valvoa monimutkaisesti pakattua MPEG
signaalia joka voi sisältää ääntä, videota ja
kuinka voidaan varmistua siitä että lähetys menee vastaanottajalle
laadukkaana. Kuinka kauan kestää ennekuin virhe havaitaan? Tietovirta
pitää myöskin olla synkronissa. Pelkästään onnistunut
lähetys ei siis takaa sitä, että lähetys menee perille.
Palveluparametrit saattavat muuttua lähetyksessä esimerkiksi asiakkaan
tekstityskieli.[WIL]
Hyökkääjä lähettää maanpäällistä
lähetyssignaalia voimakkaampaa signaalia lähellä sijaitsevasta
liikuteltavasta lähetysajoneuvosta. [MOL]
5.6 Sovelluksen vastaanotto ja suoritus
Sovelluksen tiedostot saapuvat DVB-kanavanipussa MPEG-2 lähetysvirran
mukana DSM-CC objektikarusellissa. Tämä tuo yhden lisävaiheen
sovelluksen suoritukseen, koska vastaanottimen tulee kaivaa sovellus esiin
karusellista.
5.6.1 Objektikaruselli
Yksi tai useampi objektikaruselli voidaan kuljettaa DVB-kanavanipussa. Kukin
saa tällöin oman id:n, joka merkitään DVB:n SI palvelutauluun.
Objektikaruselli saa kanavanipusta yleensä kaistaa 1 Mbps mutta todellinen
nopeus määräytyy vastaanottimen kyvystä purkaa ja prosessoida
saapuvaa dataa[MOR02].
Objektikarusellin ensisijainen tehtävä on saattaa saapunut informaatio
DVB vastaanottimen hallitsemaan tiedosto-objekti muotoon. Tiedosto-objektit
sisältävät tyypillisesti joko sovelluksia tai dataa, joihin
päätelaitteen nykyiset sovellukset ovat viitanneet.[MOR02]
Karusellin toiminta on hyvin samantapaista kun nykyisen teksti-TV:n. Teksti-TV:n
sivut päivittyvät n. 20 sekunnin välein (jos ei ole muistia),
mutta objektikarusellin toiminta on hyvin nopeaa huomattavia viiveitä
ei esiinny. Jos tietoa tarvitaan todella nopeasti, on DVB objektikarusellilla
erityinen mekanismi ns. ‘stream events’, jolla aikakriittinen data
saadaan tarvittaessa mahdollisimman nopeasti siirrettyä päätelaitteelle[ETS01].
Ennen kuin esimerkkimme Pacman -pelisovellusta voidaan aloittaa lataamaan
lähetysvirrasta vastaanottimelle, tulee sen sijainti ja oikeudet selvittää.
Nämä tiedot käy ilmi TV-kanavakohtaisesta sovellustietotaulusta.
5.6.2 Sovellustietotaulu (AIT)
Sovellustietotaulu sisältää kaiken tiedon, jonka vastaanotin
tarvitsee sovelluksen suoritukseen. Näiden tietojen perusteella laitteen
käyttäjä saa tietoja käytettävissä olevista
palveluista. Sovellustietotaulu sisältää sovelluksen nimen,
tiedostojen sijainnin, käynnistysparametrit sekä sovelluksen yksilöllisen
tunnisteen.[ETS01]
Kun käyttäjä vaihtaa esimerkiksi kanavaa, tyhjennetään
vastaanottimen muisti niistä sovelluksista, jotka eivät saa suoritusoikeutta
ko. kanavan sovellustietotaulussa [MOR02]. Tämä kanavakohtainen
turvallisuusominaisuus on tietoturvan kannalta hyvä asia, sillä
vastaanottimeen ei voi kovin pitkäksi ajaksi pesiytyä haitallisia
ohjelmia vaikka ne onnistuisivatkin pääsemään suoritukseen.
Kanavakohtaiseen turvallisuusominaisuuteen tuo poikkeuksen ns. globaali sovellus,
jota voidaan suorittaa usean eri kanavan taustalla ja edes kanavan vaihto
ei poista ohjelmaa vastaanottimen muistista. Tällöin on kuitenkin
oltava sopimus keskeisten tv-kanavien kanssa. [LIV02]
Sovelluksen yksilöllinen tunniste koostuu 32 bittisestä organisaatiotunnisteesta
(kullakin MHP sovelluksia tuottavalla yrityksellä oma) ja 16 bittisestä
sovellustunnisteesta. Sovellustietotaulu sisältää myös
tilaindikaattorin, johon sovelluksen lähettäjä voi asettaa
sovelluksen toiminnalle esimerkiksi aikarajoja ja käynnistystavan (automaattinen/käsi).
Jokaisella sovellustietotaulussa sijaitsevalla sovelluksella on sovelluksen
sijaintikuvaaja, joka kertoo sen objektikarusellin, mistä sovellus löytyy.
Jos objektikaruselli sisältää useampia sovelluksia, sijaintikuvaaja
kertoo sovelluksen sijaintipolun.[ETS01]
5.6.3 Sovelluksen allekirjoituksen ja eheyden tarkistaminen
Kun sovellustietotaulussa mainitun Pacman Xletin tiedostot on objektikarusellista
saatu siirrettyä MHP-päätelaitteeseen tapahtuu sovelluksen
allekirjoituksen ja eheyden tarkistaminen.
MHP:n tietoturvallisuuden perusta on sovellusten digitaaliset allekirjoitukset..
Allekirjoitukset tapahtuvat joko lähettäjän tai luotettavan
kolmannen osapuolen taholta. Jos sovellukset haluavat oikeuksia "hiekkalaatikon"
ulkopuolisiin resursseihin, tulee sovelluksen olla allekirjoituksella varustettu.
MHP vastaanotin tarkistaa ennen oikeuksien myöntämistä että
allekirjoitus on oikeellinen ja hyväksytyn tahon suorittama. Kaikki hyväksytyt
allekirjoitukset voidaan johtaa juurisertifikaatteihin. Jos allekirjoitus
on hyväksytyn tahon allekirjoittama sovellus on ns. signed -tyyppinen,
muussa tapauksessa unsigned -tyyppinen. Allekirjoittajataholla tulee näin
olemaan suuri vastuu lähetettävien MHP-sovellusten teknisestä
oikeellisuudesta.[LIV02]
Esimerkkipelimme Pacmanin allekirjoituksen tarkistaminen alkaa dvb.certificate.1
tiedostosta. Siitä käy ilmi kuka on myöntänyt pelifirmalle
sertifikaatin. MHP-laitteeseen on tehtaalla asennettu muutamia juurisertifikaatteja
ja tarkistuksessa havaitaan, että sertifikaatin myöntäjä
on eräs näistä juurisertifikaattitahoista. Nyt MHP-laite tietää
pelifirman sertifikaatin dvb.certificate.1 aidoksi ja tietää pelifirman
julkisen avaimen varmasti. Sertifikaatista käy ilmi myös mitä
algoritmia on käytetty allekirjoituksen tekemiseen. Näin dvb.signature.1
tiedostosta voidaan selvittää alkuperäinen juuritason tiiviste.
Nyt voidaan suorittaa kuvan 9. kaltainen tiivistetiedostojen laskeminen uudelleen
ja verrata syntynyttä master tiivistettä edellä selvittämäämme
juuritason tiivisteeseen. Jos tiivisteet ovat identtiset on tiedoston eheys
kunnossa, muussa tapauksessa tiedostoa on joku peukaloinut.
5.6.4 Sovelluksen käynnistäminen
Oletetaan että pelisovelluksellamme oli hyväksytty allekirjoitus.
(Mikäli se olisi ollut allekirjoittamaton tai allekirjoitusta ei olisi
hyväksytty, olisi peli saanut ainoastaan vastaanottaa käyttäjän
näppäilyjä sekä käsitellä näyttöä.)
Nyt Pacman voi pyytää oikeuksia toisten ohjelmien ohjaamiseen, paluukanavan
käyttöön, kanavan vaihtoon, käyttäjätietoihin,
tehdä tiedostolistauksia jne. Pyyntötiedosto dvb.Pacman.perm
on xml-muodossa ja sijaitsee samassa hakemistossa DVB-J sovelluksen pääluokan
(main) kanssa tai jos kyseessä on DVB-HTML sovellus niin sovelluksen
ensimmäisen tiedoston kanssa[MOR02]. Koska oikeuksien pyyntötiedosto
sijaitsee aina ennalta määrätyssä paikassa, on lähetysviranomaisen
helppo halutessaan tutkia tiedoston sisältö. (Jos pelin mukana ei
olisi lähetetty lupatiedostoa, olisi pelin oikeudet olleet yhtä
rajoitetut kuin allekirjoittamattomalla sovelluksella.)[ETS01]
MHP-päätelaitteen käyttäjä voi asettaa rajoituksia
sovellusten oikeuksille, esimerkiksi kieltää paluukanavan käytön.
Tällöin sovelluksen oikeudet määräytyvät lupatiedoston
ja käyttäjän asetusten yhteisvaikutuksesta. MHP:n ohjelmointirajapinnat
tarjoavat tietoturvaan liittyviä poikkeuksia, jotka voidaan heittää
silloin kun sovellus yrittää suorittaa ohjelmakoodia ilman riittäviä
oikeuksia.[MOR02]
Sovellusmanageri lataa laitteessa olevan sovelluksen pääluokan
Pacman.class ja luo siitä esiintymän Pacman -luokan oletuskonstruktorilla.
Seuraavaksi sovellusmanageri alustaa sovelluksen InitXlet(luotu_esiintymä)
-komennolla. Lopuksi manageri käynnistää alustetun sovelluksen
startXlet() -komennolla. Koska peli oli allekirjoitettu hyväksytyn tahon
toimesta saa peli oikeuden paluukanavan käyttöön.
5.7 Paluukanava
Paluukanavan voi toteuttaa MHP:ssa millä laitteella vain: modeemilla,
kaapelimodeemilla, ADSL:lla, kunhan yhteys tukee TCP/IP:tä ja TLS protokolla
on käytettävissä[ETS01]. Usein päätelaite tukee myös
HTTP:ta ja SMTP:ta. Verkkoon kytkeytyminen on helppoa. MHP käyttää
Javan tarjoamia palveluja vain pienin rajoituksin. [MOR02].
Toiminnallisuudeltaan rajattu paluukanava on mahdollinen muodostamalla suora
modeemiyhteys kaapeli- tai satelliittiverkko-operaattorin tietojärjestelmään.
Kehitteillä on myös ilmateitä käyttäviä paluukanavaratkaisuja.[LIV02]
Kunkin sovelluksen lupatiedostossa määritellään mahdollinen
paluukanavan käyttöpyyntö. Paluukanavan turvallisuusjärjestelyissä
käytetään Internetissä yleisesti käytössä
olevaa standardia nimeltä Transport Layer Security (TLS).
Jos paluukanavaa pitkin ladataan sovelluksia tms. on autentikointikäytäntö
sama kuin lähetysoperaattorilta tulevan datankin kanssa. Eheys ja allekirjoitus
tarkistetaan.
MHP päätelaitteella ei ole olemassa tiettyä palvelinta, johon
paluukanavayhteys aina luodaan. Kun Pacman pelissä pelaaja saavuttaa
Top 10 -taulukkoon oikeuttavan pistemäärän pyydetään
käyttäjältä lupaa muodostaa TCP/IP yhteys ennalta määriteltyyn
palveluntarjoajan soittosarjaan. Kun päätelaite on kytkeytynyt verkkoon,
hakee sovellus dvb.Pacman.perm -tiedostosta sen TLS palvelimen, johon
tulos on määrä kirjata.
5.7.1 TLS-palvelinsertifikaatit
Jos MHP-ohjelma haluaa luoda paluukanavayhteyden on sillä oltava ns.
TLS-palvelinsertifikaatteja. Kun Pacman -peli ottaa yhteyden ennalta määrätylle,
pisteitä keräävälle TLS-palvelimelle, täytyy tällä
palvelimella olla ainakin yksi pelin mukana tulleista palvelinsertifikaateista.
Jos yhtään vaadittavista palvelinsertifikaateista ei löydy
TLS-palvelimelta aiheuttaa päätelaite IOExeption -poikkeuksen.[ETS01]
Jos sovelluksen mukana ei lähetetty lainkaan TLS-juurisertifikaatteja
saa ohjelma halutessaan muodostaa yhteyden mihin palvelimeen vaan. Tällöin
palvelimelta pyydetään erikseen sertifikaattinippua ja tutkitaan
sisältääkö se MHP-ohjelman tarvittavaa palvelua. Palvelun
todentamiseen tarvitaan koneen nimi ja julkinen avain.[ETS01]
Käytännössä paluukanavan kautta kulkeva liikenne on aina
salattua ja turvallista. Digiboksiin murtautuminen Internetistä tutulla
ns. porttiskannaus-hyökkäyksellä on hyvin vaikeaa jo salattujen
yhteyksien vuoksi. Toinen tätä rajoittava tekijä on digiboksien
yksinkertaisuus niissä ei ole käynnissä palveluita joiden turva-aukkoihin
porttiskannauksilla pyrittäisiin pääsemään kiinni.
Kuitenkin normaaliin tietokoneeseen perustuvat digiboksit voivat olla yhtä
haavoittuvia kuin tietokoneetkin [LIV02]
Uhkia
Hyökkääjä saattaa saada narrattua käyttäjän
lataamaan troijalaisen epämääräisestä palvelimesta,
joka onkin ns. dialer -ohjelma, ja soittaa hyökkääjän
kalliiseen maksulliseen numeroon.
6 MHP:n turvallisuutta parantavat ominaisuudet
MHP:n turvallisuusmalli määrittelee, että jokainen sovellus
on käynnistettävä eri luokanlataajalla. Luokanlataajaa on käytettävä
kaikissa sovelluksen luokkien lataamisissa. Luokanlataajat mahdollistavat
luokkien lataamisen useista eri lähteistä.[MOR02]
Kaksi luokkaa ovat samat vain jos niillä on sama nimi ja ne ovat ladattu
samalla luokanlataajalla.[ETS01]
Näin:[MOL]
1) varmistetaan se, ettei sovellukset voi koskea systeemiluokkiin
2) ei tule luokkakonflikteja eri sovellusten välillä.
3) luokan omistava sovellus on helposti selvitettävissä
4) mahdollistaa paremman muistinhallinnan
Keksejä ei koskaan lähetetä palvelimelle[ETS01].
Koska MHP käyttää Javan virtuaalikonetta, pitää
virtuaalikone huolta siitä, ettei luvattomiin resursseihin ole pääsyä
haitallisilla sovelluksilla ja viruksilla. Sovelluksia ajetaan virtuaalikoneen
tarjoamassa "hiekkalaatikossa", kuten java-appletit www-selaimessa
mahdollisimman pienin oikeuksin. Jokainen sovellus luulee olevansa ainoa suoritettava
sovellus virtuaalikoneessa.[MOL]
On mahdollista tehdä ohjelma, jonka silmukkarakenne hidastaisi MHP-päätteen
toimintaa. Todellisuudessa näin toimivia virheellisiä ohjelmia pääsisi
lähetykseen ainoastaan testaajien ja allekirjoittajan laiminlyöntien
seurauksena. PC-maailmasta tuttuja "mato"-ohjelmia ei puhtaassa
MHP-maailmassa ole näköpiirissä, koska MHP-sovellus ei helposti
pääse leviämään itsenäisesti paluukanavan kautta
digiboksien välillä. Toisaalta, jos digiboksiin toteutetaan tämän
välityksen mahdollistava sähköposti, ollaan samassa tilanteessa
kuin PC-ympäristössä.[LIV02]
Ohjelmamuistin tyhjentäminen kanavanvaihdon yhteydessä sekä
tarvittaessa digiboksin uudelleenkäynnistys estää tehokkaasti
haitallisten ohjelmien pesiytymistä MHP-laitteisiin. Digibokseissa ajettavat
sovellukset määrittelee käytännössä lähetyspään
kanavanipun ja karusellijärjestelmän hallinnoija. Näihin järjestelmiin
pääsy on tarkasti rajattu. Ainoastaan muutama ns. pääkäyttäjä
voi muuttaa käytössä olevan karusellijärjestelmän
lähetysparametreja. Ohjelmien kaavailtu ennakkotarkastus ja allekirjoittaminen
käytännössä eliminoivat riskin virusten leviämisestä
lähetysverkon kautta. Huonosti testatut MHP-sovellukset ovat mahdollinen
uhka. MHP-sovellukset testataan ja allekirjoitetaan ennen lähetystä, joten
virheellisesti toimivien ohjelmien lähetys on epätodennäköistä.[LIV02]
MHP-standardi antaa katsojalle mahdollisuuden syöttää joitain omia tietojaan
laitteen asetusten kautta muistiin, josta MHP-sovellukset voivat niitä käyttää.
Näitä tietoja ovat mm. käytettävä kieli, lapsilukitukset, käyttäjän nimi,
osoite ja sähköpostiosoite. Näiden tietojen syöttäminen on täysin käyttäjän
päätettävissä ja niiden tarkoitus on helpottaa laitteen käyttöä esim. tekemällä
kaavakkeen esitäyttö mahdolliseksi. Yksityisyyden suojan kannalta nämä
syötetyt tiedot voivat tuoda mukanaan riskejä[MHO].
Digi-tv:n on oltava luotettavuudeltaan "tv:n tasoa", eli selvästi parempi
kuin koti-PC. Tämä aiheuttaa laatuvaatimuksia käytettäville sovelluksille,
jotka tulisi testata ja hyväksyttää etukäteen. Kaikkien sovellusten kattava
testaaminen ole käytännössä mahdollista. Lähetysverkon kautta levitettävien
ohjelmien laatua pystyttäisiin kenties valvomaan, mutta tuskin paluukanavan
kautta ladattavia sovelluksia. Tulevaisuudessa tullaan kenties tallettamaan
ohjelman lähdekoodi hyväksyjätahon toimesta ja ongelmatilanteessa
lähdekoodista tarkistetaan ovatko tekijät vastuullisia.[LIV02]
7 Pohdintaa
Laitteiden ja palveluiden laadun kasvaessa sekä laitehintojen laskiessa
digisovittimesta on tulossa koko kansan viihdekeskus. Laitteella katsellaan
kiintolevyllä olevia TV-nauhoituksia, kuunnellaan musiikkia ja pelataan
pelejä jne.
MHP-lisäpalveluissa verkkorahan liikuttelu tulee olemaan varsin yleistä.
Yrityksiä harhauttaa herkkäuskoisia ja tietoturvatiedoiltaan puutteellisesti
varustautuneita kansalaisia tulee varmasti. Laitteiden suojausten kiertäminen
tulee olemaan suosittua myöskin tulevaisuudessa. Jo nyt verkossa kaupitellaan
laitetta, jolla voi katsella Conaxin salaamia digitaalilähetyksiä.
Koska MHP laitteet ovat olleet vasta muutaman vuoden markkinoilla ei tietoturvauhat
ole vielä täysin tarkasti selvillä. On odotettavissa että
tulevat vuodet paljastavat laitteesta turvallisuusaukkoja. Koska digitv.n
tavoitteena on olla koko kansan päätelaite on teknisten valmisratkaisujen,
esivalintojen ja valmiiden toimintamallien merkitys suuri. Nykylaitteisiin
on jo kylvetty tietoturvarikkeen siemen, sillä esimerkiksi aiemmin esitellyn
i-Can MHP-päätelaitteen pin-koodi on oletusarvoisesti 1234. Kuinkahan
moni käyttäjä osaa tai viitsii vaihtaa laitteen pin-koodia?
Lähteet:
[ADB03] www.adbglobal.com
[CON03] www.conax.com
[ETS01] ETSI TS 102 812 V1.1.1, Digital Video Broadcasting (DVB); Multimedia
Home Platform (MHP) Specification 1.1 November 2001 http://www.mhp.org/technical_essen/pdf_and_other_files/Ts102812.V1.1.1.zip
[EVA] J-P Evain, EBU technical department, 1998, http://www.ebu.ch/trev_275-evain.pdf
[KON] Riitta Kontula, Digita Oy, Viestintäpäällikkö,
sähköpostiviesti 11.4.2003
[MHO] http://www.mhp.org, 18.4.2003
[MOL] Erik Moll, Java in Living room?, Philips, http://www.ngi.nl/docs/denhaag/tud-lezing/tsld001.htm
(luentokalvosarja)
[MOR02] Steve Morris, http://www.mhp-interactive.org/tutorial, 19.4.2003
[NEW02] J.C. Newell, An Introduction to MHP 1.0 and MHP 1.1, BBC Research
& Development White Paper, 2002, http://www.bbc.co.uk/rd/pubs/whp/whp-pdf-files/WHP030.pdf
[LIV02] Liikenne- ja viestintäministeriö. Yksityisyyden suoja digitaalisessa
televisiotoiminnassa (2002) http://www.mintc.fi/www/sivut/dokumentit/julkaisu/julkaisusarja/2002/a022002.pdf
[LPE01] Per Magnus Løvold, Aase Merethe O. Pettersen, Multimedia Home
Platform - Ordering Applications,
http://www.item.ntnu.no/felles/leifarne/SIE5045%20Videoteknologi/MHP/OrderingApp.pdf
[STA03] William Stallings, Cryptography and Network Security; principles
and practices 3rd ed. 2003, Prentice Hall
[WIL] Danny Wilson, Content Validation for the Multimedia Home Platform,
Pixelmetrix Corporation http://www.broadcastpapers.com/sigdis/PixelmetrixContentMHP.pdf,
11.4.2003
