Newsgroup: it.hobby.satellite-tv.digitale
Titolo: sulla apertura ''satellitare'' di eutelsat e sky

 Provo, per quanto possibile, a spiegare.
Allora: Le trasmissioni codificate, via satellite, sono tali perchè
l'algoritmo DVB consente di aggiungere alla ''Beam'' della portante
digitale, un'informazione, criptata anch'essa, (il lucchetto) che -impone- a
qualsiasi ricevitore standard di ricercare una data serie di permission,
verificata un tempo standar (tot secondi, in teoria).
La ''chiave'' (ossia la decodifica) avviene per mezzo della ''permission''
verificata su tale portante. un po' come il sistema di PGP, per capirci, ma
ovviamente monodirezionale.
La codifica SULLA portante, e non sul segnale, porta alcuni vantaggi, e
alcuni svantaggi.
Il primo, è, palesemente, il multicprypt. I più attenti non avranno
dimenticato quanto strano possa apparire che un qualcosa di codificato possa
essere ''letto'' con due differenti chiavi. Se prendiamo unfile zip,
banalissimo, e lo criptiamo DUE volte, sarebbero necessarie DUE distinte
decodifiche, no?
nel caso, invece, essendo -la portante- a contenere i dati di codifica, il
problema si risolve.
Ciò però pone alcuni problemi. In primis, nei fatti, il segnale mpeg (in
genere, ma non esclusivamente) trasmesso digitalmente è, nei fatti, in
chiaro. Solo la ''lettura'' da parte di decoder conformi allo standard DVB
della parte codificata della portante, ''cripta'' il segnale. In pratica:
tutti i canali sono ''non criptati'' a livello del segnale. E' l'HW del
decoder che _impedisce o consente ab initio_ la visione di alcuni canali,
poi demandando la permission ai sistemi di decodifica. Chiaro?
Ora:
Su quanto accaduto in Toscana, vigono due + 1 distinte teorie, non
verificabili dato che, per più che ovvi motivi, viene mantenuto stretto
riserbo sul COME, intanto che si mette una pezza alla falla.
La prima, è che il tipo sia in qualche modo riuscito a penetrare il sistema
di gestione Eutelsat. In tal caso, adoperando un normalissimo hot spot,
avrebbe ''detto'' ai satelliti di aggiungere alle portanti un'altra
codifica, o un'altra gestione chiave, a determinati canali (o trasponder).
In tal caso, la perdita di ''banda'' sarebbe dovuta agli accessi
''frequenti'' a tali sistemi, di norma poco utilizzati da chi sosterrebbe di
avere un canale free...
La seconda: che il tipo abbia, semplicemente, trovato il modo di far
bellamente bypassare la portante a un qualche dispositivo hardware, e
badate: la cosa pare sia costantemente realizzata nell'est europeo, e da
anni.
In questo caso, potebbe essere stato di tutto: da una cam particolare o
custom, a un particolare tipo di decoder. Il discorso delle card, in tal
caso, sarebbe da riallaccarsi a ''codici di aggiornamento'' inviati,
addirittura, via sat agli ''abbonati'' tramite sempre il famoso canale free,
da cui la seconda parte del punto 1. Cose turche, lol...
Esiste, infine, una terza possibilità, ossia che costui semplicemente
ritrasmettesse da terra il segnale decodificato da Sky, su un certo numero
di Beam utilizzati illegittimamente, al di là della banda a sua
disposizione, cannibalizzando spot inutilizzati di altre emittenti. insomma,
per capirci, una situazione analoga al famigerato caso ''Calabria Sat'',
poco tecnico e poco ''particolare''.
Sia come sia, il ''buco'' in Eutelsat è comunque grosso. In primis, perchè
appare evidente che chiunque può -ritrasmettere- quallo che riceve, se ha
accesso a un beam su satellite. Ma peggio, nei primi due casi,
significherebbe che il sistema DVB è molto più che alla frutta e SE salta,
le conseguenze saranno enormi. E spiego perchè.
Se IPOTETICAMENTE qualcuno riuscisse a ''far saltare'' la fase
dell'inibizione del segnale a un qualsiasi hardware per la ricezione
satellitare realizzato apposta, e se questo Tizio facesse tale cosa in modo
così palese da essere rintracciato... vorrebbe significare che, nel giro di
qualche MESE potrebbero essere a disposizione in Rete molteplici accrocchi
capaci di bypassare tale metodo.
Ossia: potrebbero codificare tutto in Cryptoworks, che nulla servirebbe a
nulla.
Trovo al caso MOLTO MA MOLTO inquietante una frase proferita dai
giornalisti, ossia che costui ''danneggiava'' anche la Rai, ritrasmettendo
determinati canali. L'ipotesi facile sarebbe: si vedevano in chiaro quando
codificavano in seca... quella problematica: costui bypassava anche l'Hot
Beam di Rai International... su Hot Bird.
Nel qual caso, semplicemente, è il funerale del protocollo DVB; punto, e
alla prossima. Con qualche migliaia di tonnellate di satelliti commerciali
da convertire o sostituire molto in fretta.
Questa, la mia personale riflessione tecnica sulla vicenda. Estrapolata
Saluto i vecchi appassionati di Rotori come me, della Prima Ondata di questo
Newsgroup.
E ricordate: Sky è la Tv commerciale. La passione per il Satellite è
un'altra, lontanissima, cosa.
ciao
:)
qu
-- 
 qu
 q_u[levami]@
