KR20190013406A - Method and apparatus for providing broadcast service - Google Patents

Abstract

A method for providing a broadcast service is provided. The method includes the processes of: transmitting a user datagram protocol (UDP)/Internet protocol (IP) packet including a first message containing information on a message to be signed and transmitted; and transmitting a moving picture experts group (MPEG) media transport protocol (MMTP) packet including a second message containing information on a broadcast service and information indicating whether the information on a broadcast service is signed. The first message includes an identifier of a key necessary to verify a signature of the message to be signed and transmitted and an identifier of a hash algorithm used to calculate a hash value of the message to be signed and transmitted.

Description

[0001] METHOD AND APPARATUS FOR PROVIDING BROADCAST SERVICE [0002]

The present disclosure relates to a method and apparatus for providing a broadcast service, and more particularly, to a security method and apparatus for providing a broadcast service.

It is possible to provide information for receiving and using components constituting each service for broadcasting service provisioning. At this time, in the process of providing information for receiving and using components constituting each service, information may be changed or error may occur due to external intervention. If the receiver does not know that the information has changed or an error has occurred, it may process the changed or erroneous information and may not receive the correct broadcasting service. To prevent this, a security method and apparatus for providing a broadcasting service are required.

The present disclosure relates to a method and apparatus for providing a broadcast service, and more particularly, to a security method and apparatus for providing a broadcast service.

The present disclosure provides a method for providing a broadcast service, comprising: transmitting a UDP / IP packet including a first message including information on a message to be signed and transmitted; And transmitting a MMTP packet including a second message including information on a broadcast service and information indicating whether information on the broadcast service is signed; Wherein the first message includes an identifier of a key required to verify the signature of the message to be signed and transmitted and an identifier of a hash algorithm used to calculate a hash value of the message to be transmitted to be signed do.

When the information about the broadcast service is a format defined in MPEG, the second message is an MMT format message, and the information about the broadcast service is a format defined by ATSC, the second message is an ATSC format message Lt; / RTI >

Information indicating whether or not the information on the broadcast service is signed includes a flag of 1 bit, and when the value of the flag is 1, information indicating whether or not the information on the broadcast service is signed is transmitted to the broadcast service It may indicate that the information has been signed.

The second message may further include information for confirming the signature if the information about the broadcast service is signed.

The signature may be formed by calculating a hash value using the hash algorithm and encrypting the hash value using the key.

The present disclosure provides a method for receiving a broadcast service, the method comprising: receiving a UDP / IP packet including a first message including information about a message to be signed and transmitted; Receiving an MMTP packet including a second message including information on a broadcast service and information indicating whether information on the broadcast service is signed; Wherein the first message includes an identifier of a key required to verify the signature of the message to be signed and transmitted and an identifier of a hash algorithm used to calculate a hash value of the message to be transmitted to be signed do.

When the information about the broadcast service is a format defined in MPEG, the second message is an MMT format message, and the information about the broadcast service is a format defined by ATSC, the second message is an ATSC format message Lt; / RTI >

Information indicating whether or not the information on the broadcast service is signed includes a flag of 1 bit, and when the value of the flag is 1, information indicating whether or not the information on the broadcast service is signed is transmitted to the broadcast service It may indicate that the information has been signed.

The second message may further include information for confirming the signature if the information about the broadcast service is signed.

Calculating a first hash value of the second message using the hash algorithm and obtaining a second hash value by interpreting the signature using the key; And determining that the second message is valid when the first hash value and the second hash value are equal to each other.

According to the present disclosure, it is possible for a receiver to know that a change of information or an error has occurred, so that a correct broadcast service can be provided or provided.

1 is a diagram illustrating a UDP / IP (User Datagram Protocol / Internet Protocol) packet including an LLS table.
2 is a diagram showing an MMTP (MPEG media transport protocol) packet including MMT messages of a first format or a second format.
3 is a conceptual diagram of a protocol stack of a system for transmission of a broadcast service.
4 is a diagram illustrating an ATSC 3.0 receiver protocol stack.
5 is a flowchart showing an embodiment of a method by which a transmitting apparatus provides a message for a broadcasting service to a receiving apparatus.
6 is a diagram schematically showing a process of digital signing.
7 is a flowchart showing an embodiment of a method by which a receiving apparatus receives a message for a broadcasting service from a transmitting apparatus.
8 is a diagram schematically illustrating a process of verifying a document.
9 is a block diagram illustrating an internal configuration of a transmitting apparatus for providing a broadcasting service according to an embodiment of the present invention.
FIG. 10 is a diagram illustrating an internal configuration of a receiving apparatus for receiving a broadcast service according to an embodiment of the present invention.

The terms used in this specification will be briefly described and the present invention will be described in detail.

Although the terms used in the embodiments of the present disclosure have selected general terms that are widely used in the present invention while taking into consideration the functions of the present invention, they may vary depending on the intention or the precedent of the skilled person in the art, .

In the embodiments of the present disclosure, 'module' or 'subtype' performs at least one function or operation, and may be implemented in hardware or software, or a combination of hardware and software. In addition, a plurality of 'modules' or a plurality of 'parts' may be integrated into at least one module except for 'module' or 'module' which need to be implemented by specific hardware, and implemented by at least one processor (not shown) .

