Il prontuario del Seka secondo IperSat alias ZxZaZx
Versione 1.4 - Ultima modifica effettuata il 29 dicembre 2000
Questo documento è dedicato a i vari Cocorito_99, C0m4nch3, Ctower, Egim, Frank2, JJ, Master8, Maradona, Pippo_360, ppippo, ProstaFeresi, Rendermann, Space, Toto, Tulemann, Viper, Zappa_Frank, ZZtop e tutti coloro che con la loro grande passione verso questo magico hobby, mi hanno aiutato e illuminato in questa mia opera. Indegnamente ringrazio anche i miei due alunni, il gatto (Max_Ginko) e la volpe (LorenzoF) e ricordo loro che dal gennaio 2001 non darò più lezione. Scherzo !! Parte del materiale inserito in questo documento è stato preso dalle SekaFaq 2.3,  dalla grande bibbia di John MacDonald e dal documento di Anfry sul BP. Se fosse presente qualche imprecisione o se voleste esprimere la vostra opinione vi prego di scrivermi a IperSat@Yahoo.Com o a ZxZaZx@Email.Com
Il Seka
ATR
La struttura delle chiavi seka
La struttura delle istruzioni seka
L'algoritmo del Seka (John MacDonald)
Che cosa è il Bitmap Package
Che cosa è il PPUA
Che cosa è la SuperEncryption - Prossimamente !
Gli Status-Byte (Risposte della carta)

Istruzioni base del Seka
[0A] il sistema operativo della carta
[0E] il numero seriale della carta UA
[12] l'ident dei Provider
[16] il numero dei Provider della carta
[12] il PPUA
[12] la data di fina abbonamento
[34] il Data Request
[32] il Bitmap Package
[1A] le key presenti su un Provider
[5A] il CipherText di una chiave (testo criptato)
[3C] ECM Coding Control Word
[3A] ECM Decoding Control-Word
[40-3C-3A] Criptare e decriptare una chiave

 Gestione di una carta Seka
[32-34] Trappolamento delle chiavi  - Prossimamente !
[90 FX] Inserire una nuova MK0x sul Provider Px (Pippo_360)
[82] Calcolare una Signature valida (John MacDonald)
[23] Creazione di un nuovo Provider
[D0] Aggiunta del nome del Provider
[25] Cancellazione di un Provider
[26] Autorizzazione del Provider
[17] Inserirmento codice regionale
[21] Inserimento della data
[B0] Attivazione della carta
[41] Inserimento PPUA
[90 5X] Inserimento MK0x primaria
[91 5X] Inserimento MK0x secondaria
[90 5C] Inserimento chiave 0C primaria
[90 5D] Inserimento chiave 0D primaria
[90 5E] Inserimento chiave 0E primaria
[91 5C] Inserimento chiave 0C secondaria
[91 5D] Inserimento chiave 0D secondaria
[91 5E] Inserimento chiave 0E secondaria
[10] Cancellazione MK primaria
[10] Cancellazione MK secondaira
[80] Inserimento nuovo Bitmap Package

ATR
Il formato generale dell'ATR (Answer To Reset) è: Da ISO 7816 possiamo riconoscere: Le XX sono variabili  che però non devono essere modificate. Questo significa che l'ATR non viene usato per identificare il propietario di una card. Gli ultimi 2 bytes (90 00) sono Status Byte e non appartengono propriamente all’ATR (vedi “Status Bytes“).

La card può funzionare in tre modi operativi. Ogni modo operativo viene distinto da un ATR.

E’ possibile abbandonare il modo programmazione, mentre come portare una card in modo Programmazione rimane ancora una sfida aperta.
 
 

[Torna all'indice]


La struttura delle chiavi seka

L'algoritmo SEKA è basato su una ControlWord di 8 byte  (CW) criptata attraverso la quale viene generata, con l'ausilio di una chiave di 16 byte una ControlWord decriptata, o Plain, di 8 byte. In questa occasione viene usata la OPERATION KEY. Questo Algoritmo è noto, la Signature può essere calcolata e la SuperEncryption (vedi istruzione 0x40) può essere implementata. Queste informazioni sono ampiamente trattate, così come la procedura matematica di crittografia, nel testo "Mediaguard Musings" di John MacDonald. La Key di 16 bytes consiste di una key primaria (PK) di 8 bytes e di una key secondaria (SK) di 8 bytes. La key secondaria può corrispondere alla key primaria. PK ed SK sono identificate con numeri esadecimali da 0x00 fino a 0xFF, con un numero potenziale di 16 keys.
 

Le keys da 0x0C a 0x0E sono le Operation Key. La key 0x0F sembra avere una funzione particolare.
Le keys da 0x00 a 0x0B sono Management Keys (MK).
 

FF FF FF FF FF FF FF FF        -  FF FF FF FF FF FF FF FF                <--- Struttura delle chiavi primarie e secondarie di un solo Provider.
Management Key 00 primaria -  Management Key 00 secondaria
Management Key 01 primaria -  Management Key 01 secondaria
Management Key 02 primaria -  Management Key 02 secondaria
Management Key 03 primaria -  Management Key 03 secondaria
Management Key 04 primaria -  Management Key 04 secondaria
Management Key 05 primaria -  Management Key 05 secondaria
Management Key 06 primaria -  Management Key 06 secondaria
Management Key 07 primaria -  Management Key 07 secondaria
Management Key 08 primaria -  Management Key 08 secondaria
Management Key 09 primaria -  Management Key 09 secondaria
Management Key 0A primaria -  Management Key 0A secondaria
Management Key 0B primaria -  Management Key 0B secondaria
Operation Key 0C primaria     -  Operation Key 0C secondaria
Operation Key 0D primaria     -  Operation Key 0D secondaria
Operation Key 0E primaria      -  Operation Key 0E secondaria
Operation Key 0F primaria      -  Operation Key 0F secondaria             <---- Utilizzo non ancora noto.


Distinguiamo poi ulteriormente tra SEKA Keys e Provider Keys. Attraverso la divisione in SEKA e Providers Key viene creata una struttura gerarchica: ogni Provider può modificare solo i propri dati. Mentre per poter operare nell'aggiungere o cancellare un Provider è necessario conoscere le Keys del provider SEKA. La key SEKA da 0x00 è necessaria per tutte le operazioni importanti da effettuare sulla card quali l'aggiunta o la cancellazione di un Provider. Questa Key è diversa per ogni card e può essere usata per mettere fuori uso una card. La key SEKA 0x01 (67 67 05 45 0C DB F2 E1) è identica per tutte le card, non importa a quale Provider appartenga. Non esiste su tutte le card, per esempio non esiste per Canal Satellite Numerique France (CSN)  e viene cancellata con l'uso della card. In contrasto con la SEKA key 0x00, che permette di modificare solamente una unica card, con la key 0x01 in posizione quasi tutte le card  possono venire modificate da un EMM-G (vedi istruzione 0x40). Ciò che vale per i regolari utenti non è necessariamente applicabile alle MOSC. Con la SEKA key 0x01, per mezzo della istruzione 0x40 e di un software adeguato si possono aggiungere o cancellare i Provider. La Provider key 0x00 viene tra l'altro usata  con i gettoni PPV per le transazioni sugli eventi. Il Provider Canal Satelite Digital Espana (CSD) sembra assegnare ai gruppi card un nuovo SA (Shared Address) ogni due mesi. Con la Provider Key 0x00 le card assumono le nuove Operation Keys, la nuova PPUA e naturalmente una nuova Provider Key 0x01.

La Provider Key 0x01 è estremamente importante. E' valida per un gruppo di card ed è necessaria per l'aggiornamento delle Operation Keys . Con una Key 0x01 corretta e una PPUA valida , attraverso  il comando C1 40 Px 81 4E  (e la porzione di dati che ne fa parte) è possibile ottenere l'aggiornamento della key per SUPERENCRYPTION. I dati vengono decodificati sulla base della key 0x01: alla fine dell'operazione i dati vengono scritti sulla card. Questa operazione viene chiamata AUTOUPDATE. Una card così modificata verrebbe considerata a tutti gli effetti coma una card regolarmente abbonata e quindi costantemente aggiornata. E' possibile ottenere una card auto-aggiornante modificando la PPUA in abbinamento ad una Mkey 01 valida.

Un'altra key da menzionare è la Provider Key 0x02. Rende possibile la fase di pre-abbonamento, quel periodo durante il quale è possibile decodificare i programmi con una card nuova e mai inserita nel ricevitore . Non esiste per tutti i Providers ed è in disuso. Viene cancellata con l'uso della card. Canal + NL fa uso di questa key per eseguire un comando di cancellazione di tutte le SEKA MK, tranne la 0x00. Per quanto riguarda la Provider Key 0x03  non so a quale uso sia destinata. Quando le Keys sono memorizzate nella card, nel Key-Index viene settato almeno un bit (il quinto bit  nella 0x10) che normalmente è il più alto. Cosa significhi settare questo bit avremo modo di vederlo più avanti nel testo.
 
 
 

[Torna all'indice]


La struttura delle istruzioni seka
Il sistema SEKA  riconosce tre livelli di comandi . E' importante distinguerli :

1 - Istruzione: Una funzione che interviene per mezzo di determinati valori assegnati all’ INS-Byte .
2 - Comando: Una funzione che interviene per mezzo dei valori inseriti nel Pacchetto – dati  ( data packet ). E’ la parte che segue l’invio di una istruzione .
3 - Nanocomando o Nano:  è parte dell'esecuzione di ogni istruzione ed è inserito nel data-packet. E’ la parte che segue l’invio di un comando .

E' composta da 5 bytes secondo lo standard ISO 7816. Tutti i valori sono in esadecimale. Una istruzione SEKA ha la seguente struttura:
CLA INS P1 P2 (I) LEN / P3 DATA 82 SIG

CLA = Class Byte  ( L'unica CLASSE valida per SEKA è C1)
INS = Instruction Byte
P1 = Parameter or reference byte
P2 = Parameter or reference byte
(I)LEN / P3 = Lenght byte ( lunghezza della stringa di risposta in esadecimale )
DATA = Dati che compongono l'istruzione; non è uguale per ogni istruzione (contiene comandi e Nano-comandi  seguiti dai relativi dati)
82 = NANO 0x82  (seguito dalla Signature)
SIG = Signature (composta da 8 bytes , non è necessaria per tutte le istruzioni)

Esempio :
C1 3A 00 00 10

CLA = C1       INS = 3A        P1= 00       P2 = 00        LEN = 10 (Hex)

[Torna all'indice]


L'algoritmo del Seka
Preso dal documento di John MacDonald, ve lo riporto fedelmente.
 

ALGORITMO DI DECRIPTAGGIO
L’algoritmo di decriptaggio di Mediaguard opera su una parola criptata di 8-byte, utilizzando una chiave di 16-byte per produrre una parola di 8-byte in chiaro. La chiave di 16-byte è costituita da una Chiave Primaria di 8-byte a da una Secondaria ugualmente di 8-byte. Qualche volta la ChiaveSecondaria coincide con quella Primaria, altre volte è diversa. Per chiarire questa situazione di confusione esaminiamo più approfonditamente le 2 chiavi. Entrambi le chiavi, Primaria e secondaria, sono numerate da 0x00 a 0x0F in modo che potenzialmente possono esserci 16 Chiavi Primarie e 16 Chiavi Secondarie. Sembra che le chiavi operative (Operation keys - per ECM) sono da 0x0C a 0x0F e che le chiavi da 0x00 a 0x0B sono di manipolazione (management keys - per EMM). Ma le chiavi primarie, a capriccio delle emittenti, quando sono state memorizzate nelle Smartcard possono essere state numerate da 0x10 a 0x1F. Solo le chiavi Primarie così numerate possono essere utilizzate con le chiavi Secondarie equivalenti. L’algoritmo è formato da due fasi:

1) Preparazione della Chiave
2) Manipolazione dei dati
1) Preparazione della Chiave

Immaginiamo che i byte della chiave siano disposti in forma circolare come fossero avvolti su un cerchio, in questo modo:

...k15, k16, k1, k2, ..., k13, k14...

Iniziamo da k1, prendiamo il byte che ‘lo precede’ (cioè k16), facciamo lo XOR di questo con quello che ‘segue’ k1 (cioè k2) e con una costante C. usiamo questo risultato come indice nei primi 256-byte della tabella T1 e facciamo lo XOR del valore ottenuto da T1 con k1. Questo è il nuovo valore di k1. La costante C ha un valore iniziale nullo, e la tabella T1 è mostrata alla fine di questa sezione.

Così k1 = k1 XOR T1(k16 XOR k2 XOR C).

Ripetiamo questo procedimento altre 3 volte su k2,k3 e k4 per assegnare:

k2= k2 XOR T1(k1 XOR k3 XOR C)
k3 = k3 XOR T1(k2 XOR k4 XOR C)
k4 = k4 XOR T1(k3 XOR k5 XOR C).

Incrementiamo la costante C di 1 e facciamo altre 4 iterazioni (su k5…k8):

k5= k5 XOR T1(k4 XOR k6 XOR C)
k6 = k6 XOR T1(k5 XOR k7 XOR C)
k7 = k7 XOR T1(k6 XOR k8 XOR C)
k8 = k8 XOR T1(k7 XOR k9 XOR C)

Incrementiamo la costante C e facciamo altre 4 iterazioni (su k9…k12):

K9= k9 XOR T1(k8 XOR k10 XOR C)
K10 = k6 XOR T1(k9 XOR k11 XOR C)
k11 = k7 XOR T1(k10 XOR k12 XOR C)
k12 = k8 XOR T1(k11 XOR k13 XOR C)

Incrementiamo la costante C e facciamo altre 4 iterazioni (su k13…k16):

K13= k13 XOR T1(k12 XOR k14 XOR C)
K14 = k14 XOR T1(k13 XOR k15 XOR C)
k15 = k15 XOR T1(k14 XOR k16 XOR C)
k16 = k16 XOR T1(k15 XOR k1 XOR C)

A questo punto C=3.

Incrementiamo ancora C e ricominciamo dall’inizio per ottenre k1 …k16. Ü
Ora C=7

Ripetiamo ancora due volte il processo Ü incrementando sempre C e formando nuovi valori per tutti e 16 i ‘k’ byte. A questo punto C=15 e abbiamo ripetuto l’algoritmo 16 x 4 volte. Abbiamo terminato la fase 1 di preparazione della chiave ed I valori finali di k1,...,k16 sono quelli usati nella fase di manipolazione dei dati.
 

2) Manipolazione dei dati