despammed.com
 (elimina [levami] per scrivermi)
''se la gente che inculatasi reciprocamente formasse un anello, la Terra
sarebbe Saturno"

Beam di Rai International... su Hot Bird.
Con l'attrezzatura adatta Rai International si riceve in chiaro,
legalmente e in banda C da un satellite a est (non ricordo quale e non
ho voglia di andare a cercare su Lyngsat).
Comunque, probabilmente si riferiscono a Raisat Premium, Raisat Extra e
Raisat Ragazzi, insomma i tre canali RAI all'interno del pacchetto Sky,
o al massimo Rai 1 - 2 - 3 quando codificavano sul satellite per la
questione dei diritti. Ma a quel punto non si fa prima a prendere il
segnale dal terrestre o dal digitale terrestre o decodificando dal
satellite con una wafer da 5 euro?
PS Sei il "qu" che tempo fa mise in sharing Nausicaa su eDonkey un paio
di anni fa?


[cut]
in effetti bisogna essere molto esperti in materia sat per capire a fondo
tutto il tuo discorso comunque un grazie per l'ottima spiegazione.


secondo me piu che sostituire i satelliti sostituirannno o meglio saremmo
costretti a comprare nuovi decoder , a me pare che il satellite faccia solo
da ping pong , cioe ritrasmetta pari pari quello che riceve su un altra
frequena, che poi ci siano i controlli di assetto e accesso da parte del
gestore (eutelsat) mi sembra logico, mi pare che forse gli hotbird piu
recenti supportino lo skyplex cioe ogni emittente comunica con il satellite
singolarmente e poi il satellite codifica i segnali e li ritrasmette a terra
su un unico transponder.
pero da quello che ho capito seguendo i feed di servizio sui eutelsat W dove
la maggioranza dei transponder e scpc  per agganciare il transponder basta
trasmettere verso il satellite e il transponder si apre (o forse come
auspicabile ci sono dei codici per aprirlo?)
sempre secondo la mi aopinione la falla sul dvb esiste da anni, circolavano
voci tipo leggende metropolitane gia anni fa su gente che decriptava
qualunque cosa perche aveva fatto modificare il ricevitore , forse erano
solo balle grandi come una casa , fattibile secondo me da chi conosce come
funziona il dvb , basta semplicemente dire al decoder "non bloccarmi il
canale"


