Broadcast apparatus and method of authenticating broadcast data

Abstract

A broadcast receiver includes a communicator configured to receive broadcast data including metadata associated with an application and a controller configured to obtain a comparison result by comparing a reference hash with a metadata hash generated based on the metadata, authenticate the metadata based on the comparison result, and launch the application based on a result of the authentication.

Claims

1. A broadcast receiver comprising: a communicator; and at least one processor configured to: control the communicator to receive, from a broadcast transmitter, broadcast data comprising metadata associated with an application, the received metadata comprising authorized server identification information for identifying at least one authorized server authorized to communicate information regarding the application, generate a metadata hash by applying a hash algorithm to the received metadata, control the communicator to transmit, to a server, an authentication request comprising the generated metadata hash and not including the metadata, control the communicator to receive, from the server, a comparison result of comparing a reference hash, the reference hash being stored at the server, with the generated metadata hash, authenticate the received metadata based on the comparison result, and launch the application based on a result of the authentication, wherein the reference hash is generated by the broadcast transmitter by applying the hash algorithm to the metadata associated with the application, the reference hash generated by the broadcast transmitter is transmitted to the server, and the reference hash transmitted to the server is stored at the server.

2. The broadcast receiver of claim 1, further comprising: a display, wherein the at least one processor is further configured to control the display to display information corresponding to the launched application.

3. The broadcast receiver of claim 1, wherein the at least one processor is further configured to compare the generated metadata hash with the reference hash.

4. The broadcast receiver of claim 3, further comprising: a storage configured to store a plurality of reference hashes for a same application, wherein the at least one processor is further configured to select a reference hash from among the stored plurality of reference hashes and compare the selected reference hash with the metadata hash.

5. The broadcast receiver of claim 3, further comprising: a storage configured to store a plurality of reference hashes for a same application and authentication information indicating valid periods for the plurality of reference hashes, wherein the at least one processor is further configured to select a reference hash from among the stored plurality of reference hashes having a valid period at a time when the metadata is received, based on the authentication information.

6. The broadcast receiver of claim 3, wherein the at least one processor is further configured to: control the communicator to transmit a request for the reference hash to the server and receive the reference hash from the server, the request for the reference hash comprising service identification information for identifying a service corresponding to the application, and obtain the comparison result by comparing the received reference hash to the metadata hash.

7. The broadcast receiver of claim 6, wherein the at least one processor is further configured to: control the communicator to receive a plurality of reference hashes from the server in response to the request, and authenticate the metadata by comparing the received plurality of reference hashes with the metadata hash to determine whether a reference hash of the received plurality of reference hashes matches the metadata hash.

8. The broadcast receiver of claim 1, wherein the authentication request comprises the metadata and service identification information for identifying a service corresponding to the application.

9. The broadcast receiver of claim 6, wherein the service identification information comprises at least one of an original network identifier (ON-ID), a transport stream identifier (TS-ID), a service identifier (S-ID), a country identifier (ID) for identifying a country at which the broadcast receiver is located, and a broadcast medium ID for identifying a broadcast medium through which the broadcast data received by the broadcast receiver passes.

10. The broadcast receiver of claim 1, further comprising: a display, wherein the at least one processor is further configured to, in response to the authentication of the metadata failing, control the display to display a warning message indicating that the metadata is not authenticated.

11. The broadcast receiver of claim 1, further comprising: a user input device configured to receive a user input for forcibly executing the application when the authentication of the metadata fails, wherein the at least one processor is further configured to forcibly execute the application, based on the user input.

12. A server for authenticating metadata associated with an application, the metadata comprising authorized server identification information for identifying at least one authorized server authorized for a broadcast receiver to communicate information regarding the application, the server comprising: a storage configured to store a reference hash, wherein the reference hash is generated by a broadcast transmitter by applying a hash algorithm to the metadata and transmitted to the server; a communicator configured to receive an authentication request from the broadcast receiver; and at least one processor configured to obtain a metadata hash of the metadata based on the authentication request by applying the hash algorithm to the metadata, search for a reference hash corresponding to the authentication request in the storage, compare the obtained metadata hash with the reference hash, and control the communicator to transmit a result of the comparison to the broadcast receiver to enable the broadcast receiver to authenticate the metadata based on the result of the comparison.

13. The server of claim 12, wherein the authentication request comprises service identification information for identifying a service corresponding to the metadata, and the at least one processor is further configured to search for the reference hash corresponding to the identified service in the storage.

14. The server of claim 12, wherein the authentication request comprises the metadata hash, and the at least one processor is further configured to extract the metadata hash from the authentication request.