L’algoritmo è formato da 16 cicli. Ogni ciclo opera solo su 4 byte di chiave e 4 byte di dati. Detti k1, k2, …, k16 i byte della chiave (ottenuti dopo la fase di preparazione della chiave) e detti i byte dei dati d1,d2,…,d8 si ha:
 

Numero Ciclo Byte di chiave Byte di dati
1, 5, 9, 13 k13, k14, k15, k16 d5, d6, d7, d8
2, 6, 10, 14 K9, k10, k11, k12 d5, d6, d7, d8
3, 7, 11, 15 k5, k6, k7, k8 d5, d6, d7, d8
4, 8, 12, 16 k1, k2, k3, k4 d5, d6, d7, d8

Un ciclo consiste in:

- Fare lo XOR dei byte di chiave con quelli di dati:
- Eseguire la Funzione Nucleo (core function) sui byte di dati per calcolare i 4 nuovi byte di dati
- Fare lo XOR di questi valori con gli altri 4 byte dati per calcolare i 4 nuovi valori per i byte di dati d5-d8 per il ciclo successivo
- Processare I byte di chiave per calcolare I 4 nuovi byte di chiave da utilizzare nel ciclo seguente.
Primo passo - XOR dei byte di chiave con quelli di dati

Questo è semplice:

d5 = K(i) XOR d5
d6 = K(i+1) XOR d6
d7 = K(i+2) XOR d7
d8 = K(i+3) XOR d8
dove i = 13 per i cicli 1, 5, 9, 13
               9 per i cicli 2, 6, 10, 14
               5 per i cicli 3, 7, 11, 15
               1 per i cicli 4, 8, 12, 16.

Secondo passo - Funzione Nucleo

Prima eseguire 4 accessi alla Tabella 1:

d5 = T1[d5], d6 = T1[d6], d7 = T1[d7], d8 = T1[d8]

Successivamente utilizzare la Tabella 2 (vedi oltre). Il termine '~' significa che scambio di posto del mezzo byte meno significativo con quello più significativo (es. 11100010 = E2Þ ~E2 = 2E = 00101110):
 

d5 = d8 XOR d5
d7 = T2[(~d8) + d7]

d8 = d7 XOR d8
d6 = T2[ (~d7) + d6]

d7 = d6 XOR d7
d5 = T2[ (~d6) + d5]

Ora si deve utilizzare la Tabella 1 come segue:

d6 = d5 XOR d6
d8 = T1[(~d5) + d8]

d5 = d8 XOR d5
d7 = T1[(~d8) + d7]

d8 = d7 XOR d8
d6 = T1[(~d7) + d6]

Infine eseguire:

d7 = d6 XOR d7
d6 = d5 XOR d6.

Se in qualche addizione il valore risultante è maggiore di 0xFF, sottrarre il valore 0x0100 prima di accedere alle tabelle.
 

Terzo Passo - Calcolare i nuovi valori dei byte di dati per il prosimo ciclo

Questi si ottengono dalla Tabella 2 procedendo come segue:

d1 = T2[d6] XOR d1
d2 = T2[d8] XOR d2
d3 = T2[d5] XOR d3
d4 = T2[d7] XOR d4

Prima di utilizzare i byte di dati d1, …, d8 occorre scambiarli come segue :

d1 - d5
d2 - d6
d3 - d7
d4 - d8
NOTA: al termine del 16° ciclo però questo scambio NON deve essere fatto ed i byte di dati decriptati sono d1, …, d8.
 

Quarto passo - Ottenere nuovi byte di chiave per il successivo ciclo

Eseguire le seguenti operazioni:

k(i+3) = k(i+3) XOR T1[k(i+4) XOR k(i+2) XOR C]
k(i+2) = k(i+2) XOR T1[k(i+3) XOR k(i+1) XOR C]
k(i+1) = k(i+1) XOR T1[K(i+2) XOR k(i) XOR C]
k(i) = k(i) XOR T1[k(i+1) XOR k(i-1) XOR C]

dove i = 13 per i cicli 1, 5, 9, 13
                9 per i cicli 2, 6, 10, 14
                5 per i cicli 3, 7, 11, 15
                1 per i cicli 4, 8, 12, 16.

Nei casi in cui la suddetta formula dia suffissi k fuori dall’intervallo 1-16, si deve considerare il valore ottenuto da k facendone il modulo 16. Es. Se k = 17, allora k = k mod 16 = 1, se k=16, allora k = k mod 16 = 0). Il valore della costante C dipende dal numero di ciclo. Per i cicli 1, 2, …, 15, 16 tale costante ha valori rispettivamente pari a 0x0F, 0x0E, …, 0x01, 0x00.
 
 

Tabella 1:

02ah 0e1h 00bh 013h 03eh 06eh 032h 048h
0d3h 031h 008h 08ch 08fh 095h 0bdh 0d0h
0e4h 06dh 050h 081h 020h 030h 0bbh 075h
0f5h 0d4h 07ch 087h 02ch 04eh 0e8h 0f4h
0beh 024h 09eh 04dh 080h 037h 0d2h 05fh
0dbh 004h 07ah 03fh 014h 072h 067h 02dh
0cdh 015h 0a6h 04ch 02eh 03bh 00ch 041h
062h 0fah 0eeh 083h 01eh 0a2h 001h 00eh
07fh 059h 0c9h 0b9h 0c4h 09dh 09bh 01bh
09ch 0cah 0afh 03ch 073h 01ah 065h 0b1h
076h 084h 039h 098h 0e9h 053h 094h 0bah
01dh 029h 0cfh 0b4h 00dh 005h 07dh 0d1h
0d7h 00ah 0a0h 05ch 091h 071h 092h 088h
0abh 093h 011h 08ah 0d6h 05ah 077h 0b5h
0c3h 019h 0c1h 0c7h 08eh 0f9h 0ech 035h
04bh 0cch 0d9h 04ah 018h 023h 09fh 052h
0ddh 0e3h 0adh 07bh 047h 097h 060h 010h
043h 0efh 007h 0a5h 049h 0c6h 0b3h 055h
028h 051h 05dh 064h 066h 0fch 044h 042h
0bch 026h 009h 074h 06fh 0f7h 06bh 04fh
02fh 0f0h 0eah 0b8h 0aeh 0f3h 063h 06ah
056h 0b2h 002h 0d8h 034h 0a4h 000h 0e6h
058h 0ebh 0a3h 082h 085h 045h 0e0h 089h
07eh 0fdh 0f2h 03ah 036h 057h 0ffh 006h
069h 054h 079h 09ah 0b6h 06ch 0dch 08bh
0a7h 01fh 090h 003h 017h 01ch 0edh 0d5h
0aah 05eh 0feh 0dah 078h 0b0h 0bfh 012h
0a8h 022h 021h 03dh 0c2h 0c0h 0b7h 0a9h
0e7h 033h 0fbh 0f1h 070h 0e5h 017h 096h
0f8h 08dh 046h 0a1h 086h 0e2h 040h 038h
0f6h 068h 025h 016h 0ach 061h 027h 0cbh
05bh 0c8h 02bh 00fh 099h 0deh 0ceh 0c5h

Tabella 2:

0bfh 011h 06dh 0fah 026h 07fh 0f3h 0c8h
09eh 0ddh 03fh 016h 097h 0bdh 008h 080h
051h 042h 093h 049h 05bh 064h 09bh 025h
0f5h 00fh 024h 034h 044h 0b8h 0eeh 02eh
0dah 08fh 031h 0cch 0c0h 05eh 08ah 061h
0a1h 063h 0c7h 0b2h 058h 009h 04dh 046h
081h 082h 068h 04bh 0f6h 0bch 09dh 003h
0ach 091h 0e8h 03dh 094h 037h 0a0h 0bbh
0ceh 0ebh 098h 0d8h 038h 056h 0e9h 06bh
028h 0fdh 084h 0c6h 0cdh 05fh 06eh 0b6h
032h 0f7h 00eh 0f1h 0f8h 054h 0c1h 053h
0f0h 0a7h 095h 07bh 019h 021h 023h 07dh
0e1h 0a9h 075h 03eh 0d6h 0edh 08eh 06fh
0dbh 0b7h 007h 041h 005h 077h 0b4h 02dh
045h 0dfh 029h 022h 043h 089h 083h 0fch
0d5h 0a4h 088h 0d1h 0f4h 055h 04fh 078h
062h 01eh 01dh 0b9h 0e0h 02fh 001h 013h
015h 0e6h 017h 06ah 08dh 00ch 096h 07eh
086h 027h 0a6h 00dh 0b5h 073h 071h 0aah
036h 0d0h 006h 066h 0dch 0b1h 02ah 05ah
072h 0beh 03ah 0c5h 040h 065h 01bh 002h
010h 09fh 03bh 0f9h 02bh 018h 05ch 0d7h
012h 047h 0efh 01ah 087h 0d2h 0c2h 08bh
099h 09ch 0d3h 057h 0e4h 076h 067h 0cah
03ch 0fbh 090h 020h 014h 048h 0c9h 060h
0b0h 070h 04eh 0a2h 0adh 035h 0eah 0c4h
074h 0cbh 039h 0deh 0e7h 0d4h 0a3h 0a5h
004h 092h 08ch 0d9h 07ch 01ch 07ah 0a8h
052h 079h 0f2h 033h 0bah 01fh 030h 09ah
000h 050h 04ch 0ffh 0e5h 0cfh 059h 0c3h
0e3h 00ah 085h 0b3h 0aeh 0ech 00bh 0feh
0e2h 0abh 04ah 0afh 069h 06ch 02ch 05dh

 
 
 
 

