WO2016110718A1

WO2016110718A1 - Digital television broadcast data stream authentication

Info

Publication number: WO2016110718A1
Application number: PCT/GB2016/050051
Authority: WO
Inventors: David Alan SHAW; Nicholas Birch
Original assignee: Strategy & Technology Limited
Priority date: 2015-01-08
Filing date: 2016-01-08
Publication date: 2016-07-14
Also published as: GB2534133A; GB201500293D0

Abstract

A digital television broadcast data stream authenticator (104) is configured to provide an indication of authenticity of a data stream (105) to be broadcast as a digital television broadcast stream. A hash algorithm may be applied to subsets of the broadcast data stream to reduce the consequences of data loss. Alternatively, a synchronisation mark may be included in the broadcast data stream to enable authentication data for that stream to be sent via a different means, such as a web server (1304), and so allow the media data stream to be authenticated without requiring authentication data to be carried in the stream itself.

Description

DIGITAL TELEVISION BROADCAST DATA STREAM AUTHENTICATION FIELD OF THE INVENTION

The present invention relates to digital television broadcast data stream authentication.

BACKGROUND OF THE INVENTION Systems for receiving digital television broadcasts are well established with many millions of consumer terminals such as televisions and set top boxes deployed. These consumer devices often now have considerable functionality including video cameras and Internet access.

There has been little consideration of the vulnerability of consumer terminals to the injection of malicious signals in to the broadcast distribution. However, recent technical advances have made such injection more practical as the cost of devices to inject such signals have become significantly cheaper and with recent increased functionality of consumer terminals as described above there is increased benefit to inject such malicious signals. BRIEF SUMMARY OF THE INVENTION

The inventors of the present patent application have appreciated that injection of malicious signals into a digital television broadcast stream may be identified by authenticating the digital television broadcast. Indeed, the inventors of the present patent application have appreciated that a digital television broadcast may be authenticated. Several

arrangements are described below for carrying out the authentication.

The inventors of the present patent application have appreciated that small disturbances to broadcast digital media are not uncommon and that traditional cryptographic approaches for authenticating data rely on lossless transport mechanisms and may amplify small losses of data on non-error free transport mechanisms. Many millions of receivers for digital media broadcasts are already deployed. The inventors of the present patent application have appreciated that any approach to authenticating broadcast digital media is most useful if it can be added with small cost to existing digital media broadcasts to provide a benefit to new reception equipment while at the same time not disturbing existing reception equipment. They have also appreciated that adding significant additional signalling to the broadcast distribution may be

unacceptable due to the cost to carry the additional data or the practicality of adding data to an already full carrier.

Embodiments of the invention provide a method for adding messages to a digital media stream that allow its integrity to be authenticated by a receiving terminal in a manner that is both efficient and backward compatible while at the same time mitigating the impact of broadcast data losses. These attributes allow this authentication to be added to existing digital media streams for the benefit of new receiving terminals and the possibility of retrofitting the authentication capability to already deployed receiving terminals with either a software upgrade or a hardware module while not disturbing receiving terminals that have not been upgraded.

Embodiments of the invention make it practical for a receiving terminal to authenticate that a digital media stream has not been modified since it was generated by a trusted party. This allows the receiving terminal to alter its behaviour if it determines that the digital media stream it is receiving has been modified. For example, the receiving terminal may reject the media stream until it is again able to authenticate its integrity. This enables the receiving terminal to be protected against malicious modification of a digital media stream that could cause harm to the receiving terminal or the consumer using it.

Embodiments of the invention provide a method for receiving terminals to obtain authentication information synchronised to the data stream from a second source such as a trusted internet server and thus authenticate a broadcast data stream without requiring that the authentication information is carried in the broadcast data stream.

Embodiments of the invention provide authentication for specific components of a TV service or digital television broadcast data stream. Embodiments of the invention provide for one or more specific components of a TV service to be authenticated as an alternative to providing authentication of the whole data stream. In certain circumstances, this is more practical to implement than authenticating the whole data stream.

Embodiments of the invention provide backward compatible authentication of media streams conveyed over an unreliable unidirectional transport. Embodiments of the invention provide authentication of media streams with minimal in- band data using intrinsic synchronisation references. Embodiments of the present invention are described and illustrated in the form of a digital data distribution system, digital data distribution method, a signer or authenticator, a validator or verifier, a computer program, a computer-readable medium, and a digital television broadcast data stream are described. A hash algorithm may be applied to subsets of the broadcast data to reduce the consequences of data loss. If a single hash is applied over all of the data to be

authenticated, any data loss/corruption in the broadcast (however small) causes all of the data to fail authentication. As a signing algorithm can sign several hashes in a single signature, a useful gain is available without increasing the amount of data that needs to be broadcast.

Embodiments of the present invention provide cryptographic authentication of the integrity of broadcast digital media.

Embodiments of the present invention provide cryptographic authentication of the integrity of a unidirectional data stream sent via an unreliable transport such as broadcast digital media while mitigating the effects of data losses or corruption that will tend to be amplified by typical authentication processes.

Embodiments of the present invention use a synchronisation mark in a media data stream to enable authentication data for that stream to be sent via a different means (such as a separate computer or computers in the form of a web server or servers) and so allows the media data stream to be authenticated without requiring authentication data to be carried in the data stream itself.

Advantageously, embodiments of the present invention do not require precisely timed capacity output, they may be implementable in a CA module, they may be backward compatible and/or they may only require a low data rate. The invention in its various aspects is defined in the independent claims below to which reference should now be made. Advantageous features are set forth in the dependent claims.

Arrangements are described in more detail below and take the form of a digital television broadcast data stream authenticator configured to provide an indication of authenticity of a data stream to be broadcast as a digital television broadcast stream. A hash algorithm may be applied to subsets of the broadcast data stream to reduce the consequences of data loss. Alternatively, a synchronisation mark may be included in the broadcast data stream to enable authentication data for that stream to be sent via a different means, such as a web server, and so allow the media data stream to be authenticated without requiring authentication data to be carried in the stream itself. BRIEF DESCRIPTION OF THE DRAWINGS

The invention will be described in more detail, by way of example, with reference to the accompanying drawings, in which:

Figure 1 is a schematic diagram illustrating the components of an embodiment of the invention required to generate and inject the authentication information in to a broadcast; Figure 2 is a schematic diagram illustrating the components of an embodiment of the invention required to extract the authentication information from a broadcast and then to authenticate the broadcast data;

Figures 3, 4, 5 are schematic diagrams illustrating in more detail an embodiment signing MPEG Transport Stream packets; Figure 6 is a schematic diagram illustrating in more detail an embodiment for authenticating previously signed MPEG Transport Stream packets;

Figure 7 is a schematic diagram illustrating a variation of the embodiment of Figure 6 that allows mitigation of the consequences of lost data;

Figures 8 and 9 are schematic diagrams illustrating an embodiment of the syntax for encoding signature and certificate tables as MPEG private sections compatible with most digital TV systems;

Figure 10 is a schematic diagram illustrating the components illustrated in Figure 2 embodied as a detachable module such as a Common Interface, CI Plus or CableCARD module; Figure 1 1 is a schematic diagram illustrating the syntax of the MPEG Transport Stream packet of an embodiment of the present invention;

Figure 12 is a schematic diagram illustrating a group of MPEG Transport Stream packets to be authenticated between markers in the MPEG Transport Stream or hash frame identified by subsequent PCR (Program Clock Reference) packets of an embodiment of the present invention;

Figure 13 is a schematic diagram illustrating an embodiment for gathering the

authentication information for digital media stream once it has been prepared for broadcast; Figure 14 is a schematic diagram illustrating an embodiment for a receiving terminal to authenticate a received digital media stream;

Figure 15 is a schematic diagram illustrating the components illustrated in Figure 14 embodied as a detachable module such as a Common Interface, CI Plus or CableCARD module; Figure 16 is a schematic diagram illustrating a modification of the embodiment of the invention in Figure 1. Here authentication information is generated and injected for a fraction of the broadcast data rather than being applied to the whole broadcast as is illustrated in Figure 1 ;

Figure 17 is a schematic diagram illustrating a modification of the syntax for encoding the signature table shown in Figure 8;

Figure 18 is a schematic diagram illustrating a modification of the embodiment of the invention for applying authentication to a broadcast data stream. Here authentication information is computed for at least some of the data in the stream between markers in the stream. This authentication information combined with the marker information is then conveyed in the stream in a signature message;

Figure 19 is a schematic diagram illustrating a modification of the embodiment of the invention for verifying authentication of a broadcast data stream generated in Figure 18; and

Figure 20 is a schematic diagram illustrating a syntax for the signature message applicable to the embodiment in Figures 18 and 19.

DESCRIPTION OF THE INVENTION

Various embodiments of a digital television broadcast data stream authenticator, a digital television broadcast data stream authenticating method, a digital television broadcast data stream verifier, a digital television broadcast data stream, as well as a computer program for carrying out the methods and a computer-readable medium containing a set of instructions that causes a computer to perform the methods will now be described with reference to Figures 1 to 20. The digital television broadcast data stream authenticator is implemented, at the transmitted end, by one or more computers. The digital television broadcast data stream authenticator is implemented, at the receiving end, by a set-top box, digital television receiver or by one or more computers or a detachable module such as a CI module. An appropriate computer program or software is provided on these devices to carry out the methods described. The computer-readable medium that contains the set of instructions to carry out the method may be a hard-disk drive, a CD-ROM, a DVD-ROM or a solid state memory device such as FLASH memory or a USB stick.

