EP3251374A1

EP3251374A1 - Broadcasting data in mpeg transport streams

Info

Publication number: EP3251374A1
Application number: EP16702770.5A
Authority: EP
Inventors: Chris POOLE; Nigel EARNSHAW
Original assignee: British Broadcasting Corp
Current assignee: British Broadcasting Corp
Priority date: 2015-01-28
Filing date: 2016-01-27
Publication date: 2017-12-06
Also published as: WO2016120619A1; GB201501431D0; GB2538934A

Abstract

An encoder for encoding an MPEG transport stream of MPEG sections comprises means for processing the MPEG sections using a hash function to provide multiple hash outputs each hash output being associated with one or more MPEG sections. The hash outputs and corresponding section identifying information are signed using a private key corresponding to a public key available at receivers to produce signatures. The hash output section identifying information and signatures are then coded into one or more MPEG sections themselves which are designated as signature MPEG sections. The signature MPEG sections and MPEG transport stream are broadcast together. A receiver is able to verify using the signature MPEG sections that the MPEG transport stream has been provided by a known source and has not been tampered with.

Description

Broadcasting Data in MPEG Transport Streams

BACKGROUND OF THE INVENTION

This invention relates to providing security for broadcast data streams in the sense of providing a mechanism by which a receiver can validate that a stream of data is provided by a reliable source. In particular, the invention provides a method, apparatus and system in which data is broadcast in an MPEG transport stream on an audio-video broadcast network.

Various mechanisms are known in the art for providing secure broadcast of data over an audio-video broadcast channel to multiple receivers. Such mechanisms typically provide security by encrypting the video component of a stream of data such that the video data can only be decrypted by a receiver holding a secret key. These are known as conditional access systems and usually involve providing a secret key to a receiver which is used by the receiver to decrypt keys in a broadcast stream which in turn decrypt video content. Whilst such systems provide good security, they typically require secrets to be securely stored in a receiver at manufacture, and/or a separate channel of communication from broadcaster to receiver (such as sending a smart card or pin by post) and are not appropriate for free to air broadcast of television channels for which the broadcaster does not wish to provide the administration required of conditional access systems.

In broadcast video networks that are available to all receivers without using conditional access techniques, there is currently no means for a digital television receiver to know for sure that the signal it is receiving really came from the broadcaster without modification. Various trends mean that this is becoming more of an issue. For example, the equipment needed to interfere with the broadcast signal has become cheaper, consumer TVs are more capable devices, with internet connectivity and also with devices such as web cams and microphones, and the software in TVs gets ever more complex, with large amounts of open source software, particularly in their HTML browsers and media players. The consequences are that some consumer receivers may be vulnerable to malicious attacks performed by modifying a broadcast signal that the TV is receiving. SUMMARY OF THE INVENTION

We have appreciated the desirability of limiting the possibility for security attacks in broadcast television systems. We have further appreciated the desirability of providing a mechanism such that receivers can determine whether the signal they are receiving comes from a trusted source and/ or has not been modified between broadcast and reception. The invention is defined in the claims to which reference is directed.

The techniques embodying the invention are particularly applied to parts of the broadcast signal that (a) convey instructions to the TV to run applications, and (b) allow such applications to be delivered in broadcast streams. For example, the HbbTV standard uses an Application Information Table (AIT) for (a) and the DSM- CC Object Carousel for (b). Both of these formats are based on the MPEG Section format. Further types of data to which the concept applies include EIT tables and others discussed later. The embodiments of the invention provide ways in which such data can be authenticated and integrity protected.

In broad terms, embodiments of the invention provide a mechanism by which parts of a broadcast stream may be signed by a broadcaster using a private key and verified at a receiver using a public key. The signed parts are MPEG sections according to the MPEG standards. The signatures themselves are transmitted in separate MPEG sections and so maintain compatibility with existing receivers (which can understand but ignore the signature sections), whilst allowing newer receivers to validate the broadcast. BRIEF DESCRIPTION OF THE DRAWINGS

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

Fig. 1 is a schematic diagram of a system embodying the invention;

Fig. 2 is a diagram showing signature sections;

Fig. 3 is a diagram showing the functional components of a transmitter; and

Fig. 4 is a diagram showing the functional components of a receiver. DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT OF THE INVENTION

The invention may be embodied in a method of broadcasting and receiving data, a transmitter, receiver and system comprising transmitter and multiple receivers in an audio-video broadcast network and an encoder or decoder. In this regard, a receiver includes a television, set top box or other device that includes capability to receive broadcast television channels.

MPEG Standards The embodiment of the invention is particularly applicable to broadcast of television signals according to MPEG standards. These are well known to the skilled person, but will be discussed here for ease of reference.

MPEG standards such as those relating to MPEG-2 define a structure of transmission that comprises MPEG tables, which are formed of sub-tables in turn formed of sections. A section is a syntactic structure that is used for mapping MPEG-2 tables into transport stream (TS) packets. Sections may be variable in length. The sections within each table are typically limited to 4 096 bytes in length, except for sections within certain specific tables such as the PMT which are limited to 1 024 bytes. Each section is uniquely identified by the combination of the following elements:

table_id: The table_id identifies to which table the section belongs.

table_id_extension: The table_id_extension is used for identification of a sub_table.

section_number: The section_number field allows the sections of a particular sub_table to be reassembled in their original order by the decoder. version_number: The version_number is incremented when the data in the section or sub_table changes.

current_next_indicator: Each section shall be numbered as valid "now" (current), or as valid in the immediate future (next). This allows the transmission of a future version of the section in advance of the change, giving the decoder the opportunity to prepare for the change.

The embodiments provide improvements in relation to various types of data such as the following:

MPEG Program Specific Information (PSI) that provides technical information about the contents of a broadcast transport stream (PAT, PMT, CAT etc.) - defined in ISO/I EC 13818-1

DVB Service Information that is processed by receivers to display an Electronic Programme Guide and manage receiver channel lists, including:

Information about the transmission network (in a NIT) information about the services/channels (in an SDT) and information about individual programmes ("events") scheduled on those channels (EIT)