Or "may" may be used in various embodiments of the disclosure to refer to the presence of such a function, operation, or component as disclosed herein, Components and the like. Also, in various embodiments of the invention, the terms "comprise" or "having" are intended to specify the presence of stated features, integers, steps, operations, components, parts or combinations thereof, But do not preclude the presence or addition of one or more other features, numbers, steps, operations, components, parts, or combinations thereof.

In various embodiments of the present disclosure, the expressions "or" and the like include any and all combinations of words listed together. For example, "A or B" may comprise A, comprise B, or both A and B.

&Quot; first, "" second," " first, "or" second, " etc. used in various embodiments of the present disclosure may denote various elements of various embodiments, I never do that. For example, the representations do not limit the order and / or importance of the components. The representations may be used to distinguish one component from another. For example, both the first user equipment and the second user equipment are user equipment and represent different user equipment. For example, without departing from the scope of the various embodiments of the present invention, the first component may be referred to as a second component, and similarly, the second component may also be referred to as a first component.

In the various embodiments of this disclosure, when it is mentioned that an element is "connected" or "connected" to another element, the element may be directly connected or connected to the other element However, it should be understood that there may be other components between the component and the other component. On the other hand, when it is mentioned that an element is "directly connected" or "directly connected" to another element, it is understood that there is no other element between the element and the other element It should be possible.

The terminology used in the various embodiments of this disclosure is used only to describe a specific embodiment and is not intended to limit the various embodiments of the invention. The singular expressions include plural expressions unless the context clearly dictates otherwise.

Unless defined differently in the various embodiments of this disclosure, all terms used herein, including technical or scientific terms, are intended to be synonymous with what is commonly understood by one of ordinary skill in the art to which the various embodiments of the invention pertain It has the same meaning. Terms such as those defined in commonly used dictionaries should be construed to have meanings consistent with the meaning in the context of the relevant art and, unless expressly defined in the various embodiments, interpreted in an ideal or overly formal sense It does not.

Hereinafter, a security method for providing a broadcast service according to an embodiment of the present disclosure will be described with reference to FIGS. 1 to 4. FIG.

1 is a diagram illustrating a UDP / IP (User Datagram Protocol / Internet Protocol) packet including an LLS table. 2 is a diagram showing an MMTP (MPEG media transport protocol) packet including MMT messages of a first format or a second format. 3 is a conceptual diagram of a protocol stack of a system for transmission of a broadcast service. 4 is a diagram illustrating an ATSC 3.0 receiver protocol stack.

Service signaling provides information for discovery and description of broadcast services and consists of two functional elements: Low Level Signaling (LLS) and Service Layer Signaling (SLS). . Here, the service may be a collection of media components provided to the viewer, and the components may be various types of media. One service may be provided continuously or intermittently and may be provided in real-time or non-real-time. A real-time service can consist of a series of TV programs.

Low level signaling (LLS) may refer to a first message that is included in a UDP datagram and transmitted as a User Datagram Protocol / Internet Protocol (UDP / IP) packet with a predetermined IP address / port number. The low level signaling (LLS) may be transmitted as a LLS table (LLS_table ()) to the UDP data 103 of the UDP / IP packet as shown in FIG. 1 shows the structure of a first message.

Service layer signaling (SLS) may refer to a second message transmitted in an MMTP (MPEG media transport protocol) packet that provides an MMT message for locating and acquiring terrestrial UHD broadcast service and its constituent components. Service layer signaling (SLS) may be transmitted as an MMT message to an MSG payload 205 of an MMTP packet as shown in FIG. 2 shows the structure of the second message.

Hereinafter, the first message transmitted by the transmitting apparatus to the receiving apparatus will be described. Here, the transmitting apparatus may be a broadcast base station, and the receiving apparatus may be a user apparatus.

The low level signaling (LLS) may be transmitted as a LLS table (LLS_table ()) to the UDP data 103 of the UDP / IP packet as shown in FIG. A UDP / IP packet transmitting low level signaling may have a predefined IP address and port number. The UDP data 103 of the UDP / IP packet may be the payload of the UDP / IP packet.

The UDP / IP packet can be transmitted using User Datagram Protocol / Internet Protocol. Figures 3 and 4 are diagrams illustrating a conceptual model of a system for transmitting and receiving broadcast services. 3 and 4 illustrate two methods for transmitting a broadcast service.

The method corresponding to the left side of FIG. 3 is based on the MPEG Media Transport (MMT) and transmits the MPU (Media Processing Unit) using MMTP (MMT Protocol).

The method corresponding to the center of FIG. 3 is based on the DASH-IF profile based on the MPEG DASH. The DASH segment is transmitted using the ROUTE (Real-time Object Delivery over Unidirectional Transport) protocol. A) a download application, b) a continuous or discontinuous media belonging to an app based component, or c) an Electroninc Service Guide (ESG) or EA (Emergency Alert) information is transmitted through the ROUTE protocol.

The signaling may be transmitted using the MMT or ROUTE protocol, and the bootstrap signaling information for obtaining the signaling to be transmitted to the MMT or ROUTE may be provided through a service list table (SLT).

