ITRM20000333A1 - Sistema on-line di accesso condizionamento e controllo dell'audience per servizi di comunicazione di tipo broadcast e multicast. - Google Patents

Sistema on-line di accesso condizionamento e controllo dell'audience per servizi di comunicazione di tipo broadcast e multicast. Download PDF

Info

Publication number
ITRM20000333A1
ITRM20000333A1 IT2000RM000333A ITRM20000333A ITRM20000333A1 IT RM20000333 A1 ITRM20000333 A1 IT RM20000333A1 IT 2000RM000333 A IT2000RM000333 A IT 2000RM000333A IT RM20000333 A ITRM20000333 A IT RM20000333A IT RM20000333 A1 ITRM20000333 A1 IT RM20000333A1
Authority
IT
Italy
Prior art keywords
key
broadcast
user
keys
block
Prior art date
Application number
IT2000RM000333A
Other languages
English (en)
Inventor
Paolo Rinaldi
Original Assignee
Paolo Rinaldi
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Paolo Rinaldi filed Critical Paolo Rinaldi
Priority to IT2000RM000333A priority Critical patent/IT1316201B1/it
Publication of ITRM20000333A0 publication Critical patent/ITRM20000333A0/it
Priority to PCT/IT2001/000315 priority patent/WO2001099029A2/en
Priority to EP01949874A priority patent/EP1292873A2/en
Priority to AU2001270985A priority patent/AU2001270985A1/en
Priority to US10/311,767 priority patent/US20030169885A1/en
Publication of ITRM20000333A1 publication Critical patent/ITRM20000333A1/it
Application granted granted Critical
Publication of IT1316201B1 publication Critical patent/IT1316201B1/it

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/65—Arrangements characterised by transmission systems for broadcast
    • H04H20/76—Wired systems
    • H04H20/82—Wired systems using signals not modulated onto a carrier
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/09—Arrangements for device control with a direct linkage to broadcast information or to broadcast space-time; Arrangements for control of broadcast-related services
    • H04H60/14—Arrangements for conditional access to broadcast information or to broadcast-related services
    • H04H60/23—Arrangements for conditional access to broadcast information or to broadcast-related services using cryptography, e.g. encryption, authentication, key distribution
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/26606—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel for generating or managing entitlement messages, e.g. Entitlement Control Message [ECM] or Entitlement Management Message [EMM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4622—Retrieving content or additional data from different sources, e.g. from a broadcast channel and the Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4623—Processing of entitlement messages, e.g. ECM [Entitlement Control Message] or EMM [Entitlement Management Message]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/478—Supplemental services, e.g. displaying phone caller identification, shopping application
    • H04N21/4782—Web browsing, e.g. WebTV
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6156—Network physical structure; Signal processing specially adapted to the upstream path of the transmission network
    • H04N21/6175—Network physical structure; Signal processing specially adapted to the upstream path of the transmission network involving transmission via Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/637—Control signals issued by the client directed to the server or network components
    • H04N21/6377—Control signals issued by the client directed to the server or network components directed to server
    • H04N21/63775—Control signals issued by the client directed to the server or network components directed to server for uploading keys, e.g. for a client to communicate its public key to the server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/162—Authorising the user terminal, e.g. by paying; Registering the use of a subscription channel, e.g. billing
    • H04N7/165—Centralised control of user terminal ; Registering at central
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/167—Systems rendering the television signal unintelligible and subsequently intelligible
    • H04N7/1675—Providing digital key or authorisation information for generation or regeneration of the scrambling sequence
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2211/00—Indexing scheme relating to details of data-processing equipment not covered by groups G06F3/00 - G06F13/00
    • G06F2211/007—Encryption, En-/decode, En-/decipher, En-/decypher, Scramble, (De-)compress
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/60—Digital content management, e.g. content distribution
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/60—Digital content management, e.g. content distribution
    • H04L2209/606—Traitor tracing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0457—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply dynamic encryption, e.g. stream encryption

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Databases & Information Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Theoretical Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Description

Descrizione dell'invenzione industriale dal titolo: "SISTEMA "ON-LINE" DI ACCESSO CONDIZIONATO E CONTROLLO DELL'AUDIENCE PER SERVIZI DI COMUNICAZIONE DI TIPO BROADCAST E MULTICAST".
DESCRIZIONE
La presente invenzione riguarda un sistema "on-line" di accesso condizionato e controllo dell'audience per servizi di comunicazione di tipo Broadcast e Multicast.
Nella comunicazione da uno a molti, tipicamente cioè nel Broadcasting e nel Multicasting, vi è la necessità di realizzare un sistema di crittografia ed accesso condizionato per assicurare la segretezza delle comunicazioni all'interno di un gruppo dì utenti abilitati alla ricezione.
Tuttavia, nulla impedisce ad un utente del gruppo di aiutare terzi a ricevere illegittimamente i dati riservati al gruppo.
Questo problema, detto "piraterìa", è particolarmente noto, ad esempio, nell'ambito della televisione digitale a pagamento diffusa in Broadcasting, tipicamente via satellite.
La pirateria agisce solitamente secondo due modalità:
a) Distribuisce illegalmente i contenuti decrittografati (in chiaro);
b) Distribuisce le "chiavi" di decrittografia.
La presente invenzione è finalizzata fondamentalmente alla protezione dei contenuti di valore commerciale, quindi non necessariamente segreti ma da proteggere principalmente dal punto di vista dei diritti di impiego (ad esempio un programma televisivo, dati di Borsa, ecc.).
In questo caso si ritiene non interessante una difesa rispetto al primo tipo di problema, in quanto una re-distribuzione illegale dei contenuti di tale tipo, cioè contenuti "noti", è sempre tecnicamente fattibile. Ad esempio è possibile ritrasmettere un programma televisivo ricevuto tramite un decoder legittimamente autorizzato alla ricezione. In tale caso è evidente che il problema diventa principalmente una questione di intervento delle forze dell'ordine.
D'altronde rimane sempre importante proteggere anche questo tipo di informazioni, soprattutto nei casi in cui tale informazione sia del tipo "realtime" e quindi perda gran parte del suo valore se ricevuta un certo tempo dopo rispetto agli utenti abilitati del gruppo (si pensi, ancora, alle quotazioni dei titoli di Borsa o alla trasmissione di un evento sportivo in diretta).
In questi casi è quindi importante il metodo di distribuzione delle chiavi di decrittografia.
La presente invenzione consiste in un metodo di distribuzione delle chiavi di decrittografia che:
1. preveda la distribuzione delle chiavi solo ad utenti abilitati;
2. sia realizzabile con un minimo "over-head" di banda di comunicazione;
3. garantisca il funzionamento anche nel caso in cui si debba decrittografare dati in tempo reale, pur non richiedendo elevate capacità di calcolo a livello dei sistemi di ricezione degli utenti;
4. consenta di assegnare a ciascun singolo utente un ammontare di unità di tempo di servizio (come per i gettoni telefonici) da "spendere" a suo piacimento;
5. consenta il controllo dell'audience reale per ciascun servizio;
6. come obiettivo ulteriore opzionale, consenta di individuare, con una elevata probabilità, un eventuale "traditore", cioè un utente abilitato del gruppo che ridiffonda illegalmente le chiavi.
Il sistema secondo l'invenzione è principalmente concepito per l'impiego su servizi diffusi in modalità Multicast in rete (Internet, Intranet, Extranet, LAN) ma può essere impiegato anche nelle trasmissioni di tipo Broadcast digitali (via satellite) o etere. Il sistema può anche essere impiegato con la telefonia cellulare UMTS, oppure GPRS, rete ibrida Sat-TV con ritorno via cavo telefonico, oppure con sistemi satellitari in banda Ku/Ka.
La Presente Invenzione e la Tecnica Nota
Nel mondo della televisione digitale a pagamento, il sistema di accesso condizionato più usato è basato sull'uso delle così dette "smartcard".
Tale sistema viene generalmente considerato "sicuro" in quanto posto tipicamente a confronto rispetto a sistemi completamente software. In realtà, anche se è vero che le "smartcard" sono molto più sicure di un sistema solo software, anch'esse possono essere violate dopo un certo tempo.
In tale caso il danno è enorme perché si richiede di rimpiazzare una grande quantità di sistemi periferici o "smartcard".
Nel mondo dell'Internet Protocol (IP) Multicast, si stanno invece ricercando soluzioni in cui l'accesso condizionato sia gestito a livello di router. Tali sistemi portano teoricamente ad un impiego ottimale della banda ma pongono pesanti requisiti strutturali.
Altri sistemi sono stati invece pensati per la protezione di informazione statica, ad esempio l'informazione scritta su un CD. Ad esempio, il Brevetto US 5.400.403 sembra bene adattarsi a tale scopo ma basa tutta la "resistenza all'abuso" sul fatto che il sistema di decrittografia è personalizzato per ciascun utente ed è di dimensioni analoghe all'informazione stessa (è un sistema che si potrebbe definire a "persistenza nello spazio"). Quindi, si pensa, ridistribuire tale sistema di crittografia è costoso e visibile (essendo personalizzato per ciascun utente, una copia e redistribuzione in gran quantità porterebbe implicitamente la firma del traditore).
La presente invenzione si differenzia rispetto ai precedenti sistemi in quanto:
- ha lo scopo di proteggere i dati al momento stesso della loro diffusione, per mezzo di una cifratura degli stessi effettuata da un sistema basato su chiavi che cambiano dinamicamente durante la diffusione degli stessi dati, ciascuna di queste chiavi essendo associata ad una breve porzione degli stessi dati;
- non richiede l'uso di smartcard o altro hardware dedicato specificamente all'accesso condizionato; - richiede la disponibilità di un canale di comunicazione per la distribuzione delle chiavi al sistema utente, a fianco del canale one-to many Broadcast o Multicast utilizzato per la diffusione dei dati di contenuto, che consenta una comunicazione in modalità affidabile bidirezionale ma non pone requisiti particolari su tale canale;
- basa la resistenza all'abuso da parte del potenziale traditore principalmente sul costo di attuazione e sulla visibilità di un servizio abusivo di distribuzione dinamica delle chiavi ai sistemi degli utenti; quindi basa la resistenza sul fattore "persistenza nel tempo" invece che sul fattore "persistenza nello spazio";
- il software di crittografia sul lato utente potrà essere di dimensioni estremamente contenute ed esso stesso tipicamente distribuito in modo telematico, con possibilità anche di aggiornamento frequente, proprio per scoraggiare ulteriormente eventuali traditori (ulteriore fattore di "persistenza nel tempo");
- come ulteriore caratteristica essendo le chiavi distribuite agli utenti on-demand, permette di calcolare esattamente l'audience di un contenuto diffuso in broadcast fino al dettaglio di ciascuna sua singola porzione (posta in corrispondenza di ciascuna chiave);
- come ulteriore caratteristica, consente l'accesso on-demand di ciascun utente anche solo a porzioni del contenuto, secondo il suo interesse, fino alla granularità della porzione di tempo posta in corrispondenza biunivoca con la rispettiva chiave: si pensi, ad esempio, ad un servizio di diffusione di dati di borsa in tempo reale il cui costo sia in funzione del tempo di fruizione da parte dell'utente;
consente di minimizzare la dimensione del canale di distribuzione delle chiavi, evitando un dimensionamento su un possibile picco da congestione, grazie ad un sistema di diluizione nella distribuzione delle chiavi ottenuto con una trasmissione delle chiavi anche anticipatamente rispetto ai dati ad esse correlati.
Nella trattazione che segue si farà riferimento a servizi di comunicazione diffusi con protocollo IP Multicast in Internet; ciò in quanto è ovvio che in Internet o Intranet il requisito di disponibilità di un sistema di comunicazione a due vie è facilmente soddisfacibile, ad esempio attraverso il protocollo Transport Control Protocol Internet Protocol attivando contemporaneamente alla comunicazione multicast una normale sessione unicast.
Considerando che in prospettiva la disponibilità di una connessione Internet (o semplicemente telefonica) permanente potrà divenire una realtà anche a livello domestico, il sistema potrà vantaggiosamente anche essere utilizzato per la protezione di servizi di comunicazione diffusi attraverso altri mezzi, come ad esempio la televisione digitale via satellite, eventualmente con ritorno di informazioni utente-fornitore via cavo, oppure, con i proposti sistemi con collegamento in discesa in banda Ku e collegamento in salita in banda Ka.
Il sistema secondo la presente invenzione comprende blocchi elementari preferibilmente implementati via software, organizzati come esposto nella parte caratterizzante delle rivendicazioni allegate.
La presente invenzione verrà ora descritta in riferimento a sue forme dì realizzazione attualmente preferite riportate a titolo illustrativo e non limitativo e facendo riferimento alle figure dei disegni allegati, in cui:
la figura 1 mostra la architettura generale del sistema secondo l'invenzione illustrata in termini di blocchi operativi, e possono essere ugualmente realizzati in hardware o in software anche se, ovviamente, la soluzione via software sarà quella preferita;
le figure 2(A), 2(B) mostrano diagrammi di flusso relativi al funzionamento del blocco 2 di figura 1, (Trasmission Crypto Manager);
le figure 3(A), 3(B) mostrano diagrammi di flusso relativi al funzionamento del blocco 6 di figura 1 (Conditional Access System); e
le figure 4(A), 4(B), 4(C) mostrano diagrammi di flusso relativi al funzionamento del blocco 9 di figura 1 (Decrypt).
Architettura del Sistema
Nello schema a blocchi di figura 1 sono evidenziati i diversi blocchi funzionali relativi al Centro Servizi di un Provider che eroga sistemi IP Multicast e quelli relativi ad un Utente che fruisce di uno o più tali servizi.
Il Provider e l'Utente sono interconnessi tramite una Rete (5) (LAN, Intranet, Internet o altro mezzo trasmissivo con capacità bi-direzionale come precedentemente esposto) che supporta sia la trasmissione IP Multicast sia la comunicazione bidirezionale, che in questa esemplificazione viene indicata nel protocollo di comunicazione TCP/IP. Naturalmente, in generale, sono possibili più Providers eroganti servizi sulla medesima Rete.
I blocchi funzionali indicati nell'architettura indicano Programmi (software) che girano su sistemi operativi ed hardware standard. Ad esempio, tutto il Centro Servizi può essere concentrato su un Computer o su più Computers in LAN o tramite Internet stesso, mentre Programmi lato Utente potranno funzionare tipicamente in modo concorrente su di un Personale Computer del tipo "stand-alone" o ancora su una architettura Client -Server.
La implementazione dei Programmi potrà essere realizzata con diversi linguaggi. Quello preferito è però Java, sia sul lato Provider che sul lato Utente in modo che i servizi siano fruibili sul maggior numero di piattaforme hardware e software.
Si esplicitano ora i vari blocchi di figura 1: 1. Service Manager
Il Service Manager è disposto per ricevere uno o più flussi informativi destinati alla trasmissione in modalità Multicast (che d'ora in avanti verranno denominati semplicemente "Flussi"), e ne gestisce la trasmissione, assegnando a ciascuno di essi un ID che lo caratterizza. 2. Transmission Crvpto Manager (T.C.M.)
Il T.C.M. effettua la cifratura di ciascun Flusso utilizzando un adeguato algoritmo a Chiave dinamica, cioè una chiave che viene cambiata ogni prefissato periodo di tempo (o numero di record di dati trasmesso). Tale Chiavi (ad esempio a 64 bit) vengono generate automaticamente ed in modo random dal T.C.M. stesso e comunicate al Conditional Access System (6), insieme ad un indentificatore di ciascuna specifica Chiave (K.I.) (alternativamente la chiave può essere generata dal C.A.S. 6 e comunicata al T.C.M 2).
Più esattamente, il T.C.M. opera sul flusso nel seguente modo:
i) suddivide il Flusso in Pacchetti
ii) genera le Chiavi, tipicamente una nuova chiave ogni N Pacchetti oppure ogni M secondi (o minuti).
iii) Formatta un Pacchetto così composto:
- ID del Flusso
- K.I. (Key Identifier) della Chiave con cui viene cifrato il Pacchetto, è un numero progressivo che individua la chiave attualmente utilizzata per cifrare il campo dati dei pacchetti e anche quello relativo a questo specifico pacchetto.
Campo dati cifrato tramite l'algoritmo associato alla Chiave particolare identificata da K.I.
- N.K.I. (Nuovo K.I.), indica il prossimo K.I.
cioè la prossima chiave che verrà utilizzata quando sarà scaduta quella attuale.
- C.R.C., ad esempio a 32 bit per riconoscere un pacchetto errato
iv) ad ogni cambio di chiave comunica al C.A.S. (6) la coppia N.K.I - Nuova Chiave (in modo, come si verrà in seguito, che il C.A.S. (6) abbia il tempo di consegnarla a tutti gli Utenti abilitati prima che tale Nuova Chiave venga impiegata) . Sì deve notare che il concetto di prevedere la possibilità per il Sistema Utente di acquisire anticipatamente la prossima chiave può essere esteso al fatto di acquisire un certo numero prossime chiavi.
3. Xrasmiasion Format Processor (T.F.P.)
Il T.F.P. completa e processa il Pacchetto di dati aggiungendo tutto quanto necessario alla trasmissione nello specifico protocollo previsto (ad esempio IP Multicast). Tipicamente, per aumentare l’affidabilità della trasmissione, verranno impiegati algoritmi standard di Forward Error Correction oppure, più semplicemente, verrà aggiunto un pacchetto extra ogni L pacchetti, nel quale ogni bit è calcolato come EXOR dei bit nella stessa posizione nei L pacchetti associati (bit(i) = Pi(i) EXOR P2(i) ... EXOR PL(i); in tale modo, in ricezione, il sistema di Error Correction del Blocco (8) potrà correggere/ricostruire un pacchetto errato/mancante nei L pacchetti.
4. Network Interface (N.I.)
Il blocco N.I. rappresenta appunto una interfaccia hardware e software standard per la Rete di comunicazione. Ad esempio, nel caso di Internet, potrebbe essere un Modem con relativo Driver e Socket.
5. Rete
Come detto precedentemente preferibilmente può trattarsi di una rete tipo quella usata su Internet o equivalenti oppure le altre strutture di comunicazione dati con capacità mono e bi-direzionale esposte precedentemente nella parte introduttiva della descrizione.
6. Condìtional Access System (C.A.S.l
Questo blocco di sistema è responsabile per la trasmissione delle Chiavi agli Utenti abilitati .
Il sistema verifica anzitutto nel Data Base degli utenti che l'utente richiedente la chiave sia tra quelli autorizzati per lo specifico Flusso relativo alla chiave richiesta.
Quindi si predispone a fornire la chiave a tale cliente ogni volta che questi la richieda, in modalità interattiva (TCP/IP).
E' prevista una modalità di utilizzo del servizio, da parte dell'utente, "a consumo": in questo caso all'utente vengono assegnati un certo numero di gettoni (Token) corrispondenti ciascuno ad una potenziale richiesta di fornitura di una nuova Chiave.
Ad ogni richiesta e fornitura di Chiave, il monte gettoni viene decrementato di una unità.
Quando i gettoni sono terminati, all'utente viene negata la fornitura di nuove chiavi fino a che non venga ricaricato il monte gettoni.
Si deve notare come il C.A.S. abbia la completa disponibilità, in tempo reale, del numero di utenti attivi ovvero della audience. Le chiavi sono fornite al C.A.S. dal blocco T.C.M. (2).
7. Network Interface_ (N.I.)
Il blocco N.I. (7) è l'equivalente, dal lato dell'utente, del sistema precedentemente indicato al punto 4 come Network Interface (N.I.).
8. Error Correction System
Il sistema verifica la correttezza dei Pacchetti ricevuti (calcolando il C.R.C. e confrontandolo con quello riportato nel Pacchetto) e ne effettua la correzione/ricostruzione così come precedentemente illustrato.
9. Decrypt System (D.S.)
Con D.S. si identifica il sistema che effettivamente, sul lato utente, svolge le funzioni di richiesta delle chiavi e di decrittografia dei dati ricevuti, passando poi i dati decrittografati all'Applicazione (10) che li utilizza.
Il D.S. Può lavorare autonomamente ed automaticamente oppure, come evidenziato nella figura, può lavorare su richiesta dell'applicazione (10) (richiesta di gettoni).
In quest'ultimo caso l'Applicazione (10) "spende" un gettone (Token) ogni volta che vuole ricevere i dati. Allora il D.S. si attiva per chiedere la Chiave e quindi decrittografare tutti i Pacchetti in arrivo a cui quella Chiave dà accesso. Il D.S. avvisa poi l'Applicazione (10), con ragionevole anticipo, quando la Chiave (il Gettone) sta per esaurire la sua utilità, e quindi bisogna richiedere la Nuova Chiave (corrispondente al N.K.I.) per decrittografare la successiva sequenza di Pacchetti.
Se l'utente, tramite l'Applicazione (10), conferma la volontà di proseguire (spende un altro gettone) viene chiesta la nuova Chiave e la ricezione avviene senza alcuna perdita di dati. Altrimenti, esauriti i Pacchetti decrittografabili con la chiave attuale, la ricezione in si interrompe.
In alternativa può essere il D.S. stesso, automaticamente, a richiedere la Nuova Chiave senza necessità di ricevere una "Token Request" dall'Applicazione (10). Essendo la Nuova Chiave fornita al C.A.S. (6) dal T.C.M. (2) contemporaneamente alla diffusione in Multicast del corrispondente N.K.I., il D.S. potrebbe richiedere la Nuova Chiave non appena cambia il N.K.I.. In realtà, per evitare che tutti i D.S. attivi (in corrispondenza di ciascun utente o Applicazione (10) effettuino la richiesta nello stesso istante, può essere introdotto un ritardo randomico in modo da distribuire nel tempo le richieste.
10. Applicazione
Per Applicazione s'intende qualsiasi applicazione che utilizza i dati trasmessi in Multicast .
Si deve notate come la suddivisione in tre programmi delle funzioni di Error Correction, Decrypt e Applicazione siano fondamentalmente di tipo logico. E' possibile che ì tre moduli logici siano contenuti in un unico programma, eventualmente anche un programma scritto in Java e scaricato attraverso Internet.
L'individuazione_ dell 'eventuale_ "Traditore11 .(Traitor Tracina).
Il sistema descritto raggiunge tutti gli obiettivi indicati nel primo paragrafo eccetto l’ultimo opzionale (6), ovvero l'individuazione automatica di un eventuale "Traditore" che ridiffonda illegalmente le Chiavi.
In realtà il sistema pone comunque problemi significativi al Traditore, dovendo egli porre in atto una struttura continuamente in azione e quindi facilmente individuabile con un'oppportuna indagine.
Per facilitare ulteriormente l'individuazione del Traditore bisognerebbe che a ciascun utente venissero consegnate Chiavi che lo individuino univocamente .
Ovviamente, dato che i dati sono crittografati in unico modo per tutti gli utenti, l’obiettivo non è di facile raggiungimento.
Si propongono qui due modi diversi per raggiungere l'obiettivo.
a) Sistema di Crittografia a Chiave Multipla Questo sistema è stato proposto, ma presenta una notevole complessità.
b) Sistema a Chiave Calcolata (parte della presente invenzione)
Ogni chiave calcolata fornita ciascun utente è in realtà una trasformata della Chiave reale, calcolata con una funzione diversa da utente ad utente, cambiata con una certa frequenza (ad esempio giornalmente).
Tale Funzione può essere semplicemente, ad esempio, una Chiave di scrambling ulteriore, differente da utente ad utente, tale che la Chiave vera viene calcolata in EXOR bit a bit con la stessa:
Chiave vera di decrittografia = Chiave Calcolata EXOR Chiave dì Scrambling (cambiata giornalmente)
Per rendere ancora più arduo il compito del potenziale Traditore, la Funzione sarà più complessa ed il cambiamento della stessa non si limiterà alla sostituzione periodica (giornaliera) della Chiave di Scrambling dell'utente: ad esempio, invece di applicare la Chiave di Scrambling tramite un semplice EXOR, si può utilizzare tale chiave come inizializzazione di un Linear Feedback Shift Register con catene di feedback non identiche per tutti gli utenti, (e comunque variate ogni giorno) .
Per rendere più efficace la protezione nei confronti del potenziale Traditore, la Funzione può essere scritta all1interno del programma stesso dì Decrypt (9), meglio ancora se esso stesso è a sua volta tutt'uno con l'Error Correction (8) e l'Applicazione (10).
Ciò in modo che sia molto complesso effettuare un Reverse Engineering della Funzione, ovvero che sia necessario allo scopo al Traditore un tempo superiore al ritmo di cambiamento della Funzione stessa, in modo che si trovi sempre ad inseguirla .
L'aggiornamento di tale funzione può essere effettuato in vari modi, ad esempio può essere automaticamente effettuato via Internet.
Naturalmente l'adozione di tale sistema comporterà un adeguamento delle funzionalità del C.A.S. (6), che dovrà generare tali Funzioni, memorizzarle nel D.B. utenti (7), consegnarla a ciascun utente periodicamente (giornalmente), calcolare, applicando la Funzione generata per lo specifico utente, le Chiavi calcolate da fornirgli .
Si ritiene conveniente che, con l'adozione di un sistema di Traitor Tracing a chiave differenziata / calcolata per ciascun utente, che tali chiavi vengano elaborate e memorizzate sul D.B. utente (7) in anticipo, off-line, in modo da non caricare il C.A.S. durante il funzionamento on-line. In tale caso il T.C.M. (2), dovrà esso stesso produrre in anticipo le Chiavi e gli N.K.I. e consegnarli al C.A.S. che effettua le elaborazioni. Tutto ciò può, ad esempio, avvenire in un periodo di scarsa attività (la notte).
Verrà ora descritta, a titolo esemplificativo e non limitativo, in riferimento alle figure da 2(A) a 4(C) l'architettura software del sistema secondo l'invenzione descritto in riferimento alla figura 1.
TCM (blocco 101)
TCM inizia con un primo blocco (102) di inizializzazioni varie: viene posto KI=0, che è l'indicatore della chiave attuale, e NKI=1, che è l'indicatore della nuova chiave.
Viene inizializzata anche una variabile tempo T. uguale ad una funzione FTIME che fornisce un numero intero uguale ai secondi trascorsi dall'inizio del giorno. Viene anche fissata una costante PERIOD che rappresenta un numero di secondi che esprimono il periodo di cambiamento della chiave.
Viene quindi inizializzata la prima chiave, corrispondente a KI, che all'inizio è uguale a 0, e la chiave successiva, che è NCHIAVE, sostanzialmente con due numeri randomici calcolati con la funzione RANDOM (qui calcolati rispettivamente in funzione del tempo T 1).
Finita 1 'inizializzazione si va al blocco successivo (103) che è dopo l'indirizzo ALFA.
Viene inviato al C.A.S. (6) KI e NKI, nonché la chiave corrispondente "CHIAVE" e la nuova chiave "NCHIAVE" e le due variabili T e PERIOD, in modo che il C.A.S. (6) conosca il momento in cui sono state create queste chiavi.
Al blocco (104) TCM (2), acquisisce dal SERVICE MANAGER (1) un nuovo vettore dati VDATI.
Si passa quindi al blocco (105) successivo: viene crittografato il vettore dati e generato quindi un vettore VCRIPT per mezzo della funzione FCRIPT.
FCRIPT è una qualsiasi funzione di crittografia che combina un vettore dati con una chiave; chiave che poi in seguito cambierà generando differenti VCRIPT anche non solo in funzione del vettore dati ma anche della chiave (dinamica) stessa.
Poi il pacchetto dati blocco (106) (qui parliamo di pacchetti IP) viene completato con altri dati tra cui l'identificatore ID del servizio, codice di porta "COD. PORT" (nel protocollo IP serve per identificare una porta di destinazione).
Vengono poi inserite nel pacchetto anche KI e NKI, ovviamente il vettore di dati crittografato VCRYPT e un CRC, che serve poi alla ricezione per verificare se il pacchetto ricevuto presenta errori. Vedremo in seguito che c'è un sistema di error correction (8), non è oggetto del brevetto, attraverso il quale questi dati vengono verificati.
passiamo a "BETA".
Al blocco 201 il pacchetto quindi così completato viene a questo punto inviato, cioè passato al TFP (3) che è un sistema che completa e aggiunge eventualmente ai pacchetti ulteriori informazioni, utili, ad esempio, per le funzioni di forward error correction.
Al blocco (202) viene registrato l'istante di tempo TI in cui è stato generato (T1=FTIME, cioè l'ora attuale).
Al blocco (203) viene verificato, facendo la differenza tra TI e T, se è stato superato il periodo di secondi PERIOD (scaduto il quale deve cambiare chiave): se non è superato può tornare al punto γ e quindi alla fig. 2(A) dove si acquisisce un nuovo pacchetto dati e si continua nel ciclo.
Sostanzialmente questo ciclo va avanti fino a che (Tl-T) non diventa maggiore di PERIOD.
Scaduto infatti questo periodo blocco (204) bisogna quindi aggiornare le chiavi: innanzitutto la chiave attuale KI diventa la chiave prossima quindi KI=NKI, NKI viene incrementata di 1.
Dopodiché viene verificato al blocco (205) se NKI ha superato un massimo numero intero possibile perché in quel caso bisogna (riazzerarlo) al blocco (206) in modo che non si vada in over flow.
Normalmente quindi al blocco (207) la chiave attuale diventa la chiave che prima era NCHIAVE e bisogna generare la chiave prossima futura NCHIAVE (come un'espressione randomica dell'istante di tempo T).
A questo punto si può ciclare tornare di nuovo ad ALFA e riniziare tutto il ciclo.
Nella figura 2(C) c'è 1'esplicitazione della funzione di crittografia che, come detto, non è oggetto del brevetto, potendo essere una qualsiasi funzione che effettua la crittografia di un pacchetto dati con una chiave segreta.
Qui comunque si vuole dare un esempio di un sistema molto semplice di crittografia, in cui la chiave è semplicemente utilizzata facendo un EXOR bit a bit con il pacchetto dati in sequenza. Non si ritiene necessaria una spiegazione dettagliata della sequenza in figura 2(C).
Passiamo ora al C.A.S. figura 3(A) blocco 301, il sistema responsabile di trasmettere le chiavi agli utenti abilitati. Il programma, dopo le necessarie inizializzazioni, blocco 302 si sincronizza al blocco 303 temporalmente con il TCM (2) leggendo la variabile T e la costante PERIOD.
Quindi al blocco (304) (ALFA) il sistema legge dal TCM KI e NKI ed i valori delle due chiavi corrispondenti (cioè CHIAVE e NCHIAVE).
A questo punto il CAS blocco (305-304) entra in un luogo in cui si predispone a soddisfare le richieste da parte degli utenti che ovviamente chiederanno una chiave corrispondente ad una variabile KI o NKI.
(nel caso in cui vengano richieste chiavi corrispondenti a variabili identificatrici attualmente non attive (ad esempio scadute ) il sistema non potrà rispondere e dovrà mandare un messaggio di errore).
A questo punto il sistema deve verificare se l'utente è abilitato a ricevere le chiavi richieste.
Nell'esempio che qui riportiamo il concetto di abilitazione è stato legato al concetto di consumo, cioè l'utente viene dotato di una serie di gettoni chiamati TOKEN che gli consentono di usufruire del servizio, ciascuno per un periodo di tempo prefissato .
Il sistema il CAS (6) deve verificare che l'utente ne abbia ancora disponibili (come accadeva con il vecchio telefono a gettoni).
Quindi al blocco (306) TOKEN viene inizializzato con un numero massimo (MAXINTEGER).
Il programma al blocco (307) poi verifica se l'utente ha effettivamente un numero di "gettoni limitati" (potrebbero esserci degli utenti privilegiati, il cui accesso al servizio non preveda il consumo di gettoni, ovvero non abbia "gettoni limitati").
Nel caso più articolato l'utente i-esimo è effettivamente del tipo "a gettoni limitati". In tale caso bisogna verificare se l'utente i-esimo ha ancora gettoni disponibili. Ciò viene effettuato verificando al blocco (308) se TOKEN (I) è minore di zero. Se ciò non è vero blocco 309, la sua disponibilità di gettoni viene decrementata di 1 (TOKEN (I) = TOKEN (I) - 1); al blocco (310) viene posto TOKEN = TOKEN (I) e (label BETA). Alla fig.
3 (b), blocco 401 si verifica se TOKEN è minore di 0 (se fosse uguale a 0 significherebbe che si sta impiegando l'ultimo gettone disponibile). In tale si esce dal loop e si trasmetterà all'utente (blocco 402) che ha richiesto la chiave semplicemente la variabile TOKEN, che gli ritornerà appunto minore di 0 (questo valore significherà appunto per capire che gli è stato negato 1 1accesso).
Se invece TOKEN è maggiore o uguale a 0 blocco (403), viene calcolato DELTATIME (DELTATIME esprime il tempo rimasto di validità della chiave).
A questo punto il CAS (6), al blocco (404) verifica che tipo di chiave ha richiesto (cioè KI o NKI).
Se la chiave richiesta è KI allora a questo punto il lavoro è finito e il programma deve trasmettere all'utente blocco (405) DELTATIME, PERIOD, TOKEN e CHIAVE (così l'utente sa anche quanti gettoni gli sono rimasti); altrimenti trasmetterà la chiave NCHIAVE blocco (406).
Il programma torna quindi ad alfa e si rimette in ciclo.
Decrvpt System D.S. (9) figura 4(a)
E' il sistema lato client che permette all'utente di dialogare con il sistema centrale quello che eroga le chiavi e ricevere quindi le chiavi necessarie per ricevere la crittografia.
Quindi il sistema D.S. 9, come si vede dal diagramma architetturale, comunica da un lato con il CAS (6) per farsi dare la chiave, dall'altro riceve, tramite il modulo Error Correction (8) i pacchetti dati (appunto già corretti) che gli erano stati inviati dal TCM (2) tramite il TFP (3).
La funzione del DECRYPT è quindi quella di effettuare il lavoro di decriptazione e quindi di ricreare il pacchetto dati originale e consegnarlo all 'APPLICAZIONE (10).
Con l 'APPLICAZIONE 10 vi sarà anche uno scambio di messaggi perché tipicamente sarà l'applicazione in effetti a richiedere servizi al D.S. (6), APPLICAZIONE (10) che poi a sua volta è guidata dall'utente in persona che decide quando e cosa vuole ricevere.
Vediamo adesso DECRYPT come funziona (fig.
4 (a))
Inizialmente, blocco (501), vengono effettuate alcune inizializzazioni che qui sono espresse nella subroutine in figura 4(c). Andiamo a vederla subito: fig. 4(c) viene acquisito blocco 502 un pacchetto dall 'Error Correction (8) e in particolare da questo primo pacchetto vengono estratti KI e NKI. Vengono quindi richieste blocco (503) al C.A.S. (6) entrambi le chiavi corrispondenti a KI e NKI e viene verificato blocco (504) se TOKEN è minore di zero (nel qual caso si va al return) altrimenti a questo punto bisogna inizializzare blocco (505) due nuove variabili locali della funzione D.S. (9) che appunto sono DKI (che sta per Decrypt-KI) ed, analogamente, DNKI, che vengono poste rispettivamente uguali alle due variabili KI e NKI ricevute dal CAS (6). Quindi si torna al programma principale.
A questo punto la prima domanda da fare blocco 506 è ancora se TOKEN è minore di 0 (cioè verifichiamo se l'utente ha esaurito i gettoni disponibili): in tale caso si va direttamente alla fine del programma e si manda un opportuno messaggio di APPLICAZIONE ("ACCESSO NEGATO").
Se TOKEN invece non è minore di 0 viene chiamata la subroutine denominata INPUT-DECRYPT-SEND blocco (507). Questa subroutine (vedi fig.
4(5)) è quella che acquisisce il pacchetto dall'ERROR CORRECTION (8) ed effettua la decrittografia con la chiave che si riceve dal CAS (6).
Quindi INPUT-DECRYPT-SEND blocco (508) innanzitutto acquisisce un pacchetto VCRYPT insieme a KI e NKI.
Poi verifica blocco (509) se KI è uguale alla variabile DKI . Se SI significa che la chiave corrispondente è stata già acquisita dal DECRYPT D.S. (9) (non è necessario acquisire una nuova chiave per ogni nuovo pacchetto ma solo quando la chiave è scaduta o non disponibile).
Se DKI è uguale a KI vuol dire che la chiave è già stata acquisita, che la variabile CHIAVE è la variabile corrente per potere effettuare la decriptazione . In questo caso può essere lanciata la funzione di decrittazione, che nel nostro esempio è la stessa FCRYPT (figura 2(c)) che fu usata dal TCM 2 per fare la crittografia (in effetti l'EXQR utilizzato nell 'FCRYPT funziona specularmente sia in crittografia che in decrittografia .
Quindi viene fatta blocco (510) la decrittografia del vettore VCRYPT con la chiave e viene rigenerato finalmente il vettore VDATI originale. A questo punto blocco (511) il vettore VDATI viene passato all'APPLICAZIONE 10 e si effettua il return.
Torniamo al programma principale (fig. 4(a)). Come si può notare è presente un loop nel quale si verifica blocco (512) se DKI e uguale KI (avevamo letto un nuovo KI dentro INPUT-DECRYPT-SEND, quindi si riverifica di nuovo se DKI è uguale KI).
Fino a che DKI è uguale a KI si possono acquisire nuovi pacchetti e decrittografarli e inviarli all'APPLICAZIONE. Quando DKI non è più uguale KI, vuol dire che è cambiata la chiave. Allora si suppone che la chiave successiva sia già stata acquisita e quindi si pone blocco (513) DKI uguale DNKI e CHIAVE con NCHIAVE.
Si verifica blocco (514) se DKI è effettivamente uguale a KI (teoricamente dovrebbe essere sempre così, a meno che non vi sia stato un malfunzionamento, nel qual caso bisogna rifare tutto il processo di inizializzazione), si fa di nuovo blocco (515) una cali a INPUT-DECRYPT-SEND, si chiede blocco (516) all'utente se vuole continuare la ricezione blocco (516) (siamo nella situazione in cui la chiave è scaduta e bisogna richiederne la nuova al C.A.S. (6), cioè utilizzare un nuovo gettone all'utente). Se l'utente risponde SI, blocco (517) si acquisisce dal C.A.S. (6) una nuova chiave NCHIAVE corrispondente a NKI e le altre variabili accessorie, si pone blocco (518) DKI uguale NKI e si fa la verifica blocco (519) se i gettoni sono finiti, cioè se TOKEN è minore di 0. Se SI, si manda un opportuno messaggio blocco (520) all'APPLICAZIONE (10), se NO si riprende il loop principale.

Claims (14)

  1. RIVENDICAZIONI 1. Sistema "on-line" di accesso condizionato e controllo della audience per servizi di comunicazione di tipo broadcast e multicast del genere che non utilizza smartcard o altro hardware dedicato sul lato utente, caratterizzato dal fatto che un insieme di dati informativi per comunicazioni broadcast (unidirezionali) viene criptato per mezzo di chiavi dinamiche che sono inviate a ciascun utente abilitato tramite canale interattivo e bidirezionale.
  2. 2. Sistema secondo la rivendicazione 1 caratterizzata dal fatto che detto insieme di dati informativi viene trasmesso su un canale di comunicazione che coincide con detto canale interattivo e bidirezionale.
  3. 3. Sistema secondo la rivendicazione 1, caratterizzato dal fatto che detto canale di comunicazione di insieme di dati informativi è separato da detto canale interattivo e bidirezionale.
  4. 4. Sistema secondo una o più delle precedenti rivendicazioni caratterizzato dal fatto che dette chiavi di decrittatura possono essere acquisite, in una certa prefissata quantità, anticipatamente dal sistema di decrittazione sul lato utente, evitando in tal modo la necessità di dimensionare il canale di distribuzione delle chiavi su un possibile picco da congestione.
  5. 5. Sistema secondo una o più delle precedenti rivendicazioni, caratterizzato dal fatto che il protocollo "one to many" è il protocollo Internet Protocol Multicast.
  6. 6. Sistema secondo una o più delle precedenti rivendicazioni, caratterizzato dal fatto che detto canale broadcast è: - una rete locale aziendale LAN - una rete territoriale WAN - una qualsiasi rete di tipo internet supportante il protocollo IP Multicast; - una trasmissione satellitare digitale, tipo DVB; - una trasmissione via etere digitale tipo DVB; - una trasmissione standard per telefonia cellulare tipo GPRS oppure UMTS; - una trasmissione satellitare del tipo bidirezionale nelle bande Ku/Ka; - una trasmissione standard satellitare V SAT.
  7. 7. Sistema secondo la rivendicazione 6, caratterizzato dal fatto che il canale trasmissivo bidirezionale su cui viaggiano le chiavi dinamiche dal centro agli utenti è del tipo GPRS, oppure UMTS, oppure satellitare Ku/Ka oppure V SAT, oppure una rete locale aziendale LAN, oppure una rete territoriale WAN, oppure una qualsiasi rete di tipo internet supportante il protocollo IP Multicast.
  8. 8. Sistema secondo una o più delle rivendicazioni precedenti disposto per controllare l'audience di un determinato servizio diffuso in broadcast.
  9. 9. Sistema secondo una o più delle precedenti rivendicazioni, caratterizzato dal fatto di comprendere mezzi per il tracciamento di " Traitor" per mezzo di un sistema a chiave calcolata tramite chiave di scrambling differente per ciascun utente.
  10. 10. Sistema secondo la rivendicazione 9 caratterizzato dal fatto che il tracciamento di "Traitor” viene effettuato per mezzo di una consegna di chiavi all'utente a loro volta criptate tramite funzioni complesse personalizzate in modo differente per ciascun utente.
  11. 11. Sistema secondo una o più delle precedenti rivendicazioni caratterizzato dal fatto di comprendere sul lato utente un hardware dedicato per l'operazione di decrypt eventualmente realizzato mediante un microchip, o circuteria elettronica equivalente.
  12. 12. Sistema secondo una o più delle precedenti rivendicazioni, caratterizzato dal fatto che ciascun utente può accedere "on-demand" anche solo a porzioni di dati di contenuto diffusi in Broadcast, secondo il suo interesse, fino alla granularità relativa alla porzione di tempo posta in corrispondenza biunivoca con la chiave associata alla porzione di contenuto stessa.
  13. 13. Sistema secondo una o più delle precedenti rivendicazioni caratterizzato dal fatto che consente il controllo della audience di un contenuto diffuso in Broadcast fino al dettaglio della porzione di tempo posta in corrispondenza biunivoca con la chiave associata alla porzione di contenuto stessa.
  14. 14. Sistema "on-line" di accesso condizionato e controllo della audience per servizi di comunicazione di tipo broadcast e multicast secondo una o più delle rivendicazioni precedenti e sostanzialmente come illustrato e descritto in riferimento alle figure dei disegni allegati.
IT2000RM000333A 2000-06-21 2000-06-21 Sistema on-line di accesso condizionato e controllo dell'audienceper servizi di comunicazione di tipo broadcast e multicast. IT1316201B1 (it)

Priority Applications (5)

Application Number Priority Date Filing Date Title
IT2000RM000333A IT1316201B1 (it) 2000-06-21 2000-06-21 Sistema on-line di accesso condizionato e controllo dell'audienceper servizi di comunicazione di tipo broadcast e multicast.
PCT/IT2001/000315 WO2001099029A2 (en) 2000-06-21 2001-06-15 On-line system including conditional access and audience control for broadcast and multicast communication services
EP01949874A EP1292873A2 (en) 2000-06-21 2001-06-15 On-line system including conditional access and audience control for broadcast and multicast communication services
AU2001270985A AU2001270985A1 (en) 2000-06-21 2001-06-15 A on-line system for conditional access and audience control for communication services of the broadcast and multicast kind
US10/311,767 US20030169885A1 (en) 2000-06-21 2001-06-15 On-line system for conditional access and audience control for communication services of the broadcast and multicast kind

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
IT2000RM000333A IT1316201B1 (it) 2000-06-21 2000-06-21 Sistema on-line di accesso condizionato e controllo dell'audienceper servizi di comunicazione di tipo broadcast e multicast.

Publications (3)

Publication Number Publication Date
ITRM20000333A0 ITRM20000333A0 (it) 2000-06-21
ITRM20000333A1 true ITRM20000333A1 (it) 2001-12-21
IT1316201B1 IT1316201B1 (it) 2003-04-03

Family

ID=11454795

Family Applications (1)

Application Number Title Priority Date Filing Date
IT2000RM000333A IT1316201B1 (it) 2000-06-21 2000-06-21 Sistema on-line di accesso condizionato e controllo dell'audienceper servizi di comunicazione di tipo broadcast e multicast.

Country Status (5)

Country Link
US (1) US20030169885A1 (it)
EP (1) EP1292873A2 (it)
AU (1) AU2001270985A1 (it)
IT (1) IT1316201B1 (it)
WO (1) WO2001099029A2 (it)

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6839436B1 (en) * 2000-10-16 2005-01-04 Lucent Technologies Inc. Method for providing long-lived broadcast encrypton
US7505593B2 (en) * 2002-12-09 2009-03-17 International Business Machines Corporation Method for tracing traitors and preventing piracy of digital content in a broadcast encryption system
US9520993B2 (en) * 2001-01-26 2016-12-13 International Business Machines Corporation Renewable traitor tracing
EP1418758B1 (de) 2002-10-29 2010-03-31 Volkswagen AG Verfahren und Vorrichtung zum Informationsaustausch sowie entsprechendes Computerprogramm-Erzeugnis und entsprechendes computerlesbares Speichermedium
US7702904B2 (en) * 2002-11-15 2010-04-20 Nec Corporation Key management system and multicast delivery system using the same
US7050785B2 (en) * 2003-12-08 2006-05-23 Research In Motion Limited Apparatus and method of explicit indication of call from emergency call centre
US20060031873A1 (en) * 2004-08-09 2006-02-09 Comcast Cable Holdings, Llc System and method for reduced hierarchy key management
US7630497B2 (en) * 2005-09-19 2009-12-08 International Business Machines Corporation System and method for assigning sequence keys to a media player to enable hybrid traitor tracing
US7711114B2 (en) * 2005-09-19 2010-05-04 International Business Machines Corporation System and method for assigning sequence keys to a media player to enable flexible traitor tracing
DE102006006633A1 (de) * 2006-02-10 2007-08-16 Sia Syncrosoft Verfahren zur Verbreitung von Contents
CA2645990C (en) 2007-12-20 2014-07-29 Bce Inc. Contact-less tag with signature, and applications thereof
US8108928B2 (en) * 2008-06-20 2012-01-31 International Business Machines Corporation Adaptive traitor tracing
US8122501B2 (en) * 2008-06-20 2012-02-21 International Business Machines Corporation Traitor detection for multilevel assignment
US8422684B2 (en) * 2008-08-15 2013-04-16 International Business Machines Corporation Security classes in a media key block
WO2010069033A1 (en) 2008-12-18 2010-06-24 Bce Inc Validation method and system for use in securing nomadic electronic transactions
US20120102322A1 (en) 2008-12-18 2012-04-26 O'brien William G Processing of communication device signatures for use in securing nomadic electronic transactions
US8571209B2 (en) 2009-01-19 2013-10-29 International Business Machines Recording keys in a broadcast-encryption-based system
US8893210B2 (en) * 2010-08-20 2014-11-18 Sony Corporation Server load balancing for interactive television
US10475144B2 (en) 2016-02-26 2019-11-12 Microsoft Technology Licensing, Llc Presenting context-based guidance using electronic signs
US10469997B2 (en) 2016-02-26 2019-11-05 Microsoft Technology Licensing, Llc Detecting a wireless signal based on context
US10452835B2 (en) 2016-06-30 2019-10-22 Microsoft Technology Licensing, Llc User-management of third-party user information

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5978482A (en) * 1995-08-21 1999-11-02 International Business Machines Corporation Method and system for protection of digital information
US5638445A (en) * 1995-09-19 1997-06-10 Microsoft Corporation Blind encryption
US5937067A (en) * 1996-11-12 1999-08-10 Scientific-Atlanta, Inc. Apparatus and method for local encryption control of a global transport data stream
JP4053628B2 (ja) * 1997-06-13 2008-02-27 インターシア ソフトウェア エルエルシー 電子透かしを利用するデジタルコンテンツ管理システム
AU8670598A (en) * 1997-08-01 1999-02-22 Scientific-Atlanta, Inc. Verification of the source of program of information in a conditional access system
EP1062812B1 (en) * 1998-03-16 2005-05-25 Intertrust Technologies Corp. Streaming media player with continuous control and protection of media content
CA2334203C (en) * 1998-06-04 2004-01-27 Imagictv Inc. Television delivery system
US6957330B1 (en) * 1999-03-01 2005-10-18 Storage Technology Corporation Method and system for secure information handling
EP1109405A1 (en) * 1999-12-16 2001-06-20 CANAL+ Société Anonyme Communication with receiver/decoder

Also Published As

Publication number Publication date
AU2001270985A1 (en) 2002-01-02
IT1316201B1 (it) 2003-04-03
WO2001099029A2 (en) 2001-12-27
WO2001099029A3 (en) 2002-04-11
US20030169885A1 (en) 2003-09-11
EP1292873A2 (en) 2003-03-19
ITRM20000333A0 (it) 2000-06-21

Similar Documents

Publication Publication Date Title
ITRM20000333A1 (it) Sistema on-line di accesso condizionamento e controllo dell'audience per servizi di comunicazione di tipo broadcast e multicast.
Naor et al. Threshold traitor tracing
CN1976277B (zh) 无状态接收机的广播加密和密钥撤销方法
US6735313B1 (en) Cryptographic method and apparatus for restricting access to transmitted programming content using hash functions and program identifiers
US6915434B1 (en) Electronic data storage apparatus with key management function and electronic data storage method
Chor et al. Tracing traitors
US7599497B2 (en) Key management protocol
Judge et al. WHIM: Watermarking multicast video with a hierarchy of intermediaries
US20060179489A1 (en) Conditional access system for digital data by key decryption and re-encryption
JP2005512468A (ja) ブロードキャスト・コンテンツへのアクセス
KR20020026547A (ko) 데이터 분산방법
JP2008512924A (ja) 限定受信を提供する方法
US20080219436A1 (en) Method and apparatus for providing a digital rights management engine
ES2404041T3 (es) Sistema y método para proporcionar acceso autorizado a contenido digital
US8468341B2 (en) System and method for content distribution with broadcast encryption
CN103081493B (zh) 用于保护隐私的广告选择的系统和方法
KR20110111256A (ko) 방송 서비스의 암호화 키 관리 방법 및 시스템
ES2270494T3 (es) Sistema de comunicacion de datos.
CA2318452A1 (en) Method and apparatus for conveying a private message to selected members
ES2235895T3 (es) Metodo y dispositivo para controlar la integridad y la autenticidad de un conjunto de datos.
US7539313B1 (en) System and method for key management across geographic domains
JP4447908B2 (ja) 新しい装置を導入するローカルデジタルネットワーク及び方法と、そのネットワークにおけるデータ放送及び受信方法
US20220407690A1 (en) Key ladder generating a device public key
CN109429106A (zh) 点播影院专业数字电影放映机播控系统
KR102516004B1 (ko) 영상 파일의 키 관리 시스템 및 키 생성 방법