[Torna all'indice]


Il formato della data
Diversi comandi usano la data . E' codificata a bit e può assumere valori da 01.01.1990 fino a 31.12.2118. I bit vanno letti da destra verso sinistra.
7 bits contengono l'anno . al numero ottenuto va sommato 1990 .
4 bits contengono il mese . 1 stà per gennaio
5 bits contengono il giorno del mese

Esempio :
Dopo una istrizione 0x12 otteniamo una stringa del tipo :

12 00 04 43 41 4E 41 4C 53 41 54 45 4C 4C 49 54 45 20 20 00 1A 0C 34 0E FF 90 00

La data codificata per la fine dell'abbonamento è 0E FF.
Se convertiamo in binario i due byte otteniamo 111011111111, 12 bit.
La data è comunque composta da 16 bit, quindi aggiungiamo gli zeri mancanti e otteniamo 0000111011111111. Quindi i

  7 bit sono: 0000111   ( anno )
  4 bit sono: 0111         ( mese )
  5 bit sono: 11111       ( giorno )

Convertendo in decimale i numeri ottenuti si ottiene 31.07.1997

[Torna all'indice]

Che cosa è il Bitmap Package
Questo parametro indica che tipo di abbonamento si ha. Il BP è formato da 8 byte. Ogni byte puo essere scomposto in un formato di questo tipo:
11111111 - 11111111 - 11111111 - 11111111 - 11111111 - 11111111 - 11111111 - 11111111
1 byte      - 2 byte       - 3 byte      - 4 byte      - 5 byte      - 6 byte       - 7 byte      - 8 byte
Ogni bit puo corrispondere a un pacchetto di abbonamento (Basic, Digi, Premium, ecc). Se si avesse un BP composto da 8xFF si risulterebbe essere abbonati a tutti i pacchetti. In teoria i pacchetti possono essere max 64 ma in realtà sono in quantità minore.
 
 

Tabella utilizzata da D+

  A B C D E F G H
1° Byte Non usato Non usato Non usato Non usato Non usato Non usato Non usato Non usato
2° Byte Non usato Non usato Non usato Non usato Non usato Non usato Non usato Non usato
3° Byte Non usato Non usato Non usato Non usato Non usato Non usato Non usato Non usato
4° Byte Non usato Cinema Cinema Milan Ch. Non usato Jimmy Mmusic Eursport Premium Supbasic PALCO +F1
5° Byte Non usato Non usato Non usato Non usato Non usato Non usato Non usato Non usato
6° Byte Non usato Non usato Non usato Digì Non usato Non usato Non usato Non usato
7° Byte Jimmy Non usato PremiumDigì Cinema Non usato Non usato Non usato BasicCinema
8° Byte Inter Ch. - Tmc DisneyCh. Classica Season Cinema Basic Premium Non usato

Si noti che alcuni pacchetti si ripetono in diverse locazioni. Adesso vediamo come usare questa tabella per farci il nostro “abbonamento” personalizzato per D+.

Esempio:
Vogliamo farci un abbonamento soltanto a Milan Ch. e Premium, analizziamo le locazioni:

                 A     B     C      D      E       F     G      H
1° Byte     0      0      0      0       0      0      0      0     nel 1° byte non ci sono locazioni da attivare
2° Byte     0      0      0      0       0      0      0      0     nel 2° byte non ci sono locazioni da attivare
3° Byte     0      0      0      0       0      0      0      0     nel 3° byte non ci sono locazioni da attivare
4° Byte     0      0      1      0       0      0      0      0     alla locazione C abbiamo  Milan Ch.
5° Byte     0      0      0      0       0      0      0      0     nel 5° byte non ci sono locazioni da attivare
6° Byte     0      0      0      0       0      0      0      0     nel 6° byte non ci sono locazioni da attivare
7° Byte     0      0      0      0       0      0      0      0     nel 7° byte non ci sono locazioni da attivare
8° Byte     0      0      0      0       0      0      1      0     alla locazione G abbiamo PREMIUM

Compiliamo il nostro Bitmap Package per il nostro abbonamento personalizzato, convertendo i bytes in hex, cioè:

1° Byte:  00000000bin = 00hex
2° Byte:  00000000bin = 00hex
3° Byte:  00000000bin = 00hex
4° Byte:  00100000bin = 20hex
5° Byte:  00000000bin = 00hex
6° Byte:  00000000bin = 00hex
7° Byte:  00000000bin = 00hex
8° Byte:  00000010bin = 02hex

Adesso affianchiamo il nostro bel Bitmap:
1°    2°    3°    4°   5°   6°   7°    8°
00   00   00   20   00   00   00   02
e questo è il nostro bitmap package.

Tabella utilizzata da +Calcio

 

  A B C D E F G H
1° Byte                
2° Byte                
3° Byte Crotone Cittadel. Ancona     Tmc   +Calcio Gold
4° Byte Livorno Verona  Treviso Torino Ternana Reggina   Ravenna
5° Byte Pescara Napoli Away Monza Pistoiese Lecce Away Genoa    
6° Byte Cosenza Chievo   Brescia Atalanta Vicenza Venezia Udinese Away
7° Byte Sampd. Away Salernit. Roma Away Piacenza Perugia Parma Away Milan Lazio Away
8° Byte Juventus Inter Fiorent. Away Empoli Cagliari Bologna Bari  


 
 

[Torna all'indice]


Che cosa è il PPUA
La PPUA o Programme Provider User Address è composto di quattro bytes. La PPUA è composta di due parti unite assieme: i primi 3 bytes compongono la SA (Shared Addres), seguita dal CUSTWP-Byte (Customer Word Pointer). Ad una Sa  possono essere associate un massimo di 256 card, identificate una ad una dal CUSTWP al quale è associato un registro bitmapped di 32 byte. Come conseguenza tutte le card di un gruppo, o alcune, possone essere indirizzate. Consultare il comando C1 12 Px Kx LL per determinare la vostra PPUA.
 
 

[Torna all'indice]


Status-Byte (Risposta della Carta)
Queste sono tutte le risposte che potremmo avere dalla nostra carta.
6700   Lunghezza errata
6B00   Parametro/reference byte(s) non corretto
6D00   Istruzione non supportata o protetta e non di libero uso
6E00   Classe non supportata
6F00   Non è possibile una diagnosi precisa
9000   Comando eseguito senza errori
9002   Signature falsa o mancante
9004   Provider non supportato
9005   INS 0x40 : Nano ammesso solo per SEKA
9006   INS 0x3C, Nano 0x15 : spazio mancante per memorizzare Preview Record
9006   INS 0x3C, Nano 0x19/0x2C : spazio mancante per memorizzare Preview Record
9008   INS 0x40, Nano 0x01 : non ammesso
9009   INS 0x40 : PPUA mancante nel F0-Bitmap
9010   INS 0x30 : PIN errato
9011   Istruzione non supportata
9013   INS 0x40 : Key errata , ammessa solo MK’s
9014   Istruzione precedente errata
9015   INS 0x40, Nano 0x80 : non ammesso
9015   INS 0x3C, Nano 0x15 : non ammesso
9015   INS 0x3C, Nano 0x2C : non ammesso
9015   INS 0x32/0x36 : Valore fornito non supportato
9016   INS 0x40, Nano 0x87 : Errore Decodifica
9016   INS 0x44 : non ammesso
9017   INS 0x50/0x54 : non ammesso
9017   INS 0x56 : non ammesso
9018   Provider già esistente
9019    INS 0x40, Nano 0x41 : PPUA è stata modificata
901A   INS 0x3C, Nano 0x15/0x2C : Errore acquisto gettoni
901B   INS 0x3C, Nano 0x15/0x2C : Nessun gettone disponibile
901B   Credit Record non esiste
901C   INS 0x3C, Nano 0x15/0x2C : Acquisto gettoni OK , ma solo in base al credito
901D   Primary Key non disponibile
901E   Errore
901F   Secondary Key non disponibile
9021   INS 0x04 : Key non 0x0F – rifiutata
9022   Modo errato Card
9024    Errore checksum
9026    INS 0x3C, Nano 0x31 : Fine Preview
9027    INS 0x3C, Nano 0x19 : Decodifica Preview-Phase
9301    INS 0x40, Nano 0x22 : Data eccedente quella di scadenza
9301    INS 0x3C, Nano 0x27 : Data di scadenza attraversata
9302    INS 0x3C, Nano D1 : nessuna decodifica
9304    INS 0x3C, Nano 0x12 : Regolazione Protezione Parental Control troppo bassa
9305    INS 0x3C, Nano 0xF1 : Trasmissione non destinata a questa zona geografica
9402    INS 0x32 : Valore P2 errato : ammesso solo per P2 = 0
9402    INS 0x30 : Valore P2 errato
9600    INS 0x38 : Stringa errata ( Nano errato , Signature errata )
9600    INS 0x3C : Nano 0x15/0x2C : Evento immediato 0
9600    INS 0x3C : Tutti i Nano eseguiti correttamente  – nessuna decodifica
96xx    INS 0x3C : xx Nano eseguiti correttamente , ma nessun Nano 0xD1 incontrato
96xx     INS 0x40 : Tutti i Nano eseguiti correttamente
97xx    Aggiornamento Eeprom non necessaria per alcuni Nano .
            XX è il Bitmap di questi Nano.
            Esempio : 3C = nessun update per i nano 2 , 3 , 4 , 5 ( il conteggio inizia da 0 )
99xx    Data errata .  Il credito odierno è stato modificato
99xx    Data errata


[Torna all'indice]


Determinare [0A] il sistema operativo della carta
C1 0A Px Kx LL
Determiniamo con questo comando quale sia la versione della carta
C1 = Classe istruzione
0A = Tipo istruzione
Px = Sono sempre 00
Kx = Sono sempre 00
LL = Lunghezza comando. Per le 3.0 è uguale 3E e per le 4.0 e 4.1 è uguale 44.

Esempio:
C1 0A 00 00 44
Risposta della card : 0A A3 01 06 01 37 17 1A 00 00 00 24 35 80 76 BC D2 59 59 C2 85 06 73 BC B1 F0 0C 85 34 7E 86 61 25 96 46 5E 49 7B 04 D8 0F 53 EF 28 43 29 43 41 4E 41 4C 2B 31 39 39 34 2F 39 35 2F 39 36 20 4E 75 6D 34 30 00 90 00

28 43 29 43 41 4E 41 4C 2B 31 39 39 34 2F 39 35 2F 39 36 20 4E 75 6D 34 30 in hex
(C)CANAL+1994/95/96 Num40 in decimale
 
 

[Torna all'indice]

Determinare [0E] il numero seriale della carta UA (Unique Address)
C1 0E Px Kx LL
L'istruzione premette di determinare quale sia il serial number (UA) della carta.
C1 = Classe istruzione
0E = Tipo istruzione
Px = Sono sempre 00
Kx = Sono sempre 00
LL = Lunghezza comando è uguale 08

Esempio:
C1 0E 00 00 08
0E 00 00 00 00 00 12 34 56 90 00

00 00 00 12 34 56  in esadecimale.
1193046                Trasformato in decimale.
001.193.046          Classico formato scritto sulla carta.
 
 

[Torna all'indice]

Determinare [12] l'ident dei Provider
C1 12 Px Kx LL
Questa istruzione è usata dal decoder al fine di interrogare e di ottenere i dati identificativi della CAM SEKA  e del Channel Provider. Per Provider di intende le emittenti televisive che trasmettono con codifica seka. Per ogni carta possono essere presenti 16 provider. Il primo di questi provider è sempre "seka" (con ident numerico pari a 00 00), questo provider è in grado di gestire tutta la carta e tutti i provider inseriti nella carta stessa. Il Provider seka non viene utilizzato per decodificare nessu canale in quanto con l'ident 00 00 non viene trasmesso nulla. E' un Provider di sola gestione, infatti non ha PPUA, data di fine abbonamento ne OK c,d,e, ne Bitmap Package. Possiede solo MK 00 e MK 01 al fine di ottenere una Signature valida, per la gestione della carta. Più avanti troverete tutti gli ident delle varie emittenti. Per ulteriori informazioni clicca qui.
C1 = Classe istruzione
12 = Tipo istruzione
Px = Indica il Provicer a cui il comando è indirizzato
Kx = Sono sempre 00
LL = Lunghezza comando è uguale 08

Esempio:
C1 12 00 00 19
Risposta della card : 12 00 00 53 45 43 41 20 20 20 20 20 20 20 20 20 20 20 20 11 22 33 44 DD DD 00 90 00

12 = Risposta al comando
00 00 = Ident del Provider a cui è stata fatta richiesta delle informazioni.
53 45 43 41 20 20 20 20 20 20 20 20 20 20 20 20 = Nome del Provider in Hex (SEKA).
11 22 33 44 = Il PPUA del Provider a cui è stata fatta richiesta di informazioni
DD DD = Data di fine abbonamento.
00 = Regional code - Bitmap

Esempio :
C1 12 01 00 19
Risposta della card : 12 00 04 43 41 4E 41 4C 53 41 54 45 4c 4C 49 54 45 20 20 00 1A 0C 34 0E FF 00 90 00

Dati per il Provider-Number:    01
ProviderID / Ident:                  00 04
Channel ProviderID String :     CANALSATELLITE
PPUA:                                    00 1A 0C 34
Fine dell'abbonamento:           0E FF
Regional – Bitmap:                 00

Altri Providers-ID di esempio:
00 00 SEKA
00 03 Canal+ France
00 04 Canal Satellite Numerique France ( CSN , Kiosque)
00 09 Cable Numerique France ( CSN / C+ / ABSAT )
00 0A Stream
00 0B Premiere ( vecchie SEKA card )
00 0C Canal Satellite Digital Espana ( CSD  , Taquilla )
00 0E Canal+ Horizons
00 10 Telepiù / D+
00 11 Calcio
00 12 Equidia
00 14 Canal+ NL / Canal+ Vlaanderen
00 19 Canal Digitaal NL
00 1A Equidia Int.
00 1C Mediaset
001D  Cyfra+ ( digital Platform Poland )
00 25 AB SAT
00 29 Canal+ Horizons
00 0F  AB SAT / CINESTAR
 

[Torna all'indice]

Determinare [16] il numero dei Provider della carta
C1 16 Px Kx LL
Con questa istruzione il decoder determina il numero dei Providers presenti sulla card e la validità della CAM SEKA .
 
C1 = Classe istruzione
16 = Tipo istruzione
Px = Sono sempre 00
Kx = Sono sempre 00
LL = Lunghezza comando è uguale 07

Esempio:
C1 16 00 00 07
Risposta della card : 16 00 00 00 03 00 00 FF 90 00

C1 16 00 00 07
Risposta della card : 16 00 00 01 FF 00 00 FF 90 00

I dati che ci interessano si trovano nel terzo e quarto byte della risposta della card. Questi due bytes esadecimali formano una WORD di 16 bit . (16 è il numero dei Providers totali che possono essere gestiti dalla card , SEKA CAM compresa). Per ogni Provider abilitato viene settato un bit della word. Per il primo esempio  si ha che solo 2 bit della word sono settati e cioè sono abilitati la CAM SEKA ed il Provider 01. Per il secondo esempio si ha che sono settati 9 bit della word e cioè sono abilitati la CAM SEKA ed i Prov. da 01 a 08.

Esempio :
0 0 0 0 0 0 0 0    0 0 0 0 0 0 1 1  = 00 03  ( Bin to Hex )
0 0 0 0 0 0 0 1    1 1 1 1 1 1 1 1  = 01 FF  ( Bin to Hex )

In questo modo , contando da destra verso sinistra , il software del decoder riconosce che nella istruzione 0x12 deve esaminare i dati del numero di Provider specificati.
 
 

[Torna all'indice]

Determinare il PPUA
Consultare il comando C1 12 Px Kx LL per determinare la PPUA o consultare "cosa è la PPUA".
 
 
 

[Torna all'indice]


Determinare la data di fina abbonamento
Consultare il comando C1 12 Px Kx LL
 
 
 

[Torna all'indice]


[34] il Data Request
Stiamo parlando della coppia di istruzioni 0x34 e 0x32. Mentre la 0X32 è una istruzione per esigenze di tipo generale, con la istruzione 0X34 opportunamente impiegata possiamo specificare quali dati devono essere trasmessi. La 0X34 viene sempre prima della 0X32. I seguenti comandi sono usati per stabilire quali dati trasferire, qual'e il primo byte del comando e i successivi bytes che compongono il comando: (PPV = Pay per View)
00 00 00    ProviderBitmap Package Records
01 00 00    Provider PPV Credit Records
03 xx xx     Provider PPV - Records
04 00 yy     SEKA Record
04 00 00     SEKA PPV Record
04 00 01     SEKA Startup Record
04 00 02     Record di attivazione SEKA
06 zz zz       Qualsiasi Record

xx xx           contiene la PPV-EventID, che identifica inequivocabilmente ogni trasmissione PPV.
yy              contiene il tipo di SEKA Record che sta per essere letto
zz zz           è il Numero Record  (il conteggio inizia da 00 01) a partire dal quale la lettura deve iniziare.

Esempio:
Istruzione per la card: C1 34 00 00 03 04 00 01
Echo della card:         34 04 00 01 90 00

E' importante che per mandare questa istruzione venga selezionato nel software in uso l'opzione "From CAM to Card", in modo che il decoder richieda questi dati con una specifica richiesta. Se questa indicazione non viene specificata, viene considerata per default l’opzione “From Card to CAM“. Il comando con i dati relativi viene prima portato in una "istruzione" con un grosso campo. Solo allora viene inviato. P1 e P2 sono sempre 00. La lunghezza della stringa di risposta è sempre composta da tre bytes.


Istruzione 0X34 - Specifica della Richiesta Dati ( Data Request )

Esempio (richiesta di informazioni per la CAM SEKA):
a) Istruzione per la card: C1 34 00 00 03 00 00 00
b) Istruzione per la card: C1 32 00 00 20
Risposta della card:        32 04 [ 31 * FF ] 90 00

Non esiste , normalmente , nessun Bitmap Package per SEKA , perciò il Nano 0x04  ci informa che non ci sono dati disponibili .

Esempio (richiesta di informazioni per il Provider 01):
a) Istruzione per la card : C1 34 00 00 03 00 00 00
b) Istruzione per la card : C1 32 01 00 20
Risposta della card : 32 83 00 00 00 00 00 00 00 06 04 [ 22 * FF ] 90 00

Nano 0x83 - segue Bitmap Package per Provider 01 (00 00 00 00 00 00 00 06)
Nano 0x04 - Non ci sono ulteriori informazioni disponibili.

 Istruzione 0X32 - Richiesta Dati ( Data Request )

Con questa istruzione vengono richiamati i comandi ed i relativi dati dell'istruzione 0x34. In questa specifica situazione si parla di RECORDS. Questi sono aree di memoria della card che contengono dati specifici. Grande parte del lavoro del System Management della card consiste nel leggere e selezionare questi dati , riconoscerne il tipo ed associarli a SEKA o ad un Provider. Una Card SEKA V. 4.0 può contenere al massimo 329 Records.  L’ordine dei Record non è fisso e può variare da card a card. Dall'indirizzo $E040 vengono riservati 0x24 bytes per SEKA, poi seguono 0x1C bytes per ogni Provider  (a partire da $E064), il resto da $E358 fino a $EFF4 rimane a disposizione per i Records. La gestione della memoria è dinamica, così che meno Provider ci sono sulla card più record possono essere elaborati. L'istruzione 0x32 segue sempre la 0x34. Si ricordi che si parla sempre della coppia 0x32 & 0x34. Dopo una istruzione 0x34 possono essere inviate alla card diverse istruzioni 0x32: quando l'ultimo Nano della risposta della card è 0x03 allora sono disponibili altre informazioni, altrimenti se è 0x04 vuol dire che non ci sono altre informazioni da estrarre. Questo torna utile per capire quando tutti i Records della card sono stati letti. La stringa di risposta ha una lunghezza variabile, a seconda del tipo e della quantità di dati trasmessi ai Records. Quando si chiede alla card la lettura di un numero di byte maggiore di quello inviato viene restituito 0x04 e bytes a FF. Questi bytes non hanno significato. La lunghezza massima è 89 (0x59) bytes per una card versione 3.0.  P1 contiene il numero del Provider, in questo caso 00 significa SEKA; P2 è sempre 00.

          C1 32 P1 00 LEN

I seguenti Nano possono essere applicati alla istruzione 0X32 :

Comando Nano Significato
0x00  0x83     Segue Bitmap Package ( non per il Provider 00 - SEKA )
0x01  0x84     Segue Credit Records ( non per il Provider 00 - SEKA )
0x03  0xB1    Segue PPV records
0x04  0xB2    Segue SEKA Records, ne esistono diversi generi e tipi
0x06  0xD2    Segue qualsiasi Record, nella composizione dei dati è contenuto anche il Numero dei Records e l'indicazione di quanti records vanno letti (la numerazione inizia da 00 01)
0x03              Successive informazioni possibili
0x04              Non ci sono informazioni .

Andiamo a vedere la costruzione di un Recors in un esempio .
 


SEKA Startup Record

Risposta a : C1 34 00 00 03 04 00 01

P1 e P2 sono sempre 00 , questo significa che che il SEKA Startup Record non è specifico per i Provider. Viene richiamato dal decoder al momento della inizializzazione.

    C1 32 00 00 0D

Esempio:
a)  Istruzione per la card : C1 34 00 00 03 04 00 01
b)  Istruzione per la card : C1 32 00 00 0D
Risposta della card :         32 B2 01 00 00 00 00 00 00 00 00 00 02 04 90 00

Significato:
              <-Nano B2 , lunghezza 16 bytes->
          <--------Dati del Record --------->
                      ( Nano 04 , lunghezza 00 bytes ) >

Nano 0xB2  seguono SEKA records
Nano 0x04  non ci sono ulteriori informazioni disponibili

Se questa istruzione viene inviata per una lunghezza diversa, ad esempio 20 DEC (0D Hex), la parte della stringa successiva al Nano 0x04 viene riempita con FF. Se la richiesta vista sopra ottiene risposta positiva, il decoder prosegue con la procedura di Startup. Il Provider può in questa occasione inviare un comando che cancella il SEKA Startup Record, impedendo al decoder di partire. Gli ultimi due byte contengono un bitmap che non permette, ad esempio, ad una card SEKA – Premiere di funzionare su un GoldBox francese. Si tratta quindi di un Codice Paese. Settando a  FF tutti i bytes dello Startup Records, generalmente, si risolve questo blocco generale. La richiesta di dati per un Provider diverso da 00, ottiene solo il Nano 0x04, cioè nessun dato disponibile in quanto la stringa di Startup è disponibile solo a SEKA.


Providers Bitmap Package Records

Risposta a : C1 34 00 00 03 00 00 00 .

P1 identifica il Provider, P2 è sempre 00. Viene richiamato dal decoder alla partenza e dà accesso al Menù.

    C1 32 P1 00 20

Esempio :
( richiesta di informazioni per la CAM SEKA )
a) Istruzione per la card: C1 34 00 00 03 00 00 00
b) Istruzione per la card: C1 32 00 00 20
Risposta della card:        32 04 [ 31 * FF ] 90 00

Non esiste, normalmente, nessun Bitmap Package per SEKA, perciò il Nano 0x04  ci informa che non ci sono dati disponibili.

Esempio :
( richiesta di informazioni per il Provider 01 )
a) Istruzione per la card: C1 34 00 00 03 00 00 00
b) Istruzione per la card: C1 32 01 00 20
Risposta della card:        32 83 00 00 00 00 00 00 00 06 04 [ 22 * FF ] 90 00

Nano 0x83    Segue Bitmap Package per Provider 01
Nano 0x04    Non ci sono ulteriori informazioni disponibili

Con il recupero dei dati per un Provider (tranne che per il 00), gli 8 bit che seguono il Nano 0x83 rappresentano il Bitmap Package, cioè il Pacchetto di Programmi acquistato dall'abbonato. La numerazione del Bitmap Package inizia da destra verso sinistra, inizia con 00 e può arrivare al massimo a 3F. Quindi sono possibili 64 pacchetti di programmi.

Esempio:

Supponiamo di ottenere come risposta il valore 0x06. Se lo trasformiamo in binario otteniamo 110. Di conseguenza possiamo dire che il Pacchetto 00 non è sottoscritto, mentre lo sono i pacchetti 01 e 02. Quindi 0 sta per "non abbonato" e 1 per "abbonato". Se si settano ad FF tutti I Bytes del Bitmap Package si ottiene l’attivazione completa del pacchetto  programmi .


Provider PPV Credit Records

Risposta a : C1 34 00 00 03 01 00 00

P1 identifica il Provider; questo record è specifico per il Provider. P2 è sempre 00.

    C1 32 P1 00 20

Esempio :
( richiesta di informazioni per il Provider 01 )
a) Istruzione per la card : C1 34 00 00 03 01 00 00
b) Istruzione per la card : C1 32 01 00 20
Risposta della card :        32 84 2F EE 00 AA BB D0 13 00 04 [ 22 * FF ] 90 00