The fact that services are transmitted over broadband means that one or more program components are transmitted over broadband rather than over the air, and DASH-IF profiles for MPEG DASH are used over HTTP / TCP / IP in broadband. The media file is a DASH-IF profile based on the ISO Base Media File Format (ISO BMFF) and is used for media transmission, encapsulation, and synchronization via broadcast and broadband networks.

The ATSC 3.0 service is provided using three functional layers of a physical layer, a delivery layer, and a service management layer as shown in FIG.

The physical layer provides a mechanism whereby signaling, service announcements, and IP packet streams are transmitted through the broadcast physical layer and / or the broadband physical layer.

The transport layer provides object and object flow transport functionality. It is possible to operate in UDP / IP multicast over broadcast physical layer as defined in MPEG Media Transfer Protocol (MMTP) or Real-time Object Delivery over Unidirectional Transport (ROUTE) It is possible by cast HTTP protocol.

The service management layer is basically divided into service discovery and collection services such that various types of services, such as linear TV and / or HTML5 application services, are delivered through the physical layer and the transport layer, and support acquisition means.

Hereinafter, information included in the low level signaling (LLS) will be described.

Low level signaling can provide the basic service list configuration and the information needed to obtain service level signaling (SLS) for each service. Signaling Configuration Message (SCM), Certification Collection Message (CCM), Service List Table (SLT), Rating Region Table (RRT), SystemTime, CAP (Common Alerting Protocol), and so on are included in the low level signaling in the terrestrial UHDTV broadcasting system. , A VIT (Version Information Table), a CPT (Content Protection Table), and the LLS table may include at least one of the signaling.

Low-level signaling may include information about a message that is signed and transmitted in a message sent to a service layer signaling (SLS) and / or information for key management.

UDP / IP packets including low-level signaling can be formatted and transmitted in a bitstream structure of the type shown in Table 1 below. [Table 1] may be a binary wrapper of LLS data. The first byte of the UDP / IP packet including the low level signaling may mean an ID value indicating the type of the table transmitted in the corresponding low level signaling.

Table 2 shows the semantics of the LLS table included in the UDP / IP packet.

The LLS_table_id may represent an 8-bit unsigned integer that identifies the type of table to be delivered in the body of the LLS table, and LLS_group_id represents an 8-bit unsigned integer that can associate the current LLS_table with a group of services . The value of LLS_group_id may be unique within this broadcast stream. group_count_minus1 may represent an 8-bit unsigned integer indicating one less than the total number of LLS table groups being transmitted to the current physical layer pipe (PLP). Here, the LLS table group means a set of LLS_tables having the same LLS_group_id. If the value of group_count_minus1 is 0, it indicates that there is one LLS table group in the current physical layer pipe (PLP). If the value is 1, it indicates that two LLS table groups exist in the current physical layer pipe (PLP) . The LLS_table_version may be an 8-bit unsigned integer that increments by one whenever any data in the table identified by the combination of LLS_table_id and LLS_group_id is changed. If LLS_table_version increases by 1 at its maximum value of 0xFF, its value can be set to 0x00. When there is more than one provider sharing a broadcast stream, LLS_table () can be identified by a combination of LLS_table_id and LLS_group_id.

A signaling configuration message (SCM) among the types of signaling belonging to the low level signaling will be described below.

A signaling configuration message (SCM) may include information about a message that is signed and transmitted among messages sent to the service layer signaling (SLS) and information for verifying such a signature. The information on the signed and transmitted message may be a signed and transmitted message list.

Specifically, the signaling configuration message may include the following configuration.

The signaling configuration message may include a default security configuration applied to the signed and transmitted message described in the signaling configuration message. The signaling configuration message includes a default_hash_algorithm that is an identifier of a default hash algorithm for calculating a hash value of a signed and transmitted message, a default key for verifying the signature of the signed and transmitted message, Default_key_id, which is an identifier of a key, or Default_signature_algorithm, which is an identifier of a default signature algorithm for calculating a signature of a message transmitted in a signed manner.

The signaling configuration message may also include an identifier of the service of the message to be signed and transmitted. In addition, each service may include an identifier of a signed and transmitted message, a default security configuration of a signed and transmitted message, or a security configuration of a signed and transmitted message.

The security configuration of a signed and transmitted message may include a hash algorithm, a key id, or a signature algorithm. The hash algorithm can be included if the default hash algorithm is changed. The key id may be included if the default key is changed. The signature algorithm may be included if the default signature algorithm is changed.