An embodiment of the elements required to generate and inject the authentication information in to a broadcast are shown in Figure 1. A secure equipment 101 holds the credentials provided by a certificate authority to the operator. In particular, this holds the private key issued to the operator for signing new signing certificates and a mechanism to generate a signing certificate and the associated private key. This secure equipment is operated periodically to generate a certificate chain and a private key for signing the broadcast data stream. The frequency at which this equipment is invoked to update at least the signing certificate and signing private key will depend on the key length and the security policy. There may be a period of months or perhaps years between updates. Using a shorter signing key and a more frequent updates may be appropriate if addressing reception equipment that has limited computational capacity.

Continuing in Figure 1 , up stream of one of the multiplexing stages 106 a message injector 102 has two responsibilities. Firstly it encapsulates and then periodically injects messages that convey the certificate tables. These are pseudo static only changing when the secure equipment 101 updates the signing certificate. Secondly message injector 102 generates and injects placeholder messages for signature table messages. The purpose of these placeholder messages is to reserve capacity in the assembled data stream 103 that can be simply replaced by the stream signer 104 or digital television broadcast data stream authenticator. Other embodiments of 102 and 104 are possible for example the broadcast system may natively have a capability for reserving capacity in the output 103 such as a specified rate of null packets. Alternatively digital television broadcast data stream authenticator 104 could be more complex and re-multiplex the stream 103 so that the stream 105 has a slightly higher data rate due to the addition of the signature table messages. The preferred embodiment is as shown in Figure 1 as the message injector 102 and stream signer 104 are comparatively simple to implement and their addition has low impact on an existing broadcast system.

In Figure 1 , multiplexers 106 and 107 are shown as separate items of equipment to emphasise that the message injector 102 could be quite remote from the final multiplexer 107 if that is convenient. However, multiplexers 106 and 107 (or indeed any number of intermediate multiplexers) could be conflated in to a smaller number of multiplexers or possibly a single multiplexer.

Continuing in Figure 1 , down stream of the final multiplexing stage 107 that assembles the broadcast ready data stream 103 is placed the stream signer 104. The stream signer or digital television broadcast data stream authenticator, at possibly irregular periods, computes a cryptographic signature, digital signature or indication of authenticity for the data stream 103 and encodes and encapsulates a signature table message. In the preferred embodiment, the signature table generation occurs when a place holder messages injected by 102 is detected in the data stream 103. The signature table message then replaces the placeholder message. The resulting stream 105 is thus equivalent to 103 but with the signature table messages replacing placeholder messages and providing a means of cryptographic authentication of the resulting stream 105.

The quantity of media data in a signature group can vary between signature groups. This allows signature table messages to be placed in the broadcast data stream at irregular intervals. This simplifies the implementation as the timing of the injection of the signature table message does not need to be tightly controlled. Instead the process for computing the signature table can occur when one or more suitable replaceable packets of data (such as a place holder packet or a null packet) is observed in media data at 103. This process can also be opportunistic. For example, if for a period there are more suitable replaceable packets of data then the signature table messages can be generated and injected more frequently which will benefit the tolerance of the data errors in the broadcast.

An embodiment of the elements required by a receiving terminal to extract the

authentication information from the broadcast distribution and then to use this information to authenticate the broadcast data are shown in Figure 2. The broadcast distribution 105 is as in Figure 1 but the data may have been degraded by transmission defects. The signature authentication or digital television broadcast data stream verifier 201 computes a cryptographic signature, digital signature or indication of authenticity of the broadcast data stream 105 in a similar manner to the stream signer 104 or digital television broadcast data stream authenticator in Figure 1 but authenticates the signature with the signer's public key. If the data is authenticated it can be passed 203 to the media decoder 204 as trusted data. If the authentication fails then the data is treated differently, for example, it is discarded and/or replaced with null packets. A second destination of the authenticated data 203 is the certificate capture module 205. This extracts certificate table messages and analyses the certificate chains they implement. By some mechanism the receiving terminal has previously had installed one or more trusted root certificates 207. The certificate capture module 205 evaluates the arriving certificate chains to see if they descend from these trusted roots and to see if the certificates supersede and update the previously cached certificates 206. The mechanism by which a receiving terminal has trusted root certificates 207 installed may depend on the market where the receiving terminal is deployed. For example, in some markets there may be a co-ordinating entity that certifies broadcasters and provides the trusted root certificates for that market. Alternatively, a receiving terminal may have an on-installation procedure where it acquires the root certificates from the broadcast (possibly after requesting user confirmation). The certificate capture module 205 provides the public key 208 from the current signing certificate to the signature authentication module 201 to enable it to authenticate broadcast data.

Exceptionally the signature authentication module 201 may pass un-authenticated data to the certificate capture module 205 to allow it to acquire certificates when the receiving terminal doesn't have current signing certificates cached. Accordingly, the implementation of these modules 201 and 205 should take care to ensure they are hardened against malformed or malicious data.

Figure 3 illustrates a preferred embodiment applied to MPEG Transport Stream data and providing some mitigation of data loss. MPEG Transport Stream data is conveyed as a stream of 188 byte packets 301. In the present invention a sequence of one or more such packets is termed a hash frame 302. This is a quantity of data over which a cryptographic hash or digest is computed and for which authentication can be provided.

A hash is a value returned by a hash function. A hash function maps digital data of arbitrary size to digital data of fixed size. A hash function or a cryptographic hash function easily allows verification that input data matches a stored hash value. However, it is very difficult to substitute different input data that yields the same hash value. The use of the hash value is to ensure no tampering rather than to provide privacy. In the present invention a sequence of one or more such hash frames preceding a signature table message is termed a signature group 303. The signature table message provides a cryptographic signature authenticating all or the sequence of the hash frames in that signature group. The signature table message from the preceding signature group is part of the data authenticated by the current signature group. As such every packet of the data stream is subject to authentication.

Figure 4 illustrates in more detail an embodiment of the process for computing the signature of a signature group. A signature group 401 is a sequence of MPEG Transport Stream packets divided in to hash frames. If there is more than one hash frame in a signature group all except the final hash frame contain the same number of MPEG

Transport Stream packets. The final hash frame may have a different length from the preceding hash frames in the signature group. A cryptographic hash or digest is computed for each hash frame in transmission order. The hash algorithm is initialised before computing the hash for each hash frame so that the hash bytes for a particular hash frame depend only on the packets in that hash frame. The hash bytes resulting from the hash computations on each hash frame are concatenated in the transmission order of the hash frames 402. This array of data 402 is then cryptographically signed 403 using a private key 404 resulting in a set of signature bytes 405.

Figure 5 illustrates a variation on Figure 4. The process to derive the concatenated hash bytes from hash frames of MPEG Transport Stream packets is identical. However, the concatenated hash bytes are apportioned between two or more signing processes. For example, there are 160 concatenated hash bytes 500 as SHA-256 has been used as the hash algorithm resulting in 32 bytes of hash data for each of 5 hash frames. The selected signature algorithm is RSA with a 1024 bit key with PKCS padding. This allows up to 1 17 bytes to be signed by one signature. Accordingly the 160 concatenated hash bytes are divided so that the first portion are signed by a first invocation of the signing process 501 resulting in a first set of signature bytes 502 and the second and remaining portion of the hash bytes are signed by a second invocation of the signing process 503 resulting in a second set of signature bytes 504. This illustrates how the invention can scale to work with different numbers of hash frames and different hashing and signing algorithms.

Figure 6 illustrates the process by which a receiving terminal or digital television broadcast data stream authenticator authenticates the received data. The packets of data that comprise the hash frames in the signature group 601 are processed by the hash algorithm 602 to yield a set of concatenated hash bytes 603 that should be the same as those computed in Figures 4 and 5. The signature bytes 604 are conveyed by the signature table message and then decrypted using the public key from the current and trusted signing certificate 605. This yields the authenticated concatenated hash bytes from the signature 606. Comparing the authenticated hash bytes 606 with the hash bytes derived from the broadcast data 603 allows the integrity of the received data to be authenticated.

Broadcast distribution of digital media is not guaranteed to be error free. Figure 7 illustrates a variation of the digital television broadcast data steam authenticator of Figure 6 that allows mitigation of the consequences of lost data. Here there are two instantiations of the authentication process carried out by the digital television broadcast data steam

authenticator. The first instantiation 701 operates a hash frame at a time starting at the beginning of the signature group and continues until the authentication for a hash frame fails. The second instantiation of the authentication process 702 operates if the first instance stopped before attempting to authenticate all hash frames. This second instantiation operates a hash frame at a time starting at the last hash frame of the signature group working towards a the beginning of the signature group and stopping if either a hash frame fails authentication or it has inspected all hash frames not inspected by the first authentication instantiation.

In the illustration in Figure 7 there is a defect somewhere in the third hash frame

(numbered 2). For the first authentication instantiation 701 the first two hash frames authenticate successfully but the third fails authentication. The second authentication instantiation 702 then authenticates the final two hash frames. Thus, in this case, 4 of the 5 hash frames pass authentication and only one frame is considered untrustworthy due to the authentication failure. Thus the quantity of data lost is greatly reduced compared to using a single hash and signature for the whole signature group. This improvement requires no additional transmission cost.