15. The server of claim 13, wherein the at least one processor is further configured to search for a plurality of reference hashes in the storage, compare the metadata hash with the plurality of reference hashes to determine whether the metadata hash matches a reference hash of the plurality of reference hashes, and control the communicator to transmit a result of the comparison to the broadcast receiver.

16. A broadcast transmitter comprising: at least one processor configured to obtain metadata associated with an application, the metadata comprising authorized server identification information for identifying at least one authorized server authorized for a broadcast receiver to communicate information regarding the application, generate a reference hash of the metadata by applying a hash algorithm to the metadata, and insert the metadata into broadcast data; and a communicator configured to transmit the broadcast data including the metadata to the broadcast receiver, wherein the at least one processor is further configured to control the communicator to transmit the reference hash to an external device so that the reference hash is used to authenticate the metadata.

17. A metadata authentication method comprising: receiving, from a broadcast transmitter, broadcast data including metadata associated with an application, the received metadata comprising authorized server identification information for identifying at least one authorized server authorized to communicate information regarding the application; generating a metadata hash by applying a hash algorithm to the received metadata, transmitting, to a server, an authentication request comprising the generated metadata hash and not including the metadata; receiving a comparison result of comparing a reference hash, the reference hash being stored at the server, with the generated metadata hash, wherein the reference hash is generated by the broadcast transmitter by applying the hash algorithm to the metadata associated with the application, the reference hash generated by the broadcast transmitter is transmitted to the server, and the reference hash transmitted to the server is stored at the server; and in response to the comparison result indicating that the reference hash matches the metadata hash, authenticating the metadata and automatically launching the application.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) The above and/or other aspects will become apparent and more readily appreciated from the following description of exemplary embodiments, taken in conjunction with the accompanying drawings in which:

(2) FIG. 1 is a diagram illustrating a broadcast system according to an exemplary embodiment;

(3) FIG. 2 is a flowchart illustrating an operation, performed by a broadcast receiver, of authenticating metadata, according to an exemplary embodiment;

(4) FIG. 3 is a flowchart illustrating a metadata authentication operation according to an exemplary embodiment;

(5) FIG. 4 is a flowchart illustrating a metadata authentication operation according to an exemplary embodiment;

(6) FIG. 5 is a flowchart illustrating a metadata authentication operation according to an exemplary embodiment;

(7) FIG. 6 is a diagram illustrating an example of a display that displays a warning message when authentication of metadata fails;

(8) FIG. 7 is a block diagram illustrating a configuration of a broadcast receiver according to an exemplary embodiment;

(9) FIG. 8 is a block diagram illustrating a configuration of a broadcast receiver according to an exemplary embodiment;

(10) FIG. 9 is a block diagram illustrating a configuration of a server according to an exemplary embodiment;

(11) FIG. 10 is a block diagram illustrating a configuration of a server according to an exemplary embodiment;

(12) FIG. 11 is a flowchart illustrating an operation of a broadcast provider according to an exemplary embodiment;

(13) FIG. 12 is a block diagram illustrating a configuration of a broadcast provider according to an exemplary embodiment; and

(14) FIG. 13 is a block diagram illustrating a configuration of a broadcast provider according to an exemplary embodiment.

DETAILED DESCRIPTION

(15) Reference will now be made in detail to one or more exemplary embodiments, examples of which are illustrated in the accompanying drawings, wherein like reference numerals refer to like elements throughout. In this regard, one or more exemplary embodiments may have different forms and should not be construed as being limited to the descriptions set forth herein. One or more exemplary embodiments are merely described below, by referring to the figures, to explain aspects of the inventive concept. As used herein, the term and/or includes any and all combinations of one or more of the associated listed items. Expressions such as at least one of, when preceding a list of elements, modify the entire list of elements and do not modify the individual elements of the list.

(16) Terms used herein have been selected as general terms which are widely used at present, in consideration of the functions of one or more exemplary embodiments, but may be altered according to the intent of an operator of ordinary skill in the art, conventional practice, or introduction of new technology. Also, a meaning of any arbitrarily selected term in a specific case will be described in detail in a corresponding description portion. The terms should be defined on the basis of the entire content of this specification instead of a simple understanding of each term used in isolation.

(17) In this disclosure below, when it is described that something comprises (or includes or has) some elements, it should be understood that it may comprise (or include or has) only those elements, or it may comprise (or include or have) additional elements if not explicitly limited. Moreover, each of terms such as unit, apparatus, and module used herein denotes an element for performing at least one function or operation, and may be implemented in hardware, software or the combination of hardware and software.