The identifier of the signed and transmitted message may be a binary coding (for example, 1: USBD, 2: S-TSID, etc.) or a character string (for example, string of characters (e.g., USBD, S-TSID, etc.). The identifier of the signed and transmitted message may be at least one of packet_id, message_id or atsc3_message_content_type (when message_id = 0x8100) in the case of the MMT (MPEG Media Transport) protocol.

In addition, the signaling configuration message may include an LLS_group_id, which is an identifier of an LLS table group. A plurality of broadcasters can share a frequency within one frequency, and in this case, it is possible to provide LLS signaling for different broadcasters within one frequency. In this case, the LLS table group may mean a group of LLS tables provided by one broadcaster. The signaling configuration message may include information indicating which information is transmitted and protected for each LLS table group. The signaling configuration message may comprise, by each LLS_group_id, a default security configuration applied to the LLS table of the corresponding LLS table group, an identifier of the LLS table, or a security configuration.

According to another embodiment of the present disclosure, the signaling configuration message carries only information for the signed LLS table, and the information for each service is stored in a service-list table (SLT) Element may be provided in a sub-element. The service list table may be a table containing signaling information used for providing a basic service list configuration and a bootstrap for obtaining service layer signaling.

A Certification Collection Message (CCM) among signaling types belonging to low level signaling will be described below.

The proof-gathering message may include at least one certificate, and each certificate may include a current verification key.

According to another embodiment of the present disclosure, the proof acquisition message may further include security configuration information (such as a hash algorithm, key ID, or signature algorithm) applied to a signature that can be verified using a certificate.

The service layer signaling may provide information for each service to receive and use the components constituting each service by the receiving device. The service layer signaling may be signaling that provides information for locating and acquiring terrestrial UHD broadcast service and content components that constitute the terrestrial UHD broadcast service.

The service layer signaling may be transmitted in a first type of message or in a second type of message according to the information included in the service layer signaling. For a service that transmits content to an MPU (Media Processing Unit) using the MMTP (Media Media Transport Protocol), the service layer signaling may transmit the MMT signaling message over MMTP / UDP / IP. Service layer signaling (SLS) may be transmitted as an MMT message to the payload of the MMTP packet as shown in FIG. 2 shows the structure of the second message.

The security configuration information and / or timing information for each signature may be communicated with the signature.

When an object-based transport protocol such as the ROUTE protocol is used, the XML signaling can be delivered to an object or package of objects using Secure MIME (S / MIME). When a package of objects is used, each hash of the XML document is signed and attached to the corresponding XML document, or the hashes of all the XML documents in the package are signed at once and sent to the S / MIME wrapper wrapper).

Text data (XML) or binary signaling can be encapsulated in a binary wrapper, and Table 3 shows a first type of binary wrapper (SLS) of the SLS message binary wrapper).

[Table 4] and [Table 5] are the semantics of mmt_atsc3_message.

mmt_atsc3_message () can contain the following components: It may contain a message_id which is a 16-bit unsigned integer field that must uniquely identify mmt_atsc3_message (). It can contain an 8-bit unsigned integer field, version, which increments by 1 each time the information passed in mmt_atsc3_message () changes. When the version field reaches the maximum value of 255, the value can return to zero. A 32-bit unsigned integer field that provides the length in mmt_atsc3_message () in bytes. length. The length field can count from the beginning of the next field to the last byte of mmt_atsc3_message (). and a service_id that is a 16-bit unsigned integer field that associates the payload of mmt_atsc3_message () with the service identified in the serviceId attribute included in the service list table SLT. may contain atsc3_message_content_type, a 16-bit unsigned integer field that uniquely identifies the message content type of the payload of mmt_atsc3_message (). may contain atsc3_message_content_version, an 8-bit unsigned integer field that increments by 1 each time there is a change in the contents of mmt_atsc3_message identified by service_id and atsc_message_content_type and, if present, URI. When the Atsc3_message_content_version field reaches its maximum value, its value can be wrapped around. atsc3_message_content_compression, which is an 8-bit unsigned integer field that identifies the compression type applied to the data at atsc3_message_content_byte. If the 1-bit boolean flag is set to '1', it indicates that elements are present in the authendication_data () structure, and if set to '0', it may include authentication_data_present indicating that no elements exist in the authendication_data () . That is, authentication_data_present may indicate whether the information contained in mmt_atsc3_message is signed. And an URI_length which is an 8-bit unsigned integer field that provides the length of the URI that uniquely identifies the message payload throughout the service. If there is no URI, the value of the URI_length field may be set to zero. And an 8-bit unsigned integer field containing a UTF-8 character of the URI associated with the content carried by this message, excluding the terminating null character. may contain atsc3_message_content_length, a 32-bit unsigned integer field that provides the length of the content carried by mmt_atsc3_message. It may contain atsc3_message_content_byte, which is an 8-bit unsigned integer field containing the bytes of the contents carried by mmt_atsc3_message.

[Table 6] shows the structure of authentication_data that can be included in mmt_atsc3_message when authentication_data_present indicates that the information contained in mmt_atsc3_message is signed.

Table 7 shows the semantics of authentication_data ().

authentication_data () may contain the following fields: content_hash_algorithm_identifier, which is an 8-bit unsigned integer field that uniquely identifies the hash algorithm used to generate the hash of atsc3_message_content () contained in the content_hash field. content_hash_length which is an 8-bit unsigned integer field indicating the number of bytes of the hash data present in the content_hash field. The value of content_hash_length must not be greater than the length of the hash generated by the hash algorithm pointed to by the content_hash_algorithm_identifier field, and should not be less than 8. If the content hash is omitted from the full length hash generated by the hash algorithm, the value of content_hash_length may be less than the length of the hash generated by the hash algorithm. a content_hash_byte which is an 8-bit unsigned integer field including a byte of the content hash which is calculated using the hash algorithm shown in the content_hash_algorithm_identifier field and which is omitted in the content_hash_length and which carries a cryptographic hash of atsc3_message_content. Signature_algorithm_identifier, which is an 8-bit unsigned integer field that uniquely identifies the algorithm used to compute the signature of authentication_data () passed in the signature field. Signature_key_identifier_length, which is an 8-bit unsigned integer field indicating the number of bytes of the signature_key_identifier field that follows. The signature_key_identifier field signifies signature_key_identifier_bytes of the following signature_key_identifier_length. In this case, the value of the signature_key_identifier_length field may be a value equal to or smaller than the total length of the actual public key. Signature_key_identifier_byte, which is an 8-bit unsigned integer field containing the bytes of the truncated identifier for the public key needed to verify the signature contained in the signature field. A sinature_key_identifier consisting of the signature_key_identifier_byte fields shall match the truncated identifier of the public key carried by the trust management mechanism. signature_algorithm_identifier field, which is an 8-bit unsigned integer field containing a byte of a signature that carries a digital signature computed using the algorithm specified in the signature_algorithm_identifier field. The input data for the signature algorithm can be entire authentication_data () except for signature_bytes. The total number of signature_bytes can be determined by the signature algorithm and the key being used.