It is apparent that other implementations of the above error mitigation are possible. For example, the instantiation 702 could be operated first with instantiation 701 second if required.

Figure 8 shows an embodiment of the signature table using the MPEG private section syntax which can be encapsulated in MPEG Transport Stream packets and is suitable for use in many digital TV broadcasting systems. This uses is the "pseudo 'C'" notation common in the MPEG 2 specifications such as ISO/I EC 13818-1. The hash_frame_count, hash_frame_length and signature_group_length fields convey the subdivision of the data stream in to signature groups and hash frames. The hash_type field conveys the cryptographic hash algorithm being used. The certificate_count conveys the number of different signing certificates that have provided signatures. For each signing certificate there is a certificate_id field, this conveys a reference to the signing certificate in the certificate table and thus identifies the public key required to decrypt the signature(s). The signature_type field conveys the signing algorithm and infers the signaturejength. The signature_count field conveys the number of cryptographic signatures used to sign the hash bytes. The signed_hash_byte_count field conveys the number of hash bytes signed by this signature. With reference to Figure 5 this conveys the apportionment of

concatenated hash bytes from 500 in to each of the sets of signature bytes 502 and 504. The signature_byte field conveys the signature bytes.

Figure 9 shows an embodiment of the certificate table using the MPEG private section syntax. The certificate_id field identifies the certificate chain carried by this table. The certificatejength value is inferred from the section length. The certificate_byte field conveys the certificate data.

Figure 10 illustrates the components illustrated in Figure 2 embodied as a detachable module such as a Common Interface, CI Plus or CableCARD module. These module specifications define a standard interface for the receiver 1001. If a compatible module is connected the whole received data stream is output to the module over connection 1003 and accepted back over connection 1004. The illustrated module 1002 implements the stream authentication functions so that the output stream on interface 1004 only carries trusted data. This option allows a stream authentication to be retrofitted to an existing receiving terminal by attaching a module to a standard interface.

An alternative digital data or digital television distribution system is illustrated in Figures 1 1 to 15.

The syntax of the MPEG Transport Stream packet is illustrated in Figure 11. The MPEG Transport Stream is composed of 188 bytes Transport Stream (TS) Packets. The Packet Identifier field (PID) discriminates streams of data within the Transport Stream. Packets can include the Adaptation Field which can include the Program Clock Reference (PCR) field 1 100. Formally this field carries the value of a clock at the moment the packet was emitted. For each TV or radio service there is exactly one PID that carries the packets that carry the PCR that define the timebase for that service. In a compliant stream for each service that has a PCR there will packets carrying the PCR at least every 100 ms.

The PCR provides a convenient synchronising mark for a position in the TS. There are other clocks available in the MPEG Transport Stream such as the Presentation Time

Stamp (PTS) or alternatively a synchronising mark could be added to the Transport Stream with little or no additional data. Using the PCR to provide a synchronising mark in the MPEG Transport Stream is the preferred embodiment.

Figure 12 illustrates how a hash frame is defined as the packets of the Transport Stream between two packets carrying the PCR for a nominated TV service. In the preferred embodiment the hash frame includes the PCR packet at the beginning of the hash frame 1201 and the hash frame ends in the last packet before the subsequent PCR packet with the same PID 1202.

A cryptographic hash is computed for the hash frame. The PCR value in the packet immediately after the hash frame 1202 provides an identifier to relate the hash value to this position in the data stream.

Figure 13 illustrates the components for generating and storing hash data at a point where the data stream has been assembled and is ready to be broadcast. A multiplexer 1301 does the final assembly of the Transport Stream 1302 so that it is ready to be broadcast. A process 1303 or digital television broadcast data stream authenticator observes the

Transport Stream 1302 and computes the hash for the hash frames on a nominated PID (the PCR PID of a nominated service) and extracts the PCR value.

The hash values generated by 1303 and the marker values (for example the PCR values) that identify the positions in the stream that the hash frame applies to are stored on a computer or Web Server 1304, for example, as a series of (marker, hash) tuples 1305.

Figure 14 illustrates the components for authenticating a broadcast data stream 1302 at a receiving terminal or digital television broadcast data stream verifier. The received broadcast data is quarantined 1401 and concurrently subject to the hash computation of the hash frames on the nominated PID and extraction of the PCR (or other marker) values 1402. Periodically 1402 makes a request 1403 to the computer or Web Server 1304 to request the hash values for one or more hash frames and the marker value(s) to identify the hash frame(s) of interest.

In the embodiment in Figure 14 this request is made using a secure communication technology such as TLS (transport layer security) 1405 where the communication is only allowed to servers with certificates that descend from trusted roots 1406 that were previously stored in the receiving terminal. Alternatively the hash and marker values could be signed by a trusted private key allowing a non-secure communication technology to be used. The reply 1404 from the Web Server 1304 provides hash and PCR (or other marker) values for one or more hash frames identified by the PCR values in the request 1403. The Hash Verification 1402 then compares the hash values in this reply 1404 with those computed from the received broadcast data. Where the hash values match the data is deemed authenticated and can be released from quarantine 1407 and supplied to the Media Decoder of the receiver 1408. Data that does not authenticate is treated differently.

The receiver implementation could authenticate all of the received data. For example, requests 1403 once per second for all of the hash values in that second.

Alternatively the receiver implementation could authenticate data on a sample basis. For example the implementation could make smaller or less frequent requests or make requests at irregular or randomised intervals. This would reduce the stress on the communication between receiving terminal and the Web Server 1304. Alternatively or additionally an authentication sample could be performed following an event such as the user changing the channel that the receiving terminal is consuming or if there is an interruption in the broadcast signal 1302 that the receiver is receiving. Figure 15 presents a variation of Figure 10 where the receiving terminal authentication functions illustrated in Figure 14 are be embodied in detachable module such as Common Interface module. The received broadcast signal is passed from the receiving terminal 1001 to the module 1501 over the interface 1003 and then returned if authenticated over interface 1004. The trusted internet communications from the module 1501 to the web server 1304 are carried over the low speed communications interface 1502 of the Common Interface. Figure 16 illustrates a modification of the embodiment of the invention of Figure 1. Each data stream authenticator 1601 processes one or more fractions of the whole data stream 1602. There may be a plurality of such data stream authenticators each independently acting on different fractions of the whole data stream. An example use of this might be for a TV service that includes an interactive application as one aspect. Here the fraction subject to authentication might be the signalling and/or broadcast file system that conveys this interactive application. In Figure 16 the source of this fraction to be authenticated is the data streamer 1603. The output of the data streamer 1603 is processed by the data stream authenticator 1601 within which the signature table generator 1604 generates the authentication information which is combined with the fraction of the data to be authenticated and certificate messages by the multiplexer 1606 to form an authenticated fraction of the broadcast 1607. A subsequent multiplexer 1608 then combines this authenticated fraction 1607 with other fractions.

Figure 17 illustrates a modified syntax for the signature table. This modified form includes an extra_component_count field which allows a list of zero or more additional TV service components to be conveyed. Additionally the scope of authentication is modified. For example, authentication applies just to packets with the same PID value as that carrying the signature table and packets of the extra_component_count other TV service components identified by the component_tags listed in the signature table. The computation of the hash values may also be modified in this alternative embodiment. For example rather than computing the hash value using all of the bytes of each MPEG Transport Stream packet it may be computed just on a selected fraction of each packet. For example, the PID field (see 1 101 in Figure 1 1) of each packet may be masked to allow the PID value to be modified by re-multiplexing after the authentication indication is computed. Alternatively the hash value may be computed on the MPEG Sections carried in the payload of the MPEG Transport Stream packets. In this case sections are

authenticated rather than packets.

This form (Figure 17) of the signature table is suitable for implementing authentication of a specific fraction of an MPEG Transport Stream as illustrated in Figure 16. Figure 18 illustrates a modification of the embodiment of the invention in Figures 1 and 13. Each data stream authenticator or digital television data stream authenticator 1802 processes at least some of the whole data stream 1803. There may be a plurality of such data stream authenticators each independently acting on different fractions of the whole data stream. The marker detection and hash computation function 1804 observes the appropriate fraction of the stream 1803 and computes the hash of the appropriate fraction of the data between selected markers in the data. The result is sequence of marker values and the hash values applicable to the position in the stream identified by that marker 1805. For example, a sequence of tuples of PCR value and hash value. One or more items in this sequence are then concatenated and then signed with a trusted private key and encoded in to a signature message by the signature table generator 1806. The resulting signature messages are then combined with certificate messages and other broadcast data and possibly the outputs of other data stream authenticators by one or more multiplexers 1808, 1809 etc.

The markers between which the hash data is computed may be immediately consecutive in the data stream or may optionally be less frequent or irregularly frequent. For example, if the markers are packets with a selected PID value carrying PCR values then consecutive such packets might be used as markers or alternatively a subset of the possible PCR packets might be used. For example, every third possible PCR packet might be used or the first possible PCR packet observed some time delay after the previous selected PCR packet. These choices alter the size of the hash frame and the frequency with which signature messages are generated.