all defined in ETSI EN 300 468 Application Information (in AIT) describing interactive applications available for use with a broadcast channel, including applications that should be automatically started when the channel is selected - defined in ETSI TS 102 809

Data structures delivering a DSMCC Data Carousel or Object Carousel, typically used to deliver files of interactive applications to receivers, or to deliver images or other metadata - defined in ISO/IEC 13818-6 and profiled in ETSI TS 102 809

Information about related content (in RCT) - defined in ETSI TS 102 323

The MPEG section format is usable for all sorts of things, typically by extending the 'private section' format defined by MPEG. The embodiments are applicable to all such types of data provided using the section format. For delivery in an MPEG Transport Stream, sections are split into the payloads of 188-byte MPEG Transport Packets with a header added to allow multiple streams of section data to be multiplexed and demultiplexed. Sections are typically repeated in the Transport Stream so that a receiver joining the stream at any time can receive the data after a short time.

The Improvement

A system embodying the invention is shown in Figure 1 and comprises a transmitter 10 and receiver 14 within an audio-video broadcast network shown here as a broadcast channel 12. The transmitter comprises an encoder and functionality to deliver an MPEG stream on the network. The receiver has functionality to receive and decode the stream. The encoder and decoder described below may be implemented as hardware with hardware components as decsribed or in software, in which case the functional units may be considered as software modules.

Figure 3 shows the main functional components of an encoder which may be included in a transmitter embodying the invention. The encoder may provide data to be broadcast over air, cable, satellite of other communication medium and these are known to the skilled person and will not be described further. The encoder comprises an input 20 for receiving an MPEG data stream. A processor block 22 processes received MPEG sections using a hash function to provide multiple hash outputs, each hash output being associated with one or more of the MPEG sections by section identifying information. A signature block 24 is arranged to sign the hash outputs and corresponding section identifying information using a private key 26 corresponding to a public key available at receivers to produce signatures. A processor, here shown as MPEG processor 26, is arranged to encode the hash outputs, corresponding section identifying information and signatures into one or more MPEG sections designated as signature MPEG sections. An output 28 is arranged to receive the assembled MPEG stream and provide this to be broadcast including both the signature MPEG sections and input MPEG sections in the MPEG transport stream.

At the transmitter or encoder, MPEG data arranged as MPEG sections to be broadcast over a broadcast network is processed according to the following steps. Each of the MPEG sections of data is processed using a hash function. Preferably, the computation is a hash of each MPEG section up to but not including its CRC value. If section_syntax_indicator == 1 , this can optionally cause current_next_indicator to be set to 1 first so that the hash remains the same when information pre-transmitted in advance ('next') becomes current. Alternatively, the current_next_indicator may be excluded from the hash computation so that the hash output does not depend on this value. In either approach, the hash output does not change and so a corresponding hash function at the receiver can process the section whether indicated current or not. This step provides multiple hash outputs, each hash output being associated with an MPEG section by an identifier or more generally by section identifying information. Preferably, each section is processed to produce a corresponding hash output, but multiple sections may be combined to produce a hash output. One purpose of the hash function is to reduce the amount of data for which a signature process is then run. Separately recording hash outputs for individual sections or groups of sections means that any corruption of one of those sections during transmission does not prevent the verification of other sections.

The hash outputs are subject to a signing process which may be achieved by first creating a list of 'section identifying information' and hash values for a number of sections. The 'section identifying information' includes everything needed to uniquely reference one or more sections and is used by a receiver to look up the hash value relating to a section, or to lookup one or more sections for a hash. Typically, the 'section identifying information' includes identifiers such as a table_id, section_syntax_indicator, table_id_extension, version_number and section_number. In particular, the version_number is typically included so that the reference is unique even if the data changes, up to the point where the version number wraps after 32 updates. Optionally, the version_number may be omitted and a reference made to the most recently transmitted version or the version to be transmitted next.

The 'section identifying information' may optionally include additional bytes to match against the section contents. For example, to uniquely reference an EIT section, four additional bytes would typically be used to reference specific values of the transport_stream_id and original_network_id fields. The 'section identifying information' may optionally identify a number of sections to be covered by the same hash. For example, the information may identify a range of section_number values, or may provide a reference to all the sections that have a particular combination of table_id, table_id_extension and version_number. In a further option, the 'section identifying information' may include more than one set of identifiers, thereby referencing two or more specific sections.

The multiple hash outputs and corresponding identifiers are then signed using a private key corresponding to a public key available at receivers, including the necessary information to reference the public key needed for verification.

The multiple hash outputs, identifiers and signatures are then encoded into one or more MPEG sections. Such sections may be referred to as signature sections in the sense that these sections are specified for containing the signed hash outputs of regular MPEG sections. The encoding may be by encoding the list into one or more MPEG sections, as shown in table 1 below. The signature MPEG sections are then sent with the regular MPEG sections by including the contents shown in this table in the transport stream. The set of all signature sections can be termed the signature table.

Many different hash and signature algorithms can be used. To allow for rapid verification of signatures at the receiver, the RSA algorithm could be used. However, RSA keys and signatures are large in size for a given security strength and so the bitrate needed to deliver the signatures and keys would be larger. If the bitrate needs to be kept to a minimum, the ECDSA algorithm could be used, at the likely expense of increased processing times in the receiver.

There is also flexibility in the choice of hash algorithm. The hashes may need to be resistant to a 'pre-image attack' and they may need to be resistant also to a 'collision attack'. Different hash lengths may be appropriate in each case. The SHA-1 and SHA-2 families of hash functions can be used. In either case, hashes can be truncated to a shorter length according to the security strength required and the bitrate available. For example, in cases where resistance to collisions is not required, SHA-1 hashes could be used, truncated to 112 bits or 14 bytes. If collision resistance is also needed, SHA-256 truncated to 224 bits or 28 bytes could be used.

Table 1

The semantics of the fields is as follows:

table_id: A unique value allocated to distinguish signature table sections from other types of section delivered on the same PID. This value would typically be allocated by MPEG or by a regional organisation such as DVB, ATSC or ARIB. section_syntax_indicator: a 1-bit field that shall be set to .

sectionjength: a 12-bit field specifying the number of bytes in the section, starting immediately following the sectionjength field and including the CRC.

table_id_extension: a 16-bit field for possible future use that may be used to differentiate independent sets of signature sections.

version_number: a 5-bit field that shall be incremented by 1 when the information carried in a signature sub-table (identified by table_id and table_id_extension) changes. When it reaches value 31 , it wraps so that the next value is 0.

current_next_indicator: a 1-bit field that shall be set to .

section_number: an 8-bit field that gives the number of the section within the sub- table. The first section shall have the value ΌχΟΟ' and each subsequent section shall have the next consecutive value.

last_section_number: an 8-bit field that gives the number of the last section within the sub-table. This is the highest section_number value in use for sections of the sub-table.

hash_algorithm_identifier: an 8-bit field that identifies the hash algorithm used to create the hashes of data sections that are contained in the section_hash_byte fields. The following values are defined:

hashjength: an 8-bit value that indicates the number of bytes of hash data present in the section_hash_byte fields for each hash. This value can be used to truncate the hash value included in the table from the full length hash produced by the hash algorithm. The hashjength value must not be greater than the length of the digest output by the hash algorithm signalled in the hash_algorithm_identifier field. hash_signature_algorithm_identifier: an 8-bit value that identifies the signature algorithm used to calculate the section signature that forms the signature_byte fields. The following values are defined:

forward_reference_flag: a 1-bit flag that when set to indicates that this section itself can be verified using a hash value to be delivered in another signature_section, as an alternative to verifying this section directly using its signature. Receivers with limited ability to perform frequent signature verifications may defer processing of such a section and verify it via the hash value after checking the signature of the signature_section that includes its hash.

hashesjoopjength: a 12-field that indicates the length in bytes of the loop of hashes that follows.

ref_table_id: an 8-bit field that identifies the referenced table_id for a section whose hash is equal to the following section_hash_bytes.

ref_section_syntax_indicator: a 1-bit field that when set to indicates that the section being referenced has its section_syntax_indicator also set to and that the section is referenced by the combination of ref_table_id, ref_table_id_extension, ref_version_number, ref_section_number and zero or more ref_additional_byte. When set to Ό' this indicates that the section being referenced has its section_syntax_indicator set to Ό' and is the most recently transmitted section or the section to be transmitted next, as indicated by the ref_before_after flag.

ref_before_after: a 1-bit field that shall be set to if ref_section_syntax_indicator is Ό' and the section being referenced is the most recently transmitted section whose table_id matches ref_table_id. It is set to Ό' if the ref_section_syntax_indicator is or if ref_section_syntax_indicator is Ό' and the section being referenced is the next section table_id matches ref_table_id that will be transmitted. ref_additional_bytes_count: a 3-bit field that indicates the number of ref_additional_byte bytes to be matched as part of the section reference. This field shall be set to Ό' if ref_section_syntax_indicator is set to Ό'.

ref_table_id_extension: a 16-bit field that identifies the referenced table_id_extension for a section whose hash is equal to the following section_hash_bytes.

ref_version_number: an 8-bit field that identifies the referenced version_number for a section whose hash is equal to the following section_hash_bytes.

ref_section_number: an 8-bit field that identifies the referenced section_number for a section whose hash is equal to the following section_hash_bytes.

ref_additional_byte: zero or more (specified by ref_additional_bytes_count) 8-bit bytes that identifies zero or more bytes at offset 8 into a section whose hash is equal to the following section_hash_bytes. For example: if ref_additional_bytes_count is 4 then 4 ref_additional_byte values are present and these indicate the value of the 4 bytes immediately following the last_section_number field of the section being referenced.

section_hash_byte: one or more (specified by hashjength) 8-bit bytes forming a cryptographic hash of a referenced section, calculated using the hash algorithm specified by the hash_algorithm_identifier field.

signature_key_identifier_length: an 8-bit field that indicates the length of the signature key identifier contained in the signature_key_identifier_byte values. signature_key_identifier_byte: one or more 8-bit bytes forming an identifier for the public key needed to verify the signature contained in the signature_byte values. This field must match the identifier of a public key delivered separately. Typically, the key identifier would be a SHA1 or SHA-256 hash of the public key. signature_byte: one or more 8-bit bytes forming a digital signature calculated using the algorithm specified in the hash_signature_algorithm_identifier field. The input data for the signature algorithm is the entire section up to but not including the first signature_byte. If the hash_signature_algorithm_identifier refers to the ECDSA algorithm, the first signature_byte identifies a named Elliptic Curve used to generate the signature. The following values are defined:

Value Curve name