According to another embodiment of the present disclosure, the input to the signature algorithm may be the entire mmt_atsc3_message (), except for signature_byte.

In a real-time streaming protocol such as MMT, binary signaling can be encapsulated into a binary wrapper containing a signature, and Table 8 is a binary wrapper of a second type of service layer signaling. .

The transmission of mmt_signed_message () means that the information contained in mmt_signed_message () is signed, and the receiving device knows that the information contained in mmt_signed_message () has been signed by receiving mmt_signed_message (). That is, mmt_signed_message () itself can indicate whether the information contained in mmt_signed_message () is signed.

In Table 8, the message_id may be a 16-bit unsigned integer field that uniquely identifies mmt_signed_message (). In Table 8, message () can be an MMT signaling message.

[Table 9] is a table showing an example of the MMT signaling message.

[Table 10] shows the structure of authentication_data () included in mmt_signed_message ().

The sementics of [Table 10] can be the same as the sementics of [Table 7].

Hereinafter, a method for providing a broadcast service and a method for receiving a broadcast service will be described with reference to FIGS.

5 is a flowchart showing an embodiment of a method by which a transmitting apparatus provides a message for a broadcasting service to a receiving apparatus. 6 is a diagram schematically showing a process of digital signing. 7 is a flowchart showing an embodiment of a method by which a receiving apparatus receives a message for a broadcasting service from a transmitting apparatus. 8 is a diagram schematically showing a process of verifying a document.

First, a method of providing a message for a broadcast service from a transmitter to a receiver will be described with reference to FIG.

The transmitting apparatus can confirm the input message (501). Here, the input message may be information for the receiving device to receive and use the components constituting each service, such as the HELD, MPD, and MMT signaling messages described above.

The transmitting apparatus can confirm the format of the input message (502). The transmitting apparatus can confirm whether the input message is an MPEG format corresponding to the MMT signaling message of [Table 9], for example, a PA table, an MP table, or the like. Alternatively, the sending device can check if the input message corresponds to the HELD, MPD, etc. illustrated in the information contained in the atsc3_message_content_type in Table 4. If the input message is identified by the information contained in the atsc3_message_content_type, The input message is encapsulated 509 in mmt_atsc3_message (), and the input message is encapsulated in a second format, mmt_signed_message (), if the input message is identified as information corresponding to the MMT signaling message (509).

At this time, the transmitting apparatus can confirm whether the input message is a message to be signed (503, 507). That is, the transmitting apparatus can confirm whether the input message is signed and transmitted. If the input message is identified by a message to be signed, the input message may be signed 506, 508 before it is encapsulated in mmt_atsc3_message () or mmt_signed_message (). The sending device may determine the certificate to be used for the signature. The sending device can form a signature by calculating the hash value of the input message using a hash function. The sending device may form a low level signaling message including a hash function and / or a certificate used for signing.

The transmitting device may transmit the message encapsulated in the first format or the second format to the receiving device (510). The message encapsulated in the first format or the second format may be the second message. A signature formed in the second message can be transmitted together, or a separate dedicated authentication message including a signature can be formed and transmitted. The transmitting apparatus may transmit the first message to the receiving apparatus before transmitting the first message. The first message may be a message comprising a low-level signaling table.

Here, a signature is a digital signature that identifies the sender (signer) in the public key system and is used to authenticate the identity of the sender by indicating that the sender has signed the electronic document. It may be information in an electronic form attached or logically combined. Alternatively, the signature may be transmitted separately as a dedicated message roll. A recipient can decrypt an electronic document encrypted by its private key with the sender's public key. The recipient subscribing to the service may have the sender's public key.

The digital signature can be composed of three algorithms. The three algorithms can be a key generation algorithm for generating a public key pair, an algorithm for generating a signature using the sender's private key, and an algorithm for verifying the signature using the sender's public key.

Referring to FIG. 6, the signing process includes calculating a hash value through a hash function of the electronic document, encrypting the hash value with the sender's private key to form a signature, . ≪ / RTI > These signatures may be attached to the document or logically combined and transmitted. At this time, certification may also be transmitted with the corresponding electronic document.

Hereinafter, a method of receiving a message for a broadcast service from a transmitting apparatus will be described with reference to FIG.

The receiving apparatus can confirm the received message (701). Here, the received message may be the first message or the second message transmitted by the transmitting apparatus to the receiving apparatus.