(18) Hereinafter, one or more exemplary embodiments will be described in detail so as to be easily understood by those of ordinary skill in the art with reference to the accompanying drawings. One or more exemplary embodiments may be embodied in many different forms and should not be construed as being limited to the one or more exemplary embodiments set forth herein. Certain well-known elements may be omitted for clarity.

(19) FIG. 1 is a diagram illustrating a broadcast system according to an exemplary embodiment.

(20) Referring to FIG. 1, the broadcast system may include a broadcast receiver 100 such as a television (TV) or a set-top box, a server 200, and a broadcast provider 300.

(21) The broadcast provider 300 may transmit broadcast data to the broadcast receiver 100 through a transmitter. Here, the broadcast data may include data associated with broadcast streaming, metadata, and/or the like, but is not limited thereto.

(22) The metadata may include various pieces of information associated with an application providing a broadcast service. For example, metadata associated with a certain application may include application identification information for identifying an application, service identification information for identifying a service corresponding to an application, authorization server identification information for identifying one or more authorized servers which are authorized for an application to perform communication, and/or the like, but is not limited thereto. The broadcast receiver 100 and the broadcast provider 300 may all communicate with the server 200 over a network 500 such as the Internet or the like.

(23) As illustrated in FIG. 1, the broadcast receiver 100 and the broadcast provider 300 may communicate with the server 200 over the same network 500 or different networks.

(24) The broadcast provider 300 may add metadata associated with an application into broadcast data. The metadata may be used for informing the broadcast receiver 100 that it is possible to launch an application. An operation of launching an application may include installing the application to be executed and executing the installed application.

(25) Metadata may have various forms according to a broadcast standard applied to a broadcast system. For example, in digital video broadcasting (DVB), the metadata may be in the form of an application information table (AIT). The AIT may include a uniform resource locator (URL), connected to a web address for searching for application execution code, and an application identifier (ID). However, the broadcast system according to an exemplary embodiment is not limited to a case of using DVB.

(26) When metadata is transmitted from the broadcast provider 300 to the broadcast receiver 100 using broadcast data, the metadata may be vulnerable to a man-in-the-middle (MITM) attack. The MITM attack may be an attack method that taps or manipulates communication details by using network communication, and an attacker may arbitrarily alter data between a transmitter and a receiver or may generate new data by using the MITM attack. Therefore, before launching an application on the basis of received broadcast data, the broadcast receiver 100 may check whether the received broadcast data is transmitted by the broadcast provider 300. By authenticating the metadata before launching the application, the broadcast receiver 100 may check whether the transmitted metadata is valid, and may safely launch an application corresponding to the metadata.

(27) The broadcast receiver 100 may authenticate the metadata by using a metadata hash and a reference hash which are generated from the metadata. Here, the metadata hash may be a value which is obtained by applying a hash algorithm to the metadata. The metadata hash may be generated by the broadcast receiver 100 or the server 200.

(28) The reference hash may be a value that is used for comparing with the metadata hash when authenticating the metadata. Here, the reference hash may be generated based on the metadata by the broadcast provider 300. Also, before the broadcast data is transmitted to the broadcast receiver 100, the broadcast provider 300 may previously transmit the reference hash to the broadcast receiver 100 or the server 200. The broadcast receiver 100 or the server 200 may store the transmitted reference hash and then may use the stored reference hash when authenticating the metadata.

(29) Moreover, the reference hash may include a valid period. In this case, a reference hash may be used when authenticating the metadata during its valid period. Also, the reference hash may be updated periodically or according to a user request.

(30) FIG. 2 is a flowchart illustrating an operation, performed by a broadcast receiver, of authenticating metadata, according to an exemplary embodiment.

(31) In operation S201, the broadcast receiver 100 may receive broadcast data including metadata associated with an application executable by the broadcast receiver 100. Here, the metadata may include service identification information for identifying a service corresponding to the application. Also, the metadata may include authorization server identification information for identifying one or more authorization servers that are authorized for the application to perform communication. For example, the authorization server identification information may include a list of authorized URLs, a list of authorized Internet protocol (IP) addresses, and/or the like, but is not limited thereto. When executing the application, the broadcast receiver 100 may prevent the application from communicating with a server which is not identified as an authorization server.

(32) In operation S202, the broadcast receiver 100 may obtain a comparison result by comparing a metadata hash with a reference hash. The metadata hash and the reference hash may be generated by using the hash algorithm. An output generated by using the hash algorithm may be referred to as a hash value, a hash code, or a hash sum, but is not limited thereto.

(33) The metadata hash may be directly generated by the broadcast receiver 100, or may be remotely generated by the server 200.