Riassumo brevemente e traduco in parole povere (se sbaglio qualcuno mi
bacchetti e corregga): le trasmissioni da un qualsiasi provider al
satellite e dal satellite al ricevitore, viaggiano TUTTE in chiaro.
Sono le informazioni aggiunte al segnale in chiaro (audio e video per
capirci vengono trasmessi cosi' come sono senza "oscuramenti") che
istruiscono il decoder affinche' interroghi un suo dispositivo (la parte
di hardware e software che interagisce con la tua smart card) con
"domande" poste in un modo "criptico" e che solo la smart card,
opportunamente programmata, riesce a capire e a rispondere correttamente
ma in modo altrettanto criptico (in pratica un linguaggio che capiscono
solo chi trasmette e la smart card)
Se le risposte sono ottenute nel tempo previsto e correttamente. il
decoder rimette in chiaro il segnale altrimenti vedi nero e ti esce il
classico avviso (non hai diritti, il segnale e' criptato o quant'altro)
Questa specie di falla del DVB e' uscita fuori gia' qualche anno fa e
gia' allora si lanciarono una serie di allarmi (ricordo addirittura
degli articoli di 
satellite.it
 prima che si sbracasse definitivamente)
sulla possibile e catastrofica fine della tv digitale via sat.
Tra l'altro credo che alle stesse lacune sia soggetto il DVB-T, ovvero
il tanto strombazzato digitale terrestre. O sbaglio? Chissa' a Pierdudu
se tremano le vene dei polsi... gia' il suo sciagurato investimento per
acquisire i diritti per ritrasmettere il calcio a pagamento sul dvb-t
era dato per incredibilmente inopportuno (non rientreranno mai dei soldi
spesi, fonti Mediaset), figuriamoci adesso.
Oh mentre scrivo... visto che chi ha aperto il thread ed e' intervenuto
sembra davvero competente, le schede tvsat perche' riescono a "sbafare"
certe trasmissioni?
Certi emulatori in circolazione per i vari decoder sfruttano lo stesso
tipo di debolezza del DVB (o le varie schede multicodifica)?
E se si potesse attivare sto benedetto return-path dalla parabola e
quindi stabilire un colloquio diretto col decoder, probabilmente le cose
per i provider sarebbero piu' semplici? Certo questo comporterebbe anche
la totale dipendenza dell'utente dal fornitore ( un po' come vuole fare
Murdock in Italia com la sua scatola per i confetti)
Comunque una botta micidiale alla serenita' di certi imprenditori sat
secondo me e' stata data da Internet.... non c'e' niente di piu' potente
per diffondere informazioni di tutti i tipi e per condividere e
sperimentare collaborativamente tra persone dislocate a migliaia di km
di distanza una dall'altra.

>Beam di Rai International... su Hot Bird.
Altra domanda, scusa l'ignoranza ma la voglia di conoscere č tanta e la 
documentazione in merito č cosi poca: cosa SONO i "Nanos" di Mediaguard 
2? variazioni alla chiave privata che vengono "interpretate" dalla smart 
secondo delle determinate regole o cosa?
(ah se esistesse un SoftICE per CAM...gia avrei dato molti problemi a 
Sky :)
grazie anticipatamente per l'attenzione che hai dato gia leggendo questo 
post

 poi demandando la permission ai sistemi di decodifica. Chiaro?
Suppongo che nei decoder compatibili DVB questa funzione sia svolta
via hardware da un chip apposito, non via firmware. Il firmware si
limita a passare al suddetto chip i dati che provengono dalla CAM
(vera o virtuale che sia, vedi i firmware modificati che non hanno
bisogno di nessuna card), ma comunque l'abilitazione vera e propria
del segnale avviene dentro al chip, presumo tramite una chiave che e'
il risultato di cio' che la CAM ha decrittato.
Se non fosse cosi', allora sarebbe proprio vero che tutta la pirateria
e' in mano ai commercianti... altrimenti questa cosa dovrebbe essere
di dominio pubblico da anni e anni.