The receiving apparatus can confirm the format of the received message. The receiving apparatus can confirm whether the received message is in the MMt_signed_message () format of the second format (702) or the MMt_atsc3_message () format of the first format (703). In FIG. 7, it is confirmed that the second type is a type (702) and the first type is confirmed (703). However, the order may be changed and the first type or the second type may also be determined.

The receiving device processes 704 the received message if the received message is neither in the first format nor in the second format.

The receiving device can verify 705 whether the received message is signed if the received message is in the first format or the second format. If the received message is not signed, the message is extracted from the payload of the received message and processed (706).

The receiving device may store the received message in a buffer if it is signed. If the received message is signed, the receiving device may extract 707 a message from the payload of the received message and verify the signature 708.

Referring to FIG. 8, the process of verifying a document includes calculating a hash value using the hash function of the received document data, calculating a hash value obtained by decoding the signature of the received document using the sender's public key And confirming that the signature is valid if the two values are the same.

Referring again to FIG. 7, the receiving apparatus can calculate a first hash value, which is a hash value of the extracted message, using the hash function (709). The hash function may be included in the received message or may be included in a low level signaling message received by the receiving device before and after the received message. The hash function may be the same as the hash function that the transmitting device used to compute the hash value of the received message. The receiving device may receive and process low level signaling messages to obtain a certificate and identify the signed message.

The receiving apparatus may calculate a second hash value obtained by decoding the encrypted hash value attached to the received message with the public key (709). Here, the encrypted hash value may mean the signature of the received message. The public key is also referred to as a verification key, and the receiving device can receive the certificate including the public key. The receiving device may receive the public key and / or certificate via a low level signaling message.

The receiving apparatus can check whether the first hash value and the second hash value are identical (710). If the first hash value and the second hash value are the same, the signature is correct, and if the values are different or there is an error in the conversion, it can be judged that the signature is wrong. If the signature is incorrect, the message is judged as having a change or an error in the receiving process, and the received message can be discarded without processing (711). If the signature is determined to be correct, the message may be processed (712).

The receiving apparatus can use the previously received low level signaling message in the process of determining whether the received message is a signed message. Since the low level signaling message includes information on a message to be transmitted and signed, the receiving device can know in advance the message to be transmitted through the information included in the received low level signaling message, Whether or not the received message is a signed message, without processing the received message. Therefore, the message processing speed can be improved and unnecessary resource waste can be reduced. In addition, one service can simultaneously provide real-time streaming content and files associated with normal live streaming content. In this case, the system providing the service may separately operate the transmission protocol for real-time streaming and the transmission protocol for file transmission. At this time, the process for processing the signature may be slightly different according to the transmission protocol, but it is preferable in terms of transmission efficiency to transmit common information for the signature to the low level signaling message instead of each transmission protocol .

9 is a block diagram illustrating an internal configuration of a transmitting apparatus for providing a broadcasting service according to an embodiment of the present invention.

9, the transmitting device 900 includes a first transmitter 902, a first receiver 904 and a first controller 906. The first transmitter 902, ). The transmitting apparatus 900 may be a broadcasting base station.

The first controller 906 controls the overall operation of the transmitting apparatus 900. In particular, the first controller 906 controls to perform overall operations related to transmission of the first message and the second message according to an embodiment of the present invention. Here, the overall operation related to the transmission of the first message and the second message is the same as that described with reference to FIG. 1 to FIG. 5, and a detailed description thereof will be omitted here.

The first transmitter 902 transmits various messages according to the control of the first controller 906. Here, various messages and the like transmitted by the first transmitter 902 are the same as those described with reference to FIG. 1 to FIG. 5, and a detailed description thereof will be omitted here.

The first receiver 904 receives various messages and the like under the control of the first controller 906. Here, various messages and the like received by the first receiver 904 are the same as those described with reference to FIG. 1 to FIG. 5, and detailed description thereof will be omitted here.

FIG. 10 is a diagram illustrating an internal configuration of a receiving apparatus for receiving a broadcast service according to an embodiment of the present invention.

10, the illustrated receiving device 1000 includes a second transmitter 1002, a second receiver 1004 and a second controller 1006. The second transmitter 1002, .

The second controller 1006 controls the overall operation of the receiving apparatus 1000. Particularly, the second controller 1006 controls the overall operation related to the reception of the first message and the second message according to the embodiment of the present invention. Here, the overall operation related to the reception of the first message and the second message is the same as that described with reference to FIG. 1 to FIG. 4 and FIG. 6, and a detailed description thereof will be omitted here.

The second transmitter 1002 transmits various messages according to the control of the second controller 1006. Here, various messages and the like transmitted by the second transmitter 1002 are the same as those described with reference to FIG. 1 to FIG. 4 and FIG. 6, and detailed description thereof will be omitted here.

The second receiver 1004 receives various messages and the like under the control of the second controller 1006. Here, various messages and the like received by the second receiver 1004 are the same as those described with reference to FIG. 1 to FIG. 4 and FIG. 6, and a detailed description thereof will be omitted here.