(34) The reference hash may be generated based on the metadata by the broadcast provider 300. According to an exemplary embodiment, the reference hash may be stored in a local cache of the broadcast receiver 100, or may be stored in the server 200. When the reference hash is stored in the server 200, the broadcast receiver 100 may request the reference hash from the server 200, receive the reference hash from the server 200, and compare the received reference hash with the metadata hash.

(35) In operation S203, the broadcast receiver 100 may authenticate the metadata, based on a result obtained by comparing the metadata hash with the reference hash. When the metadata hash matches the reference hash, the broadcast receiver 100 may check that the received metadata matches the metadata transmitted by the broadcast provider 300. When the metadata is successfully authenticated, the broadcast receiver 100 may automatically launch the application, or may obtain approval from the user and then launch the application.

(36) When the metadata hash does not match the reference hash, the authentication of the metadata may fail. That the metadata hash does not match the reference hash may denote that the metadata received by the broadcast receiver 100 has been changed by an attacker.

(37) The attacker may use a high power transmitter for changing a broadcast signal and metadata, transmitted by a broadcast provider, to its own data. For example, the attacker may change an application URL, directly connected to the broadcast receiver 100, to an application URL connected to another server storing a malicious execution code.

(38) When the authentication of the metadata fails, the broadcast receiver 100 may display a warning message indicating that the metadata is not authenticated. While displaying the warning message, the broadcast receiver 100 may receive a user input for selecting whether to launch the application, despite the metadata being unauthenticated. Also, the broadcast receiver 100 may launch the application or may perform various operations such as launching the application and the like in a protected mode, based on a selection of the user. When the authentication of the metadata fails, the broadcast receiver 100 may perform one or more of the above-described operations, but is not limited thereto.

(39) Hereinafter, a case where a plurality of reference hashes are stored in the broadcast receiver 100 will be described in detail.

(40) According to an exemplary embodiment, a plurality of reference hashes may be stored in the local cache of the broadcast receiver 100. Generally, the metadata may be quasi-static, but the broadcast provider 300 may occasionally update the metadata. When the plurality of reference hashes are stored in the local cache of the broadcast receiver 100 (for example, an internal memory or a local network storage), the broadcast receiver 100 may store authentication information associated with the plurality of reference hashes for the same application along with the plurality of reference hashes. The authentication information may define valid periods of the plurality of reference hashes. The broadcast receiver 100 may select a reference hash, which is valid at a time when the metadata is received, from among the plurality of reference hashes stored in the local cache and may compare a metadata hash with the selected reference hash. Therefore, since the broadcast receiver 100 stores a plurality of reference hashes for the same application along with authentication information, received metadata is accurately authenticated, despite the metadata being updated by the broadcast provider 300.

(41) When a reference hash obtained through an update does not match the metadata hash, the broadcast receiver 100 may determine that the received metadata is invalid.

(42) FIG. 3 is a flowchart illustrating a metadata authentication operation according to an exemplary embodiment.

(43) In operation S301, the broadcast receiver 100 may receive broadcast data including metadata associated with an application.

(44) In operation S302, the broadcast receiver 100 may generate a metadata hash from the metadata. The metadata hash may be generated using a generally known hash algorithm.

(45) In operation S303, the broadcast receiver 100 may transmit, to the server 200, a request for a reference hash for authenticating the metadata. An address of the server 200 for requesting the reference hash may have been previously programmed in the broadcast receiver 100.

(46) The request for the reference hash may include service identification information for identifying a broadcast service provided by the application, in order for the server 200 to search for an accurate reference hash in a storage of the server 200. The broadcast receiver 100 may launch an application corresponding to a service, thereby using the service provided by a service provider 400. A service may correspond to an application in a one-to-one relationship. Here, service identification information may have various forms, and the form of the service identification information may be changed according to a broadcast standard used by the broadcast system. Also, the service identification information may include information of metadata. For example, the service identification information may include a country ID for identifying a country at which the broadcast receiver 100 is located, or a broadcast medium ID for identifying a broadcast medium such as a cable broadcast, an over-the-air broadcast, a satellite broadcast, and/or the like, but is not limited thereto.

(47) Moreover, when broadcast standard used by the broadcast system is DVB, service identification information may include a DVB triplet. The DVB triplet may include an original network ID (ON-ID), a transport stream ID (TS-ID), and a service ID (S-ID). The server 200 may individually identify services provided by an application, based on the DVB triplet and may transmit one reference hash to the broadcast receiver 100.

(48) Service identification information according to an exemplary embodiment may be used to separately identify a certain service, or may be used to identify a plurality of certain services. In detail, since one piece of service identification information may correspond to a plurality of certain services in one or more exemplary embodiments, the service identification information may be used to identify a service corresponding to each of users.