Nano 0x84    segue Credit Record per il Provider richiesto
Nano 0x04    non ci sono ulteriori informazioni disponibili

Questa richiesta avviene nel corso della gestione dei gettoni PPV. In questi Records sono contenute le informazioni dei gettoni relativi ad un Provider. I gettoni sono crediti acquistati per ottenere la visione di alcuni eventi PPV. Certi film sono vibili solo con gettone, altri devono essere acquistati direttamente. La richiesta di dati rivolta al Provider 00 (CAM SEKA) ottiene come risposta il Nano 0x04 in quanto non ci sono PPV Credit Records  per SEKA. I due bytes scritti in italico successivi al nano 0x84 (2F EE) cambiano ad ogni processo di scrittura. AA BB dichiarano la quantità dei gettoni acquistati il 16/06/2000 (D0 13) – (vedi formato della data). Il numero dei gettoni può essere modificato una volta per giorno, può aumentare o diminuire, ma solo il giorno successivo (D0 14) può essere fatta una nuova modifica. La data può assumere come valore massimo FF FE, anche se alla card viene inviato FF FF. Se viene inviata questa data (FF FE) solo con la data a FF FF il numero dei gettoni potrà essere modificato. Il comando 42 FF FF 00 00 cancella il Record.


SEKA PPV Record

Risposta a : C1 34 00 00 03 04 00 00

P1 e P2 sono sempre 00; anche questo record non è specifico per il Provider.

    C1 32 00 00 20

Esempio :
a) Istruzione per la card : C1 34 00 00 03 04 00 00
b) Istruzione per la card : C1 32 00 00 20
Risposta della card :        32 B2 00 04 05 00 18 00 0B 03 3C 52 05 04 [ 19 * FF ] 90 00

Nano 0xB2   segue SEKA Records
Nano 0x04    non ci sono ulteriori informazioni disponibili
00 0B            identifica il Provider-ID / Ident di Premiere

Questa richiesta avviene nel corso della gestione dei gettoni PPV. La richiesta di dati rivolta a Provider diversi da 00 (CAM SEKA) ottiene come risposta il Nano 0x04 in quanto questa stringa è accessibile solo per SEKA.


Providers PPV Records

Risposta a : C1 34 00 00 03 03 xx xx

P1 identifica il Provider, anche il PPV Record è specifico per il Provider . P2 è sempre 00. Si ricorda che il PPV-EventID, al quale fa riferimento questa richiesta , era specificato nell'istruzione 0x34 ( xx xx ).

    C1 32 P1 00 20

Esempio :
( supponiamo che nella 0x34 sia controllato il PPV Event 07 6A )
a) Istruzione per la card : C1 34 00 00 03 03 67 6A
b) Istruzione per la card : C1 32 01 00 20
Risposta della card :        32 B1 01 07 6A FF 05 00 00 FF FF 00 00 04 [ 19 * FF ] 90 00      <---  Quando il Film è disponibile per l’acquisto, ma non è ancora stato visionato.
Risposta della card :        32 B1 01 07 6A 0F 04 00 00 11 1C 00 00 04 [ 19 * FF ] 90 00      <---   Quando il Film è disponibile ed è stato visionato almeno una volta.

Nano 0xB1   Segue il PPV record
07 6A           = PPV-EventID
0F                 = Numero di diffusione / FF  ancora nessun numero di diffusione è stato fornito
04                 = La trasmissione può essere visionata ancora 4 volte nell’arco del giorno di attivazione
05                 = La trasmissione può essere visionata 5 volte nel giorno dell’attivazione.
11 1C           = data di acquisto dell'evento / FF FF = Evento non ancora attivato.
Nano 0x04    Non ci sono ulteriori informazioni disponibili

Come si vede, se un evento non è ancora stato attivato non viene inserita la DATA e quindi nemmeno il numero di diffusione. Il decoder può, attraverso questa richiesta di dati, determinare se uno ha acquistato un particolare evento. Possono essere memorizzati un massimo di due PPV Events per ogni Provider. Questa richiesta avviene nel corso della gestione dei diritti PPV. Se un PPV Event è specificato nell'istruzione 0x34, ma non è stato memorizzato nella card (questa ne può contenere max. 2) vengono accettati tutti i PPV Events che hanno un valore Hex uguale o maggiore a quello specificato. Il PPV-EventID 00 00 individua in ogni caso quale PPV Event è stato memorizzato nella card. La richiesta di dati rivolta al Provider 00 (CAM SEKA) ottiene come risposta il Nano 0x04 in quanto non ci sono PPV Records  per SEKA.


Records di attivazione SEKA

Risposta a : C1 34 00 00 03 04 00 02