Certain aspects of the invention may also be implemented as computer readable code in a computer readable recording medium. The computer readable recording medium is any data storage device capable of storing data that can be read by a computer system. Examples of the computer-readable recording medium include a read only memory (ROM), a random access memory (RAM), a compact disc Read-only memories (CD-ROMs), magnetic tapes, floppy disks, optical data storage devices, and carrier waves. (Such as data transmission over the Internet). The computer readable recording medium may also be distributed over networked computer systems, and thus the computer readable code is stored and executed in a distributed manner. Also, functional programs, code, and code segments for accomplishing the present invention may be readily interpreted by programmers skilled in the art to which the invention applies.

It will also be appreciated that the apparatus and method according to an embodiment of the present invention may be implemented in hardware, software, or a combination of hardware and software. Such arbitrary software may be stored in a memory such as, for example, a volatile or non-volatile storage device such as a storage device such as ROM or the like, or a memory such as a RAM, a memory chip, a device or an integrated circuit, , Or stored in a storage medium readable by a machine (e.g., a computer), such as a compact disk (CD), a DVD, a magnetic disk or a magnetic tape, have. The method according to an embodiment of the present invention can be implemented by a computer or a mobile terminal including a control unit and a memory and the memory is suitable for storing a program or programs including instructions embodying the embodiments of the present invention It is an example of a machine-readable storage medium.

Accordingly, the invention includes a program comprising code for implementing the apparatus or method as claimed in any of the claims herein, and a storage medium readable by a machine (such as a computer) for storing such a program. In addition, such a program may be electronically transferred through any medium, such as a communication signal carried over a wired or wireless connection, and the present invention appropriately includes equivalents thereof

Also, an apparatus according to an embodiment of the present invention may receive and store the program from a program providing apparatus connected by wire or wireless. The program providing apparatus may include a memory for storing a program including instructions for causing the program processing apparatus to perform a predetermined content protection method, data necessary for the content protection method, and the like, and a wired or wireless communication with the graphics processing apparatus And a control unit for transmitting the program to the transceiver upon request or automatically by the graphic processing apparatus.

Hereinafter, another embodiment according to the present disclosure will be described.

The service layer signaling may provide information for each service to receive and use the components constituting each service by the receiving device. At this time, the service layer signaling message may be signed and transmitted, or a plurality of service layer signaling messages may be signed and transmitted at a time. At this time, security configuration information and / or timing information for signatures of a plurality of service layer signaling messages can be transmitted in a loop in a form of one message at a time.

[Table 11] shows mmt_authentication_message () including information on signatures of a plurality of service layer signaling messages. mmt_authentication_message () can be sent in mmt_atsc3_message or mmt_signed_message, or mmt_authentication_message () can be sent separately from mmt_atsc3_message and mmt_signed_message.

Table 12 shows the semantics of mmt_authentication_message ().

mmt_authentication_message () can contain the following elements: and a message_id that is a 16-bit unsigned integer field that uniquely identifies mmt_authentication_message (). Authentication_group_id, which is a 16-bit unsigned integer field that uniquely identifies the authentication sub_table. A hash algorithm may be used to generate a hash of the signaling message, which may be an 8-bit unsigned integer field that can uniquely identify the message_hash field in message_hash_algorithm_identifier. message_hash_length which is an 8-bit unsigned integer field indicating the number of bytes of the hash data existing in the message_hash field. The value of message_hash_length shall not be greater than the length of the hash generated by the hash algorithm indicated by the message_hash_algorithm_identifier field and shall not be less than 8. The value of message_hash_length may be less than the total length of the hash generated by the hash algorithm, if the hash contained in mmt_authentication_message () contains only part of the total length hash generated by the hash algorithm.

Also, mmt_authentication_message () may include signature_algorithm_identifier, which is an 8-bit unsigned integer field that uniquely identifies the algorithm used to compute the signature passed in the signature field. number_of_hashes, which is an 8-bit unsigned integer field that uniquely identifies the number of hashes of mmt_authentication_message (). And a reference_type that is an 8-bit unsigned integer field that indicates how the signaling message associated with the hash value following is located and identified.

The reference_type can be coded as follows. If the reference_type value is zero, the signaling message is located on the same MMTP session with the same packet_id, and can be identified by the first and second referece_byte and the message_id value carried by itself. The reference_length field may be set to two. If the reference_type value is 1, the signaling message is located on the same MMTP session as the packet_id carried in the first and second reference_bytes, and can be identified by the third and fourth referece_bytes and the message_id value carried by itself . The reference_length field may be set to four. If the reference_type value is 2, the signaling message is located in the MMTP session in the first 10 reference_bytes with the packet_id included in the 11th and 12th reference_bytes, and can be identified by the message_id value and the message_hash in the 13th and 14th referece_bytes have. The reference_length field may be set to 14. If the reference_type value is 3, the signaling message is mmt_atsc_message, which can be identified by the atsc_message_content_type value and message_hash, which are located in the same MMTP session with the same packet_id and carried in the first and second referece_bytes. The reference_length field may be set to two. If the reference_type value is 4, the signaling message can be identified as the mmt_atsc_message in the same MMTP session as the packet_id passed in the first and second reference_bytes, and the third and fourth referece_bytes and the atsc_message_content_type value passed in its own self_hash. The reference_length field may be set to four. If the reference_type value is 5, the signaling message is identified by the atsc_message_content_type value in the 13th and 14th referece_bytes and the message_hash in the mmt_atsc_message located in the MMTP session included in the first 10 reference_bytes together with the packet_id carried in the 11th and 12th reference_bytes. . The reference_length field may be set to 14.