In summary, the data stream is observed and an indication of authenticity is calculated between markers in the stream data formed that relates the indication of authenticity to the markers. A trusted indication of authenticity is injected into the stream. For example, the data that is signed by the signature message is a concatenated plurality of (marker, hash) tuples. This arrangement may be applied to all or a subset of the stream. The hash may not be computed between every marker. Instead, the hash may be computed between a subset of the markers. For example, rather than computing between a marker and then the next one, it is computed between every third marker. As a result, the "hash frame" is longer and there are fewer hash frames.

Figure 19 illustrates a modification of the embodiment of the invention in Figures 2 and 14. The received signature tables are decoded and verified 1901 from the received broadcast data 1803 using public keys from the previously installed trusted certificates 1902. This yields a sequence of trusted hash value and associated marker value information 1903. The hash computation and verification function or digital television broadcast data stream verifier 1904 receives this trusted hash value and associated marker value information 1903 and computes the hash values between the portions of the received broadcast data stream 1803 identified by the markers notified 1903 and compares these hash values with the trusted hash values 1903. Any portion of the data stream for which the hash value computed from the received data matches the trusted hash values delivered by a signature message can be considered authenticated and released from quarantine 1905. Any portion of the data stream for which the hash values do not match or for which there is no trusted hash information provided by a signature message can be considered to have failed authentication and can be treated differently.

Figure 20 illustrates a syntax for the signature message applicable to the embodiment in Figures 18 and 19. This removes the hash_frame_count, hash_frame_length and signature_group_length fields from the syntax in Figure 17 as the structure of the hash frames is delimited by the markers. Also, the signed_hash_byte_count is now

signed_byte_count as the data signed is now concatenated tuples of (marker value, hash bytes).

The system described with reference to Figures 18 to 20 has many technical advantages. The outgoing data stream is observed, but it is not modified. As a result, the system is simple to build. The trusted indication of authenticity can be injected up-stream in a non- time critical manner like the certificate messages. It is another data injection task that is easy to do. The data error mitigation method described above can be used as one signature message can convey separate indications of authenticity for a plurality of fractions of the data. In this way, all data may not all be lost if there is a small corruption. Furthermore, advantageously no internet connection is required. By choosing which markers are the boundaries of hash frames, the rate at which signature messages are generated can be regulated and thus a trade-off between granularity and bit rate may be made.

Embodiments of the invention are described in more detail below that take the form of the system for authenticating a broadcast DVB (digital video broadcast) transport stream forming a so called Trusted TS (transport stream).

There are two components to the trusted TS scheme: signing the TS data; and providing the certificate that was used for signing. Two message types are defined to support this: signature tables and certificate tables. These are carried on two "well known" PIDs or packet identifiers

Table 1 : PID allocation for trust signalling

SIGNING THE DATA

Signature tables are inserted periodically in to the TS. Each signature table carries a set of signed hashes of TS packets. The packets from the first packet of a signature table up to and including the last packet before the start of the subsequent signature table is termed a signature group. This is the set of packets is cryptographically authenticated by the signature table that follows the signature group.

The packets in a signature group are divided into one or more "hash frames". Each hash frame is a sequence of TS packets for which a cryptographic digest is computed. This division of signature group in to hash frames allows a degree of damage limitation if packets are lost (e.g. due to transmission defects) within a signature group.

The signature table carries: a single hash value for each hash frame; and one or more signatures computed across the hash values as illustrated in Figure 3.

A signature table that is transported on multiple Transport Packets may be interleaved with the payload packets of other PID values. These packets (both signature and payload) are part of the subsequent hash group. Verification of a signature group can only start once a signature table has been assembled. System profiling may wish to constrain the distribution of the signature packets through the signature group as this defines the latency that the receiving device must support. Also, if packets of the signature table are carried in multiple hash frames this removes the packet loss mitigation benefit of having multiple hash frames. Having the packets for a signature table consecutive or close together is beneficial.

Advantageously, null packets (and stuffing sections) may be filled with high entropy payloads so as not to weaken the digest algorithms. CERTIFYING THE DATA

Signature tables reference signing certificates via a certificate_id. The certificates are carried in one or more certificate tables.

The scope of this certificate_id is a set of transport streams that share a common network_id. The set of transmitted certificate tables and their relationship with the certificate_id is pseudo static. These constraints allow the certificate tables :to be transmitted at low repetition rate assuming persistent caching by the receiver; used on multiple Transport Streams (i.e. a single trust entity could sign multiple Transport Streams within a network); and cross carried on multiple Transport Streams in a network A network may have more than one signing certificate. Support for multiple certificates allows: more than one trusted entity to operate within a single network (a network might have two or more multiplex operators who each sign the Transport Streams that they emit); and migration between signing certificates

CERTIFICATE RENEWAL

Certificates are not renewed while they are actively in use for signing in a network. The procedure for certificate renewal is as follows:

Old certificate with certificate_id value 'A' is in use signing data in the network. The certificate 'A' is being transmitted in the network. In parallel to certificate 'A' transmit a new certificate with a certificate_id set to a currently unused value 'Β'. The transmission of certificate 'B' starts sufficiently before the planned use of the certificate that receivers in normal use have adequate opportunity to acquire and persistently store it. Start using this new 'B' certificate for signing and stop all use of the old 'A' certificate for signing in the network. Start transmitting an updated version of the 'A' certificate table with an

incremented version_number and an empty payload. This transmission continues for a period sufficient that receivers in normal use have adequate opportunity to remove or inactivate the 'A' certificate from their persistent store. If at a future date the broadcaster choses to re-use the certificate_id value 'A' it is introduced with a version number that either has never been used for that certificate_id or is the least recently used version number for that certificate_id. Receivers should periodically verify that the certificates that they have stored for a particular network_id + protocol_version + certificate_id matches the certificate being broadcast.

PROTOCOL VERSION

Part of the table id extension in each table is used to signal the protocol version. More than one protocol version may be present in a stream. A receiver only considers sections associated with one protocol version (preferably the most advanced) and ignores all others.

SIGNATURE TABLE

Table 2: signature section syntax