P1 e P2 sono sempre 00. Anche questo record non è specifico per il Provider .

     C1 32 00 00 20

Esempio :
a) istruzione per la card : C1 34 00 00 03 02 00 00
b) Istruzione per la card : C1 32 00 00 20
Risposta della card :        32 B2 02 06 06 20 00 00 00 00 00 00 00 04 [ 19 * FF ] 90 00

Nano 0xB2      Segue SEKA Records
Nano 0x04       Non ci sono ulteriori informazioni disponibili

Il Record contiene la data di attivazione della card  in Plain text (06 06 20 00 = 06/06/2000). La richiesta di dati rivolta ad un Numero Provider diverso da 00, ottiene come risposta il Nano 0x04 in quanto questa stringa è riservata a  SEKA.


Selezione dei Records

Risposta a : C1 34 00 00 03 06 yy yy

Vengono sempre letti i record per i Providers specificati in P1 . P2 è sempre 00. Il processo inizia dal numero-record specificato nel comando 0x34. La numerazione inizia con il Record-Number (yy yy) 00 01.

     C1 32 P1 00 12

Esempio 1 :
a) Istruzione per la card : C1 34 00 00 03 06 00 01
b) Istruzione per la card : C1 32 00 00 12
Risposta della card :        32 D2 00 01 01 00 00 00 00 00 00 00 00 00 02 E0 00 00 03 90 00

Significato:

Nano D2    Seguito dai relativi dati; lunghezza 16 byte

Numero Record  - nell'esempio 00 01
Description byte  - nell'esempio E0
Tipo record        - nell'esempio 01
Record-Dati        - dal D2 a 03
Nano 03             - lunghezza 00 byte

Nano 0xD2      Seguono i records a partire dal Record-Number 00 01
Nano 0x03       Sono disponibili ulteriori informazioni

Esempio 2 :
a) Istruzione per la card : C1 34 00 00 03 06 00 06
b) Istruzione per la card : C1 32 01 00 12
Risposta della card :        32 D2 00 06 00 15 35 01 00 00 00 0E B6 00 00 B1 00 00 03 90 00

Nano 0xD2        Seguono i records dal Record-Number 00 06
Nano 0x03         Sono disponibili ulteriori informazioni

Vediamo adesso i Tipi e Classi di Records. Negli esempi appena visti il byte successivo al Numero Record (01 / 00) così come i bytes E0 / B1 servono a identificarli. I bytes 00 / 01 / 02 sono caratteristici del tipo Records, mentre i Description-Byte E0 o 60 indicano la classe del Record. Nei SEKA records distinguiamo per esempio:

Tipo 00:  00 04 05 00 18 00 0B 03 3C 52 05 E0   = SEKA PPV Record
Tipo 01:  01 00 00 00 00 00 00 00 00 00 02 E0    = SEKA Startup Record
Tipo 02:  02 29 09 19 99 00 00 00 00 00 00 E0    = Record Attivazione SEKA

Vediamo ora la CLASSE dei Records. Questi vengono distinti dai bytes E0 e B1 ( Record Description Byte ) negli esempi. Il Low Nibble di E0 (che è 0) sta per SEKA Cam, per i vari Provider l’identificazione successiva va da E1 per il Provider 01, E2 per il Provider 02 e così via. Il High Nibble (0xE) rappresentato in binario è 1110. Il primo bit significa "record in uso"; 1 sta per Yes, 0 per No. Rimane ancora 110, che in esadecimale diventa 0x06. Questo identifica il genere di informazioni che il record contiene: qui è un SEKA-record.

0xB1 --> 10110001 --> 0110001  --> 0x31  denota un PPV record .

Esempio 1 :  SEKA Record tipo 01 , Numero Record 00 01 , in uso
Esempio 2 :  PPV Record per il Provider 01 ; Numero record 00 06 , in uso

Attraverso questa tecnica possono essere lette anche le Keys ;  normalmente sono rappresentate da 8 * FF .

D2 00 03 F0 FF FF FF FF FF FF FF FF 00 00 80 00 00
D2 00 04 50 FF FF FF FF FF FF FF FF 00 00 C0 00 00

I bytes evidenziati in grassetto rappresentano rispettivamente il Key-Index e, quelli sottolineati, il Record Description Byte. In questa occasione gli Upper Nibbles (8 e C)  ci interessano per primi. Convertiamo il valore 0x8 in binario ed otterremo 1000. Il primo bit significa, come nell'esempio precedente, che il Record è in uso. I successivi 3 bits 000  indicano la Primary Key; 100 indicherebbe la Secondary Key. Il primo esempio mostra un record in uso che contiene la Primary Key con index 0xF0. Il secondo esempio , 0xC0 -> 1100 0000 , indica un record in uso contenente la Secondary Key con index 0x50. Lo zero nel low Nibble indica la CAM SEKA. Le Key per il Provider 01 verranno poi identificate con 0x81 e 0xC1 e così via. I 2 bytes  00 00 successivi al Description-Byte possono assumere anche valori diversi nelle card versione V 4.1. E’ possibile dare il seguente ordine ai Bytes di descrizione:

8x   Record con Primary Key
9x   Provider Package Bitmap
Cx   Record con Secondary Key
Ax   Provider PPV Preview Record
Bx   Provider PPV Record
Dx   Provider PPV Credit Record
Ex   SEKA-Record