(49) In operation S304, the server 200 may search for the reference hash in the storage of the server 200, based on the transmitted request. When one piece of service identification information corresponds to a plurality of services, the server 200 may search for reference hashes for the plurality of services corresponding to the received service identification information. In operation S305, the server 200 may transmit the reference hash to the broadcast receiver 100. When one piece of service identification information corresponds to a plurality of services, the server 200 may transmit a plurality of reference hashes for the plurality of services to the broadcast receiver 100.

(50) In operation S306, the broadcast receiver 100 may compare the metadata hash with the received reference hash to determine whether the metadata hash matches the received reference hash. If a service corresponds to an application in a one-to-one relationship, and if the metadata received by the broadcast receiver 100 is valid, the metadata hash may match the reference hash received from the server 200. When the metadata hash matches the reference hash, the metadata may be successfully authenticated, and the broadcast receiver 100 may launch the application in operation S308.

(51) However, when the metadata hash does not match the reference hash, the authentication of the metadata may fail. Therefore, the broadcast receiver 100 may display a warning message indicating that the metadata is not authenticated. Even when the authentication of the metadata fails, the broadcast receiver 100 may receive a user input for forcibly executing the application and may forcibly execute the application, based on the user input.

(52) FIG. 4 is a flowchart illustrating a metadata authentication operation according to an exemplary embodiment.

(53) Referring to FIG. 4, the broadcast receiver 100 may receive metadata in operation S401, and may generate a metadata hash from the received metadata in operation S402.

(54) In operation S403, the broadcast receiver 100 may transmit an authentication request for the metadata to the server 200. Here, the authentication request may include a metadata hash and service identification information.

(55) In operation S404, the server 200 may receive an authentication request for the metadata and may extract the metadata hash from the received authentication request. Also, the server 200 may extract the service identification information from the received authentication request and may search for a reference hash for a service corresponding to the extracted service identification information.

(56) In operation S405, the server 200 may compare the reference hash with the metadata hash to determine whether the reference hash matches the metadata hash.

(57) The service identification information may allow a single service among a plurality of services to be individually identified. For example, the server 200 may search for reference hashes for a plurality of certain services in operation S404, and may compare a found plurality of reference hashes with the metadata hash to determine whether one of the found plurality of reference hashes matches the metadata hash in operation S405. The server 200 may compare a plurality of reference hashes with the metadata hash sequentially, and when one of the plurality of reference hashes matches the metadata hash, may terminate operation S405.

(58) In operation S406, the server 200 may transmit a result of the comparison to the broadcast receiver 100. For example, when the metadata hash matches the reference hash, the server 200 may transmit, to the broadcast receiver 100, a message indicating that the metadata is valid. However, when the metadata hash does not match the reference hash, the server 200 may transmit, to the broadcast receiver 100, a message indicating that the metadata is invalid.

(59) In operation S407, the broadcast receiver 100 may authenticate the metadata, based on the comparison result received from the server 200.

(60) In operation S408, when the metadata is successfully authenticated, the broadcast receiver 100 may launch the application.

(61) However, when the authentication of the metadata fails, the broadcast receiver 100 may display a warning message indicating that the authentication of the metadata failed.

(62) In the authentication method illustrated in FIG. 4, a metadata hash may be transmitted as a portion of an authentication request for the metadata instead of metadata. Since a size of the metadata hash is smaller than that of the metadata itself, the broadcast receiver 100 may reduce the amount of data transmitted to the server 200.

(63) FIG. 5 is a flowchart illustrating a metadata authentication operation according to an exemplary embodiment.

(64) Operations S501 and S504 to S508 of FIG. 5 respectively correspond to operations S401 and S404 to S408 of FIG. 4.

(65) Referring to FIG. 5, in operation S502, the broadcast receiver 100 may transmit an authentication request for metadata to the server 200. The authentication request may include the metadata and service identification information.

(66) In operation S503, the server 100 may extract the metadata from the transmitted authentication request and may generate a metadata hash, based on the extracted metadata. The server 200 may use a hash algorithm for generating the metadata hash.

(67) In operation S504, the server 200 may extract the service identification information, from the received authentication request and may search for a reference hash for a service corresponding to the extracted service identification information. Operations S503 and S504 may be performed in a reverse order or may be performed simultaneously.

(68) The server 200 may compare the metadata, generated in operation S505, with the reference hash to determine whether the metadata matches the reference hash, and may transmit a result of the comparison to the broadcast receiver 100 in operation S506.