0x17 secp256r1 (defined in SEC 2 available from

http://www.secg.org/ )

0x18 secp384r1 (defined in SEC 2 available from

http://www.secg.org/ )

other values reserved The total number of signature_byte bytes present is determined by the signature algorithm and key being used,

reserved: shall be set to .

reserved_future_use: shall be set to .

Signed signature_sections can then be delivered to the receiver along with the data being protected.

At the receiver, a process is operated to verify the signed signature section, to compute a hash of the MPEG sections and then compare the locally computed hash to the signed hash. If the hash outputs match, and the signature is verified then the receiver has established that the data was: (1) broadcast by an entity in possession of the private key that corresponds to the public key at the receiver and (2) the data in the MPEG sections has not been altered.

Figure 4 shows a decoder for a receiver embodying the invention. The decoder has an input 30 for receiving the MPEG stream from the transmitter. An extraction block 32 analyses the MPEG stream and extracts sections that are signature sections. A verify block 34 verifies the signature of signature blocks and rejects any such blocks for which the verification fails. A hash block produces a hash output of the MPEG sections protected by the signature sections and provides a hash output. The hash output for each section is then compared in a comparison block. If the hashes match and the verification confirms the signature then an output is asserted at output 40 to reject MPEG sections or otherwise provide security.

The steps at the receiver are therefore:

for MPEG sections that are determined to be signature MPEG sections;

- verifying that the signature of one or more signature sections is consistent with the signed contents using a public key corresponding to the private key and rejecting any signature section which is not consistent;

for at least some other MPEG sections

- processing each of the MPEG sections using a hash function to provide a hash output; - comparing the hash output of each of the MPEG sections with the corresponding hash output contained in one of the signature MPEG sections; and

- rejecting MPEG sections for which the comparing step determines that the hash output and corresponding hash output contained in one of the signature MPEG sections do not match.

When a signature section is received, the receiver may store it for processing later. If the last_section_number field of the signature section is zero, this indicates that the signature table is formed of only one signature section and the signature section supersedes any previous signature table received. If the last_section_number field is greater than zero, this indicates that the complete signature table comprises more than one signature section and a receiver that stores the signature section should retain each section of the table. The receiver may optionally discard previously-stored signature sections after receiving a signature section with a different version_number value.

The step of rejecting the MPEG sections may be implemented in a variety of ways. For example, the data in the rejected sections may simply be ignored. As a result, any malicious code inserted in those sections will be ignored, but the receiver will continue to operate normally. The step of rejecting sections may cause further actions such as displaying a warning to a user or causing the receiver to change state such as rebooting, shutting down or otherwise reducing functionality to reduce the risk that malicious code is implemented. The steps at the receiver discussed above may be implemented in a variety of ways depending upon receiver capability. For example, if the receiver has a large memory available, it can store multiple MPEG sections and operate the verification process once a corresponding signature section has been received. Alternatively, the transmitter may compute and send the signature section in advance of the MPEG sections to which the signature section relates, thereby requiring the receiver to store only the signature section. These possibilities are discussed as possible variations below. Variations

Various variations are possible within the improvement. In particular, the manner in which the additional signature data is multiplexed into the MPEG transport stream may be varied according to the needs of the system and constraints of receivers.

The signature sections are preferably multiplexed using the same PID as the data being signed. Figure 2a shows a first option for multiplexing in which the signature section is inserted after the data to which it refers. This approach is computationally simple at the transmitter, but we have appreciated may not be optimum at the receiver as it requires the storing of sections until the signature section is received. Figure 2b shows an alternative in which the signature section is sent first with the advantage that the receiver only has to store the (small) signature section, rather than store and delay processing of the data itself. Figure 2c shows a variation in which the signature section is sent periodically with the advantage that bit errors that corrupt the signature section don't mean the loss of all the data covered by it. A receiver may store MPEG sections that have not yet been checked against a signature section in order to await the arrival of one or more signature sections. When a signature section is received, the receiver may then check the integrity of stored MPEG sections and for each one, either reject it or accept it for further processing.

The receiver may reject any MPEG section for which no corresponding hash output is present in a verified signature section previously received. Alternatively, the receiver may implement a timeout and reject an MPEG section only once a particular period of time has passed and no signature section has been received and verified that includes a hash output for that section, as determined by the section identifying information.

The signature sections may be sent using a separate PID. This PID could be a well-known PID value when carrying signatures relating to parts of the Transport Stream not specifically associated with an individual MPEG Program or DVB Service. For signatures relating to a specific Program or Service, the PID would be identified by an entry in the Program Map Table (PMT) for that service using a stream_type value allocated for the purpose or by using the private_section (0x05) stream_type defined by MPEG, in combination with a descriptor identifying the PID as carrying signature data.

When the data to be sent changes, a new version of the signature section is created including hashes for the updated sections and dropping hashes of sections (or section versions) no longer being transmitted. Further variations are possible such as a signature section that includes hashes for a rolling window of MPEG sections that a receiver will encounter before and/or after. The receiver need not verify repetitions of a data section it has seen before if it has cached the previously-verified section. Computation of hash values is generally faster than verification of signatures. To aid low performance receivers that cannot verify signatures frequently, a signature section can also include a hash of an earlier signature table section. Low performance devices, provided they can store data for a little longer before verification, can then choose to verify 1 in every N sections at the expense of a little more delay.

Figure 2d shows a further variation in which the process is extended to allow verification of an earlier signature section without requiring verification of the signature contained in that section. This can be considered a kind of tiered approach. Since a signature section is itself a section according to the MPEG standard, it may be hashed and verified according to the process described.

A flag (referred to as the forward_reference_flag) can be set in a signature section to indicate that its integrity can be checked in this way by checking its hash together with the signature of a subsequent signature section. Low performance devices wishing to take advantage of this verification option must store the signature section until another signature section that contains a hash for the section is received and verified. In all variations, the receiver is arranged to discard a signature section with an incorrect CRC. Any section of normal data received that has a valid CRC must then be checked against the hash in the verified signature section (after setting current_next_indicator to 1 as described above) and discarded if the hash doesn't match.

Further Improvement - Source of Trust

To establish trust, a public key is needed at the receiver that is trusted in the sense that the public key is known (to an appropriate level of confidence) to have been supplied by the broadcaster. Various approaches to the problem of supplying the public key to a receiver are possible, but we have appreciated that many such approaches require a separate communication channel, and this is to be avoided if possible.

It is normal cryptographic practice to authenticate data received over a remote connection through the use of cryptographic asymmetric public-private keys to digitally sign the data before publishing. A relying party can then subsequently independently verify the data has not been tampered with or altered after publication by the signing author by performing well-known cryptographic techniques on the received data. However, in order to establish that the signed data was indeed signed by the author rather than some other third party, the process depends on the relying party having independently verified that the public key used in the validation is exclusively controlled by the assumed author. This is normally done by what is known as Out of band' methods, whereby communication and assurance of key pair ownership is established through an external process outside of the data transaction to be authenticated and may for instance involve a prior physical meeting of author and relying party to faithfully establish such ownership.

This improvement describes an alternative way in which a relying party (the receiver, on behalf of a user), may receive and infer trust in specific public key material transmitted over an un-obfuscated channel without necessarily using Out of band' techniques. This invention is aimed at applications where the risk-benefit analysis of not relying on independent verification is favourable and uncertainty in execution may be mitigated through external means, for instance, external lookups, receiver resets or temporary suspension of operation.

This improvement to supplying a public key to a device may be used in conjunction with the main improvement or separately.

The proposed improvement is to broadcast a public key, such as periodically in MPEG sections or in a well-known location in a DSMCC carousel. The receiver is arranged to maintain a table for all the channels it knows, identified using DVB identifiers (original network ID, transport ID, service ID), recording each public key (or hash of it) that has been seen on that channel, plus a count relating to the number of times that key has been seen. The key with the greatest count may then be used as the basis of trust for that channel. If no key is present, there is no trust and the channel's data cannot be verified. Optionally, if the receiver is internet connected, keys can also be checked on the internet. For example, a trusted third party or regulator may manage the delegation of responsibility for broadcast networks by original_network_id and provide secure access through for example secure web sites, such that the receiver can request the public keys for a specific service by using the DVB identifiers original_network_id, transport_stream_id, service_id. This can be achieved by the receiver forming an https URL consisting of some static elements together with these identifiers. The identifiers can form part of the domain name of the URL or part of the path. The receiver can then make a secure request to retrieve information from that URL using the standard HTTP and TLS protocols, obtaining keys.

The security of this improvement relies on the persistence of a broadcast package over the days, weeks and years that a device may operate to reject (or rather ignore) assertions that persist for less than the same duration of alternative packages. By gaining trust in a single key (notwithstanding key update as described here), there is a single path by which other authoritative data can be sent. An attacker may introduce alternative or additional public key data into the broadcast stream, however, a new public key will have to persist longer than the current observed package has already persisted for the device to switch over to it. The attacker may replace the instances of the persistent package in order to seduce devices into building up trust in their package rather than the original persistent package. In this case the device can optionally raise an alarm that an alternative public key has been received. In an internet-connected device, this alarm can be in the form of a notification to the owner of the original key. In other cases, the alarm can be in the form of an alert to the user.

The attacker may be waiting for a specific target device to be initiated so as to arrange a local attack on a receiver with no history of observations of the persistent certificate and therefore no established package. However such attack would only benefit a situation in which the attacker is aware that such a 'first-start' is possible. The invention of this improvement mitigates the vulnerability of a man-in- the middle at the point of first-start.

On removal of the attacker data, (after attack) the device will observe a change in the certificate and will be aware that an attack may have occurred. The device may indicate this so that remedial action can be taken by the user.

It is additionally possible, for systems that are particularly sensitive to such man-in-the-middle attacks to offer added protection through extra knowledge from a known source. For example, on start-up, user checks hash of key, as presented by the device, in a TV or radio listings magazine, TLS-secured website and so on.

The technique of enabling confidence to build in a trusted public key can also be applied to public keys associated with each individual service the receiver can receive.

In this case, the same principles apply as described above, but now the receiver has a list of public keys for which it has established an independent confidence level based on the number of times it has observed the public key information associated with each subject. In a typical embodiment the subject in the broadcast key certificate will be consistent with the broadcast service data making up the broadcast service in which it was conveyed.

As described above for the single trusted public key, the confidence level grows such that an attacker would have to persist for a longer time than the hitherto established key in order to imply it was in fact the rightful key data for the service.

In order to maintain a minimum degree of confidence across a number of independently acquired public keys, a newly introduced service and public key may be required to exceed a fixed initial threshold of confidence before the receiver can infer trust in that key. In an alternative scheme, the minimum confidence scheme might be proportionate to the established confidence level already associated with the other established trusted keys. The broadcast key certificate may be delivered in the broadcast stream in a variety of ways. It may be expressed using the X.509 certificate format and included as a file in a DSMCC object carousel. In this case, the signature_key_identifier_byte values of the signature_section may include the filename of the file in the carousel or the filename to use may be known to the receiver. Alternatively, the broadcast key certificate may be delivered using the MPEG section format as shown in table 2.

Table 2

Syntax Number of Identifier

bits

certificate_section() {

table_id 8 uimsbf section_syntax_indicator 1 bslbf reserved_future_use 1 bslbf reserved 2 bslbf sectionjength 12 uimsbf table_id_extension 16 uimsbf reserved 2 bslbf version_number 5 uimsbf Syntax Number of Identifier bits

cu rre nt_n ext_i nd i cato r 1 bslbf section_number 8 uimsbf last_section_number 8 uimsbf time_nonce_length 8 uimsbf for (i=0;i<N;i++) {

time_nonce_byte 8 bslbf

}

key_identifier_length 8 uimsbf for (i=0;i<N;i++) {

key_identifier_byte 8 bslbf

}

key_algorithm 8 uimsbf key_parameters 8 uimsbf key_length 8 uimsbf for (i=0;i<N;i++) {

key_byte 8 bslbf

}

alternative_key_flag 1 bslbf reserved 7 bslbf if (alternative_key_flag == ) {

alternative_key_identifier_length 8 uimsbf for (i=0;i<N;i++) {

alternative_key_identifier_byte 8 bslbf

}

alternative_key_algorithm 8 uimsbf alternative_key_parameters 8 uimsbf alternative_key_length 8 uimsbf for (i=0;i<N;i++) {

alternative_key_byte 8 bslbf

}

subjectjength 8 uimsbf Syntax Number of Identifier

bits

for (i=0;i<N;i++) {

subject_byte 8 bslbf

}

hash_signature_algorithm_identifier 8 uimsbf for (i=0;i<N;i++) {

signature_byte 8 bslbf

}

CRC_32 32 rpchof

}

The semantics of the fields is as follows:

table_id: A unique value allocated to distinguish certificate table sections from other types of section delivered on the same PID. This value would typically be allocated by MPEG or by a regional organisation such as DVB, ATSC or ARIB. section_syntax_indicator: a 1-bit field that shall be set to .

table_id_extension: a 16-bit field for possible future use that may be used to differentiate independent sets of certificate sections.

version_number: a 5-bit field that shall be incremented by 1 when the information carried changes. When it reaches value 31 , it wraps so that the next value is 0. current_next_indicator: a 1-bit field that shall be set to .

section_number: an 8-bit field that gives the number of the section within the sub- table. This field shall have the value ΌχΟΟ' as only one section is used.

last_section_number: an 8-bit field that gives the number of the last section within the sub-table. This field shall have the value ΌχΟΟ' as only one section is used. time_nonce_length: an 8-bit field that indicates the length of the data contained in the following time_none_byte values.

time_none_byte: one or more 8-bit bytes optionally used to include a nonce in the signed data. This use of this field demonstrates that the signer has access to the private key and is not replaying earlier certificate messages. If used, it is recommended that this field contains a monotonic counter value or a representation of time such as UTC. Receivers may optionally check that the nonce value is not repeated.

key_identifier_length: an 8-bit field that indicates the length of the key identifier contained in the following key_identifier_byte values.

key_identifier_byte: one or more 8-bit bytes forming an identifier for the public key. This field is used to match the key when it is referenced in a signature section or stored by the device. Typically, the key identifier would be a SHA1 or SHA-256 hash of the public key.

key_algorithm: an 8-bit value that identifies the type of public key that follows. The following values are defined:

keyjength: an 8-bit field that indicates the length of the public key contained in the following key_byte values.

key_byte: one or more 8-bit bytes forming the public key.

alternative_key_flag: a 1-bit field that when set to indicates that an alternative key is included.

alternative_key_identifier_length:

alternative_key_identifier_byte:

alternative_key_algorithm: alternative_key_parameters:

alternative_key_length:

alternative_key_byte:

These fields have the same semantics as the preceding fields but describe an optional alternative key that may be associated with the confidence count. In time, future broadcast key certificates may be issued with this as the signing key. subjectjength: an 8-bit field that indicates the length of the subject contained in the following subject_byte values.

subject_byte: one or more 8-bit bytes forming a string describing the entity to be associated with the public key once trusted. Typically this would be set to a URL or DNS domain name.

hash_signature_algorithm_identifier: an 8-bit value that identifies the signature algorithm used to calculate the section signature that forms the signature_byte fields. The following values are defined:

signature_byte: one or more 8-bit bytes forming a digital signature calculated using the algorithm specified in the hash_signature_algorithm_identifier field using the key contained in the key_byte fields. The input data for the signature algorithm is the entire section up to but not including the first signature_byte. If the hash_signature_algorithm_identifier refers to the ECDSA algorithm, the Elliptic Curve used to generate the signature is the same curve as specified in the key_parameters field. The total number of signature_byte bytes present is determined by the signature algorithm and key being used,

reserved: shall be set to .

reserved future use: shall be set to . At a receiver, a self-signed broadcast key certificate is received and the receiver notes the time of arrival according to an internal clock.

The device verifies the integrity of the received broadcast key certificate through signature validation based on the public key it conveys and the signed part of its internal data. In an alternative embodiment in which a time or nonce field is included, the time field value is verified as being later than the time field of the previous certificate The key ID preferably has a relationship to the public key. In this case, the key ID conveyed within the broadcast key certificate is checked as having the required relationship with the key value in the broadcast key certificate. For example, an embodiment may choose to use a well-known cryptographic hash function on one or more components of the key value to represent the key ID. In another where the key length is not prohibitive, it may choose the whole or large part of the binary representation of a public key component as the Key ID representation.

The time of the previous observation of the same broadcast key certificate is retrieved from the device stored data.

If the device current time, determined by a device controlled clock at the time of reception of the broadcast key certificate, is not greater than the retrieved time of the previous noted observation by some pre-defined threshold then the table of stored values associated with this broadcast public key is not updated as a result of receiving this broadcast key certificate.

If the device current time is greater than the retrieved time of the previous noted observation by a pre-defined threshold then the table count is incremented by one and the time of the last noted observation updated with the time associated with this observation of the broadcast key certificate.

Preferably, for the purposes of measuring the time between observations of a certificate, a monotonic clock is used that is not influenced by any timing information present in the broadcast stream. This ensures that an attacker cannot affect the application of the threshold by manipulating the broadcast stream.

The confidence level of public key is given by the count value which is related to the duration over which the broadcast key certificate has been observed in the stream.

When the receiver seeks to determine which public key is considered the trusted key associated with a particular subject, (e.g., the key associated with a known DVB URL or organisation DNS registered domain, appropriate to the context of the embodiment) the receiver consults the internal table of data for an entry containing the subject.

Where no entry exists, no trust has been established that associates a public key with that subject.

Where a single entry exists and the count exceeds any embodiment imposed thresholds, the associated public key can be declared the trusted public key for that subject.

Where there is more than one entry for a given subject, the entry with the highest count is considered the trusted public key for that subject, after checking the count exceeds any embodiment imposed thresholds. Example schematic of receiver data.

Note that when the receiver detects there is more than one row with the same subject, an embodiment may wish to log or raise an alarm. Furthermore, when the confidence count of a row exceeds another row with the same subject, an embodiment may use this to log or raise an alarm or system message.

Once trust has been established in a public key, it may be desirable to replace the key with a new key and at the same time transferring the confidence aggregated in the first key to the second. This is possible by means of including the alternative key and alternative key ID in the key data broadcast key certificate such that the receiver can use a broadcast key certificate with either key ID to update the trust status table with either key ID or alternative key ID present in the Key ID field.

When subsequently a broadcast key certificate is received with the signing key ID replaced by a previous alternative key id, this becomes the key returned to the device on successful enquiry for a known subject public key.

Advantages of the Improvements

Various advantages of the main and further improvement are described below. The arrangements do not require a receiver to store secrets which would likely not be practical for free to air receivers for broadcast television.

Digital signature algorithms require a lot of computation. Whilst the processing power of television devices is increasing all the time, they are still limited in what they can do. The solutions can run effectively on low-end consumer devices. Broadcast capacity is limited so it is important that any additional signalling introduced does not require significant extra bitrate. The insertion of extra MPEG sections does not significantly increase the bitrate and the optional use of truncated hashes and compact ECDSA signatures minimises this. Another way of minimising bitrate and computation is to combine a large amount of data to be signed, thus reducing the frequency of the signature messages and reducing the number of signature verifications needed by the receiver. This variation is possible within the embodiments. However, this introduces delay as the receiver cannot then act on the data until it receives the signature, and must store the data until then. On receivers with limited memory, this may also be undesirable.

Signatures are included as separate MPEG sections from the data that they relate to. This reduces risks of incompatibility with large numbers of receivers that are already in the market. The challenge of associating the data with the signature is addressed by the embodiments.

If a lot of data is covered by one signature, and there is some corruption of a small part due to broadcast reception errors, under some schemes, the entirety of the signed data would have to be rejected. This can be avoided in the embodiments.

Establishing some root of trust by which signatures can be verified as belonging to the expected broadcaster is a big challenge in an open, broadcast-only system. Creating a public key infrastructure specifically for this is challenging because of the need for a suitable trusted organisation to run it. The further improvement obviates this problem.

Claims

1. A method of broadcasting data in an MPEG transport stream on an audio- video broadcast network, the data being arranged as MPEG sections, comprising: - processing MPEG sections using a hash function to provide multiple hash outputs, each hash output being associated with one or more of the MPEG sections by section identifying information;

- signing the hash outputs and corresponding section identifying information using a private key corresponding to a public key available at receivers to produce signatures;

- encoding the hash outputs, corresponding section identifying information and signatures into one or more MPEG sections designated as signature MPEG sections; and

- broadcasting the signature MPEG sections in the MPEG transport stream.

2. A method according to claim 1 , wherein the processing using a hash function comprises producing a separate hash output for each MPEG section.

3. A method according to claim 1 , wherein the processing using a hash function comprises producing a separate hash output for groups of MPEG sections.

4. A method according to any of claims 1 , 2 or 3, wherein the processing using a hash function comprises processing selected elements of each MPEG section but excluding a CRC element.

5. A method according to any preceding claim, wherein the section identifying information comprises a combination of one or more of the following elements: table_id, section_syntax_indicator, table_id_extension, version_number, and section_number.

6. A method according to any preceding claim, wherein each signature MPEG section is inserted into the MPEG transport stream after the respective MPEG sections identified by the section identifying information of the respective signature MPEG section.

7. A method according to any preceding claim, wherein each signature MPEG section is inserted into the MPEG transport stream before the respective MPEG sections identified by the section identifying information of the respective signature MPEG section.

8. A method according to any preceding claim, wherein one or more of the MPEG sections that are processed using the hash function, signed and encoded are themselves designated as signature MPEG sections.

9. A method according to claim 8, wherein selected ones of the signature MPEG sections contain hash values of other signature MPEG sections to provide a tiered arrangement.

10. A method according to claim 8 or 9, further comprising including an indicator in one or more of the signature MPEG sections to indicate that its contents are verified by another of the signature MPEG sections.

1 1. A method according to any preceding claim, wherein the section identifying information includes the values of one or more bytes that follow a section_number element.

12. A method according to claim 11 , wherein the section identifying information includes additional data to match against the section contents depending upon the type of data conveyed by the section.

13. An encoder for encoding data for broadcast in an MPEG transport stream on an audio-video broadcast network, the data being arranged as MPEG sections, comprising:

- means for processing MPEG sections using a hash function to provide multiple hash outputs, each hash output being associated with one or more of the MPEG sections by section identifying information;

- means for signing the hash outputs and corresponding section identifying information using a private key corresponding to a public key available at receivers to produce signatures;

- means for encoding the hash outputs, corresponding section identifying information and signatures into one or more MPEG sections designated as signature MPEG sections; and

- means for broadcasting the signature MPEG sections in the MPEG transport stream.

14. An encoder according to claim 13, wherein the processing using a hash function comprises producing a separate hash output for each MPEG section.

15. An encoder according to claim 13,, wherein the processing using a hash function comprises producing a separate hash output for groups of MPEG sections.

16. An encoder according to any of claims 13, 14 or 15, wherein the processing using a hash function comprises processing selected elements of each MPEG section but excluding a CRC element.

17. An encoder according to any of claims 13 to 16, wherein the section identifying information comprises a combination of one or more of the following elements: table_id, section_syntax_indicator, table_id_extension, version_number, and section_number.

18. An encoder according to any of claims 13 to 17, wherein each signature MPEG section is inserted into the MPEG transport stream after the respective MPEG sections identified by the section identifying information of the respective signature MPEG section.

19. An encoder according to any of claims 13 to 18, wherein each signature MPEG section is inserted into the MPEG transport stream before the respective

MPEG sections identified by the section identifying information of the respective signature MPEG section.

20. An encoder according to any of claims 13 to 19, wherein one or more of the MPEG sections that are processed using the hash function, signed and encoded are themselves designated as signature MPEG sections.

21. An encoder according to claim 20, wherein selected ones of the signature MPEG sections contain hash values of other signature MPEG sections to provide a tiered arrangement.

22. An encoder according to any of claims 20 or 21 , further comprising including an indicator in one or more of the signature MPEG sections to indicate that its contents are verified by another of the signature MPEG sections.

23. An encoder according to any of claims 13 to 22, wherein the section identifying information includes the values of one or more bytes that follow a section_number element.

24 An encoder according to claim 23, wherein the section identifying information includes additional data to match against the section contents depending upon the type of data conveyed by the section.

25. A method of processing received broadcast data in an MPEG transport stream on an audio-video broadcast network, the data being arranged as MPEG sections, at least some of the MPEG sections being designated as signature MPEG sections containing hash outputs and section identifying information of other MPEG sections in the received broadcast the signature MPEG sections having been signed using a private key, comprising determining, for each MPEG section, whether the MPEG section is a signature MPEG section; and

for MPEG sections that are determined to be signature MPEG sections;

- verifying that the signature of one or more signature sections is consistent with the signed contents using a public key corresponding to the private key;

for at least some other MPEG sections

- processing each of the MPEG sections using a hash function to provide a hash output;

- comparing the hash output of each of the MPEG sections with the corresponding hash output contained in one of the signature MPEG sections; and

26 A method according to claim 25, further comprising receiving, storing and deferring processing of MPEG sections until signature MPEG sections with section identifying information for those MPEG sections are received.

27. A method according to claim 25, further comprising receiving and storing signature MPEG sections until MPEG sections designated by the section identifying information of the signature MPEG sections are received.

28. A method according to claim 26 or 27, further comprising rejecting MPEG sections for which no signature MPEG section is received that contains corresponding section identifying information.

29. A method according to any of claims 25 to 28, comprising processing all of the MPEG sections for which signature MPEG sections are received.

30. A method according to any of claims 25 to 28, comprising processing all of the MPEG sections.

31. A method according to any of claims 25 to 28, comprising processing selected ones of the MPEG sections.

32. A method according to any of claims 25 to 31 , wherein the corresponding hash output contained in one of the signature sections is identified by the section identifying information.

33. A method according to any of claims 25 to 32, comprising rejecting signature MPEG sections for which the signature is not consistent with the signed contents.

34. A decoder for processing received broadcast data in an MPEG transport stream on an audio-video broadcast network, the data being arranged as MPEG sections, at least some of the MPEG sections being designated as signature MPEG sections containing hash outputs and section identifying information of other MPEG sections in the received broadcast the signature MPEG sections having been signed using a private key, comprising means for determining, for each MPEG section, whether the MPEG section is a signature MPEG section; and for MPEG sections that are determined to be signature MPEG sections;

- means for verifying that the signature of one or more signature sections is consistent with the signed contents using a public key corresponding to the private key;

for at least some other MPEG sections

- means for processing each of the MPEG sections using a hash function to provide a hash output;

- means for comparing the hash output of each of the MPEG sections with the corresponding hash output contained in one of the signature MPEG sections; and

- means for rejecting MPEG sections for which the comparing step determines that the hash output and corresponding hash output contained in one of the signature MPEG sections do not match.

35. A decoder according to claim 34, further comprising receiving, storing and deferring processing of MPEG sections until signature MPEG sections with section identifying information for those MPEG sections are received.

36. A decoder according to claim 34, further comprising receiving and storing signature MPEG sections until MPEG sections designated by the section identifying information of the signature MPEG sections are received.

37. A decoder according to claim 35 or 36, further comprising rejecting MPEG sections for which no signature MPEG section is received that contains corresponding section identifying information.

38. A decoder according to any of claims 34 to 37, comprising processing all of the MPEG sections for which signature MPEG sections are received.

39. A decoder according to any of claims 34 to 38, comprising processing all of the MPEG sections.

40. A decoder according to any of claims 34 to 38, comprising processing selected ones of the MPEG sections.

41. A decoder according to any of claims 34 to 40, wherein the corresponding hash output contained in one of the signature sections is identified by the section identifying information.

42. A decoder according to any of claims 34 to 41 , comprising rejecting signature MPEG sections for which the signature is not consistent with the signed contents.

43. A transmitter comprising the encoder of any of claims 13 to 24.

44. A receiver comprising the decoder of any of claims 34 to 42.

45. A system comprising the transmitter of claim 43 and receiver of claim 44.

46. A method of processing received broadcast data provided on a broadcast channel, to establish a trusted public key provided on the broadcast channel, comprising at a receiver:

- periodically receiving one or more public keys on the broadcast channel;

- storing public keys that have been seen on that channel, and a count that relates to the number of times that each public key has been received;

- determining the public key that has the highest count; and

- asserting the public key with the highest count as the trusted public key.

47. A method according to claim 46, wherein the count is increased only if the time since the public key was last received exceeds a threshold.

48. A method according to claim 46, wherein the count is increased each time the corresponding public key is received.

49. A method according to any of claims 46 to 48, comprising receiving a separate public key for each separate service the receiver can receive and maintaining separate counts relating to the number of times that each separate public key has been received.

50. A method according to any of claims 46 to 49, comprising determining a confidence level using the count of the number of times that each public key has been received and asserting the public key as a trusted key if the confidence level exceeds a threshold.

51. A method according to any of claims 46 to 50, further comprising replacing a trusted key with a new key by transferring the confidence aggregated in the one key to another.

52. A method according to claim 51 , wherein transferring confidence is by a process involving including the new key and new key ID in a message signed with a trusted key such that the receiver can then assign the confidence in that trusted key to the new key.

53. A decoder for processing received broadcast data provided on a broadcast channel, to establish a trusted public key provided on the broadcast channel, comprising at a receiver:

- means for periodically receiving one or more public keys on the broadcast channel;

- means for storing public keys that have been seen on that channel, and a count that relates to the number of times that each public key has been received;

- means for determining the public key that has the highest count; and

- means asserting the public key with the highest count as the trusted public key.

54. A decoder according to claim 53, wherein the count is increased only if the time since the public key was last received exceeds a threshold.

55. A decoder according to claim 53, wherein the count is increased each time that each public key is received.

56. A decoder according to claim 53, 54 or 55, comprising means for receiving a separate public key for each separate service the receiver can receive and means for maintaining separate counts relating to the number of times that each separate public key has been received.

57. A decoder according to any of claims 53 to 56, comprising means for determining a confidence level using the count of the number of times that each public key has been received and means for asserting the public key as a trusted key if the confidence level exceeds a threshold.

58. A decoder according to any of claims 53 to 57, further comprising means for replacing a trusted key with a new key by transferring the confidence aggregated in the one key to another.

59. A decoder according to claim 58, wherein transferring confidence is by a process involving including the new key and new key ID in a message signed with a trusted key such that the receiver can then assign the confidence in that trusted key to the new key.

60. A receiver comprising the decoder of any of claims 53 to 59.

61. A system comprising a transmitter and a receiver of claim 60.

62. A computer program which when executed undertakes the method of any of claims 1 to 12, 25 to 33 or 46 to 52.