[Torna all'indice]


Determinare il [32] Bitmap Package
Consultare l'istruzione [34] il Data Request
 

[Torna all'indice]


Determinare [1A] le key presenti su un Provider
C1 1A Px Kx LL
Ci informa di quante chiavi sono presenti su di un Provider Px.
C1 = Classe istruzione
1A = Tipo istruzione
Px = Indica il Provider a cui è fatta richiesta di informazioni
Kx = Sono sempre 00
LL = Lunghezza comando è uguale 20

Con questa istruzione è possibile determinare quale Primary Key di un Provider si trova su una card. I Key-Index non utilizzati sono visualizzati con FF.

Esempio:
C1 1A 03 00 20
Risposta della card: 1A FF FF 0C 84 00 51 5C 5D 5E 50 [ 22 * FF ] 90 00

Provider 03 i Key-Index 50, 51, 5C, 5D, 5E sono presenti sulla card.
 
 

[Torna all'indice]

Determinare [5A] il CipherText di una chiave (testo criptato)
C1 5A Px Kx 08
Questo comando permette di criptare un chiave esistente sulla carta con tutti 8*00.
C1 = Classe istruzione
5A = Tipo istruzione
Px = Indica il Provider a cui è fatta richiesta di informazioni
Kx = Indica il numero della key da criptare
LL = Lunghezza comando è uguale 08

Esempio:
C1 5A 00 00 08
Risposta della card : 5A D2 E9 44 1B E3 B1 AE 0B 90 00
00 00 00 00 00 00 00 00  viene criptato con la Key 00 di SEKA.

Se non ci fossero Keys relative ai parametri inseriti, si otterrebbe come risultato :   5A [8 * FF] 90 04
 


[Torna all'indice]


[3C] ECM - Coding Control Word
C1 3C Px Kx LEN

L’istruzione 0x3C contiene nella sua sezione dati la CONTROL WORD codificata di un canale. Questo ricade nella categoria degli ECM (Entitlement Control Message). La lunghezza della stringa di risposta è variabile e dipende, tra le altre cose, da quanti canali sono attivi (uno o più Channel ID o Channel Bundle ID). Ugualmente la lunghezza della stringa è influenzata dai Nano aggiunti (quanti 0x04; vedi Nano 0x04). Il Channel ID identifica univocamente un canale. I Canali possono comunque fare parte di un pacchetto (Channel Bundle) e anche questi vengono identificati. Tale ID consiste di un Byte. Px contiene il Provider Number, Kx identifica la Key usata dal Provider per la decodifica. Sono da tenere presenti il quinto bit di Px e l’ottavo bit di Kx, contati come sempre da destra verso sinistra. Questi dati devono naturalmente essere validi (corretti Key-Index e Provider-Number attivi sulla card). Da ricordare che la Control-Word codificata, quella che ritorna codificata col comando 0x3A, verrà poi utilizzata dalla card solo se la stringa risulta completa e corretta, ad esempio se contiene la Signature ed il Channel-ID. La decodifica della Control-Word continua poi con le Operation Key. La decifrazione della Control-Word inizia direttamente dopo il controllo della Signature. I Test-Abbonements sono possibili grazie a questo, per esempio: se la istruzione 0x3C contiene il Nano 0x04 il processo viene interrotto ed il programma risulta decodificato senza bisogno di una abbonamento. Il Nano 0x04 è inserito prima del Channel-Bundle-ID (chiamato anche Bouquet-Information) e della data (vedi formato della data). E' importante che prima di inviare questa istruzione alla card, venga attivata l'opzione "From CAM to CARD" nel software che stiamo usando, in modo tale che il decoder invii alla card i dati da decrittare.
 

L'istruzione 0x3C si trova principalmente in tre formati:
a ) per un canale standard
b ) per un canale PPV con Preview
c ) per un canale PPV senza Preview

I Nano che seguono possono essere applicati con l'istruzione 0x3C:

0x04    Il canale può essere reso visibile senza abbonamento (ad esempio per test) ignorando la richiesta di quale Channel-ID sia parte dell'abbonamento.
0x12    Il parental-Control viene classificato nella stringa - Dati della trasmissione. Il Parental-Control PIN viene richiesto quando il Parental-Control Status risulta attivato.
0x13    Segue il Channel-Bundle-ID
0x15   Controllo PPV. La visione di un evento PPV è possibile attraverso l'acquisto di un gettone PPV-Events
0x19    Controllp PPV con Preview: i dati associati contengono il valore di inizio di un contatore Step-Down.


Il contatore viene decrementato dopo ogni istruzione 0x3C, approssimativamente ogni 10 secondi. Quando lo Step-Down counter raggiunge lo zero, la decrittazione della Control Word viene interrotta (fine della fase di Preview). E’ usato solo in associazione ad un Nano 0x31 che lo precede ed un Record Ax quando una trasmissione prevede il Preview  e quando non esiste ancora alcun Provider PPV Record (Bx) con lo stesso PPV-Event ID. Nel Record verrà poi scritto il valore del contatore. Se esiste già un Provider PPV Record  (Bx) per quella trasmissione, la  data viene inserita per mezzo del Nano 0x27. Solo tre PPV event per lo stesso giorno possono essere inseriti nello stesso record; questo avviene quando il contatore raggiunge il valore 00; se gli eventi sono più di tre quelli eccedenti vengono posizionati in un nuovo record . Per la cancellazione del Record vedi Nano 0x27;  per maggiori dettagli sul contenuto dei Records vedi Nano 0x27 e 0x31.
 

Esempio di un Provider PPV Preview Record:
32 D2 00 1A 17 FE 08 08 00 09 08 04  00 00 00 A2 00 00 03 90 00

Data:                  17 FE
PPV Event ID:    08 08 / contenuto del contatore 00
PPV Event ID:    09 08 / contenuto del contatore 04

0x2C    Controllo PPV. Probabilmente in questo modo è possibile l'acquisto dei gettoni. Nei relativi dati ci sarà un byte che contiene il costo, ed un altro per il counter per un’eventuale Preview
0x2D    Controllo PPV
0x27     Segue la data della trasmissone. (Vedi formato della data)


Cancella subito tutti i Preview Records con data più vecchia dei relativi Providers (un INS 0x3C solo col Nano 0x27 che inserisca una nuova data nel Record Ax della card, cancella i vecchi record senza che ne vengano creati dei nuovi). Eccezione: Se nella Card si trovano due Record Ax e l’ INS 3C contiene una data posteriore per un identico PPV Event ID, questi records devono essere prima cancellati con una doppia INS 0x3C. La data viene scritta nel Record Ax  nel corso di un ulteriore INS 0x3C in combinazione dei Nano 0x31 e 0x19.

0x31    Controllo PPV  e dei dati associati al PPV-Event-ID ( i primi due bytes ) e del numero di diffusione corrente (3 bytes che assieme identificano chiaramente una emissione PPV). Un incremento del numero di diffusione corrente inviato alla card per mezzo di un INS 0x3C decrementa il contatore del Provider PPV Record (Bx record), il quale definisce quante volte un evento PPV  può essere visionato. Il numero di diffusione attuale è scritto nel Provider PPV Record. E’ usato solo in associazione ad un Nano 0x19 al quale segue un Record Ax , quando una trasmissione prevede il Preview  e quando ancora non esiste un Provider PPV Record (Bx) con lo stesso PPV-Event ID; in questo record verrà scritto ilPPV-Event ID (senza numero di diffusione). Se esiste già un Provider PPV Record ( Bx ) per questa trasmissione, la data viene inserita per mezzo del Nano ox27.
0x71    Viene ignorato dall’ istruzione 0x3C. I dati per questo parametro sono 00 per molti Provider così come per un canale PPV.
0x82    Segue la Signature
0x87    Viene ignorato dall' istruzione 0x3C
0xD1    Segue la Control-Word codificata
0xF1     Segue il Bitmap per il Codice-Regione


Ecco il formato delle stringhe : tra parentesi la spiegazione , segue poi l'esempio .
 

1 Byte       Nano 0x71 ( 71 )
1 Byte      (00)
2 Bytes     Provider-ID ( 00 14 )
2 Bytes     anno attuale , in esadecimale ( 07 CE = 0x7CE = 1998 )
2 Bytes     mese attuale , in esadecimale ( 00 07 = 0x7 = luglio )
1 Byte       Nano 0x27 ( 27 )
2 Bytes     Data della trasmissione ( 10 F5 = 31.07.1998 )
1 Byte       Nano 0x13 ( 13 )
1 Byte       Channel-Bundle-ID . Un canale può fare parte di più pacchetti-canali ; questa è una delle cause della  variazione della lunghezza
1 Byte       Nano 0xD1 , segue la Control-Word codificata  (D1)
8 Bytes     Control-Word 1 Codificata (96 88 7A 31 3E 7D BD 19)
8 Bytes     Control-Word 2 Codificata (9D A0 79 EE F1 E7 A0 80)
1 Byte       Nano 0x82. Segue la Signature (82)
8 Bytes     Signature. (76 2E 2A 53 FC A9 08 B4)
Esempio:
(decodifica della Conrol-Word per il Provider 01, usando la key primaria 0D, 0D)

Istruzione per la card:      C1 3C 01 0D 27
Stringa Dati:                    71 00 00 14 07 CE 02 27 10 F5 13 01 D1 96 88 7A 31 3E 7D BD 19 9D A0 79 EE F1 E7 A0 80 82 76 2E 2A 53 FC A9 08 B4
Echo della card:               3C 71 00 00 14 07 CE 00 02 27 10 F5 13 01 D1 96 88 7A 31 3E 7D BD 19 0D A0 79 EE F1 E7 A0 80 82 76 2E 2A 53 FC A9 08 B4 90 00

Solo dopo viene mandato il comando. Le due Control-Words codificate sono sottolineate, le Signature sono in grassetto.


[Torna all'indice]


[3A] ECM Decoding Control-Word
C1 3A Px Kx 10
Questa istruzione viene eseguita subito dopo la 0x3C se questa termina con lo status byte 90 00. La card invia al decoder le Control-Words codificate. Con queste il decoder è in grado di decodificare il flusso dato MPEG-2 (la Plain Control-word viene inviata al registro xy del "Common Scrambling Algorithmus" che si trova nell'hardware del decoder). Vediamo nella istruzione 0x3C come il decoder della Card invii le Control-Words codificate. Queste sono decodificate dalla card e poi con la 0x3a vengono restituite al decoder trattate. La lunghezza della stringa di risposta ammonta sempre a 16 bytes. Essa contiene ogni circa 10 secondi due nuove Plain-Control-Words. Px e Kx sono sempre 00.
In altre parole con l'istruzione 3A si legge il buffer della carta. Nell'esempio del Control-Words il decoder chiede alla carta se è in possesso delle chiavi di decodifica e se il canale in questione può essere visuliazzato. La carta elabora tutti i dati contenuti nell'istruzione 3C, data di trasmissione, canale e pacchetto a cui appartiene il canale, Provider a cui appartine in canale, chiave utilizzata per il Control-Words. Se la carta possiede le chiavi correte, un giusto Bitmap Package, e una data di fine abbonamento non scaduta, la carta decodifica le due chiavi casuali di 8+8 byte che il decoder invia alla carta con l'ins 3C criptandole con la key in quel momento utilizzata per la codifica del canale. Con l'ins 3A la CAM verifica con una periodicità di 10 secondi circa che la carta sia regolarmente abbonata, andando a leggere il buffer della carta dopo avergli fatto elaborare un nuovo ins 3C.
 
Esempio :
C1 3A 00 00 10
3A  01 44 45 50 41 05 44 D4  50 10 50 D6 00 01 51 B2  90 00

Plain-Control-Word 1: 01 44 45 50 41 05 44 D4
Plain-Control-Word 2: 50 10 50 D6 00 01 51 B2
 

[Torna all'indice]

[40-3C-3A] Criptare e decriptare una chiave
Per criptare e/o decriptare una chiave o parte di un corpo dati di un’istruzione, occorre seguire i seguenti passi:
Istruzione CAM to CARD
C1 40 Px 8y 09 dd dd dd dd dd dd dd dd 00
C1 3C 01 0F 00
C1 3A 00 00 08


C1 = Classe istruzione
40 = Tipo istruzione
Px = Indica il Provider a cui è indirizzata la richiesta
8x = Indica con quale chiave si intende criptare o decriptare
09 = Lunghezza comando
dd dd dd dd dd dd dd dd = Dati da criptare/decriptare
00 = Fine dati

Ripsosta della carta: dd dd dd dd dd dd dd dd 90 02


C1 = Classe istruzione
3C = Tipo istruzione
01 = Sempre settato in questo modo
0F = Sempre settato in questo modo
00 = Lunghezza comando

Ripsosta della carta: Il comando c1 3c 01 0f 00 darà sempre errore come risultato. E' normale.


C1 = Classe istruzione
3A = Tipo istruzione
00 = Sempre settato in questo modo
00 = Sempre settato in questo modo
08 = Lunghezza comando

Ripsosta della carta: 3A R1 R2 R3 R4 R5 R6 R7 R8 90 00      <---  Che è il valore criptato e/o decriptato.

Esempio:
Se volessimo decriptare il valore 33 44 55 66 55 44 33 22 con la MK 03 del Provider 01, il comando sarà:
C1 40 01 83 09 33 44 55 66 55 44 33 22 00           -    33 44 55 66 55 44 33 22 90 02
C1 3C 01 0F 00                                                       -    errore
C1 3A 00 00 08                                                       -    3A K1 K2 K3 K4 K5 K6 K7 K8 90 00
Il risultato "K1 K2 K3 K4 K5 K6 K7 K8" di quest'ultima istruzione sarà il cript/decript della chiave sopra citata.

[Torna all'indice]

Creazione di un nuovo provider
C1 40 Px Kx LL 23 PP PP 82 S1 S2 S3 S4 S5 S6 S7 S8
Questa istruzione permette di aggiungere un nuovo Provider nella carta. Requisito fondamentale conoscere un MK del Prov.SEKA.
C1 = Classe istruzione
40 = Tipo istruzione
Px = Provider
Kx = Criptato con MK Kx
LL = Lunghezza comando
23 = Nano che indica creazione Provider
PP PP = Ident del nuovo Provider (ad esempio D+=00 10, +Calcio=00 11)
82 = Nano che indica che seguirà la Signature
S1 S2 S3 S4 S5 S6 S7 S8 = Signature ottenuta con MK Kx

Esempio:
C1 40 00 06 0C 23 00 0A 82 Signature
Creazione del Provider di Stream conoscendo la MK 06 del Prov. SEKA
 
 

[Torna all'indice]

Aggiunta del nome del provider
C1 40 Px Kx LL 24 PP PP D0 nn nn nn nn nn nn nn nn nn nn nn nn nn nn nn nn 82 S1 S2 S3 S4 S5 S6 S7 S8
Questo comando segue direttamente l'istruzione [23] del nuovo Provider, inserendo in esadecimale il nome del Provider.
C1 = Classe istruzione
40 = Tipo istruzione
Px = Provider
Kx = Criptato con MK Kx
LL = Lunghezza comando
24 = Nano che indica l'ident del Provider a cui è inviato il comando
PP PP = Ident del Provider a cui è inviato il comando
D0 = Nano che indica il nome in HEX del nuovo Provider appena creato
nn nn nn nn nn nn nn nn nn nn nn nn nn nn nn nn = Nome in HEX del nuovo Provider
82 = Nano che indica che seguirà la Signature
S1 S2 S3 S4 S5 S6 S7 S8 = Signature ottenuta con MK Kx

Esempio:
C1 40 00 06 1D 24 00 0A D0 53 54 52 45 41 4D 20 20 20 20 20 20 20 20 20 20 82 Signature
Aggiunta del nome del nuovo Provider Stream conoscendo la MK 06 del Prov. SEKA
 
 

[Torna all'indice]

Cancellazione di un provider
C1 40 Px Kx LL 25 PP PP 82 S1 S2 S3 S4 S5 S6 S7 S8
Questo comando cancella dalla carta l'ident del Provider inserito dopo il nano 25.
C1 = Classe istruzione
40 = Tipo istruzione
Px = Provider
Kx = Criptato con MK Kx
LL = Lunghezza comando
25 = Nano che indica l'ident del Provider da cancellare
PP PP = Ident del Provider da cancellare
82 = Nano che indica che seguirà la Signature
S1 S2 S3 S4 S5 S6 S7 S8 = Signature ottenuta con MK Kx

Esempio:
C1 40 00 06 0D 25 00 10 82 Signature
Elimina il Provider di D+ (00 10) conoscendo la MK 06 del Prov. SEKA
 

[Torna all'indice]

Autorizzazione del Provider
C1 40 Px Kx LL 24 PP PP 26 FF FF 82 S1 S2 S3 S4 S5 S6 S7 S8
Questa istruzione da le autorizzazioni per il Provider PP PP.
C1 = Classe istruzione
40 = Tipo istruzione
Px = Provider
Kx = Criptato con MK Kx
LL = Lunghezza comando
24 = Nano che indica l'ident del Provider a cui è inviato il comando
PP PP = Ident del Provider a cui è inviato il comando
26 = Nano che concede le autorizzazioni al nuovo Provider
FF FF = Autorizzazioni
82 = Nano che indica che seguirà la Signature
S1 S2 S3 S4 S5 S6 S7 S8 = Signature ottenuta con MK Kx 

FF FF = 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 = 16 bit
                  |  |  |  |  |  |> a ( 1 – 10 )   <|
                  |  |  |  |  |> b ( 11 )
                  |  |  |  |> c ( 12 )
                  |  |  |
                  |  |_|> d ( 13 – 14 )
                  |> e ( 15 )

1 bit = numero Massimo di Record Bytes per questo Provider
2 bit = numero Massimo di Record Bytes per questo Provider
3 bit = numero Massimo di Record Bytes per questo Provider
4 bit = numero Massimo di Record Bytes per questo Provider
5 bit = numero Massimo di Record Bytes per questo Provider
6 bit = numero Massimo di Record Bytes per questo Provider
7 bit = numero Massimo di Record Bytes per questo Provider
8 bit = numero Massimo di Record Bytes per questo Provider
9 bit = numero Massimo di Record Bytes per questo Provider
10 bit = numero Massimo di Record Bytes per questo Provider
11 bit = per il nano 0x32 deve essere settato (abilita il nano 32)
12 bit = per il nano 0x80 deve essere settato (abilita il Bitmap Package)
13 bit = per i nano 0x30 , 0x42 , 0x43 deve essere settato (Attiva la PPV gettoni,acquisto,ecc)
14 bit = per i nano 0x30 , 0x42 , 0x43 deve essere settato (Attiva la PPV gettoni,acquisto,ecc)
15 bit = per il nano 0x01 (scrive 0xFF nella struttura del Provider con offset 0x1B; Il Provider non può più essere gestito col Nano 0x24.
16 bit = Non contemplato

Esempio:
C1 40 00 06 0F 24 00 0A 26 FF FF 82 Signature
Da autorizzazionoi FF FF al nuovo Provider di Stream conoscendo la MK06 del Provider Seka. Autorizzazioni complete.

C1 40 00 06 0F 24 00 0A 26 EF FF 82 Signature
Da autorizzazionoi EF FF al nuovo Provider di Stream conoscendo la MK06 del Provider Seka. Autorizzazioni parziali con le quali si impedisce la gestione del Provider di Stream con il nano 24, per cui molti comandi di gestione carta (ins 40) sono inutilizzabili a meno che il Provider Stream non abbia una Management key sul proprio Provider ident (00 0A). Questo si ha in 2 casi o se si abbonati regolarmente o se la carta di proprietà di Stream.


 

[Torna all'indice]


Inserirmento codice regionale
C1 40 Px Kx LL 24 PP PP 17 CC 82 “S1 S2 S3 S4 S5 S6 S7 S8
Inserisce per il Provider PP PP un nuovo codice regionale.
C1 = Classe istruzione
40 = Tipo istruzione
Px = Provider
Kx = Criptato con MK Kx
LL = Lunghezza comando
24 = Nano che indica l'ident del Provider a cui è inviato il comando
PP PP = Ident del Provider a cui è inviato il comando
17 = scrive il Byte dato nella struttura del Provider con offset 0x18: probabilmente un codice regionale
CC = Codice regionale
82 = Nano che indica che seguirà la Signature
S1 S2 S3 S4 S5 S6 S7 S8 = Signature ottenuta con MK Kx

Esempio:
C1 40 00 06 0D 24 00 0A 17 55 82 Signature
Inserisce un nuovo codice regionale 55 per il Provider di Stream, conoscendo la MK 06 di Seka.
 

[Torna all'indice]

Inserimento della data
C1 40 Px Kx LL 24 PP PP 21 FF FF 82 S1 S2 S3 S4 S5 S6 S7 S8
Modifica la data di fine abbonamento per il Provider PP PP
C1 = Classe istruzione
40 = Tipo istruzione
Px = Provider
Kx = Criptato con MK Kx
LL = Lunghezza comando
24 = Nano che indica l'ident del Provider a cui è inviato il comando
PP PP = Ident del Provider a cui è inviato il comando
21 = Nano che da la data di scadenza abbonamento
FF FF = Nuova data (Max FF FF)
82 = Nano che indica che seguirà la Signature
S1 S2 S3 S4 S5 S6 S7 S8 = Signature ottenuta con MK Kx

Esempio:
C1 40 00 06 0E 24 00 11 21 A3 34 82 Signature
Scrive sulla carta una nuova data di fine abbonamento (A3 34) per il Provider +Calcio (00 11) firmando il comando con una Signature valida della MK 06 del Provider Seka.
 
 

[Torna all'indice]

Attivazione della carta
C1 40 Px Kx LL B0 01 00 00 00 00 00 00 00 02 00 93 00 00 00 82 S1 S2 S3 S4 S5 S6 S7 S8
C1 = Classe istruzione
40 = Tipo istruzione
Px = Provider
Kx = Criptato con MK Kx
LL = Lunghezza comando
B0 = Nano che indica l'attivazione della carta
01 00 00 00 00 00 00 00 02 00 93 00 00 00 = Attivazione
82 = Nano che indica che seguirà la Signature
S1 S2 S3 S4 S5 S6 S7 S8 = Signature ottenuta con MK Kx
 
[Torna all'indice]

Inserimento PPUA
C1 40 Px Kx LL 24 PP PP 41 uu uu uu uu 82 S1 S2 S3 S4 S5 S6 S7 S8
Inserisce un nuovo PPUA per il Provider PP PP
C1 = Classe istruzione
40 = Tipo istruzione
Px = Provider
Kx = Criptato con MK Kx
LL = Lunghezza comando
24 = Nano che indica l'ident del Provider a cui è inviato il comando
PP PP = Ident del Provider a cui è inviato il comando
41 = Nano che indica che seguirà il nuovo PPUA
uu uu uu uu = Nuovo PPUA
82 = Nano che indica che seguirà la Signature
S1 S2 S3 S4 S5 S6 S7 S8 = Signature ottenuta con MK Kx

Esempio:
C1 40 00 04 11 24 00 0A 41 12 34 56 78 82 Signature
Scrive per il  Provider di Stream una nuova PPUA conoscendo la MK 04 del  Provider SEKA.
 
 

[Torna all'indice]

Inserimento MK0x primaria
C1 40 Px Kx LL 24 PP PP 90 5x K1 K2 K3 K4 K5 K6 K7 K8 82 S1 S2 S3 S4 S5 S6 S7 S8
Inserisce una nuova MK 5x primaria per il Provider PP PP conoscendo una MK Kx del Provider Seka.
C1 = Classe istruzione
40 = Tipo istruzione
Px = Provider
Kx = Criptato con MK Kx
LL = Lunghezza comando
24 = Nano che indica l'ident del Provider a cui è inviato il comando
PP PP = Ident del Provider a cui è inviato il comando
90 5x = Nano che indica che seguirà una nuova MK primaria (la x indica il numero della nuova MK)
K1 K2 K3 K4 K5 K6 K7 K8 = Nuova MK criptata con la Kx
82 = Nano che indica che seguirà la Signature
S1 S2 S3 S4 S5 S6 S7 S8 = Signature ottenuta con MK Kx

Esempio:
C1 40 00 06 16 24 00 0A 90 56 11 22 33 44 55 66 77 88 82 Signature
Creazione di una nuova MK 06 primaria per il  Provider di Stream. La nuova MK 1122334455667788 è criptata con la MK 06 del  Provider SEKA
 
 
 

[Torna all'indice]

Inserimento MK0x secondaria
C1 40 Px Kx LL 24 PP PP 91 5x K1 K2 K3 K4 K5 K6 K7 K8 82 S1 S2 S3 S4 S5 S6 S7 S8
Inserisce una nuova MK 5x secondaria per il Provider PP PP conoscendo una MK Kx del Provider Seka.
C1 = Classe istruzione
40 = Tipo istruzione
Px = Provider
Kx = Criptato con MK Kx
LL = Lunghezza comando
24 = Nano che indica l'ident del Provider a cui è inviato il comando
PP PP = Ident del Provider a cui è inviato il comando
91 5x = Nano che indica che seguirà una nuova MK secondaria (la x indica il numero della nuova MK)
K1 K2 K3 K4 K5 K6 K7 K8 = Nuova MK criptata con la Kx
82 = Nano che indica che seguirà la Signature
S1 S2 S3 S4 S5 S6 S7 S8 = Signature ottenuta con MK Kx

Esempio:
C1 40 00 06 16 24 00 0A 91 56 11 22 33 44 55 66 77 88 82 Signature
Creazione di una nuova MK 06 secondaria per il Provider di Stream. La nuova MK 1122334455667788 è criptata con la MK 06 del Provider SEKA
 
 
 

[Torna all'indice]

Inserimento chiave 0C primaria
C1 40 Px Kx LL 24 PP PP 90 5C K1 K2 K3 K4 K5 K6 K7 K8 82 S1 S2 S3 S4 S5 S6 S7 S8
Inserisce una nuova OK 5C primaria per il Provider PP PP conoscendo una MK Kx del Provider Seka.
C1 = Classe istruzione
40 = Tipo istruzione
Px = Provider
Kx = Criptato con MK Kx
LL = Lunghezza comando
24 = Nano che indica l'ident del Provider a cui è inviato il comando
PP PP = Ident del Provider a cui è inviato il comando
90 5C = Nano che indica che seguirà una nuova Key 0C
K1 K2 K3 K4 K5 K6 K7 K8 = Nuova MK criptata con la Kx
82 = Nano che indica che seguirà la Signature
S1 S2 S3 S4 S5 S6 S7 S8 = Signature ottenuta con MK Kx

Esempio:
C1 40 00 06 16 24 00 0A 90 5C 11 22 33 44 55 66 77 88 82 Signature
Creazione di una nuova Key 0C primaria per il Provider di Stream. La nuova OK 1122334455667788 è criptata con la MK 06 del Provider SEKA

[Torna all'indice]

Inserimento chiave 0D primaria
C1 40 Px Kx LL 24 PP PP 90 5D K1 K2 K3 K4 K5 K6 K7 K8 82 S1 S2 S3 S4 S5 S6 S7 S8
Inserisce una nuova OK 5D primaria per il Provider PP PP conoscendo una MK Kx del Provider Seka.
C1 = Classe istruzione
40 = Tipo istruzione
Px = Provider
Kx = Criptato con MK Kx
LL = Lunghezza comando
24 = Nano che indica l'ident del Provider a cui è inviato il comando
PP PP = Ident del Provider a cui è inviato il comando
90 5D = Nano che indica che seguirà una nuova Key 0D primaria
K1 K2 K3 K4 K5 K6 K7 K8 = Nuova OK criptata con la Kx
82 = Nano che indica che seguirà la Signature
S1 S2 S3 S4 S5 S6 S7 S8 = Signature ottenuta con MK Kx

Esempio:
C1 40 00 06 16 24 00 0A 90 5D 11 22 33 44 55 66 77 88 82 Signature
Creazione di una nuova Key 0D primaria per il Provider di Stream. La nuova OK 1122334455667788 è criptata con la MK 06 del Provider SEKA

[Torna all'indice]

Inserimento chiave 0E primaria
C1 40 Px Kx LL 24 PP PP 90 5E K1 K2 K3 K4 K5 K6 K7 K8 82 S1 S2 S3 S4 S5 S6 S7 S8
Inserisce una nuova OK 5E primaria per il Provider PP PP conoscendo una MK Kx del Provider Seka.
C1 = Classe istruzione
40 = Tipo istruzione
Px = Provider
Kx = Criptato con MK Kx
LL = Lunghezza comando
24 = Nano che indica l'ident del Provider a cui è inviato il comando
PP PP = Ident del Provider a cui è inviato il comando
90 5E = Nano che indica che seguirà una nuova Key 0E primaria
K1 K2 K3 K4 K5 K6 K7 K8 = Nuova OK criptata con la Kx
82 = Nano che indica che seguirà la Signature
S1 S2 S3 S4 S5 S6 S7 S8 = Signature ottenuta con MK Kx

Esempio:
C1 40 00 06 16 24 00 0A 90 5E 11 22 33 44 55 66 77 88 82 Signature
Creazione di una nuova Key 0E primaria per il Provider di Stream. La nuova OK 1122334455667788 è criptata con la MK 06 del Provider SEKA
 
 
 

[Torna all'indice]

Inserimento chiave 0C secondaria
C1 40 Px Kx LL 24 PP PP 91 5C K1 K2 K3 K4 K5 K6 K7 K8 82 S1 S2 S3 S4 S5 S6 S7 S8
Inserisce una nuova OK 5C secondaria per il Provider PP PP conoscendo una MK Kx del Provider Seka.
C1 = Classe istruzione
40 = Tipo istruzione
Px = Provider
Kx = Criptato con MK Kx
LL = Lunghezza comando
24 = Nano che indica l'ident del Provider a cui è inviato il comando
PP PP = Ident del Provider a cui è inviato il comando
91 5C = Nano che indica che seguirà una nuova Key 0C secondaria
K1 K2 K3 K4 K5 K6 K7 K8 = Nuova OK criptata con la Kx
82 = Nano che indica che seguirà la Signature
S1 S2 S3 S4 S5 S6 S7 S8 = Signature ottenuta con MK Kx

Esempio:
C1 40 00 06 16 24 00 0A 91 5C 11 22 33 44 55 66 77 88 82 Signature
Creazione di una nuova Key 0C secondaria per il Provider di Stream. La nuova OK 1122334455667788 è criptata con la MK 06 del Provider SEKA


[Torna all'indice]


Inserimento chiave 0D secondaria
C1 40 Px Kx LL 24 PP PP 91 5D K1 K2 K3 K4 K5 K6 K7 K8 82 S1 S2 S3 S4 S5 S6 S7 S8
Inserisce una nuova OK 5D secondaria per il Provider PP PP conoscendo una MK Kx del Provider Seka.
C1 = Classe istruzione
40 = Tipo istruzione
Px = Provider
Kx = Criptato con MK Kx
LL = Lunghezza comando
24 = Nano che indica l'ident del Provider a cui è inviato il comando
PP PP = Ident del Provider a cui è inviato il comando
91 5D = Nano che indica che seguirà una nuova Key 0D secondaria
K1 K2 K3 K4 K5 K6 K7 K8 = Nuova OK criptata con la Kx
82 = Nano che indica che seguirà la Signature
S1 S2 S3 S4 S5 S6 S7 S8 = Signature ottenuta con MK Kx

Esempio:
C1 40 00 06 16 24 00 0A 91 5D 11 22 33 44 55 66 77 88 82 Signature
Creazione di una nuova Key 0D secondaria per il Provider di Stream. La nuova OK 1122334455667788 è criptata con la MK 06 del Provider SEKA
 
 
 

[Torna all'indice]

Inserimento chiave 0E secondaria
C1 40 Px Kx LL 24 PP PP 91 5E K1 K2 K3 K4 K5 K6 K7 K8 82 S1 S2 S3 S4 S5 S6 S7 S8
Inserisce una nuova OK 5E secondaria per il Provider PP PP conoscendo una MK Kx del Provider Seka.
C1 = Classe istruzione
40 = Tipo istruzione
Px = Provider
Kx = Criptato con MK Kx
LL = Lunghezza comando
24 = Nano che indica l'ident del Provider a cui è inviato il comando
PP PP = Ident del Provider a cui è inviato il comando
91 5E = Nano che indica che seguirà una nuova Key 0E secondaria
K1 K2 K3 K4 K5 K6 K7 K8 = Nuova OK criptata con la Kx
82 = Nano che indica che seguirà la Signature
S1 S2 S3 S4 S5 S6 S7 S8 = Signature ottenuta con MK Kx

Esempio:
C1 40 00 06 16 24 00 0A 91 5E 11 22 33 44 55 66 77 88 82 Signature
Creazione di una nuova Key 0E secondaria per il Provider di Stream. La nuova OK 1122334455667788 è criptata con la MK 06 del Provider SEKA
 
 
 

[Torna all'indice]

Cancellazione MK primaria
C1 40 Px Kx LL 24 PP PP 10 0x 82 S1 S2 S3 S4 S5 S6 S7 S8
Cancella un MK (master key) o OK (operation key) primaria del Provider PP PP conoscendo una MK Kx del Provider Seka.
C1 = Classe istruzione
40 = Tipo istruzione
Px = Provider
Kx = Criptato con MK Kx
LL = Lunghezza comando
10 = Nano che indica la cancellazione MK primaria
0x = MK secondaria da cancellare
82 = Nano che indica che seguirà la Signature
S1 S2 S3 S4 S5 S6 S7 S8 = Signature ottenuta con MK Kx

Esempio:
C1 40 00 06 0D 24 00 11 10 03 82 Signature
Cancella la MK primaria 03 del Provider +Calcio (00 11) conoscendo la MK 06 del Provider Seka.
 
 
 

[Torna all'indice]

Cancellazione MK secondaria
C1 40 Px Kx LL 24 PP PP 10 1x 82 S1 S2 S3 S4 S5 S6 S7 S8
Cancella un MK (master key) o OK (operation key) secondaria del Provider PP PP conoscendo una MK Kx del Provider Seka.
C1 = Classe istruzione
40 = Tipo istruzione
Px = Provider
Kx = Criptato con MK Kx
LL = Lunghezza comando
10 = Nano che indica la cancellazione MK secondaria
1x = MK da cancellare
82 = Nano che indica che seguirà la Signature
S1 S2 S3 S4 S5 S6 S7 S8 = Signature ottenuta con MK Kx

Esempio:
C1 40 00 06 0D 24 00 11 10 13 82 Signature
Cancella la MK secondaria 03 del Provider +Calcio (00 11) conoscendo la MK 06 del Provider Seka.

[Torna all'indice]

Inserimento nuovo Bitmap Package
C1 40 Px Kx LL 24 PP PP 80 P1 P2 P3 P4 P5 P6 P7 P8 82 S1 S2 S3 S4 S5 S6 S7 S8
Inserisce per il Provider PP PP un nuovo Bitmap Package, il quale indica a quali canali si è abbonati.
C1 = Classe istruzione
40 = Tipo istruzione
Px = Provider
Kx = Criptato con MK Kx
LL = Lunghezza comando
24 = Nano che indica l'ident del Provider a cui è inviato il comando
PP PP = Ident del Provider a cui è inviato il comando
80 = Nano che indica che seguirà il nuovo Bitmap Package
P1 P2 P3 P4 P5 P6 P7 P8 = Nuovo Bitmap Package
82 = Nano che indica che seguirà la Signature
S1 S2 S3 S4 S5 S6 S7 S8 = Signature ottenuta con MK Kx

Esempio:
C1 40 00 06 16 24 00 0A 80 EF FF FF FF FF FF FF FF 82 Signature
Scrive il nuovo Bitmap Package (EF FF FF FF FF FF FF FF) per il Provider di Stream (00 0A)
 
 
 

[Torna all'indice]

Inserire una nuova MK0x sul Provider Px non conoscendo nulla (Metodo di Pippo_360)
C1 40 Px Kx LL C1 C2 C3 C4 C5 C6 C7 C8 40 00 HH 00 00 90 Fx M1 M2 M3 M4 M5 M6 M7 M8 82 S1 S2 S3 S4 S5 S6 S7 S8
Metodo ormai storico per inserire in un qualsiasi Provider un MK     5x per poter poi gestire il Provider stesso a nostro piacimento.
C1 = Classe istruzione
40 = Tipo istruzione
Px = Provider a cui è indirizzato il comando
Kx = Criptato con MK Kx
LL = Lunghezza comando (nel nostro caso 20 hex)
C1 C2 C3 C4 C5 C6 C7 C8 = Risultato che otteniamo effettuando i seguenti passaggi.
Criptiamo "M2 M3 M4 M5 M6 M7 M8 82" con l'istruzione [40-3C-3A], il risultato "Y1 Y2 Y3 Y4 Y5 Y6 Y7 Y8" lo Xoriamo con "40 00 HH 00 00 90 5x M1" ottenendo il valore “H1 H2 H3 H4 H5 H6 H7 H8” che di nuovo criptato, sempre con l'istruzione [40-3C-3A] da un valore "C1 C2 C3 C4 C5 C6 C7 C8".
HH = E’ un cifra che se cambiata permette al risultato “C1 C2 C3 C4 C5 C6 C7 C8” di assumere un valore valido ai fini delle inserimento della MK.
90 Fx = Indica l'inserimento di una MK x primaria.
M1 M2 M3 M4 M5 M6 M7 M8 = La nuova MK0x (90 52 = MK02) di fantasia che andiamo ad inserire. Ovviamente la MK che inseriamo verrà criptata con la key di inserimento. Per cui dovrà essere decriptata sempre con l'istruzione [40-3C-3A], ottenendo cosi la MK valida. Per la verifica consultare l'istruzione [5A]
82 = Nano che indica che seguirà la Signature
S1 S2 S3 S4 S5 S6 S7 S8 = Signature valida calcolata con l'istruzione C15APxKx08
 

Esempio:
Ipotizzando di inserire un nuova MK 07 nel Provider Seka 00, digitatiamo il nostro comando:
C1 40 00 00 20 C1 C2 C3 C4 C5 C6 C7 C8 40 00 EE 00 00 90 F7 11 22 33 44 55 66 77 88 82 S1 S2 S3 S4 S5 S6 S7 S8

e procediamo poi come segue:

Cam to Card
C1 5A 00 00 08                                                           =        5A S1 S2 S3 S4 S5 S6 S7 S8 90 00   < --- Signature MK 00 Provider Seka 00
C1 40 00 80 09 22 33 44 55 66 77 88 82 00                   =        22 33 44 55 66 77 88 82 90 02
C1 3C 01 0F 00                                                           =        Errore
C1 3A 00 00 08                                                           =        3A Y1 Y2 Y3 Y4 Y5 Y6 Y7 Y8 90 00
Y1 Y2 Y3 Y4 Y5 Y6 Y7 Y8  xor 40 00 EE 00 00 90 F7 11    =        H1 H2 H3 H4 H5 H6 H7 H8
C1 40 00 80 09 H1 H2 H3 H4 H5 H6 H7 H8 00                 =        H1 H2 H3 H4 H5 H6 H7 H8 90 02
C1 3C 01 0F 00                                                           =        Errore
C1 3A 00 00 08                                                           =        3A C1 C2 C3 C4 C5 C6 C7 C8 90 00

C1 40 00 00 20 C1 C2 C3 C4 C5 C6 C7 C8 40 00 EE 00 00 90 F7 11 22 33 44 55 66 77 88 82 S1 S2 S3 S4 S5 S6 S7 S8
Inviamo il nostro comando alla carta, che come risposta dovrebbe dare 90 00. Se dà "90 00" eseguire questo ultimo passo qui sotto, altrimenti ricontrollare tutti i passaggi, e nel caso cambiare il valore EE.

C1 40 00 80 09 11 22 33 44 55 66 77 88 00                   =        11 22 33 44 55 66 77 88 90 02
C1 3C 01 0F 00                                                           =        Errore
C1 3A 00 00 08                                                           =        3A M1 M2 M3 M4 M5 M6 M7 M8 90 00

M1 M2 M3 M4 M5 M6 M7 M8 è la vostra nuova MK 07 del Provider Seka 00.

Per ulteriore verifica potete fare cosi, inviate l'istruzione C1 5A 00 07 08 alla carta che come risposta darà 5A K1 K2 K3 K4 K5 K6 K7 K8 90 00. Se inserite il valore K1 K2 K3 K4 K5 K6 K7 K8 in CocDec nella sezione Decript campo CW. Poi inserite la vostra MK07 (M1 M2 M3 M4 M5 M6 M7 M8 nell'esempio sopra citato) e cliccate su "Decript" il risultato dovrebbero essere tutti 00 00 00 00 00 00 00 00. Se cosi non fosse ricontrollate tutto che la vostra MK potrebbe essere diversa.
 
 

[Torna all'indice]


Calcolare una signature valida
Per calcolare una signature (o firma) valida ad un comando, vi sottopongo la teoria descritta nel '99 dall'ormai mitico John MacDonald. Vi consiglio di leggerlo, ma se qualcuno di voi vuole saltare questo passaggio ed consultare il metodo pratico clicchi qui.
 

ALGORITMO DI SEGNATURA DI MESSAGGIO
Sembra che sia per i messaggi ECM che per quelli EMM venga utilizzato solo un algoritmo di segnatura. La procedura consiste nei seguenti passi:

Essendo l’algoritmo di segnatura  l’inverso dell’algoritmo di decriptaggio (come per Eurocrypt S), non è necessario descriverlo in tutti i suoi dettagli (come invece è stato fatto per l’algoritmo di decriptaggio). L’inizializzazione del buffer hash è basata sul valore dei bit 7-5 più significativi del parametro P1, come segue: L’algoritmo consiste in 16 cicli. Ogni ciclo opera solo su 4 byte di chiave e 4 byte di dati. Detti k1, k2, …, k16 i byte della chiave (ottenuti dopo la fase di preparazione della chiave) e detti i byte dei dati d1,d2,…,d8 si ha:

Numero Ciclo Byte di chiave Byte di dati
1, 5, 9, 13 k1, k2, k3, k4 d5, d6, d7, d8
2, 6, 10, 14 K5, k6, k7, k8 d5, d6, d7, d8
3, 7, 11, 15 K9, k10, k11, k12 d5, d6, d7, d8
4, 8, 12, 16 k13, k14, k15, k16 d5, d6, d7, d8

Un ciclo consiste in:

L’ ordine delle operazioni è lievemente diverso rispetto a quello di decriptaggio dal momento che il processo è inverso a quest’ultimo. È  simile al ‘left shifts DES function’ e ‘DES function, right shift’ di Eurocrypt M e S.

Primo passo - Ottenere nuovi byte di chiave per il successivo ciclo

Eseguire le seguenti operazioni:

 k(i) = k(i) XOR T1[k(i+1) XOR k(i-1) XOR C]
k(i+1) = k(i+1) XOR T1[K(i+2) XOR k(i) XOR C]
k(i+2) = k(i+2) XOR T1[k(i+3) XOR k(i+1) XOR C]
 k(i+3) = k(i+3) XOR T1[k(i+4) XOR k(i+2) XOR C]

dove i =     1 per i cicli 1, 5, 9, 13
                  5 per i cicli 2, 6, 10, 14
                  9 per i cicli 3, 7, 11, 15
                13 per i cicli 4, 8, 12, 16.

Nei casi in cui la suddetta formula dia suffissi k fuori dall’intervallo 1-16, si deve considerare il valore ottenuto da k facendone il modulo 16. Es.  Se k = 17, allora k = k mod 16 = 1, se k=16, allora k = k mod 16 = 0). Il valore della costante C dipende dal numero di ciclo. Per i cicli 1, 2, …, 15, 16 tale costante ha valori rispettivamente pari a 0x00, 0x01, …,  0x0E, 0x0F. Questo annulla (unwinding) l’effetto della manipolazione della chiave circolare nell’algoritmo di decriptaggio.

Secondo passo - XOR dei byte di chiave con quelli di dati

Questo è semplice:

d5 = K(i) XOR d5
d6 = K(i+1)  XOR d6
d7 = K(i+2)  XOR d7
d8 = K(i+3)  XOR d8

dove i =     1 per i cicli 1, 5, 9, 13
                 5 per i cicli 2, 6, 10, 14
                 9 per i cicli 3, 7, 11, 15
               13 per i cicli 4, 8, 12, 16

L’inversione dei suffissi annulla (unwinds) l’interazione dei byte di chiave con quelli di dati, confrontati nell’algoritmo di decriptaggio.

Terzo passo - Funzione Nucleo

Prima eseguire 4 accessi alla Tabella 1:

d5 = T1[d5], d6 = T1[d6], d7 = T1[d7], d8 = T1[d8]

Successivamente utilizzare la Tabella 2 (vedi oltre). Il termine '~' significa che scambio di posto del mezzo byte meno significativo con quello più significativo (es. 11100010 = E2  Þ  ~E2 = 2E = 00101110):

 d5 = d8 XOR d5
 d7 = T2[(~d8) + d7]

 d8 = d7 XOR d8
 d6 = T2[ (~d7) + d6]

 d7 = d6 XOR d7
 d5 = T2[ (~d6) + d5]

Ora si deve utilizzare la Tabella 1 come segue:

 d6 = d5 XOR d6
 d8 = T1[(~d5) + d8]

 d5 = d8 XOR d5
 d7 = T1[(~d8) + d7]

 d8 = d7 XOR d8
 d6 = T1[(~d7) + d6]

Infine eseguire:

 d7 = d6 XOR d7
 d6 = d5 XOR d6.

Se in qualche addizione il valore risultante è maggiore di 0xFF, sottrarre il valore 0x0100 prima di accedere alle tabelle. Questo passo è identico a quello relativo all Funzione Nucleo di decriptaggio, ma chiaramente opera in direzione opposta.

Quarto passo - Calcolare i nuovi valori dei byte di dati per il prosimo ciclo

Questi si ottengono dalla Tabella 2 procedendo come segue:

 d1 = T2[d6] XOR d1
 d2 = T2[d8] XOR d2
 d3 = T2[d5] XOR d3
 d4 = T2[d7] XOR d4

Prima di utilizzare i byte di dati d1, …, d8 occorre scambiarli come segue :

d1 D d5
d2 D d6
d3 D d7
d4 D d8

NOTA: al termine del 16° ciclo però questo scambio NON deve essere fatto e i byte d1, …, d8 rappresentano la segnatura completa che dovrebbe coincidere agli 8 byte che seguenti al parametro 0x82. Sono consapevole che un’occhiata a tutto questo materiale è abbastanza scoraggiante, ma se studierete il materiale attraverso un esempio, troverete il coraggio di andare avanti. Per ricapitolare, possiamo dire che la parola di controllo è il Decriptaggio Mediaguard, viceversa il messaggio di segnatura è il Criptaggio Mediaguard. Le chiavi sono memorizzate per l’uso diretto con il criptaggio Mediaguard e ad ogni ciclo viene generata una chiave circolare per quel ciclo. Possiamo quindi dire che l’algoritmo di Criptaggio opera sulle chiavi circolari R1, R2, …, R16. L’algoritmo di decryptaggio è l’inverso di quello di Criptaggio; il fine della fase di preparazione della chiave è quello di generare R16. Ad ogni ciclo di Decriptaggio viene generata la chiave circolare per il successivo ciclo. Le chiavi circolari per il decriptaggio sono R16, R15, …, R1. L’intera procedura assicura che il Decryptaggio è esattamente il procedimento inverso del Criptaggio.
 
 


Metodo pratico per calcolare una signature valida
Nella maggior parte delle istruzioni Seka, è fondamentale aggiungere nel fondo una signature o firma corretta per dare al comando stesso validità. La signature è formata da 8 byte e per calcolarla correttamente procediamo in questo modo:

Una unica raccomandazione, mi raccomando di cliccare sul pulsante "Signature" solo dopo aver digitato completamente il comando, inclusa la lunghezza dell'istruzione che può essere calcolata prima, tenendo conto che la signature è sempre di 8 byte.
 

[Torna all'indice]