(69) In the method illustrated in FIG. 4, the broadcast receiver 100 may generate the metadata hash and may transmit the generated metadata hash as a portion of the authentication request. However, in the method illustrated in FIG. 5 the broadcast receiver 100 may transmit the authentication request including all of the metadata to the server 200, and the server 200 may generate the metadata hash.

(70) In the method illustrated in FIG. 5, since the server 200 generates the metadata hash and compares the metadata hash with the reference hash to determine whether the metadata hash matches the reference hash, a processing burden of the broadcast receiver 100 is minimized.

(71) FIG. 6 is a diagram illustrating an example of a display that displays a warning message when authentication of metadata fails.

(72) A display 600 of the broadcast receiver 100 according to an exemplary embodiment may display a warning message indicating that authentication of received metadata fails. While displaying the warning message, the broadcast receiver 100 may receive a user input for selecting whether to launch an application.

(73) As illustrated in FIG. 6, when a user selects YES in operation S601, the broadcast receiver 100 may launch the application despite the authentication of the metadata failing. Alternatively, when NO is selected, the broadcast receiver 100 may not launch the application.

(74) Moreover, when the authentication of the metadata fails, the broadcast receiver 100 according to an exemplary embodiment may launch the application in the protected mode. When desiring to launch the application in the protected mode, the broadcast receiver 100 may execute the application in a state of having a limited authority.

(75) FIG. 7 is a block diagram illustrating a configuration of a broadcast receiver 100 according to an exemplary embodiment.

(76) Referring to FIG. 7, the broadcast receiver 100 according to an exemplary embodiment may include a communicator 110, a controller 120, and a storage 130, e.g., a storage device. According to one or more exemplary embodiments, the broadcast receiver 100 may be implemented with additional elements, for example, a display 140.

(77) The communicator 110 may receive metadata associated with an application from the broadcast provider 300. The communicator 110 may be a transceiver.

(78) The communicator 110 may transmit, to the server 200, a request for a reference hash or an authentication request for the metadata. When the communicator 110 transmits the authentication request for the metadata to the server 200, the authentication request may include service identification information. In other exemplary embodiments, the authentication request may include the metadata or a metadata hash.

(79) When the communicator 110 transmits the request for the reference hash to the server 200, the communicator 110 may receive the reference hash found in the server 200. Alternatively, when the communicator 110 transmits the authentication request for the metadata to the server 200, the communicator 110 may receive a result which is obtained by the server 200 comparing the metadata hash with the reference hash.

(80) The controller 20 may obtain a comparison result of the metadata hash and the reference hash and may authenticate the metadata, based on the obtained comparison result. An operation of comparing the metadata hash with the reference hash may be performed by the controller 120 of the broadcast receiver 100 or may be remotely performed by the server 200. When the metadata hash matches the reference hash, the controller 120 may determine that the metadata, received through the communicator 110, is valid and may launch the application. However, when the metadata hash does not match the reference hash, the controller 120 may determine the received metadata as invalid.

(81) Further, when a plurality of reference hashes are stored in the broadcast receiver 100, the controller 120 may compare the plurality of reference hashes with the metadata hash to determine whether one of the plurality of reference hashes matches the metadata hash.

(82) The controller 120 may select a reference hash, which is valid at a time when the metadata is received, from among the plurality of reference hashes, based on authentication information indicating a valid period of a corresponding reference hash.

(83) The controller 120 may obtain, from the metadata, authentication server identification information for identifying one or more authorized servers which are authorized for the application to perform communication. The controller 120 prevents the application from communicating with an unauthorized server when executing the application, based on the obtained authentication server identification information.

(84) When the authentication of the metadata fails, the controller 120 may perform control a display of a warning message indicating that the metadata is not authenticated. Also, the controller 120 may perform control to forcibly execute the application according to a selection of a user even when the authentication of the metadata fails.

(85) The storage 130 may store a plurality of reference hashes for a same service. Therefore, even when the server 200 cannot be used to authenticate the metadata, the broadcast receiver 100 may authenticate the metadata.

(86) Moreover, the storage 130 may store authentication information indicating valid periods of a plurality of reference hashes.

(87) The display 140 may display information of an application launched by the broadcast receiver 100. When metadata is authenticated, the broadcast receiver 100 may launch the application, based on a result of the authentication. In this case, the display 140 may display the information of the application which includes a name of the launched application, an application description, an icon representing the application, and/or the like, but is not limited thereto. As non-limiting examples, the display 140 may display the information of the application in the form of popups and may display the information as highlights on a lower end of the display 140.

(88) Moreover, when the authentication of the metadata fails, the display 140 may display a warning message indicating that the metadata is not authenticated. As non-limiting examples, the warning message may be displayed in the form of popups and may be displayed as highlights on the lower end of the display 140.