secondo delle determinate regole o cosa?
Non ne ho la piu` pallida idea, ma probabilmente e` come dici tu.
Sia chiaro che quanto scritto in questo e nel mio post precedente sono
per lo piu` mie deduzioni personali, ma non vedo altre spiegazioni
logiche (e se ci sono che vengano pure fuori).

satellite e dal satellite al ricevitore, viaggiano TUTTE in chiaro.
Questo e` quanto viene detto nel primo post, ma a questo punto si
sarebbe bellamente fregato NDS, Cryptoworks e via dicendo. A che serve
trovare il modo di decriptare quella parte? Perlomeno sul Dreambox che
e` open source si poteva bellamente fare in modo di ignorarla...
Ovviamente non e` come viene detto in quello e nel tuo post.

qu ha scritto:
......
il flusso mpg2 č scramblato alla partenza. su questa cosa si č discusso 
assai e ormai ne sono tutti convinti.
il tipastro secondo me riceveva il normale segnale sky a terra, lo 
decodificava con una normale carta abbonata, e poi riusciva (qui sta il 
buco) a plexralo dentro un transponder poco vigilato. si dice che lo 
ricodificasse, prima di inviarlo, nel vecchio irdeto1 e cosě stava 
tranquillo che stesse ben nascosto e visibile solo hai suoi affezionati.

 logiche (e se ci sono che vengano pure fuori).
La forza di questi signori, ripeto, non è la potenza crittografica ma la 
segretezza piu che dell'algoritmo crittografico, del vero e proprio 
sistema di funzionamento (mi riferisco al command handshaking continuo 
tra smart e cam). La storia dell'hacking ha sempre dimostrato che questo 
e' un muro all'apparenza sempre invalicabile, ma che col lume della 
comprensione si rivela piu' che fragile.
Il fatto è che in Europa non esistono gruppi con un know-how molto 
profondo e una cultura di compresione cosi' radicata come in USA. Tengo 
a precisare che ci sono gruppi che hanno scavalcato protezioni 
impossibili con chiavi TripleDES a 128bit nell'ambito del networking e 
delle protezioni software (3dsmax, Maya, Softimage...pacchetti sw che 
costano migliaia di Dollari e che vengono regolarmente sfondati - 
addirittura Softimage XSI aveva una chiave hardware autodistruggente e 
pure è stata bucata), evidentemente l'etica hacker, quella vera, male si 
addice al mero cracking di una emittente per vedere film porno o partite 
di football.

 assai e ormai ne sono tutti convinti.
Ragazzi mi sono perso. Gli esperti cerchino di aiutare anche gli altri a 
capire.
Quali di queste informazioni e' falsa?
*) il segnale ricevuto dai decoder, conforme al DVB, contiene 2 
informazioni: quella audio/video, in chiaro, e quella per la codifica
*) il decoder interpreta la cam, che a sua volta parla - eventualmente - con 
la smart card, per ricevere l'ok per la trasmissione del flusso
Allora, ecco le domande:
*) alla cam arriva il flusso audio/video o solo la parte relativa ai codici 
per la codifica? e alla smart card?
*) la morte del DVB e' allora abbastanza vicina: basterebbe creare una CAM 
che risponde sempre ok al decoder oppure sostituire il chip del decoder con 
uno che non interroga la CAM e che rispedisca subito il flusso all'utente
In un mondo dove l'hack di Xbox e PS2 e' disponibile a pochi giorni 
dall'uscita in commercio della console, com'e' che un simile chip tardi ad 
arrivare per il DVB? Possibile che gli ingegneri del DVB non abbiano pensato 
alla possibilita' di oscurare alla meglio il segnale? E se l'audio e il 
video di una trasmissione sono invece realmente criptati, quale 
chip/processore si occupa della decodifica di un simile flusso, la cam o il 
decoder? 

 decoder? 
CAM, interrogando la smart sul come lo deve fare

 tranquillo che stesse ben nascosto e visibile solo hai suoi affezionati.