Syntax Bits Type signature section ( ) {

table id 8 uimsbf section syntax indicator 1 bslbf reserved future use 1 bslbf reserved 2 bslbf section length 12 uimsbf reserved 8 bslbf protocol version 8 uimsbf reserved 2 bslbf version number 5 uimsbf current next indicator 1 bslbf section number 8 uimsbf last section number 8 uimsbf hash type 8 uimsbf hash frame count 8 uimsbf hash frame length 16 uimsbf signature group length 16 uimsbf certificate count 8 uimsbf for <i=0; i<certificate count; i++) {

certificate id 8 bslbf signature type 8 bslbf signature count 8 uimsbf for ( j=0; j<signature count; j ++ ) {

signed iash byte count 16 uimsbf for( k= 0; k<signature length; k++ ) {

signature byte 8 bslbf

CRC 32 32 rpchof

Semantics of the signature section: table_id: The value [0x7B] identifies this table. section_syntax_indicator: The section_syntax_indicator is a 1-bit field which is set to "1 ". sectionjength: This is a 12-bit field. It specifies the number of bytes of the section, starting immediately following the sectionjength field and including the CRC. The sectionjength does not exceed 4093 bytes so that the entire section has a maximum length of 4096 bytes. protocol_version: This 8-bit field conveys the protocol version. Sections conforming to the specification in the present document set this field to the value zero. Receivers ignore and treat as non trusted signature sections that signal a protocol version that they do not support. version_number: This 5-bit field is the version number of the table. This increments in each successive signature table with the protocol version. current_next_indicator: This is set to "1". section_number: This 8-bit field gives the number of the section. The section_number of the first section in the table is "0x00". The section_number is incremented by 1 with each additional section with the same table_id. last_section_number: This 8-bit field specifies the number of the last section (that is, the section with the highest section_number) of the table of which this section is part. hash_type: This 8-bit field encodes two independent 4-bit fields that control how hash data is computed. The low 4-bits of the 8-bit field is an enumeration that identifies the hash algorithm used and the hashjength value associated with that algorithm. The upper 4-bits of the 8-bit field is an enumeration that identifies the method by which data is selected for hashing.

Table 3: Hash type encoding of hash algorithm

Table 4: Hash type encoding of data selection

hash_frame_count: This 8-bit field conveys the number of hash frames in this signature group. This value shall be at least 1. The hash frame count may be the same or different in consecutive signature groups. hash_frame_length: This 16-bit field conveys the number of 188 byte TS packets in each hash frame up to but not including the final hash frame. The final hash frame in a signature group may be shorter or longer than this value as the final hash frame terminates with the last packet before the first packet of the signature table. If hash frame count has value 1 then the hash frame length is set to signature group length. The variable length final hash frame allows some implementation flexibility for the signature table injection. For example, replacing packets whose position in the stream cannot be exactly predicted. signature_group_length: This 16-bit field conveys the number of 188 byte TS packets in each signature group.

The signature group length may have a value different from hash_frame_count * hash_frame_length due to the variable length of the finale hash frame. certificate_count: This 8-bit field conveys the number of different signatures that have been used to sign this signature group. This value shall be at least 1. certificate_id: This 8-bit field identifies the certificate signs the signature that follows. This value corresponds to the certificate_id of one certificate table.

The certificate_id is unique within the network (i.e. the set of Transport Streams with the same network_id) and the protocol_version. signature_type: This 8-bit field is an enumeration identifying the signature algorithm. The signaturejength is a consequence of the signature_type. Table 5: Signature type values

signature_count: This 8-bit field conveys the number of signatures used to sign the hash data of this signature group. This value is at least 1. signed_hash_bytes_count: This 16-bit field conveys the number of hash bytes signed by the following signature. This value is at least 1. signature_byte: These 8-bit bytes form a octet string with length specified by

signaturejength. This conveys the binary representation of the signature resulting from signing signed_hash_bytes_count hash bytes with the certificate specified by the preceding certificate_id.

The hash bytes resulting from hashing hash frames are signed in the transmission order of the hash frames. So, for each certificate_id the first signature applies to the earliest hash frame(s) in the signature group. For example, if the hash frame count for the signature group is 5 and the selected hash type is 1 (SHA-1) then 5 hashes each of 20 bytes length are produced. These are concatenated in to a 100 byte octet string. If the selected signature type is 1 (RSA 512) then at most 53 bytes can be signed by each signature. So, at least 2 signatures are required. For example, the first 50 hash bytes signed by the first signature and the remaining 50 bytes by the second signature. The field signed_hash_bytes_count signals how many bytes are signed by each signature. SIGNATURE TABLE - ALTERNATIVE VERSION

Table 6: signature section syntax

Semantics of this alternative signature section:

As for the previous signature table syntax with the following additional/modified semantics: extra_component_count: This 8-bit field defines the number (zero or more) of 8-bit component_tag values that follow this field. component_tag: These 8-bit fields each specify the component tag of additional TV service components that are authenticated by this signature table. As a minimum, this signature table provides authentication for data conveyed by packets with the same PID value as the packets that carry this signature table. The

extra_component_count field allows data conveyed by packets of zero or more additional TV service components to also be authenticated. CERTIFICATE TABLE

The certificate table carries certificate chains for the certificate used to sign Transport Stream data.

Each certificate section carries a single X.509 certificate. Sections with a common certificate_id and protocol_version are a sub-table carrying a single certificate chain. Each chain includes the signing (leaf) certificate, the root certificate and all the intermediate certificates in the certificate chain. The section's section_number provides the position of the certificate in the certificate chain:

Table 7: Order of certificates in sub table

Table 8: certificate table syntax

Semantics of the certificate section:

table_id: The value [0x7C] identifies this table. section_syntax_indicator: The section_syntax_indicator is a 1-bit field which is set to "1 ". sectionjength: This is a 12-bit field. It specifies the number of bytes of the section, starting immediately following the sectionjength field and including the CRC. The sectionjength shall not exceed 4093 bytes so that the entire section has a maximum length of 4096 bytes. certificatejd: This 8-bit field identifies the certificate carried in this table.

The certificatejd is unique within the network (i.e. the set of Transport Streams with the same networkjd) and protocol version. protocol_version: This 8-bit field conveys the protocol version. Sections conforming to the specification in the present document set this field to the value zero.

Receivers ignore certificate sections that signal a protocol version that they do not support. version_number: This 5-bit field is the version number of the table. This is incremented if the certificate is updated.

The semantic of changing the version number is that the previous version of the certificate is no longer in use for signing in this network. By implication receivers that cache these certificates remove the old version of the certificate and acquire and store the new version.

The certificate version number is not incremented while the network is using that certificate for signing. current_next_indicator: Set to "1". section_number: This 8-bit field gives the number of the section. The section_number of the first section in the table is "0x00". The section_number is incremented by 1 with each additional section with the same tablejd, certificatejd and protocol_version that forms part of the sub-table that carries a particular certificate chain.

See Table 7: Order of certificates in sub table last_section_number: This 8-bit field specifies the number of the last section (that is, the section with the highest section_number) of the table of which this section is part. certificate_byte: These 8-bit bytes form an octet string that fills the remainder of the section up to the CRC. These convey a single X.509 certificate file.

An empty certificate byte field (certificate length is zero) signals that the certificate previously signalled with this certificate_id is no longer in use in this network and the receiver may remove it from its certificate cache. The section version number changes when the section is updated to carry and empty certificate after previously carrying a nonempty certificate.

When the leaf/signing certificate is being broadcast as an empty certificate all of the sections in this sub-table (i.e. all of the certificates in this certificate chain) are broadcast as empty certificates.

Receiving terminals do not trust packets signed by an empty certificate. The

certificatejength is inferred from the sectionjength and the section syntax.

HASH AND SIGNATURE COMPUTATION

The hash algorithm selected by the hash type is applied to the transport packets of each hash frame in turn. This results in a set of hash bytes for each hash frame. The hash algorithm is initialised before computing the hash bytes for each hash frame.

The hash bytes for each hash frame are concatenated in to a single octet string. These hash bytes are then signed with the private key that correspond to the public key in the leaf certificate specified by the cert id and protocol version. Depending on the number of hash frames and the selected hash and signature algorithms the hash bytes may need to be divided between multiple signatures as illustrated in Figure 5.

For example, if signature tables are inserted in to the Transport Stream approximately every second and the TS bit rate is 24 Mbps there are about 16000 packets per second. In the case illustrated above there are 5 hash frames although the final frame is quite short. In this illustration the first 4 frames have a length of about 4000 packets.

If SHA-1 is used as the hash algorithm there is a 20 byte result from computing the hash of each of the 5 frames. Once concatenated these form a 100 byte octet string. These could be signed by a single signature using RSA 1024 or higher. Alternatively, these 100 bytes could be divided between multiple signatures. For example, two RSA 512 signatures each signing 50 bytes.

The division of hash bytes between several signatures with shorter keys allows multiple hash frames to be used without incurring the computational cost of a single signature with a very long key.

DATA VERIFICATION

The receiver verification process computes the hashes for the hash frames of the received payload packets in the same manner as when the encoder computes them to generate the signature(s). This leads to an octet string of hash bytes. The receiver also operates the verify algorithm on the signature data. This extracts the original hash bytes from the signature. If these extracted hash bytes match those just computed over the received broadcast packets then the broadcast data has been authenticated. This is illustrated in Figure 6.

MITIGATION OF LOST DATA

The use of multiple hash frames in the signature table enables limited data loss mitigation by a receiving terminal.

The signature table signals the overall length of the signature group and the length and number of the hash frames. From these the receiving terminal infers the length of the final hash frame.

For example, if the number of received packets does not match the signature group length and/or continuity count errors are detected in the received data then the receiving terminal can apply mitigation behaviour.

As illustrated in Figure 7, the example procedure is as follows.

1. As normal, starting at the beginning of the signature group, identify the first hash frame, compute its hash and verify against the corresponding hash result extracted from the signature. 2. If the hash verifies repeat for the next and subsequent hash frames (1 , 2, etc.) until there is a mismatch in the hash results. In the illustration of Figure 7 frames 0 and 1 match but frame 2 fails.

3. Continuing at the final hash frame verify this frame and then work back towards the beginning of the signature group. In the illustration of Figure 7 frames 4 and 3 match but frame 2 fails.

4. Treat as trusted the hash frames that pass verification (in this example frames 0, 1 , 3, 4) and treat as untrusted the frame(s) that fail verification (in this example frame 2).

This process mitigates a single burst loss or corruption of data within a signature group.

VERIFICATION OF SIGNATURES

The signature table for one signature group is part of the data verified by the following signature group. A receiving terminal may wait for the verification of the subsequent signature group to verify the packets carrying the signature table for the previous signature group.

MULTI PACKET SIGNATURES

Signature tables may be sufficiently long that multiple packets are required to carry them. A signature group cannot be verified until the whole signature table has been acquired.

Accordingly it is beneficial in terms of receiver latency and buffering resources if the signature table can be completely delivered soon after the end of the signature group that it authenticates.

This basic scheme provides: implementation simplicity, low transmission cost, and moderate tolerance of data loss.

The configuration parameters are selected to allow each signature table to be carried in a single TS packet as follows. RSA signing key length is 512 bits (this leads to a 64 byte signature that can sign 53 bytes). Two signatures are used to allow up to 106 bytes to be signed. SHA-1 hashing is provided (this generates a 20 byte hash for each hash frame). A single current signing certificate is provided. 5 hash frames per signature group are provided. A 24 Mbps transmission has approximately 16000 packets per second. As the signature group length field is 16 bits a signature group must not be longer than 4 seconds. A signature table is inserted once per second. This costs at approximately 1500 bits per second of transmission bandwidth to carry the signature tables. 5 hash frames per signature group has the potential to limit the impact of data loss to about 200 ms.

Table 9: Number / period of hash frames as table size varies (RSA 512, SHA-1)

(Frame period: Hash frame duration if the packet rate is a constant one packet per second, i.e. the table rate reduces as its size grows.)

Larger signature tables support more hash frames but use more packets. The table repetition rate can be reduced proportionately to maintain a constant packet bit rate. Table 9 shows that there is some benefit in using a 2 packet table but little benefit in using more. However, a larger table might be desired to support more secure algorithms. For a 3 certificate chain where each certificate is of the order of 1 KB: root certificate of the CA; intermediate certificate issued to the operator by the CA; and leaf/signing certificate generated by the operator.

As the signing certificate life may be short, there is a current and next certificate chain being transmitted concurrently. I.e. in total approximately 6 x 1 KB certificate files. Each sub-table (carrying one certificate) requires approximately 6 packets. So, in this scenario approxroximately 36 packets are required to carry the certificate chains. If broadcast at a rate of 1 packet per second the transmission cost is approximately 1500 bits per second and the acquisition time is approximately 36 seconds. As the certificate tables are pseudo static and can be persistently cached by receivers, a lower repetition rate may be practical. TRANSMISSION IMPLEMENTATION

A transmission implementation is illustrated in Figure 1. There are three main components in a transmission implementation: certificate and private key generation; certificate table generation; and signature table generation.

Both the certificate table and the signature table are inserted in to the Transport Stream to be distributed to receivers.

Certificate and key generation is a security sensitive process. However, it does not need to be performed close to the point of transmission. Here using documents provided by the certificate authority the operator periodically generates: a private key for signing; and a public leaf certificate. The signing key is securely transferred to the signature table generator. The corresponding leaf certificate is sent along with the rest of the certificate chain to the certificate table generator.

Depending on the signing key length the life time of the leaf certificate might relatively short (e.g. a few months for a 512 bit key).

Inserting the certificate tables is comparatively simple. These are a pseudo static MPEG sections carrying "public" data that are inserted at low data rate. This uses existing SI injection mechanisms and is done at the final multiplexer or earlier.

The signature table generation and injection is more complex: it occurs after the final assembly of the Transport Stream is complete; it is secure as it holds the private signing key; it injects in to an ostensibly complete and full Transport Stream.

The signature table implementation can be simplified with some constraints: signature tables are constrained to fit in to a single TS packet; and packets are available in the outgoing TS that can be replaced with signature table packets (for example a low rate of null packets or "place holder" packets perhaps injected by the certificate table generator).

If required the signature table generation can have low latency by being implemented as follows. The hash for a hash frame is computed as packets pass towards transmission. T his continues until the end of the final hash frame is approaching and a packet that can be replaced with a signature table is detected (e.g. a null packet). The hash for the final hash frame of the signature group is then computed and the signature table generated and written in to the available packet. RECEIVER IMPLEMENTATION

A receiver implementation is illustrated in Figure 2.

The receiver implementation has two major components: signature verification - which quarantines arriving broadcast data until it can be verified; and certificate capture and management, which caches trusted certificates. The signature verification: Buffers TS packets for a signature group; decodes the signature table following the signature group; computes the hash values for each hash frame (using the hash frame size signalled in the table); verifies these hashes with the signed hash; and releases from quarantine the packets for each hash frame that verifies, replace with stuffing any hash frames that don't verify. In addition, the signature verification has a "boot strap mode" where solely certificate table packets and SI are passed to the certificate capture module. This allows the system to start-up if it has no current signing certificates cached.

The certificate capture module filters for certificate tables. The module then maintains a cache of the current certificates that descend from trusted roots and provides the current trusted public signing keys to the signature verification module.

The traditional parts of the receiver (the media decoders etc.) operate as normal. The input data stream is as normal (but delayed by a second or so) and may contain bursts of stuffing packets where hash frame verification has failed.

SIGNING KEY LENGTH Normal internet wisdom is to prefer longer RSA keys. However, the broadcast data is very ephemeral. A scheme could reasonably choose a short signing key and arrange for the leaf certificate expiry to be appropriately short that attack is infeasible during the lifetime of the certificate. For example, with a 512 bit RSA key a certificate lifetime of a few months is appropriate. This conveniently reduces both the size of the signature (e.g. 64 bytes for a 512 bit key) and the computational cost for the receiver.

An issue here is the trustworthiness of the receiver's clock. In particular the receiver should be able distrust if the broadcast clock (TDT etc.) is reset to a much earlier date (that might make an expired certificate valid again). Many receivers will need to solve this problem for other reasons. For example many DRMs may need a trustworthy clock so that they can expire time limited media licenses.

A benefit of the signing the whole transport stream (apart from the signature sections themselves) is that the broadcast TDT/TOT are verified.

ROOT OF TRUST

The certificate tables carry the complete certificate chain from the signing certificate up to and including the root. Example mechanisms include the following. The root certificate belongs to a trust authority that the terminal trusts for other contexts (e.g. it is a certificate authority issuing trusted TLS certificates - a normal TLS style certificate may not be sufficient as the trust cannot be triangulated with a host name; a more trustworthy certificate with enhanced verification may be provided.) A root certificate may be issued by a national or pan-national coordinating body. Embodiments of the present invention have been described. It will be appreciated that variations and modifications may be made to the described embodiments within the scope of the present invention. For example, embodiments of the present invention could be applied to packetized elementary stream (PES) packets forming the payload.

Claims

1. A digital television broadcast data stream authenticator configured to provide an indication of authenticity to at least some of a data stream to be broadcast as a digital television broadcast stream.

2. A digital television broadcast data stream authenticator according to claim 1 , wherein the digital television broadcast data stream comprises a plurality of data packets.

3. A digital television broadcast data stream authenticator according to claim 2, wherein the digital television broadcast data stream authenticator is further configured to group some of the plurality of packets and to provide the indication of authenticity based on the group.

4. A digital television broadcast data stream authenticator according to claim 3, wherein the digital television broadcast data stream authenticator is further configured to group some of the plurality of packets, or data extracted from some of the plurality of packets such as MPEG sections, into hash frames.

5. A digital television broadcast data stream authenticator according to claim 4, wherein the digital television broadcast data stream authenticator is further configured to apply a hash function for each hash frame to form a hash value of each hash frame.

6. A digital television broadcast data stream authenticator according to any preceding claim, wherein the digital television broadcast data stream authenticator is further configured to provide the indication of authenticity by inserting the indication of authenticity in the data stream.

7. A digital television broadcast data stream authenticator according to claim 6, wherein the digital television broadcast data stream authenticator is further configured to apply a hash function to each hash frame in a predictable sequence.

8. A digital television broadcast data stream authenticator according to claim 7, wherein the predictable sequence is transmission order.

9. A digital television broadcast data stream authenticator according to claim 7 or claim 8, wherein the digital television broadcast data stream authenticator is further configured to concatenate the hash value of each hash frame.

10. A digital television broadcast data stream authenticator according to claim 8 or claim 9, wherein the digital television broadcast data stream authenticator is further configured to apply authentication to the concatenated hash values with a private key.

1 1. A digital television broadcast data stream authenticator according to claim 9, wherein the digital television broadcast data stream authenticator is further configured to apply authentication to different parts of the concatenated hash values with different indications of authenticity.

12. A digital television broadcast data stream authenticator according to any of claims 6 to 1 1 , wherein the indication of authenticity comprises a digital signature.

13. A digital television broadcast data stream authenticator according to any of claims 6 to 12, wherein the digital television broadcast data stream authenticator is further configured to insert an indication of authenticity periodically in the data stream.

14. A digital television broadcast data stream authenticator according to claim 13, wherein the digital television broadcast data stream authenticator is further configured to insert an indication of authenticity periodically in the data stream at irregular intervals.

15. A digital television broadcast data stream authenticator according to any of claims 6 to 13, wherein the digital television broadcast data stream authenticator is further configured to insert an indication of authenticity in a placeholder in the data stream.

16. A digital television broadcast data stream authenticator according to any of claims 6 to 13, wherein the digital television broadcast data stream authenticator is further configured to compute the indication of authenticity based on at least some of the data stream between at least some markers of the data stream.

17. A digital television broadcast data stream authenticator according to claim 16, wherein the at least some of the data stream is some or all of the data stream.

18. A digital television broadcast data stream authenticator according to claim 16 or claim 17, wherein the at least some of the markers is some or all of the markers.

19. A digital television broadcast data stream authenticator according to any preceding claim, wherein the digital television broadcast data stream authenticator is further configured to compute the indication of authenticity with a public key.

20. A digital television broadcast data stream authenticator according to any preceding claims, wherein the digital television broadcast data stream authenticator is further configured to use markers, such as pre-existing markers or added markers, in the data stream to relate an indication of authenticity to a position in the data stream.

21. A digital television broadcast data stream authenticator according to claim 20, wherein the digital television broadcast data stream authenticator further comprises an output configured to output the position in the data stream to which an indication of authenticity applies to at least one computer.

22. A digital television broadcast data stream authenticator according to claim 20 or claim 21 , wherein the digital television broadcast data stream authenticator further comprises an output configured to output the indication of authenticity to at least one computer to provide the indication of authenticity.

23. A digital television broadcast data stream authenticator according to any of claims 20 to 22, wherein the digital television broadcast data stream authenticator further comprises an output configured to output the hash values and the position of the hash values to a data stream separate from that being authenticated.

24. A digital television broadcast data stream authenticator according to any preceding claim, wherein the indication of authenticity of a data stream is provided to at least one computer.

25. A digital television broadcast data stream authenticator according to claim 22, wherein the at least one computer comprises at least one web server.

26. A digital television broadcast data stream authenticator according to any preceding claim, wherein the data stream comprises an MPEG transport stream.

27. A digital television broadcast data stream authenticator according to any preceding claim, wherein the authenticator is configured to partition the data stream to be authenticated such that transmission errors in one partition do not prevent data in another partition from being authenticated, whilst allowing plural partitions to be authenticated together.

28. A digital television broadcast data stream authenticator according to any preceding claim, wherein the data stream authenticator is configured to provide an indication of authenticity of all of the data stream.

29. A digital television broadcast data stream authenticator according to any of claims 1 to 27, wherein the data stream authenticator is configured to provide an indication of authenticity of some of the data stream.

30. A digital television broadcast data stream authenticator according to claim 29, wherein the data stream authenticator is configured to provide an indication of authenticity of a predetermined portion of the data stream.

31. A digital television broadcast data stream authenticator according to claim 29 or claim 30, wherein the predetermined portion of the data stream does not include an identifier of the data stream.

32. A digital television broadcast data stream authenticator according to claim 31 , wherein the identifier comprises a packet identifier or PID.

33. A digital television broadcast data stream authenticator according to any of claims 29 to 32, wherein the data stream authenticator is configured to provide the indication of authenticity of some of the data stream by masking a portion of the data stream to which the indication of authenticity is not provided.

34. A digital television broadcast data stream authenticator according to any of claims 29 to 32, wherein the data stream authenticator is configured to provide the indication of authenticity to only a payload of the data stream, such as MPEG sections.

35. A digital television broadcast data stream authenticator according to claim 29, wherein the data stream authenticator is configured to provide the indication of authenticity to at least one predetermined functional component of the data stream.

36. A digital television broadcast data stream authenticator according to claim 35, wherein the at least one predetermined functional component of the data stream comprises an interactive application component.

37. A digital television broadcast data stream authenticator according to any preceding claim, wherein the indication of authenticity is provided so that the digital television broadcast data stream is backwards compatible with existing digital television broadcast data stream reception equipment.

38. A digital television broadcast data stream verifier configured to verify a received digital television broadcast data stream to which an indication of authenticity has been provided to at least some of the data stream.

39. A digital television broadcast data stream verifier according to claim 38, wherein the digital television broadcast data stream verifier is further configured to verify the

authenticated digital television broadcast data stream using a public key.

40. A digital television broadcast data stream verifier according to claim 38 or claim 39, wherein the digital television broadcast data stream verifier is further configured to verify the authenticated digital television broadcast data stream by verifying the indication of authenticity contained in the digital television broadcast data stream.

41. A digital television broadcast data stream verifier according to any of claims 38 to 40, wherein the digital television broadcast data stream verifier is further configured to verify the authenticated digital television broadcast data stream by verifying hash values derived from the digital television broadcast stream contained in the digital television broadcast data stream.

42. A digital television broadcast data stream verifier according to claim 41 , wherein the hash values are based on groups of data packets, or data extracted from some of the plurality of packets such as MPEG sections, of the digital television broadcast data stream.

43. A digital television broadcast data stream verifier according to claim 42, wherein the hash values are based on concatenated groups of data packets, or data extracted from some of the plurality of packets such as MPEG sections, of the digital television broadcast data stream.

44. A digital television broadcast data stream verifier according to claim 42, wherein the digital television broadcast data stream receiver is further configured to verify the authenticity of the authenticated digital television broadcast data stream by verifying indications of authenticity in the digital television broadcast data stream at different locations of the data stream.

45. A digital television broadcast data stream verifier according to any of claims 41 to 44, wherein the digital television broadcast data stream receiver is further configured to verify the authenticity of the authenticated digital television broadcast data stream by verifying a plurality of hash values derived from different locations of the digital television broadcast stream.

46. A digital television broadcast data stream verifier according to claim 45, wherein the different locations comprises two locations.

47. A digital television broadcast data stream verifier according to any of claims 41 to 46, wherein the digital television broadcast data stream receiver is further configured to verify the authenticity of the authenticated digital television broadcast data stream by verifying the plurality of hash values derived from different locations in the digital television broadcast stream against the plurality of trusted hash values provided by the indication of authenticity.

48. A digital television broadcast data stream verifier according to claim 47, wherein the digital television broadcast data stream receiver is further configured to recognise as failing authentication any of the plurality of locations in the digital television broadcast data stream for which the hash value computed for that location by the data stream verifier does not match the hash value conveyed by the indication of authenticity for that location.

49. A digital television broadcast data stream verifier according to claim 48, wherein the digital television broadcast data stream receiver is further configured to stop the authentication at the end at which authentication failed if a hash value cannot be authenticated.

50. A digital television broadcast data stream verifier according to claim 48 or claim 49, wherein the digital television broadcast data stream receiver is further configured to stop the authentication from either end if a hash value cannot be authenticated.

51. A digital television broadcast data stream verifier according to claim 38 or claim 39, wherein the digital television broadcast data stream verifier is further configured to verify the authenticity of the authenticated digital television broadcast data stream by verifying indications of authenticity obtained from at least one separate computer.

52. A digital television broadcast data stream verifier according to claim 51 , wherein the digital television broadcast data stream verifier is further configured to use markers in the data stream to relate each indication of authenticity to a position in the data stream.

53. A digital television broadcast data stream verifier according to claim 52, wherein the digital television broadcast data stream verifier further comprises an input configured to input the position in the digital television broadcast data stream to which of the indications of authenticity apply from the at least one computer.

54. A digital television broadcast data stream verifier according to any of claims 38 to 53, wherein the digital television broadcast data stream receiver is further configured to verify the authenticity of the authenticated digital television broadcast data stream by obtaining indications of authenticity from at least one separate computer.

55. A digital television broadcast data stream verifier according to claim 54, wherein the at least one separate computer comprises a web server.

56. A digital television broadcast data stream verifier according to any of claims 38 to 55, wherein the data stream comprises an MPEG transport stream.

57. A digital television broadcast data stream verifier according to any of claims 38 to 56, wherein the data stream verifier is configured to verify a received digital television broadcast data stream to which an indication of authenticity has been provided to all of the data stream.

58. A digital television broadcast data stream verifier according to any of claims 38 to 56, wherein the data stream verifier is configured to verify a received digital television broadcast data stream to which an indication of authenticity has been provided to some of the data stream.

59. A digital television broadcast data stream verifier according to claim 58, wherein the data stream verifier is configured to verify a predetermined portion of the received digital television broadcast data stream data stream.

60. A digital television broadcast data stream verifier according to claim 58 or claim 59, wherein the predetermined portion of the data stream does not include an identifier of the data stream.

61. A digital television broadcast data stream verifier according to claim 60, wherein the identifier comprises a packet identifier or PID.

62. A digital television broadcast data stream verifier according to any of claims 58 to 61 , wherein the data stream verifier is configured to verify the indication of authenticity applied to only a payload of the data stream, such as MPEG sections.

63. A digital television broadcast data stream verifier according to claim 62, wherein the data stream verifier is configured to verify the indication of authenticity applied to at least one predetermined functional component of the data stream.

64. A digital television broadcast data stream verifier according to claim 63, wherein the at least one predetermined functional component of the data stream comprises an interactive application component.

65. A digital television broadcast data stream verifier according to any of claims 38 to 64, wherein the digital television broadcast data stream verifier is further configured to verify the indication of authenticity based on at least some of the data stream between at least some markers of the data stream.

66. A digital television broadcast data stream verifier according to claim 65, wherein the at least some of the data stream is some or all of the data stream.

67. A digital television broadcast data stream verifier according to claim 65 or claim 66, wherein the at least some of the markers is some or all of the markers.

68. A digital television broadcast data stream verifier according to any of claims 38 to 67, wherein the indication of authenticity is provided so that the digital television broadcast data stream is backwards compatible with existing digital television broadcast data stream reception equipment.

69. A digital television broadcast data stream authenticating method, the method comprising providing an indication of authenticity of at least some of a data stream to be broadcast as a digital television broadcast stream.

70. A digital television broadcast data stream authenticating method according to claim 69, wherein the digital television broadcast data stream comprises a plurality of data packets.

71. A digital television broadcast data stream authenticating method according to claim 70 further comprising:

grouping some of the plurality of packets, or data extracted from some of the plurality of packets such as MPEG sections; and

providing the indication of authenticity based on the grouping.

72. A digital television broadcast data stream authenticating method according to claim 71 , wherein the method further comprises grouping some of the plurality of packets, or data extracted from some of the plurality of packets such as MPEG sections, into hash frames.

73. A digital television broadcast data stream authenticating method according to claim 72, wherein the method further comprises applying a hash function for each hash frame to form a hash value of each hash frame.

74. A digital television broadcast data stream authenticating method according to any of claims 69 to 73, wherein the method further comprises providing the indication of authenticity by inserting the indication of authenticity in the data stream.

75. A digital television broadcast data stream authenticating method according to claim

74, wherein the method further comprises applying a hash function to each hash frame in a predictable sequence.

76, A digital television broadcast data stream authenticating method according to claim

75, wherein the predictable sequence is transmission order.

77. A digital television broadcast data stream authenticating method according to claim 75 or claim 76, wherein the method further comprises concatenating the hash values of the hash frames.

78. A digital television broadcast data stream authenticating method according to claim

77, wherein the method further comprises authenticating the concatenated hash values with a private key.

79. A digital television broadcast data stream authenticating method according to claim

78, wherein the method further comprises authenticating different parts of the concatenated hash values with different indications of authenticity.

80. A digital television broadcast data stream authenticating method according to any of claims 69 to 79, wherein the indication of authenticity comprises a digital signature.

81. A digital television broadcast data stream authenticating method according to any of claims 69 to 80, wherein the method further comprises inserting an indication of

authenticity periodically in the data stream.

82. A digital television broadcast data stream authenticating method according to claim 81 , wherein the method further comprises inserting an indication of authenticity periodically in the data stream at irregular intervals.

83. A digital television broadcast data stream authenticating method according to any of claims 69 to 82, wherein the method further comprises inserting an indication of

authenticity in a placeholder in the data stream.

84. A digital television broadcast data stream authenticating method according to any of claims 69 to 83, wherein the method further comprises computing the indication of authenticity based on at least some of the data stream between at least some markers of the data stream.

85. A digital television broadcast data stream authenticating method according to claim 84, wherein the at least some of the data stream is some or all of the data stream.

86. A digital television broadcast data stream authenticating method according to claim 84 or claim 85, wherein the at least some of the markers is some or all of the markers.

87. A digital television broadcast data stream authenticating method according to any of claims 69 to 86, wherein the method further comprises authenticating the indication of authenticity with a public key.

88. A digital television broadcast data stream authenticating method according to any of claims 69 to 87, wherein the method further comprises using markers, such as pre-existing markers or added markers, in the data stream to relate an indication of authenticity to a position in the data stream.

89. A digital television broadcast data stream authenticating method according to claim 88, wherein the digital television broadcast data stream method further comprises outputting the position in the data stream to which an indication of authenticity applies to at least one computer.

90. A digital television broadcast data stream authenticating method according to claim 88 or claim 89, wherein the method further comprises outputting the indication of authenticity to at least one computer to provide the indication of authenticity.

91. A digital television broadcast data stream authenticating method according to any of claims 69 to 90, wherein the indication of authenticity of a data stream is provided to at least one computer.

92. A digital television broadcast data stream authenticating method according to claim 91 , wherein the at least one computer comprises at least one web server.

93. A digital television broadcast data stream authenticating method according to any of claims 68 to 92, wherein the data stream comprises an MPEG transport stream.

94. A digital television broadcast data stream authenticating method according to any of claims 69 to 93, wherein the method further comprises partitioning the data stream to be authenticated such that transmission errors in one partition do not prevent data in another partition from being authenticated, whilst allowing plural partitions to be authenticated together.

95. A digital television broadcast data stream authenticating method according to any of claims 69 to 94, wherein the method further comprises providing an indication of authenticity of all of the data stream.

96. A digital television broadcast data stream authenticating method according to any of claims 69 to 95, wherein the method further comprises providing an indication of authenticity of some of the data stream.

97. A digital television broadcast data stream authenticating method according to claim 95, wherein the method further comprises providing an indication of authenticity of a predetermined portion of the data stream.

98. A digital television broadcast data stream authenticating method according to claim 97, wherein the predetermined portion of the data stream does not include an identifier of the data stream.

99. A digital television broadcast data stream authenticating method according to claim 98, wherein the identifier comprises a packet identifier or PID.

100. A digital television broadcast data stream authenticating method according to any of claims 96 to 99, wherein the method further comprises providing the indication of authenticity of some of the data stream by masking a portion of the data stream to which the indication of authenticity is not provided.

101. A digital television broadcast data stream authenticating method according to any of claims 96 to 98, wherein the method further comprises providing the indication of authenticity to only a payload of the data stream, such as MPEG sections.

102. A digital television broadcast data stream authenticating method according to claim 97, wherein the method further comprises providing the indication of authenticity to at least one predetermined functional component of the data stream.

103. A digital television broadcast data stream authenticating method according to claim

102. wherein the at least one predetermined functional component of the data stream comprises an interactive application component.

104. A digital television broadcast data stream authenticating method according to claim 67, wherein providing the indication of authenticity of at least some of a data stream to be broadcast as a digital television broadcast stream is such that the digital television broadcast data stream is backwards compatible with existing digital television broadcast data stream reception equipment.

105. A digital television broadcast data stream verification method comprising verifying a received digital television broadcast data stream to which an indication of authenticity has been provided to at least some of the data stream.

106. A digital television broadcast data stream verification method according to claim 105, further comprising verifying the authenticated digital television broadcast data stream using a public key.

107. A digital television broadcast data stream verification method according to claim 105 or claim 106, wherein the digital television broadcast data stream verification method further comprises verifying the authenticated digital television broadcast data stream by verifying the indication of authenticity contained in the digital television broadcast data stream.

108. A digital television broadcast data stream verification method according to any of claims 105 to 107, wherein the method further comprises verifying the authenticated digital television broadcast data stream by verifying hash values derived from the digital television broadcast stream contained in the digital television broadcast data stream.

109. A digital television broadcast data stream verification method according to claim

108, wherein the hash values are based on groups of data packets, or data extracted from some of the plurality of packets such as MPEG sections, of the digital television broadcast data stream.

1 10. A digital television broadcast data stream verification method according to claim

109, wherein the hash values derived from the digital television broadcast stream contained in the digital television broadcast data stream are concatenated.

1 11. A digital television broadcast data stream verification method according to claim 109, wherein the method further comprises verifying the authenticity of the authenticated digital television broadcast data stream by verifying indications of authenticity in the digital television broadcast data stream at different locations of the data stream.

1 12. A digital television broadcast data stream verification method according to claim

1 11 , wherein the method further comprises verifying the authenticity of the authenticated digital television broadcast data stream by verifying a plurality of hash values derived from different locations of the digital television broadcast stream.

1 13. A digital television broadcast data stream verification method according to claim

1 12, wherein the plurality of different locations comprises two locations.

1 14. A digital television broadcast data stream verification method according to claim 109, wherein the method further comprises verifying the authenticity of the authenticated digital television broadcast data stream by verifying the plurality of hash values derived from different locations in the digital television broadcast stream against the plurality of trusted hash values provided by the indication of authenticity.

1 15. A digital television broadcast data stream verification method according to claim 1 14, wherein the method further comprises recognising as failing authentication any of the plurality of locations in the digital television broadcast data stream for which the hash value computed for that location by the data stream verifier does not match the hash value conveyed by the indication of authenticity for that location.

1 16. A digital television broadcast data stream verification method according to claim 1 15, wherein the digital television broadcast data stream verification method further comprises stopping the authentication at the end at which authentication failed if a hash value cannot be authenticated.

1 17. A digital television broadcast data stream verification method according to claim 115 or 116, wherein the method further comprises stopping the authentication from either end if a hash value cannot be authenticated.

1 18. A digital television broadcast data stream verification method according to claim 106 or claim 107, wherein the method further comprises verifying the authenticity of the authenticated digital television broadcast data stream by verifying indications of authenticity obtained from at least one separate computer.

1 19. A digital television broadcast data stream verification method according to claim

1 18, wherein the method further comprises using markers in the data stream to relate each indication of authenticity to a position in the data stream.

120. A digital television broadcast data stream verification method according to claim

1 19, wherein the method further comprises inputting the position in the digital television broadcast data stream to which of the indications of authenticity apply from the at least one computer.

121. A digital television broadcast data stream verification method according to any of claims 1 12 to 120, wherein the method further comprises verifying the authenticity of the authenticated digital television broadcast data stream by obtaining indications of authenticity from at least one separate computer.

122. A digital television broadcast data stream verification method according to claim 121 , wherein the at least one separate computer comprises a web server.

123. A digital television broadcast data stream verification method according to any of claims 105 to 122, wherein the data stream comprises an MPEG transport stream.

124. A digital television broadcast data stream comprising an indication of authenticity to at least some of the data stream.

125. A digital television broadcast data stream according to claim 123, wherein the digital television broadcast data stream comprises a plurality of data packets.

126. A digital television broadcast data stream according to claim 125, wherein the indication of authenticity is based on a group of some of the plurality of packets, or data extracted from some of the plurality of packets such as MPEG sections.

127. A digital television broadcast data stream according to claim 125 or 126, wherein the digital television broadcast data stream comprises a plurality of packets grouped into hash frames.

128. A digital television broadcast data stream according to claim 127, wherein the digital television broadcast data stream comprises a hash value derived from each hash frame.

129. A digital television broadcast data stream according to claim 128, wherein the digital television broadcast data stream comprises a concatenation of the derived hash values.

130. A digital television broadcast data stream according to any of claims 124 to 129, wherein the indication of authenticity comprises a digital signature.

131. A digital television broadcast data stream according to any of claims 124 to 130, wherein the indication of authenticity is periodically in the data stream.

132. A digital television broadcast data stream according to claim 131 , wherein the indication of authenticity is periodically in the data stream at irregular intervals.

133. A digital television broadcast data stream according to any of claims 124 to 132, wherein the indication of authenticity is in a placeholder in the data stream.

134. A digital television broadcast data stream according to any of claims 124 to 133, wherein the data stream comprises an MPEG transport stream.

135. A digital television broadcast data stream according to any of claims 124 to 134, wherein the indication of authenticity is provided so that the digital television broadcast data stream is backwards compatible with existing digital television broadcast data stream reception equipment.

136. A computer program for carrying out the method of any of claims 69 to 123.

137. A computer-readable medium containing a set of instructions that causes a computer to perform the method of any of claims 69 to 123.