(89) The display 140 may display a message for selecting whether to launch the application, along with the warning message.

(90) FIG. 8 is a block diagram illustrating a configuration of a broadcast receiver 100 according to an exemplary embodiment.

(91) As illustrated in FIG. 8, the broadcast receiver 100 according to an exemplary embodiment may include a reception device 710, a metadata extractor 720, an authenticator 730, a network interface 740, and an application execution device 750. In FIG. 8, the reception device 710 and the network interface 740 may be included in the communicator 110 of FIG. 7, and the metadata extractor 720, the authenticator 730, and the application execution device 750 may be included in the controller 120 of FIG. 7.

(92) The broadcast receiver 100 disclosed in FIG. 8 may perform the authentication method illustrated in FIG. 3. In one or more exemplary embodiments, one or more elements illustrated in FIG. 8 may be omitted.

(93) The reception device 710 may receive broadcast data including metadata associated with an application executable by the broadcast receiver 100.

(94) The metadata extractor 720 may extract metadata from the received broadcast data.

(95) The authenticator 730 may authenticate the metadata, based on a result obtained by comparing a reference hash with a metadata hash.

(96) Referring to FIG. 8, the authenticator 730 may include a hash generator 731 and a hash comparator 732. The hash generator 731 may generate the metadata hash, based on the metadata extracted by the metadata extractor 720. The hash comparator 732 may compare the metadata hash with the reference hash and may authenticate the metadata, based on a result of the comparison. Also, the hash comparator 721 may transmit a request for the reference hash from the server 200 through the network interface 740 and may receive the requested reference hash though the network interface 740.

(97) Moreover, the broadcast receiver 100 may include an application execution device 750 that executes an application corresponding to the extracted metadata. Here, the application execution device 750 may include one or more processors that execute a program instruction included in an application execution code. When the metadata is successfully authenticated, the application execution device 750 may execute the application corresponding to the metadata.

(98) Moreover, the application execution device 750 may search for the application execution code in an external storage 760, e.g., an external storage device, such as an application server, based on a URL included in the metadata. However, the above-disclosed exemplary embodiments are not limited to a case where the application execution code is stored in the external storage 760. In other exemplary embodiments, the application execution code may be stored in the broadcast receiver 100.

(99) FIG. 9 is a block diagram illustrating a configuration of a server 200 according to an exemplary embodiment.

(100) The server 200 may authenticate metadata received from the broadcast receiver 100 according to the method illustrated in FIG. 5.

(101) Referring to FIG. 9, the server 200 according to an exemplary embodiment may include a storage 210, a controller 220, and a communicator 230.

(102) The storage 210 may store a reference hash necessary to authenticate metadata.

(103) The communicator 230 may receive an authentication request for the metadata from the broadcast receiver 100.

(104) The controller 220 may generate a metadata hash, based on the authentication request including the metadata. However, in other exemplary embodiments, the broadcast receiver 100 may generate the metadata hash, and the authentication request transmitted from the broadcast receiver 100 to the server 200 may include the metadata hash. In this case, the controller 220 may not perform an operation of generating the metadata hash.

(105) The controller 220 may identify a service associated with the metadata from service identification information included in the authentication request and may search for a reference hash corresponding to the identified service.

(106) The controller 220 may compare the metadata hash with the reference hash to determine whether the metadata hash matches the reference hash, and may control the communicator 230 to transmit a result of the comparison to the broadcast receiver 100.

(107) FIG. 10 is a block diagram illustrating a configuration of a server 200 according to an exemplary embodiment.

(108) Referring to FIG. 10, the server 200 may include an authenticator 220 including a hash generator 221 and a hash comparator 222, a communicator 230, and a storage 210.

(109) According to one or more exemplary embodiments, one or more elements of the server 200 illustrated in FIG. 10 may be omitted. The authenticator 220 of FIG. 10 may be included in the controller 220 of FIG. 9. The communicator 230 and storage 210 of FIG. 10 respectively correspond to the communicator 230 and storage 210 of FIG. 9.

(110) The authenticator 220 may include the hash generator 221 and the hash comparator 222.

(111) The hash generator 221 may generate a metadata hash, based on metadata received from the communicator 230. However, in other exemplary embodiments, if the broadcast receiver 100 generates the metadata hash, the hash generator 221 may be omitted.

(112) The hash comparator 222 may search for a reference hash corresponding to an identified service among a plurality of reference hashes stored in the storage 210 and may compare a found reference hash with the metadata hash generated by the hash generator 221.