A prescindere da quello che ha fatto il tizio, questa storia della
"codifica DVB" mi ha sempre stuzzicato parecchio, anche se per carenza
di tempo non ci ho mai studiato sopra. Ho sempre avuto la sensazione
che studiarsi tutti i vari protocolli "utente" (seca, nds ecc..) sia
sostanzialmente una perdita di tempo, perche' tanto ne possono creare
all'infinito e complessi a piacere. Se invece si aprisse direttamente
la codifica DVB, sarebbe un'apocalisse per il settore: qualsiasi
decoder al mondo dovrebbe essere rimpiazzato, per non parlare delle
attrezzature di tutti i broadcaster!
Credo che ci siano alcuni fatti su cui possiamo essere piuttosto
certi:
-Il flusso MPEG non puo' essere in chiaro, perche' altrimenti
basterebbe un qualsiasi decoder che ignora i flussi di controllo per
vedere tutto. Troppo facile, impossibile che non lo abbia mai fatto
nessuno;
-I produttori di decoder e costruttori di CAM non possono essere al
corrente di informazioni "critiche", per lo stesso motivo di cui
sopra: a qualcuno sarebbe gia' sfuggito qualcosa (avete idea di quanta
gente ci lavora?).
-Stesso discorso per i vari broadcaster.
A parer mio, l'unica spiegazione "ragionevole" e' quella che in
qualsiasi encoder e decoder DVB (quindi sia i ricevitori che i
"trasmettitori") ci sia un chip ASIC che si occupa della de/codifica
del segnale MPEG:
1-In trasmissione il chip genera un flusso di chiavi (probabilmente
random) e le usa per codificare il flusso MPEG. Tali chiavi vengono
spedite assieme al segnale MPEG in un flusso ausiliario;
2-In ricezione il chip decodifica il flusso MPEG in base a queste
chiavi.
Questa e' la situazione per i canali "free to air". Secondo me i vari
provider SECA, NDS eccetera (e le relative CAM) entrano in questa
catena:
1-In trasmissione, cifrano le chiavi DVB con un algoritmo asimmetrico
di loro scelta;
2-In ricezione, le decifrano attraverso la loro CAM (che cosi' non
deve gestire il complesso flusso MPEG, e di fatto lavora soltanto sul
flusso a bassa velocita' delle chiavi).
In sostanza non fanno altro che lasciare inalterato il flusso MPEG e
aggiungere una "cifratura personalizzata" al flusso delle chiavi,
inserendo tutte le funzionalita' che desiderano (ppv, ecc). Pero' non
hanno idea di come funziona l'algoritmo di de/cifratura DVB, che e'
implementato in hardware.
Se le cose stessero davvero cosi', le possibili soluzioni sarebbero
piuttosto ostiche e improbabili:
-Fare un reverse engineering dell'algoritmo di cifratura DVB (che
probabilmente, vista l'eta', non e' molto complesso) ed eseguire una
decifratura di "forza bruta" del flusso MPEG. Non so niente al
riguardo, ma non mi sorprenderebbe se qualcuno avesse gia' trovato il
modo di decifrare (magari dopo ore di calcolo) un singolo frame (il
che equivale a dire che si conosce gia' l'algoritmo).
-Fare il reverse engineering di cui sopra, ma inoltre scoprire anche
la logica con la quale vengono prodotte le chiavi (qualsiasi funzione
pseudorandom in realta' puo' essere predetta, se si conosce il "seme"
di partenza). In questo caso il successo sarebbe ASSAI vicino.
Mi piacerebbe molto approfondire queste tematiche... sono piu' che
certo che c'e' gia' qualcuno che ci sta lavorando, ma qui non si parla
piu' di hobbisti e lamer che loggano nanocomandi! :)

 di football.
Santerrime parole. Si concilia male pure al compito di ''sfondare'' sw
commerciale, generalmente
qu

 Ovviamente non e` come viene detto in quello e nel tuo post.
se tu sai come funziona dimmelo subito cosi' non perdo tempo in
supposizioni cretine :-)
Dico davvero non per polemizzare
Non puo' essere che con NDS, Cryptoworks e altro non sia gia' possibile
"bucare" perche' ancora non sono noti i "linguaggi" usati?
D'altra parte come han fatto a sviluppare degli emulatori per i sistemi
gia' aperti?
Solo perche' qualcuno (uno a caso) ha messo in giro le info giuste

Ape wrote:
 >
tutto quello che hai detto.
tuttavia al chip che opera la decodifica occorrono i *valori* delle 
dworld restituite dalla carta secondo il modo sempre variabile che viene 
chiesto dalla ins di controllo diritti.
ogni treno di mpeg viaggia con il flusso scramblato, con la relativa 
serratura e chiede alla carta la chiave che in quel momento potrebbe 
aprire. Non chiede alla carta un semplice consenso a procedere ma vuole 
i valori delle due dworld esatte (che sappiamo cambiano ripetutamente 
per evitare trucchetti da asilo).
probabilmente i chip sono istruiti a procedere solo in caso di controllo 
  chiave serratura sia positivo altrimenti buio. forse è possibile 
forzare i chip a procedere comunque alla descramblatura ma il risultato 
nelle migliori delle ipotesi sarebbe un segnale descramblato in modo non 
efficace e forse peggiorato.
qualcuno asseriva che le dworld fossere ancora un primo passo per la 
generazione di altre chiavi che consentivano la corretta descramblatura.
il fatto che diverse codifiche e ecm ottenessero la messa in chiaro di 
un solo canale ha fatto sempre pensare che il decoder abbia la capacità 
di descramblare a prescindere e che un piccolo salto (scambio) sul 
controllo dei diritti poteva fare il miracolo. In realtà si è ormai 
certi che tutte le codifiche alla fine generino una unica chiave finale 
(o chiavi equivalenti) per rimettere a posto un segnale che è stato 
alterato in un solo modo (viaggia un solo flusso video nello stream per 
ogni canale..).

 assai e ormai ne sono tutti convinti.
Cavolo, ho fatto qualche ricerca ed e' impressionante quante
informazioni si riescano a recuperare su questo argomento su Internet!
Sembra proprio che ci sia altra gente che crede nella bonta' dell'idea
:)
http://www.google.com/search?hl=it&ie=UTF-8&q=%22Common+Scrambling+Algorithm%22&btnG=Cerca&lr=
http://csa.irde.to/
http://islab.oregonstate.edu/koc/ece575/04Project/Alfaresi-Kamawal/report.pdf
E chi piu' ne ha, piu' ne metta...

decoder? 
Allora, riepiloghiamo. Facciamo l'esempio di una trasmissione in
diretta.
1) La trasmissione viene ripresa, con telecamere digitali, passa
attraverso la regia che ne cura le inquadrature eccetera
2) Viene aggiunto il logo dell'emittente e le altre scritte, il
televideo eccetera
3) Il flusso audio/video (che fino a quel momento era non compresso)
viene codificato in tempo reale in formato mpeg2 da appositi apparati
(nel caso di Sky di scarsa qualita`) chiamati encoder
4) I dati mpeg2 arrivano alla sezione che riguarda la codifica. Nel caso
di Sky vengono codificati con due chiavi, una in SECA2 e una in NDS.
Queste includono anche i comandi che devono arrivare alle card (ad
esempio le attivazioni per la PPV). Questi comandi vengono inviati su
TUTTI i canali, leggi la parte comandi e` sempre uguale, e probabilmente
e` in chiaro, mentre la parte codifica comprendente tra l'altro audio e
video del canale, ovviamente no)
5) Il flusso viene aggiunto agli altri canali di quel transponder a cura
del proprietario del transponder (Sky ha interi transponder e fa tutto
in proprio)
6) Qui viene quindi effettuato l'uplink, su una frequenza di servizio,
verso il satellite, nel nostro caso Hotbird a 13°Est; probabilmente
vengono inseriti dei codici per far capire al satellite su quale
frequenza deve rimandare tutto e in generale chi e` l'emittente (elenco
delle emittenti nella lista transponder)
7) Il satellite riconosce l'emittente, prende il segnale e lo
ritrasmette sulla frequenza intorno ai 10-12 GHz
8) Il segnale arriva sulle parabole di chi punta quel satellite, viene
da esse riflesso verso il fuoco ed entra quindi negli LNB, situati
appunto nel fuoco. Negli impianti dual feed il secondo LNB e` situato
nella parte riflessa del secondo segnale (che colpisce la parabola in
una posizione distante dal fuoco e quindi ci perde).
9) L'LNB, su comando del decoder ad esso collegato, prende quel quarto
di frequenze (secondo la banda -alta o bassa- e la polarizzazione
-orizzontale o verticale-) e lo ritrasforma in frequenze meglio
trasportabili su un cavo coassiale, verso cui quindi invia il segnale.
10) Tutto il quarto di frequenze finisce nel tuner del decoder, che
seleziona la singola frequenza relativa al transponder sintonizzato e lo
passa al circuito di selezione del canale
11) Se non e` un transponder SCPC (a singolo canale per transponder) il
circuito di selezione del canale prende il singolo canale, esaminando i
pid audio, video, pmt ecc., ed esamina il canale. Se il canale e` in
chiaro il flusso viene immediatamente passato al circuito di
demultiplexing e si passa al punto 18.
12) Se il canale e` codificato, viene passato tutto il flusso del canale
alla CAM (integrata, emulata o fisicamente presente). Se non ci sono CAM
adatte, viene visualizzato il messaggio che informa l'utente che il
canale e` codificato, e il tutto viene bloccato li` finche` non si
cambia canale.
13) La CAM riceve tutto il flusso dei dati e verifica che appartiene
alla o alle codifiche da essa supportate. Se la risposta e` negativa, si
passa alla seconda CAM se presente, e via via fino all'esaurimento. Dopo
l'ultima CAM con esito negativo, viene visualizzato il messaggio che
informa l'utente che il canale e` codificato, e il tutto viene bloccato
li` finche` non si cambia canale.
14) La CAM guarda il flusso e capisce se e` semplicemente codificato con
una codifica o se ha bisogno di una chiave. Se e` semplicemente
codificato o se la chiave e` all'interno della CAM, lo decripta e lo
ripassa alla CPU del decoder, restando in attesa del prossimo flusso di
dati.
15) Se invece il flusso necessita di chiavi, e la CAM non ne integra al
suo interno, verifica che sia presente una smart card. Se la smart card
non e` presente o se e` danneggiata o se non e` adatta a quel provider o
se e` scaduta, viene visualizzato il messaggio di cortesia "Inserire
smart card".
16) Se la smart card e` presente ed e` adatta a quel provider, si
interroga la card per sapere se si hanno i diritti per quello specifico
canale, in caso di risposta negativa viene visualizzato il messaggio di
cortesia "Mancano i diritti".
17) Se i diritti ci sono, la CAM chiede alla card una chiave, e prova ad
usarla secondo il suo algoritmo di codifica per rimettere in chiaro il
flusso che arriva dal satellite. Se la chiave non e` valida e non arriva
nulla di intelleggibile viene notificato con un messaggio. Se la chiave
e` valida, il flusso viene passato al circuito di demultiplexing.
18) Il circuito di demultiplexing divide audio e video, se si ha un
canale multilingue seleziona la lingua secondo le preferenze
dell'utente, prepara il televideo, passa l'audio cosi` com'e` all'uscita
digitale (ottica e/o coassiale) e contemporaneamente lo invia al
circuito di preamplificazione per l'audio analogico (RCA, scart ed
eventualmente per il modulatore integrato).
19) La parte video viene decodificata definitivamente e passata al
circuito di modulazione PAL e/o alla parte RGB, viene aggiunto l'audio e
viene inviato sulle scart, sulle uscite component e/o composite, e
inviata al modulatore integrato che si occupa di modulare il segnale su
un canale UHF.
20) Il segnale arriva quindi al televisore che visualizza l'immagine e
fa sentire l'audio, ed eventualmente al VCR che lo registra,
all'impianto home theater, eccetera.
Questi 20 punti, MOLTO SCHEMATIZZATI, sono cio` che avviene con una
trasmissione satellitare.

implementato in hardware.
DVB e` solo un sistema di trasporto (che a sua volta si puo` dividere in
DVB-S, DVB-T, DVB-C e il futuro DVB-H).
Per capirci meglio, non e` diverso da avi o mkv. Sono entrambi sistemi
di trasporto, e, se ci limitiamo al video e a un flusso audio, sono
equivalenti tra loro.
Per fare un esempio pratico, mettiamo che io debba trasportare mezzo
chilo di pane, 200 g di mozzarella, 2 mele, 12 uova e 1 chilo di
pomodori.
Facciamo finta che tutte queste cose buone non abbiano in realta` una
consistenza materiale e non ci sia quindi il pericolo di schiacciare le
uova e romperle se avessi l'idea di metterle sotto, idem per il resto.
Diciamo che stiamo nello spazio (ecco, cosi` siamo piu` vicini
all'esempio del satellite :P) e non c'e` gravita`.
Se prendo il mio bel contenitore a scomparti (cioe` il sistema di
trasporto, in questo caso il DVB) e ci metto pane - mozzarella - mele -
uova - pomodori (cioe` video, audio1, audio2, sottotitoli, televideo,
ecc.) non e` diverso dal mettere mozzarella - pomodori - uova - pane -
mele. Ho semplicemente modificato l'ordine, ma non saro` piu` in grado
di usare il mio contenitore a scomparti per com'e` progettato. In parole
povere, sono uscito fuori standard, o fuori specifiche.
Ecco, il DVB non e` altro che un sistema di trasporto. In realta` non si
limita a contenere il flusso ma implementa un sistema di controlli per
verificare che il flusso stia arrivando bene. Questo sistema non e`
diverso, concettualmente, da un banale CRC. Ma e` pubblico: se cosi` non
fosse, non potrebbero nascere i programmi open source per le schede sat
e i firmware alternativi per Dreambox. Senza contare che se non fosse
pubblico sarebbe brevettato e bisognerebbe chiedere la concessione ogni
volta che si voglia produrre qualcosa.
E`, per intenderci, esattamente come il sistema VHS: la JVC (detentrice
del brevetto) ha rinunciato a farne profitti pur di farlo diventare il
sistema maggiormente usato e ne ha rilasciato liberamente le specifiche.
Per il DVD il concetto e` quasi analogo: le royalties che i produttori
pagano (oltre che alla SIAE) sono per la codifica CSS e il Macrovision,
ma non sono obbligati a farlo, e se non lo fanno non devono pagare nulla
al DVD Forum.


Il flusso delle informazioni è codificato TUTTO, da cui l'acronimo CA 
(Conditional Access). La chiave è unica, cambia ogni tot secondi ed è 
stabilita dal broadcaster (Eutelsat, ad esempio). Tale chiave è a sua 
volta codificata attraverso diversi algoritmi che per ottenere la chiave 
utilizzano loro specifiche sotto-chiavi. Detto più terra terra: c'è un 
portone chiuso a chiave. C'è una copia di tale chiave in tre cassette di 
sicurezza chiuse a loro volta a chiave. Il signori NDS, SECA e VIACCESS 
hanno solo la chiave delle loro rispettive cassette di sicurezza, che 
dovranno aprire per prendere la chiave che aprirà la porta.
Ecco perché la storia (che periodicamente salta fuori) che il flusso sia 
in chiaro è una LEGGENDA METROPOLITANA!
-- 
Ciao, Mauro CB.

di football.
Quella della chiave HW autodistruggente non la sapevo. M'informero` ;)

 qu
ciao,
Luciano.

>Quindi è ipotizzabile anche che ci sia una private key per ogni 
[...]