Also, mmt_authentication_message () can contain the following elements. And an 8-bit unsigned integer field that specifies the length (in bytes) of the next reference field. And an 8-bit reference_byte specifying the reference field in order. The syntax and semantics of the reference field can be defined by reference mechanisms identified in the reference_type field. A cryptographic hash of atsc3_message_content calculated using the hash algorithm indicated in the content_hash_algorithm_identifier field can be delivered using the content_hash_length unsigned 8-bit integer field message_hash_byte. Signature_key_identifier_length which is an 8-bit unsigned integer field indicating the number of bytes of the next signature_key_identifier field. Signature_key_identifier_length unsigned 8-bit integer field signature_key_identifier_byte which includes all or part of the public key identifier required for verifying the signature included in the signature field. The consecutive bytes contained in the signature_key_identifier_byte fields shall match the truncation identifier of the public key carried by the trust management mechanism. signature_algorithm_identifier field, which is an 8-bit unsigned integer field containing the signature's byte that carries the digital signature computed using the algorithm specified in the signature_algorithm_identifier field. The input data for the signature algorithm can be the entire mmt_authentication_message () except signature_byte. The number of signature bytes present can be determined by the signature algorithm and the key being used.

The input to the hash algorithm can be part of the overall message or message. At this time, the hash of the message can be computed only from message_payload except for the message_id, version and length fields.

[Table 13] is another embodiment of the above-mentioned mmt_atsc3_message ().

The usage of each field shown in [Table 13] may be the same as the usage described in [Table 5], except for the fields of [Table 14]. Table 14 shows the semantics of mmt_atsc3_message.

Although the use of atsc3_signature_byte described above is described as applying both the atsc3_message_content_byte and atsc3_signature_byte compression algorithms (including uncompressed) identified by the value of the atsc3_message_content_compression field, a separate compression algorithm (including uncompressed) can be applied according to the implementation May be added to the field.

In the embodiment shown in Table 13, when the receiver receives the mmt_atsc3_message (), it can check the value of the atsc3_signature_length field to determine whether the digital signature is applied to the mmt_atsc3_message (). More specifically, when the value of the atsc3_signature_length field is 0, it is found that the digital signature is not applied to the mmt_atsc3_message (). If the value of the atsc3_signature_length field is greater than 0, the digital signature is applied to the mmt_atsc3_message .

[Table 15] is another embodiment of the above-mentioned mmt_signed_message (). Table 16 shows the semantics of mmt_signed_message.

Although the use of mmt_signed_message () described above is described as applying the compression algorithm (including uncompressed) identified by the value of the atsc3_signature_compression field to atsc3_signature_byte only, it is also possible to use the same compression algorithm as that applied to message () or atsc3_signature_byte Compression) can be applied and a field for indicating this can be added.

While the present invention has been particularly shown and described with reference to exemplary embodiments thereof, it is to be understood that the invention is not limited to the disclosed exemplary embodiments, but, on the contrary, It should be understood that various modifications may be made by those skilled in the art without departing from the spirit and scope of the present disclosure.

900: transmitting apparatus
902: first transmitter
904: first receiver
906: first controller
1000: Receiver
1002: second transmitter
1004: second receiver
1006: second controller

Claims (8)

A method for providing a broadcast service,
Transmitting a UDP / IP packet including a first message including information on a message to be signed and transmitted; And
Transmitting an MMTP packet including a second message including information on a broadcast service and length information of the signature; / RTI >
Wherein the first message includes an identifier of a key required to verify the signature of the message to be signed and transmitted and an identifier of a hash algorithm used to compute a hash value of the message to be transmitted,
A method for providing a broadcast service. The method according to claim 1,
When the information about the broadcast service is a format defined by MPEG, the second message is an MMT format message, and the information about the broadcast service is a format defined by ATSC, the second message is ATSC formatted message sign,
A method for providing a broadcast service. The method according to claim 1,
And wherein the second message further comprises information about a byte of the signature. The method according to claim 1,
Wherein the signature is generated by calculating a hash value using the hash algorithm and encrypting the hash value using the key. A method for receiving a broadcast service,
Receiving a UDP / IP packet including a first message including information on a message to be signed and transmitted; And
Receiving an MMTP packet including a second message including information on a broadcast service and length information on the signature; / RTI >
Wherein the first message includes an identifier of a key required to verify the signature of the message to be signed and transmitted and an identifier of a hash algorithm used to compute a hash value of the message to be transmitted,
A method for receiving a broadcast service. 6. The method of claim 5,
When the information about the broadcast service is a format defined by MPEG, the second message is an MMT format message, and the information about the broadcast service is a format defined by ATSC, the second message is ATSC formatted message sign,
A method for receiving a broadcast service. 6. The method of claim 5,
Wherein the second message further comprises information about a byte of the signature. 6. The method of claim 5,
Calculating a first hash value of the second message using the hash algorithm and obtaining a second hash value by interpreting the signature using the key; And
And determining that the second message is valid if the first hash value and the second hash value are equal to each other.
A method for receiving a broadcast service.

Images