(113) When the metadata hash matches the reference hash, the server 200 may transmit, to the broadcast receiver 100, a message indicating that the metadata is valid.

(114) FIG. 11 is a flowchart illustrating an operation of a broadcast provider according to an exemplary embodiment.

(115) A method according to an exemplary embodiment may be performed by the broadcast provider 300 illustrated in FIG. 1.

(116) In operation S1101, the broadcast provider 300 may obtain metadata associated with an application executable by the broadcast receiver 100. The broadcast provider 300 may receive the metadata from the service provider 400 that provides a broadcast service and an application associated with the broadcast service. Alternatively, the broadcast provider 300 may directly generate the metadata based on application information received from the service provider 400.

(117) The metadata may include an authorization server list listing names and the like of authorized servers which are authorized for an application to perform communication. By using the authorization server list, the application is prevented from communicating with an unauthorized server.

(118) In operation S1102, the broadcast provider 300 may generate a reference hash of the metadata by using a hash algorithm. The hash algorithm used to generate the reference hash may be the same as the hash algorithm which is used by the broadcast receiver 100 or the server 200 to generate a metadata hash.

(119) In operation S1103, the broadcast provider 300 may transmit the generated reference hash to an external device so that the reference hash is used when authenticating the metadata. The external device may be the broadcast receiver 100 or the server 200. The reference hash may be stored in the external device, and, when metadata authentication is necessary, the reference hash may be used for the broadcast receiver 100 or the server 200 to compare the reference hash with the metadata hash to determine whether the reference hash matches the metadata hash.

(120) In operation S1104, the broadcast provider 300 may insert the metadata into broadcast data, and in operation S1105, the broadcast provider 300 may transmit the broadcast data including the metadata to the broadcast receiver 100. Then, the broadcast receiver 100 may extract the metadata from the received broadcast data and may authenticate the extracted metadata by using the reference hash stored in the external device. The reference hash may be stored prior to the transmission of the broadcast data.

(121) FIG. 12 is a block diagram illustrating a configuration of a broadcast provider according to an exemplary embodiment.

(122) Referring to FIG. 12, the broadcast provider may include a communicator 310 and a controller 320.

(123) The controller 320 may obtain metadata associated with an application. Here, the controller 320 may receive the metadata from the service provider 400 that provides a broadcast service and an application associated with the broadcast service. Alternatively, the controller 320 may generate the metadata, based on application information received from the service provider 400.

(124) The controller 320 may generate a reference hash from the obtained metadata and may insert the metadata into broadcast data.

(125) The communicator 310 may transmit the broadcast data including the metadata to the broadcast receiver 100.

(126) Moreover, the communicator 310 may transmit the reference hash, generated by the controller 310, to an external device so that the reference hash may be used when authenticating the metadata. As described above, the external device may be the broadcast receiver 100 or the server 200.

(127) FIG. 13 is a block diagram illustrating a configuration of a broadcast provider according to an exemplary embodiment.

(128) Referring to FIG. 13, the broadcast provider 300 may include a metadata obtainer 321, a hash generator 322, and a communicator 310. The metadata obtainer 321 and the hash generator 322 may be included in the controller 320 of FIG. 12. The communicator 310 illustrated in FIG. 13 may correspond to the communicator 310 illustrated in FIG. 12.

(129) The metadata obtainer 321 may generate metadata, based on application information received from the service provider 400. Alternatively, the metadata obtainer 321 may receive the metadata from the service provider 400.

(130) The hash generator 322 may generate a reference hash of the metadata, based on the metadata generated by the metadata obtainer 321. As described above, a hash algorithm used to generate the reference hash may be the same as the hash algorithm which is used by the broadcast receiver 100 or the server 200 to generate a metadata hash.

(131) All operations of the method according to the exemplary embodiments may be performed by dedicated hardware, such as an application specific integrated circuit (ASIC), or software having the form of computer program instructions.

(132) Moreover, various elements of the apparatus according to the exemplary embodiments may be implemented in hardware or software, or may be implemented by a combination of hardware and software. For example, one or more elements may be implemented as one or more processors configured to execute computer readable code stored on one or more memories.

(133) Computer program instructions may be stored in a computer-readable storage medium, and may be executed by an appropriate processing unit including one more processors.

(134) It should be understood that exemplary embodiments described herein should be considered in a descriptive sense only and not for purposes of limitation. Descriptions of features or aspects within each described exemplary embodiment should typically be considered as available for other similar features or aspects in other exemplary embodiments.

(135) While one or more exemplary embodiments have been described with reference to the figures, it will be understood by those of ordinary skill in the art that various changes in form and details may be made therein without departing from the spirit and scope as defined by the following claims and their equivalents.