EP1552420A1 - Method for managing metadata - Google Patents

Method for managing metadata

Info

Publication number
EP1552420A1
EP1552420A1 EP03808905A EP03808905A EP1552420A1 EP 1552420 A1 EP1552420 A1 EP 1552420A1 EP 03808905 A EP03808905 A EP 03808905A EP 03808905 A EP03808905 A EP 03808905A EP 1552420 A1 EP1552420 A1 EP 1552420A1
Authority
EP
European Patent Office
Prior art keywords
metadata
information
fragment data
authentication
related information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP03808905A
Other languages
German (de)
French (fr)
Other versions
EP1552420A4 (en
Inventor
Yang-Lim Choi
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Samsung Electronics Co Ltd
Original Assignee
Samsung Electronics Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from KR1020030013002A external-priority patent/KR100860984B1/en
Application filed by Samsung Electronics Co Ltd filed Critical Samsung Electronics Co Ltd
Publication of EP1552420A1 publication Critical patent/EP1552420A1/en
Publication of EP1552420A4 publication Critical patent/EP1552420A4/en
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/40—Information retrieval; Database structures therefor; File system structures therefor of multimedia data, e.g. slideshows comprising image and additional audio data
    • G06F16/48—Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/40—Information retrieval; Database structures therefor; File system structures therefor of multimedia data, e.g. slideshows comprising image and additional audio data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/606—Protecting data by securing the transmission between two devices or processes

Definitions

  • the present invention relates to a method for managing metadata in a transmission server and a client that receives the metadata, and more particularly, to a method for managing metadata including authentication of a message source, and message integrity and confidentiality until a client receives the metadata.
  • a service provider provides multimedia content and its related metadata to a client.
  • the metadata transmitted to the client may be used for various purposes.
  • the metadata can be used by the client to select multimedia content to be reproduced, recorded, or transmitted.
  • the amount and complexity of data that can be contained in metadata used by a client of a broadcasting system have increased.
  • metadata management method that enables effective metadata authentication has not yet been proposed.
  • the present invention provides a method for managing metadata to be transmitted in a metadata transmission server so that authentication of the metadata to be transmitted can be effectively performed.
  • the present invention also provides a method for managing in a client metadata received from a transmission server so that authentication of the received metadata can be effectively performed.
  • a method for managing metadata in a metadata transmission server involves (a) generating a plurality of fragment data by partitioning metadata to be transmitted on the basis of a predetermined segment unit, (b) selecting predetermined fragment data among the plurality of fragment data, (c) generating metadata-related information using the selected fragment data, and (d) transmitting the selected fragment data and the metadata-related information with data format information indicating the type of the selected fragment data.
  • a method for managing metadata in a client that receives the metadata. The method involves (a) reading predetermined fragment data and its corresponding metadata-related information and data format information indicating the type of the predetermined fragment data from the received metadata, (b) generating metadata-related information using the predetermined fragment data and its corresponding data format information, and (c) determining whether or not the received metadata has been authenticated by comparing the metadata-related information generated in step (b) with the metadata-related information read in step (a).
  • a method for managing metadata in a client that receives the metadata. The method involves (a) receiving fragment data of the received metadata, metadata-related information, data format information indicating the type of the fragment data, metadata authentication information, and an encrypted first encryption key, (b) generating metadata-related information using the fragment data of the received metadata and its corresponding data format information, (c) decrypting the encrypted first encryption key using a second encryption key stored in the client, (d) generating metadata authentication signature information using the generated metadata-related information and the decrypted first encryption key, and (e) determining whether or not the received metadata has been authenticated by comparing the generated metadata authentication signature information with the received metadata authentication signature information.
  • the present invention relates to a method for managing metadata in a transmission server and a client device, which is capable of identifying whether or not metadata has been damaged during being transmitted from the transmission server to the client device and effectively verifying which service provider or metadata content provider has transmitted the corresponding metadata to the client device.
  • FIG. 1 is a block diagram illustrating metadata authentication levels
  • FIG. 2 is a diagram illustrating a method of transmitting data using different transmission units
  • FIG. 3 is a diagram illustrating the format of a metadata container used for metadata container-level authentication in a unidirectional channel
  • FIG. 4 is a diagram illustrating a SOAP message used for metadata container-level authentication in a bi-directional channel
  • FIG. 5 is a block diagram illustrating a metadata classification method using index information of metadata
  • FIG. 6 is a flowchart of a method for managing metadata in a metadata transmission server according to a preferred embodiment of the present invention.
  • FIG. 7 is a flowchart of a method for managing metadata in a metadata client according to a preferred embodiment of the present invention.
  • FIG. 8 is a flowchart of a method for managing metadata in a metadata transmission server according to another preferred embodiment of the present invention.
  • FIG. 9 is a flowchart of a method for managing metadata in a metadata client according to another preferred embodiment of the present invention.
  • FIG. 10 is a diagram illustrating the format of a data container in a unidirectional channel.
  • FIG. 11 is a diagram illustrating a SOAP message in a bi-directional channel.
  • Metadata authentication may be performed at a transmission level or a source level.
  • transmission-level metadata authentication includes authentication of a message source, and message integrity and confidentiality.
  • the message source is not a source from which a message, i.e., metadata content, is generated but a source from which the message is transmitted.
  • a metadata content provider 120 and a service provider 140 such as SK Telecom Corp., are separately provided as shown in FIG. 1 , it can be verified through transmission-level authentication of a message source whether metadata A received by a client 160 has been transmitted from the service provider 140.
  • transmission-level authentication of message integrity verifies whether or not the metadata A has been changed in the process of transmitting the metadata A from the service provider 140 to the client 160.
  • Transmission-level authentication of message confidentiality verifies whether or not the metadata A has not yet been disclosed to a third party during the transmission process.
  • These three transmission-level authentication processes are performed using an SSL/TLS algorithm in a TCP/IP protocol, a DTCP algorithm in an IEEE 1394 protocol, and an HDCP algorithm in a DVI protocol.
  • source-level metadata authentication also includes authentication of a message source, and message integrity and confidentiality.
  • source-level authentication of a message source verifies a source from which a message, i.e., metadata content, is generated.
  • source-level authentication of a message source of the metadata A shows that the metadata A received by the client 160 has been transmitted from the metadata content provider 120.
  • Source-level authentication of message integrity verifies whether or not the metadata A has been changed in the process of transmitting the metadata A from the metadata content provider 120 to the client 160.
  • Source-level authentication of message confidentiality verifies whether or not the metadata A has not yet been disclosed to a third party during the transmission of the metadata A between the metadata content provider 120 and the client 160.
  • transmission-level metadata authentication may not need to be performed.
  • FIGS. 2(a) through 2(c) show a method of transmitting data in different transmission units in a physical layer.
  • FIG. 2(a) illustrates transmission packets that are subject to transmission-level metadata authentication.
  • Transmission-level metadata authentication is performed on each transmission packet shown in FIG. 2(a).
  • Each transmission packet has a binary XML format.
  • FIG. 2(c) illustrates metadata subject to source-level metadata authentication.
  • the metadata shown in FIG. 2(c) has a text XML format.
  • FIG. 2(b) illustrates metadata containers subject to metadata container-level authentication. Each predetermined semantic unit of metadata is contained in a metadata container. Examples of such metadata container are shown in FIGS. 3 and 4.
  • FIG. 3 is a diagram illustrating the format of a metadata container subject to metadata container-level authentication in a unidirectional channel.
  • a metadata container includes a header, fragment data, and metadata authentication information, and the header contains control information used for metadata container-level authentication.
  • the control information includes first control information F_1 , second control information F_2, third control information F_3, fourth control information F_4, and fifth control information F_5.
  • the control information ranging from the first control information F_1 through the fifth control information is comprised of a signal or a flag.
  • the first control information F_1 is an authentication flag indicating whether or not metadata container-level authentication has been performed on the fragment data.
  • the metadata container-level authentication may be performed using a media authentication code (MAC) or digital signature algorithm (DSA).
  • MAC media authentication code
  • DSA digital signature algorithm
  • the second control information F_2 is information on a specific algorithm used for generating metadata container-level authentication information.
  • the second control information F_2 may be represented by a set of binary codes. The relationship between the specific algorithm and the binary codes is defined in advance and is rendered to a server providing services and a client receiving metadata containers.
  • the third control information F_3 is data format information showing in detail the way to apply the specific algorithm to the fragment data.
  • the fragment may have a binary XML format or a text XML format, and thus the method of applying the specific algorithm to the fragment data varies depending on the format of the fragment data.
  • Metadata authentication information in the present invention is comprised of values obtained by substituting metadata into a hash function, i.e., hash values. Therefore, authentication information of fragment data having a text XML format has nothing to do with authentication information of fragment data having a binary XML format, and this is the reason why the third control information F_3 is necessary.
  • the fourth control information F_4 is encryption key information concerning metadata authentication.
  • the encryption key information is inserted into the metadata container together with metadata and then directly transmitted from a server to a client. Alternatively, the encryption key information may be transmitted from the server to the client via an additional security channel.
  • the fifth control information F_5 is an authentication level flag indicating a level of metadata authentication that has been performed. For example, when the fifth control information F_5 is set to '0', it indicates that transmission-level metadata authentication has been performed. When the fifth control information F_5 is set to '1 ', it indicates that source-level metadata authentication has been performed. With the help of the authentication level flag indicating whether or not transmission-level or source-level metadata authentication has been performed, it is possible to determine, using an application program of a client, how much reliable the metadata transmitted from a server is. Based on the reliability of the received metadata, it can be further determined whether to use the received metadata or not based on the reliability of the received metadata.
  • the metadata container includes a fragment data storage region where at least one fragment data is contained.
  • a predetermined semantic unit of metadata for example, fragment data, such as information on a program, is inserted into the metadata container in the present embodiment.
  • the metadata container of the present invention may also be used to selectively carry arbitrary units of metadata.
  • a group of related metadata is transmitted from a service provider to a client, while being carried by a series of metadata containers.
  • one metadata container includes one or more metadata fragments.
  • one of the metadata fragment data may be a sub-tree of an XML tree structure representing the entire metadata.
  • the metadata container-level authentication information includes metadata digest information and metadata authentication signature information.
  • the metadata digest information represents a value obtained by substituting one of the fragment data stored in the fragment data storage region into a unidirectional function, such as a hash function specified in the second control information F_2.
  • Each metadata digest information is related to its corresponding fragment data using a predetermined pointer.
  • first metadata digest information is related to the first fragment data using the predetermined pointer.
  • a hash function has been used to generate the metadata digest information.
  • other functions having the same characteristics as a unidirectional function such as a hash function, can also be used to obtain the metadata digest information.
  • the metadata authentication signature information is a value obtained by substituting the metadata digest information and an encryption key K into a unidirectional function, for example, the hash function specified in the second control information F_2.
  • Each metadata authentication signature information is related to its corresponding fragment data using a predetermined pointer.
  • first metadata authentication signature information is related to the first fragment data using the predetermined pointer.
  • a hash function has been used to generate the metadata authentication signature information.
  • other functions having the same characteristics as a unidirectional function such as a hash function, can also be used to obtain the metadata digest information.
  • FIG. 4 is a diagram illustrating the format of an SOAP envelope used for metadata container-level authentication in a bi-directional channel. As shown in FIG. 4, authentication-related information is included in an SOAP header, and metadata fragment data is included in the body of the SOAP envelope.
  • 'Algorithm ID' information, 'SignatureValueBaseType' information, and 'Keylnfo' information correspond to the second control information F_2, the third control information F_3, and the fourth control information F_4, respectively, of FIG. 3.
  • 'Digest' information and 'SignatureValue' information correspond to the metadata digest information and the metadata authentication signature information, respectively, described above with reference to FIG. 3.
  • 'AuthenticationLevel' information specifies a level of metadata authentication and corresponds to an authentication level flag, i.e., the fifth control information F_5 of FIG. 3. As shown in FIGS. 3 and 4, it is possible to effectively perform encryption management and metadata management by inserting fragment data obtained by partitioning the metadata on the basis of a predetermined semantic unit into a metadata container.
  • FIG. 6 is a flowchart of a metadata container-level authentication method using the metadata container shown in FIGS. 3 and 4. More specifically, FIG. 6 is a flowchart of the operation of the metadata content provider 120 or the service provider 140 of FIG. 1. Referring to FIG.
  • a plurality of fragment data are generated by dividing metadata on the basis of a predetermined semantic unit.
  • Each fragment data generated in the present embodiment is a predetermined semantic unit of metadata that has a predetermined meaning, like program information.
  • predetermined fragment data is selected from among the plurality of fragment data generated in step 610.
  • metadata digest information is generated by substituting the selected fragment data into a hash function, for example, a secured hash algorithm, such as SHA-1.
  • a hash function is used to generate message digest information.
  • other functions having the same characteristics as a unidirectional function, such as a hash function can also be used.
  • a metadata container including the selected fragment data, the generated metadata digest information, and data format information indicating whether the format of the selected fragment data is binary XML or text XML, is generated and then transmitted to a client.
  • the format of the selected fragment data is specified using the data format information because two different types of fragment data can bring about two different types of metadata digest information in step 620 even though the two fragment data are basically the same.
  • step 640 Examples of the metadata container generated in step 640 are shown in FIGS. 3 and 4.
  • a predetermined authentication flag is set so as to indicate that metadata container-level authentication has been performed on fragment data of metadata carried by the metadata container.
  • Algorithm information that has been used to generate the metadata digest information may be inserted into the metadata container.
  • algorithm information indicating that the hash function has been used as an authentication information generation algorithm is inserted into the metadata container.
  • the algorithm information is already well known to both a server and a client, there is no need to insert such algorithm information into the metadata container.
  • metadata digest information corresponding to each of the plurality of fragment data is contained in the metadata container, and so is pointer information indicating a relationship between each of the plurality of fragment data and its corresponding metadata digest information.
  • indexing information for each of the plurality of fragment data is also contained in the metadata container.
  • FIG. 7 is a flowchart of a metadata container-level authentication method using the metadata container shown in FIGS. 3 and 4. More specifically, FIG. 7 is the flowchart of the operation of the client 160 of FIG. 1. Referring to FIG. 7, in step 710, a metadata container is received from the metadata content provider 120 or the service provider 140.
  • step 720 first control information F_1 , i.e., an authentication flag, of a header of the received metadata container is read.
  • step 730 if the result of reading the authentication flag shows that metadata container-level authentication has been performed on fragment data contained in the metadata container, the method moves on to step 740. Otherwise, the method moves on to step 742.
  • step 740 an algorithm used for generating metadata digest information included in the metadata container is read by identifying second control information F_2, i.e., an algorithm used for generating authentication information.
  • the algorithm used for generating authentication information is a hash function. In a case where the algorithm used for generating authentication information is determined in advance and known to both the metadata content provider 120 (or the service provider 140) and the client 160, the process of reading the algorithm used for generating authentication information can be omitted.
  • step 740 the format of fragment data, used in computing metadata digest information included in the metadata container, is identified by recognizing third control information F_3, i.e., metadata format information.
  • step 742 such metadata container-level authentication is completed.
  • step 750 predetermined fragment data of metadata and its corresponding metadata digest information are read.
  • step 760 metadata digest information is generated based on the fragment data and the data format information read in step 740 by using the algorithm used for generating metadata digest information, for example, a hash function.
  • step 770 it is determined whether or not the metadata container-level authentication has been performed on metadata transmitted from the metadata content provider 120 or the service provider 140 by comparing the metadata digest information generated in step 760 with the metadata digest information of the predetermined fragment data read in step 750.
  • a metadata authentication level flag may be further included in the metadata container transmitted from the metadata content provider 120 or the service provider 140.
  • the metadata container-level authentication is a transmission-level metadata authentication or a source-level metadata authentication by reading the metadata authentication level flag using an application program of the client 160.
  • FIG. 8 is a flowchart of a metadata container-level authentication method using the metadata container shown in FIGS. 3 and 4. More specifically, FIG. 8 is the flowchart of the operation of the metadata content provider 120 or the service provider 140 shown in FIG. 1.
  • a plurality of fragment data are generated by partitioning metadata on the basis of a predetermined semantic unit.
  • Each fragment data generated in the present embodiment is a predetermined semantic unit, such as program information.
  • step 820 predetermined fragment data among the plurality of fragment data is selected.
  • step 830 metadata digest information is generated by substituting the selected fragment data into a hash function.
  • a hash function is used to generate the metadata digest information.
  • other functions having the same characteristics as a unidirectional function, such as a hash function can also be used.
  • a metadata authentication signature is generated by substituting the metadata digest information generated in step 830 and an encryption key K into the hash function.
  • the encryption key K is specific to the service provider 140.
  • a hash function is used to generate the metadata digest information.
  • other functions having the same characteristics as a unidirectional function, such as a hash function can also be used.
  • the encryption key K used to generate the metadata authentication signature is encrypted using another encryption key L.
  • an encrypted encryption key value obtained using the encryption key L will be represented by E(K).
  • the encrypted encryption key value E(K) is transmitted to the client 160, being carried by a metadata container.
  • the encrypted encryption key value E(K) is transmitted to the client 160 via a security channel.
  • the encryption key L is transmitted to the client 160 via another security channel.
  • a metadata container including the metadata digest information, the metadata authentication signature, and data format information of the selected fragment data is generated and then transmitted to the client 160.
  • step 850 metadata container-level authentication flag is allotted to the generated metadata container so as to indicate that metadata container-level authentication has been performed on fragment data of metadata carried by the metadata container.
  • Information on an algorithm used for generating the metadata digest information may be inserted into the metadata container.
  • the data format information of the selected fragment data indicates whether the format of the selected fragment data used for generating the metadata digest information and the authentication information is binary XML or text XML.
  • metadata digest information and metadata authentication signature information for each of the plurality of fragment data are also included in the metadata container.
  • pointer information indicating a relationship between each of the plurality of fragment data and its corresponding metadata digest information and metadata authentication signature information is further included in the metadata container.
  • FIG. 9 is a flowchart of a metadata container-level authentication method using the metadata container shown in FIGS. 3 and 4. More specifically, FIG. 9 is a flowchart of the operation of the client 160 of FIG. 1.
  • a metadata container is received from the metadata content provider 120 or the service provider 140.
  • step 920 first control information included in a header of the metadata container, i.e., an authentication flag, is read.
  • step 930 if the result of reading the authentication flag shows that metadata container-level authentication has been performed on fragment data contained in the metadata container, the method moves on to step 940. Otherwise, the method moves on to step 942.
  • an algorithm used for generating metadata digest information included in the metadata container is read by recognizing second control information F_2, i.e., an algorithm used for generating authentication information.
  • the algorithm used for generating authentication information is a hash function. In a case where the algorithm used for generating authentication information is determined in advance and known to both the metadata content provider 120 (or the service provider 140) and the client 160, the process of reading the algorithm used for generating authentication information can be omitted.
  • step 940 the format of fragment data, used in computing metadata digest information included in the metadata container, is identified by recognizing third control information F_3, i.e., metadata format information.
  • step 942 metadata container-level authentication is completed.
  • step 950 predetermined fragment data of metadata contained in the metadata container, and its corresponding metadata digest information, metadata authentication signature information, and data format information are read.
  • step 960 metadata digest information is generated based upon the predetermined fragment data and its corresponding data format information read in step 950 by using the algorithm read in step 940, for example, a hash function.
  • step 970 an encryption key K that has been encrypted is decrypted using another encryption key L stored in the client 160.
  • the encryption key L has been transmitted from the metadata content provider 120 or the service provider 140 to the client 160.
  • a metadata authentication signature S is generated using the metadata digest information generated in step 960 and the decrypted key K.
  • step 990 it is determined whether or not a metadata authentication signature received by the client 160 is verified by comparing the metadata authentication signature S generated in step 980 with the metadata authentication signature information read in step
  • the metadata container may further include an authentication level flag indicating the level of metadata authentication performed on the metadata container, in which case the metadata authentication level is read using an application of the client 160 and depending on the metadata authentication level, it is determined whether to use metadata contained in the metadata container or not.
  • K_s indicates a secret key
  • K_p indicates a public key
  • a client can obtain the public key K__p through reliable sources. Therefore, in a case where the client receives a metadata container with the service provider's signature, the client figures out who the service provider that has transmitted the metadata container is and obtains the public key K_p corresponding to the identified service provider. The client verifies whether or not the received signature is valid using the public key K_p.
  • 'View' is one of the simplest examples of metadata use and is simply performed by accessing the metadata.
  • a metadata file management system is required.
  • copying the metadata using a remote application for example, in the case of transmitting the metadata from a client to a service provider, a request for the metadata and transmission of the requested metadata and its source authentication information are required.
  • metadata may include highly confidential or private data.
  • metadata needs to be encrypted before being transmitted or stored so that it can be prevented from being undesirably exposed to the public.
  • the confidentiality of the metadata can be preserved by performing transmission-level encryption on the metadata, i.e., encrypting a transmission unit or container of the metadata.
  • source-level encryption of the metadata can solve all possible problems concerning the confidentiality of metadata at a transmission level or a storage level.
  • the unidirectional channel environment concerning a conditional access system includes terrestrial broadcasting, such as ATSC or DVB, satellite broadcasting, such as Direct TV, cable TV, and IP-multicasting.
  • a unidirectional channel is used except for a case where data exchanges, such as transactions, are carried out using a return channel. Functions provided in the unidirectional channel environment concerning a conditional access system are as follows.
  • a receiver and a transmitter with hardware devices automatically authorize each other.
  • the receiver and the transmitter are enabled to share a common secret via a predetermined channel.
  • the common secret represents a code shared by the receiver and the transmitter.
  • Packet payload is encrypted and transmitted. Later, the encrypted packet payload is decrypted using the common secret or using a key decrypted with the use of the common secret.
  • a handshake protocol is used and a server and a client authorize each other by exchanging and authenticating certificates issued by a third certificate authorization organization.
  • a common secret is shared by the client and the server, and a session key is generated later.
  • Packet payload is encrypted using the session key and then transmitted.
  • the encrypted packet payload is decrypted using the session key.
  • Source authentication may be performed using an algorithm, such as DSA or MAC.
  • authorization of the client and the server is performed through the authentication and exchange of certificates issued a third certificate authorization organization. The confidentiality of data transmitted between the client and the server to the other is preserved through encryption of packet payload and message authentication.
  • the common secret needs to be shared by the receiver and the transmitter in a safe manner so that the receiver and the transmitter can authorize each other and data transmitted there between and data can be encrypted and then transmitted.
  • authorization of a receiver and a transmitter is carried out at a transmission level, and authorization of the metadata and preservation of the confidentiality of the metadata are carried at a broadcasting system level.
  • each SOAP message consisting of a head and a body can be used as a unit of protection, as shown in FIG. 10.
  • data signature information is transmitted using a SOAP message, in which case the data information is included in the body of the SOAP message, as shown in FIG. 1 1.
  • Data contained in the body of the SOAP message can be encrypted.
  • the preservation of metadata integrity and confidentiality in a broadcasting system is enabled by allotting an authentication signature to metadata and encrypting the metadata.
  • the entire metadata is not always subjected to such an encryption process because of no need to preserve the integrity of the entire metadata, it is necessary to represent specific portions of the metadata that have been encrypted or authenticated with a predetermined pointer, and this process can be performed at a source level where the predetermined pointer can be maintained by using a right management protection (RMP) system.
  • RMP right management protection
  • a source level signature a metadata source can be practically authenticated.
  • the metadata must include such information as a source authentication signature.
  • a standard description of metadata access and usage rights and implementation thereof are required.
  • a standard description may have an XML schema format or may assume the form of an element of a set of data having a predetermined meaning. Such a standard description may be generated using a conventional markup language, such as XrML, XACML, or SAML.
  • a license description and a usage rule can be isolated from metadata. In a case where there are many metadata fragments, usage information of which is worth describing, access/usage control can be performed in such a simple way as follows. Once access to an application is authorized, the application is believed to operate following predetermined usage rules set as default values.
  • an application program interface (API) of an RMP system is used to access or use metadata.
  • the API is needed when access/usage control information is managed by a TVA RMP system.
  • the API issues and authorizes a request for accessing metadata.
  • the API modifies, copies, and exports metadata.
  • authentication there are several types of authentication that can be performed at a predetermined structure level, and they are transmission-level authentication, metadata container-level authentication or SOAP message-level authentication, and source-level authentication.
  • authentication information on specific portions of metadata that have been authenticated is provided using a pointer.
  • authentication information is included in a header of a SOAP message together with a pointer for part of metadata contained in the body of the SOAP message or a pointer for the entire metadata.
  • Authentication of a metadata source requires metadata container-level authentication and SOAP message-level authentication.
  • the syntax of a metadata container enabling source authentication is shown in FIG. 1 1.
  • source authentication information needs to be provided to each node between the source and the final destination. More specifically, metadata is authenticated at a predetermined node between a source and a final destination using authentication information transmitted from a previous node, new authentication information is generated, and the metadata and the new authentication information are passed on to a next node. Alternatively, metadata is authenticated at a predetermined node using authentication information transmitted from a previous node, and the metadata and the authentication information are directly passed on to a next node so that the metadata can be authenticated again at the next node using the authentication information.
  • a flag or a signal indicating whether new authentication information is generated or not after the metadata is authenticated at a predetermined node using authentication information transmitted from a previous node, can be inserted into the authentication information.
  • the flag or signal indicating the presence of source authentication information helps a receiver determine whether to accept the corresponding metadata or not.
  • the above-described embodiments of the present invention can be realized as computer-readable codes written on a computer-readable recording medium.
  • the computer-readable recording medium includes all kinds of storages where computer-readable data can be stored, such as a ROM, a RAM, a CD-ROM, a magnetic tape, a hard disk, a floppy disk, a flash memory, an optical data storage, and a carrier wave, such as data transmission through the Internet.
  • the computer-readable recording medium can be distributed over computer systems connected via a network so that the computer-readable codes written on the computer-readable recording medium can be executed in an independent manner.
  • the method for managing metadata according to the present invention makes it possible to authenticate metadata at a metadata container level. Therefore, it is possible to carry out transmission-level authentication in any channel environment.
  • the present invention makes it possible to selectively carry out either transmission-level authentication or source-level authentication or both by inserting data format information indicating the format of metadata into a metadata container. Considering that the size of a metadata container-level packet is larger than the size of a transmission-level packet, the present invention reduces the number of packets to be transmitted, thus simplifying a system.

Abstract

A method for managing metadata in a metadata transmission server is provided. The method involves generating a plurality of fragment data by partitioning metadata to be transmitted on the basis of a predetermined segment unit, selecting predetermined fragment data among the plurality of fragment data, generating metadata-related information using the selected fragment data, and transmitting the selected fragment data and the metadata-related information with data format information indicating the type of the selected fragment data.

Description

METHOD FOR MANAGING METADATA
Technical Field
The present invention relates to a method for managing metadata in a transmission server and a client that receives the metadata, and more particularly, to a method for managing metadata including authentication of a message source, and message integrity and confidentiality until a client receives the metadata.
Background Art
In a multimedia system, such as a broadcasting system where data is transmitted from a server to a client or a video-on-demand service system where data is transmitted through interactions between the server and the client, a service provider provides multimedia content and its related metadata to a client.
The metadata transmitted to the client may be used for various purposes. For example, the metadata can be used by the client to select multimedia content to be reproduced, recorded, or transmitted. In recent years, the amount and complexity of data that can be contained in metadata used by a client of a broadcasting system have increased. Thus, there has been an increasing demand for security of such metadata. In particular, in a case where metadata is generated and then transmitted to a client from a transmission server, it is very important to authenticate a source of the metadata and verify whether or not the integrity and confidentiality of the metadata have been affected during the transmission process. However, a metadata management method that enables effective metadata authentication has not yet been proposed.
Disclosure of the Invention The present invention provides a method for managing metadata to be transmitted in a metadata transmission server so that authentication of the metadata to be transmitted can be effectively performed. The present invention also provides a method for managing in a client metadata received from a transmission server so that authentication of the received metadata can be effectively performed.
According to an aspect of the present invention, there is provided a method for managing metadata in a metadata transmission server. The method involves (a) generating a plurality of fragment data by partitioning metadata to be transmitted on the basis of a predetermined segment unit, (b) selecting predetermined fragment data among the plurality of fragment data, (c) generating metadata-related information using the selected fragment data, and (d) transmitting the selected fragment data and the metadata-related information with data format information indicating the type of the selected fragment data.
According to another aspect of the present invention, there is provided a method for managing metadata in a client that receives the metadata. The method involves (a) reading predetermined fragment data and its corresponding metadata-related information and data format information indicating the type of the predetermined fragment data from the received metadata, (b) generating metadata-related information using the predetermined fragment data and its corresponding data format information, and (c) determining whether or not the received metadata has been authenticated by comparing the metadata-related information generated in step (b) with the metadata-related information read in step (a).
According to still another aspect of the present invention, there is provided a method for managing metadata in a client that receives the metadata. The method involves (a) receiving fragment data of the received metadata, metadata-related information, data format information indicating the type of the fragment data, metadata authentication information, and an encrypted first encryption key, (b) generating metadata-related information using the fragment data of the received metadata and its corresponding data format information, (c) decrypting the encrypted first encryption key using a second encryption key stored in the client, (d) generating metadata authentication signature information using the generated metadata-related information and the decrypted first encryption key, and (e) determining whether or not the received metadata has been authenticated by comparing the generated metadata authentication signature information with the received metadata authentication signature information.
The present invention relates to a method for managing metadata in a transmission server and a client device, which is capable of identifying whether or not metadata has been damaged during being transmitted from the transmission server to the client device and effectively verifying which service provider or metadata content provider has transmitted the corresponding metadata to the client device.
Brief Description of the Drawings FIG. 1 is a block diagram illustrating metadata authentication levels;
FIG. 2 is a diagram illustrating a method of transmitting data using different transmission units;
FIG. 3 is a diagram illustrating the format of a metadata container used for metadata container-level authentication in a unidirectional channel;
FIG. 4 is a diagram illustrating a SOAP message used for metadata container-level authentication in a bi-directional channel;
FIG. 5 is a block diagram illustrating a metadata classification method using index information of metadata;
FIG. 6 is a flowchart of a method for managing metadata in a metadata transmission server according to a preferred embodiment of the present invention;
FIG. 7 is a flowchart of a method for managing metadata in a metadata client according to a preferred embodiment of the present invention;
FIG. 8 is a flowchart of a method for managing metadata in a metadata transmission server according to another preferred embodiment of the present invention;
FIG. 9 is a flowchart of a method for managing metadata in a metadata client according to another preferred embodiment of the present invention;
FIG. 10 is a diagram illustrating the format of a data container in a unidirectional channel; and
FIG. 11 is a diagram illustrating a SOAP message in a bi-directional channel.
Best mode for carrying out the Invention
When metadata is received, it is necessary to authenticate the received metadata. Metadata authentication may be performed at a transmission level or a source level.
In particular, transmission-level metadata authentication includes authentication of a message source, and message integrity and confidentiality. Here, the message source is not a source from which a message, i.e., metadata content, is generated but a source from which the message is transmitted.
For example, in a case where a metadata content provider 120 and a service provider 140, such as SK Telecom Corp., are separately provided as shown in FIG. 1 , it can be verified through transmission-level authentication of a message source whether metadata A received by a client 160 has been transmitted from the service provider 140.
In addition, transmission-level authentication of message integrity verifies whether or not the metadata A has been changed in the process of transmitting the metadata A from the service provider 140 to the client 160.
Transmission-level authentication of message confidentiality verifies whether or not the metadata A has not yet been disclosed to a third party during the transmission process. These three transmission-level authentication processes are performed using an SSL/TLS algorithm in a TCP/IP protocol, a DTCP algorithm in an IEEE 1394 protocol, and an HDCP algorithm in a DVI protocol. Like the transmission-level authentication, source-level metadata authentication also includes authentication of a message source, and message integrity and confidentiality.
In particular, source-level authentication of a message source verifies a source from which a message, i.e., metadata content, is generated. For example, as shown in FIG. 1 , source-level authentication of a message source of the metadata A shows that the metadata A received by the client 160 has been transmitted from the metadata content provider 120.
Source-level authentication of message integrity verifies whether or not the metadata A has been changed in the process of transmitting the metadata A from the metadata content provider 120 to the client 160.
Source-level authentication of message confidentiality verifies whether or not the metadata A has not yet been disclosed to a third party during the transmission of the metadata A between the metadata content provider 120 and the client 160.
When such source-level metadata authentication is performed, transmission-level metadata authentication may not need to be performed.
FIGS. 2(a) through 2(c) show a method of transmitting data in different transmission units in a physical layer.
More specifically, FIG. 2(a) illustrates transmission packets that are subject to transmission-level metadata authentication.
Transmission-level metadata authentication is performed on each transmission packet shown in FIG. 2(a). Each transmission packet has a binary XML format. FIG. 2(c) illustrates metadata subject to source-level metadata authentication. The metadata shown in FIG. 2(c) has a text XML format.
FIG. 2(b) illustrates metadata containers subject to metadata container-level authentication. Each predetermined semantic unit of metadata is contained in a metadata container. Examples of such metadata container are shown in FIGS. 3 and 4.
FIG. 3 is a diagram illustrating the format of a metadata container subject to metadata container-level authentication in a unidirectional channel. As shown in FIG. 3, a metadata container includes a header, fragment data, and metadata authentication information, and the header contains control information used for metadata container-level authentication.
The control information includes first control information F_1 , second control information F_2, third control information F_3, fourth control information F_4, and fifth control information F_5. The control information ranging from the first control information F_1 through the fifth control information is comprised of a signal or a flag.
The first control information F_1 is an authentication flag indicating whether or not metadata container-level authentication has been performed on the fragment data. Here, the metadata container-level authentication may be performed using a media authentication code (MAC) or digital signature algorithm (DSA).
The second control information F_2 is information on a specific algorithm used for generating metadata container-level authentication information. The second control information F_2 may be represented by a set of binary codes. The relationship between the specific algorithm and the binary codes is defined in advance and is rendered to a server providing services and a client receiving metadata containers.
The third control information F_3 is data format information showing in detail the way to apply the specific algorithm to the fragment data. The fragment may have a binary XML format or a text XML format, and thus the method of applying the specific algorithm to the fragment data varies depending on the format of the fragment data.
Metadata authentication information in the present invention is comprised of values obtained by substituting metadata into a hash function, i.e., hash values. Therefore, authentication information of fragment data having a text XML format has nothing to do with authentication information of fragment data having a binary XML format, and this is the reason why the third control information F_3 is necessary.
In other words, there is a need to identify the format of metadata used to obtain hash values in order to determine whether or not an authentication signature is valid based upon metadata included in a metadata container received by a client and the hash values.
The fourth control information F_4 is encryption key information concerning metadata authentication. The encryption key information is inserted into the metadata container together with metadata and then directly transmitted from a server to a client. Alternatively, the encryption key information may be transmitted from the server to the client via an additional security channel.
The fifth control information F_5 is an authentication level flag indicating a level of metadata authentication that has been performed. For example, when the fifth control information F_5 is set to '0', it indicates that transmission-level metadata authentication has been performed. When the fifth control information F_5 is set to '1 ', it indicates that source-level metadata authentication has been performed. With the help of the authentication level flag indicating whether or not transmission-level or source-level metadata authentication has been performed, it is possible to determine, using an application program of a client, how much reliable the metadata transmitted from a server is. Based on the reliability of the received metadata, it can be further determined whether to use the received metadata or not based on the reliability of the received metadata.
The metadata container includes a fragment data storage region where at least one fragment data is contained. A predetermined semantic unit of metadata, for example, fragment data, such as information on a program, is inserted into the metadata container in the present embodiment. However, the metadata container of the present invention may also be used to selectively carry arbitrary units of metadata. In addition, a group of related metadata is transmitted from a service provider to a client, while being carried by a series of metadata containers. Furthermore, one metadata container includes one or more metadata fragments. For example, one of the metadata fragment data may be a sub-tree of an XML tree structure representing the entire metadata.
The metadata container-level authentication information includes metadata digest information and metadata authentication signature information.
The metadata digest information represents a value obtained by substituting one of the fragment data stored in the fragment data storage region into a unidirectional function, such as a hash function specified in the second control information F_2. Each metadata digest information is related to its corresponding fragment data using a predetermined pointer. For example, first metadata digest information is related to the first fragment data using the predetermined pointer. In the present embodiment, a hash function has been used to generate the metadata digest information. Sometimes, however, other functions having the same characteristics as a unidirectional function, such as a hash function, can also be used to obtain the metadata digest information. The metadata authentication signature information is a value obtained by substituting the metadata digest information and an encryption key K into a unidirectional function, for example, the hash function specified in the second control information F_2. Each metadata authentication signature information, like each metadata digest information, is related to its corresponding fragment data using a predetermined pointer. For example, first metadata authentication signature information is related to the first fragment data using the predetermined pointer. In the present embodiment, a hash function has been used to generate the metadata authentication signature information. Sometimes, however, other functions having the same characteristics as a unidirectional function, such as a hash function, can also be used to obtain the metadata digest information.
FIG. 4 is a diagram illustrating the format of an SOAP envelope used for metadata container-level authentication in a bi-directional channel. As shown in FIG. 4, authentication-related information is included in an SOAP header, and metadata fragment data is included in the body of the SOAP envelope.
Among pieces of the authentication-related information contained in the SOAP header, 'Algorithm ID' information, 'SignatureValueBaseType' information, and 'Keylnfo' information correspond to the second control information F_2, the third control information F_3, and the fourth control information F_4, respectively, of FIG. 3. 'Digest' information and 'SignatureValue' information correspond to the metadata digest information and the metadata authentication signature information, respectively, described above with reference to FIG. 3. 'AuthenticationLevel' information specifies a level of metadata authentication and corresponds to an authentication level flag, i.e., the fifth control information F_5 of FIG. 3. As shown in FIGS. 3 and 4, it is possible to effectively perform encryption management and metadata management by inserting fragment data obtained by partitioning the metadata on the basis of a predetermined semantic unit into a metadata container.
For example, by allotting indexing information to each fragment data and using an index list stored in an index list storing unit, it is possible to store only predetermined metadata selected from among all metadata input into a cache 520 in a data storage 540 of FIG. 5. In addition, since metadata is partitioned into predetermined semantic units, such as program information, segment information, and so on, as shown in FIG. 4, it is possible to selectively encrypt the metadata fragment data on a predetermined semantic unit-by-predetermined semantic unit basis. FIG. 6 is a flowchart of a metadata container-level authentication method using the metadata container shown in FIGS. 3 and 4. More specifically, FIG. 6 is a flowchart of the operation of the metadata content provider 120 or the service provider 140 of FIG. 1. Referring to FIG. 6, in step 610, a plurality of fragment data are generated by dividing metadata on the basis of a predetermined semantic unit. Each fragment data generated in the present embodiment is a predetermined semantic unit of metadata that has a predetermined meaning, like program information. In step 620, predetermined fragment data is selected from among the plurality of fragment data generated in step 610.
In step 630, metadata digest information is generated by substituting the selected fragment data into a hash function, for example, a secured hash algorithm, such as SHA-1. In the present embodiment, a hash function is used to generate message digest information. Sometimes, however, other functions having the same characteristics as a unidirectional function, such as a hash function, can also be used.
In step 640, a metadata container, including the selected fragment data, the generated metadata digest information, and data format information indicating whether the format of the selected fragment data is binary XML or text XML, is generated and then transmitted to a client. Here, it is necessary to specify the format of the selected fragment data using the data format information because two different types of fragment data can bring about two different types of metadata digest information in step 620 even though the two fragment data are basically the same.
Examples of the metadata container generated in step 640 are shown in FIGS. 3 and 4. In step 640, a predetermined authentication flag is set so as to indicate that metadata container-level authentication has been performed on fragment data of metadata carried by the metadata container.
Algorithm information that has been used to generate the metadata digest information may be inserted into the metadata container. For example, in a case where the metadata digest information is generated in step 630 using a hash function, algorithm information indicating that the hash function has been used as an authentication information generation algorithm is inserted into the metadata container. However, in a case where the algorithm information is already well known to both a server and a client, there is no need to insert such algorithm information into the metadata container. Furthermore, it is also possible to insert a flag specifying a metadata authentication level into the metadata container together with the data formation information of the selected fragment data. The flag specifies whether metadata authentication using the metadata container has been performed at a transmission level or at a source level. In a case where a plurality of fragment data are inserted into the metadata container, metadata digest information corresponding to each of the plurality of fragment data is contained in the metadata container, and so is pointer information indicating a relationship between each of the plurality of fragment data and its corresponding metadata digest information.
In addition, in a case where a plurality of fragment data are inserted into the metadata container, indexing information for each of the plurality of fragment data is also contained in the metadata container.
FIG. 7 is a flowchart of a metadata container-level authentication method using the metadata container shown in FIGS. 3 and 4. More specifically, FIG. 7 is the flowchart of the operation of the client 160 of FIG. 1. Referring to FIG. 7, in step 710, a metadata container is received from the metadata content provider 120 or the service provider 140.
In step 720, first control information F_1 , i.e., an authentication flag, of a header of the received metadata container is read.
In step 730, if the result of reading the authentication flag shows that metadata container-level authentication has been performed on fragment data contained in the metadata container, the method moves on to step 740. Otherwise, the method moves on to step 742. In step 740, an algorithm used for generating metadata digest information included in the metadata container is read by identifying second control information F_2, i.e., an algorithm used for generating authentication information. In the present embodiment, the algorithm used for generating authentication information is a hash function. In a case where the algorithm used for generating authentication information is determined in advance and known to both the metadata content provider 120 (or the service provider 140) and the client 160, the process of reading the algorithm used for generating authentication information can be omitted. In step 740, the format of fragment data, used in computing metadata digest information included in the metadata container, is identified by recognizing third control information F_3, i.e., metadata format information.
In step 742, such metadata container-level authentication is completed.
In step 750, predetermined fragment data of metadata and its corresponding metadata digest information are read.
In step 760, metadata digest information is generated based on the fragment data and the data format information read in step 740 by using the algorithm used for generating metadata digest information, for example, a hash function.
In step 770, it is determined whether or not the metadata container-level authentication has been performed on metadata transmitted from the metadata content provider 120 or the service provider 140 by comparing the metadata digest information generated in step 760 with the metadata digest information of the predetermined fragment data read in step 750.
A metadata authentication level flag may be further included in the metadata container transmitted from the metadata content provider 120 or the service provider 140. In this case, it is possible to figure out whether the metadata container-level authentication is a transmission-level metadata authentication or a source-level metadata authentication by reading the metadata authentication level flag using an application program of the client 160. In addition, it is also possible to determine whether to use the metadata transmitted from the metadata content provider 120 or the service provider 140 or not based upon the reliability of the metadata.
FIG. 8 is a flowchart of a metadata container-level authentication method using the metadata container shown in FIGS. 3 and 4. More specifically, FIG. 8 is the flowchart of the operation of the metadata content provider 120 or the service provider 140 shown in FIG. 1.
Referring to FIG. 8, in step 810, a plurality of fragment data are generated by partitioning metadata on the basis of a predetermined semantic unit. Each fragment data generated in the present embodiment is a predetermined semantic unit, such as program information.
In step 820, predetermined fragment data among the plurality of fragment data is selected.
In step 830, metadata digest information is generated by substituting the selected fragment data into a hash function. In the present embodiment, a hash function is used to generate the metadata digest information. However, other functions having the same characteristics as a unidirectional function, such as a hash function, can also be used.
In step 840, a metadata authentication signature is generated by substituting the metadata digest information generated in step 830 and an encryption key K into the hash function. The encryption key K is specific to the service provider 140. In the present embodiment, a hash function is used to generate the metadata digest information. However, other functions having the same characteristics as a unidirectional function, such as a hash function, can also be used. The encryption key K used to generate the metadata authentication signature is encrypted using another encryption key L. Hereinafter, an encrypted encryption key value obtained using the encryption key L will be represented by E(K). The encrypted encryption key value E(K) is transmitted to the client 160, being carried by a metadata container. Alternatively, the encrypted encryption key value E(K) is transmitted to the client 160 via a security channel. The encryption key L is transmitted to the client 160 via another security channel.
In step 850, a metadata container including the metadata digest information, the metadata authentication signature, and data format information of the selected fragment data is generated and then transmitted to the client 160.
Examples of the metadata container generated in step 850 are shown in FIGS. 3 and 4. In step 850, metadata container-level authentication flag is allotted to the generated metadata container so as to indicate that metadata container-level authentication has been performed on fragment data of metadata carried by the metadata container.
Information on an algorithm used for generating the metadata digest information may be inserted into the metadata container.
In addition, the data format information of the selected fragment data indicates whether the format of the selected fragment data used for generating the metadata digest information and the authentication information is binary XML or text XML.
In a case where a plurality of fragment data are inserted into the metadata container, metadata digest information and metadata authentication signature information for each of the plurality of fragment data are also included in the metadata container. In addition, pointer information indicating a relationship between each of the plurality of fragment data and its corresponding metadata digest information and metadata authentication signature information is further included in the metadata container.
FIG. 9 is a flowchart of a metadata container-level authentication method using the metadata container shown in FIGS. 3 and 4. More specifically, FIG. 9 is a flowchart of the operation of the client 160 of FIG. 1. Referring to FIG. 9, in step 910, a metadata container is received from the metadata content provider 120 or the service provider 140.
In step 920, first control information included in a header of the metadata container, i.e., an authentication flag, is read.
In step 930, if the result of reading the authentication flag shows that metadata container-level authentication has been performed on fragment data contained in the metadata container, the method moves on to step 940. Otherwise, the method moves on to step 942.
In step 940, an algorithm used for generating metadata digest information included in the metadata container is read by recognizing second control information F_2, i.e., an algorithm used for generating authentication information. In the present embodiment, the algorithm used for generating authentication information is a hash function. In a case where the algorithm used for generating authentication information is determined in advance and known to both the metadata content provider 120 (or the service provider 140) and the client 160, the process of reading the algorithm used for generating authentication information can be omitted.
In step 940, the format of fragment data, used in computing metadata digest information included in the metadata container, is identified by recognizing third control information F_3, i.e., metadata format information.
In step 942, metadata container-level authentication is completed.
In step 950, predetermined fragment data of metadata contained in the metadata container, and its corresponding metadata digest information, metadata authentication signature information, and data format information are read.
In step 960, metadata digest information is generated based upon the predetermined fragment data and its corresponding data format information read in step 950 by using the algorithm read in step 940, for example, a hash function. In step 970, an encryption key K that has been encrypted is decrypted using another encryption key L stored in the client 160. The encryption key L has been transmitted from the metadata content provider 120 or the service provider 140 to the client 160.
In step 980, a metadata authentication signature S is generated using the metadata digest information generated in step 960 and the decrypted key K.
In step 990, it is determined whether or not a metadata authentication signature received by the client 160 is verified by comparing the metadata authentication signature S generated in step 980 with the metadata authentication signature information read in step
950. The metadata container may further include an authentication level flag indicating the level of metadata authentication performed on the metadata container, in which case the metadata authentication level is read using an application of the client 160 and depending on the metadata authentication level, it is determined whether to use metadata contained in the metadata container or not.
In addition, various methods for testing message integrity are available. One of those various methods is cryptography using a public key. According to this method, a service provider possesses a pair of keys (K_s, K_p) and signs a message using the key K_s. Here, K_s indicates a secret key, and K_p indicates a public key. A client can obtain the public key K__p through reliable sources. Therefore, in a case where the client receives a metadata container with the service provider's signature, the client figures out who the service provider that has transmitted the metadata container is and obtains the public key K_p corresponding to the identified service provider. The client verifies whether or not the received signature is valid using the public key K_p.
Hereinafter, requisites for metadata authentication and a metadata authentication method for preserving the security of metadata will be described in greater detail in the following paragraphs.
In order to maintain the security of metadata, it is necessary to authorize metadata access and use, preserve metadata integrity and confidentiality, and effectively protect the binary format or text format of subgroups of the metadata. Authorization of access to the entire metadata or part of it must be performed according to predetermined authorization rules. This metadata access authorization process is performed on each application or each metadata.
Various operations including 'view', 'modify', and 'copy' are carried out based on accessing of the entire metadata or part of it. 'View' is one of the simplest examples of metadata use and is simply performed by accessing the metadata. On the other hand, in the case of modifying or copying all or part of the metadata, a metadata file management system is required. In addition, in the case of copying the metadata using a remote application, for example, in the case of transmitting the metadata from a client to a service provider, a request for the metadata and transmission of the requested metadata and its source authentication information are required.
In addition, it is necessary to preserve metadata confidentiality in order to preserve the security of metadata. In some cases, metadata may include highly confidential or private data. For this or other reasons, metadata needs to be encrypted before being transmitted or stored so that it can be prevented from being undesirably exposed to the public. In other words, even during transmitting metadata, the confidentiality of the metadata can be preserved by performing transmission-level encryption on the metadata, i.e., encrypting a transmission unit or container of the metadata. In addition to the transmission-level encryption of the metadata, source-level encryption of the metadata can solve all possible problems concerning the confidentiality of metadata at a transmission level or a storage level. Hereinafter, the security of metadata in a unidirectional channel environment concerning a conditional access system and a bi-directional channel (TLS) environment will be described in greater detail.
Here, the unidirectional channel environment concerning a conditional access system includes terrestrial broadcasting, such as ATSC or DVB, satellite broadcasting, such as Direct TV, cable TV, and IP-multicasting. In the unidirectional channel environment concerning a conditional access system, a unidirectional channel is used except for a case where data exchanges, such as transactions, are carried out using a return channel. Functions provided in the unidirectional channel environment concerning a conditional access system are as follows.
A receiver and a transmitter with hardware devices automatically authorize each other. In addition, the receiver and the transmitter are enabled to share a common secret via a predetermined channel. Here, the common secret represents a code shared by the receiver and the transmitter. Packet payload is encrypted and transmitted. Later, the encrypted packet payload is decrypted using the common secret or using a key decrypted with the use of the common secret.
In the bi-directional channel environment, a handshake protocol is used and a server and a client authorize each other by exchanging and authenticating certificates issued by a third certificate authorization organization. A common secret is shared by the client and the server, and a session key is generated later. Packet payload is encrypted using the session key and then transmitted. The encrypted packet payload is decrypted using the session key. Source authentication may be performed using an algorithm, such as DSA or MAC. In addition, in the bi-directional channel environment, authorization of the client and the server is performed through the authentication and exchange of certificates issued a third certificate authorization organization. The confidentiality of data transmitted between the client and the server to the other is preserved through encryption of packet payload and message authentication.
In order to keep metadata secured during the transmission of the metadata, the common secret needs to be shared by the receiver and the transmitter in a safe manner so that the receiver and the transmitter can authorize each other and data transmitted there between and data can be encrypted and then transmitted.
Hereinafter, a method for protecting metadata at a transmission level or at a source level will be described in greater detail.
As for the protection of metadata during the transmission of the metadata, authorization of a receiver and a transmitter is carried out at a transmission level, and authorization of the metadata and preservation of the confidentiality of the metadata are carried at a broadcasting system level.
For example, in a unidirectional channel, each SOAP message consisting of a head and a body can be used as a unit of protection, as shown in FIG. 10. On the other hand, in a bi-directional channel, data signature information is transmitted using a SOAP message, in which case the data information is included in the body of the SOAP message, as shown in FIG. 1 1. Data contained in the body of the SOAP message can be encrypted.
Hereinafter, a method for preserving metadata integrity and confidentiality and controlling metadata access and use in a broadcasting system, which is classified as metadata protection at a source level, will be described.
The preservation of metadata integrity and confidentiality in a broadcasting system is enabled by allotting an authentication signature to metadata and encrypting the metadata. Given that the entire metadata is not always subjected to such an encryption process because of no need to preserve the integrity of the entire metadata, it is necessary to represent specific portions of the metadata that have been encrypted or authenticated with a predetermined pointer, and this process can be performed at a source level where the predetermined pointer can be maintained by using a right management protection (RMP) system. By using a source level signature, a metadata source can be practically authenticated. Of course, the metadata must include such information as a source authentication signature. In order to control metadata access and usage, a standard description of metadata access and usage rights and implementation thereof are required. A standard description may have an XML schema format or may assume the form of an element of a set of data having a predetermined meaning. Such a standard description may be generated using a conventional markup language, such as XrML, XACML, or SAML. A license description and a usage rule can be isolated from metadata. In a case where there are many metadata fragments, usage information of which is worth describing, access/usage control can be performed in such a simple way as follows. Once access to an application is authorized, the application is believed to operate following predetermined usage rules set as default values.
In this case, an application program interface (API) of an RMP system is used to access or use metadata. The API is needed when access/usage control information is managed by a TVA RMP system. For example, the API issues and authorizes a request for accessing metadata. In addition, the API modifies, copies, and exports metadata.
As described above, there are several types of authentication that can be performed at a predetermined structure level, and they are transmission-level authentication, metadata container-level authentication or SOAP message-level authentication, and source-level authentication.
In the case of source-level authentication, authentication information on specific portions of metadata that have been authenticated is provided using a pointer. In the case of a SOAP message-level authentication, authentication information is included in a header of a SOAP message together with a pointer for part of metadata contained in the body of the SOAP message or a pointer for the entire metadata.
In a case where only metadata integrity is requested to be preserved during transmission of metadata, only transmission-level authentication is required. On the other hand, in a case where there is a need to secure transmission independence, metadata container-level authentication or SOAP message-level authentication can satisfy the need. The size of metadata contained in a metadata container or a body of an SOAP message is much larger than the size of a transmission packet. Therefore, transmission-level authentication helps reduce a system's load, in which case a security channel is not necessary.
Authentication of a metadata source requires metadata container-level authentication and SOAP message-level authentication. The syntax of a metadata container enabling source authentication is shown in FIG. 1 1.
In order to perform source authentication on metadata at each node between a source and a final destination, source authentication information needs to be provided to each node between the source and the final destination. More specifically, metadata is authenticated at a predetermined node between a source and a final destination using authentication information transmitted from a previous node, new authentication information is generated, and the metadata and the new authentication information are passed on to a next node. Alternatively, metadata is authenticated at a predetermined node using authentication information transmitted from a previous node, and the metadata and the authentication information are directly passed on to a next node so that the metadata can be authenticated again at the next node using the authentication information. Accordingly, in the case of transmitting metadata from a source to a final destination while source-level-authenticating the metadata at each node between the source and the final destination, a flag or a signal, indicating whether new authentication information is generated or not after the metadata is authenticated at a predetermined node using authentication information transmitted from a previous node, can be inserted into the authentication information. The flag or signal indicating the presence of source authentication information helps a receiver determine whether to accept the corresponding metadata or not.
While the present invention has been particularly shown and described with reference to exemplary embodiments thereof, 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 of the present invention as defined by the following claims.
The above-described embodiments of the present invention can be realized as computer-readable codes written on a computer-readable recording medium. The computer-readable recording medium includes all kinds of storages where computer-readable data can be stored, such as a ROM, a RAM, a CD-ROM, a magnetic tape, a hard disk, a floppy disk, a flash memory, an optical data storage, and a carrier wave, such as data transmission through the Internet. The computer-readable recording medium can be distributed over computer systems connected via a network so that the computer-readable codes written on the computer-readable recording medium can be executed in an independent manner.
Industrial Applicability
As described above, the method for managing metadata according to the present invention makes it possible to authenticate metadata at a metadata container level. Therefore, it is possible to carry out transmission-level authentication in any channel environment. In addition, the present invention makes it possible to selectively carry out either transmission-level authentication or source-level authentication or both by inserting data format information indicating the format of metadata into a metadata container. Considering that the size of a metadata container-level packet is larger than the size of a transmission-level packet, the present invention reduces the number of packets to be transmitted, thus simplifying a system.

Claims

What is claimed is:
1. A method for managing metadata in a metadata transmission server, comprising:
(a) generating a plurality of fragment data by partitioning metadata to be transmitted on the basis of a predetermined segment unit;
(b) selecting predetermined fragment data among the plurality of fragment data;
(c) generating metadata-related information using the selected fragment data; and (d) transmitting the selected fragment data and the metadata-related information with data format information indicating the type of the selected fragment data.
2. The method of claim 1 , wherein the selected fragment data, the metadata-related information, and the data formation information of the selected fragment data are transmitted in a metadata container.
3. The method of claim 1 , wherein the data format information indicates whether the selected fragment data has a binary XML format or a text XML format.
4. The method of claim 1 , wherein the plurality of fragment data are predetermined semantic units of the metadata.
5. The method of claim 2, wherein an authentication level flag specifying a metadata authentication level is further contained in the metadata container.
6. The method of claim 1 , wherein the metadata-related information is metadata digest information obtained by substituting the selected fragment data into a unidirectional function.
7. The method of claim 6, wherein the unidirectional function is a hash function.
8. The method of claim 1 further comprising generating metadata authentication signature information using the metadata-related information and a first encryption key and inserting the metadata authentication signature information in the metadata container containing the selected fragment data.
9. The method of claim 8, wherein the metadata authentication signature information is obtained by substituting the metadata-related information and the first encryption key into a unidirectional function.
10. The method of claim 9 further comprising encrypting the first encryption key using a second encryption key and inserting the encrypted first encryption key into the metadata container containing the selected fragment data.
11. The method of claim 2, wherein the plurality of fragment data and their respectively metadata-related information are inserted into the metadata container, and each of the plurality of fragment data and its corresponding metadata-related information are connected to each other by pointer information.
12. The method of claim 8, wherein the plurality of fragment data and their respective metadata-related information and metadata authentication signature information are inserted into the metadata container, and each of the plurality of fragment data and its corresponding metadata-related information and metadata authentication signature information are connected to one another by pointer information.
13. A method for managing metadata in a client that receives the metadata, comprising:
(a) reading predetermined fragment data and' its corresponding metadata-related information and data format information indicating the type of the predetermined fragment data from the received metadata;
(b) generating metadata-related information using the predetermined fragment data and its corresponding data format information; and
(c) determining whether or not the received metadata has been authenticated by comparing the metadata-related information generated in step (b) with the metadata-related information read in step (a).
14. The method of claim 13, wherein the predetermined fragment data and its corresponding metadata-related information and data format information are received in a metadata container.
15. The method of claim 13, wherein the data format information indicates whether or not the predetermined fragment data has a binary XML format or a text XML format.
16. The method of claim 13, wherein the fragment data is a predetermined semantic unit of the received metadata.
17. The method of claim 14, wherein an authentication level flag is further included in the metadata container.
18. The method of claim 13, wherein the metadata-related information is metadata digest information obtained by substituting the predetermined fragment data into a unidirectional function.
19. The method of claim 18, wherein the unidirectional function is a hash function.
20. The method of claim 14, wherein a plurality of fragment data and their respective metadata-related information are included in the metadata container, and each of the plurality of fragment data and its corresponding metadata-related information is connected to each other by pointer information.
21. A method for managing metadata in a client that receives the metadata, comprising:
(a) receiving fragment data of the received metadata, metadata-related information, data format information indicating the type of the fragment data, metadata authentication information, and an encrypted first encryption key;
(b) generating metadata-related information using the fragment data of the received metadata and its corresponding data format information;
(c) decrypting the encrypted first encryption key using a second encryption key stored in the client;
(d) generating metadata authentication signature information using the generated metadata-related information and the decrypted first encryption key; and
(e) determining whether or not the received metadata has been authenticated by comparing the generated metadata authentication signature information with the received metadata authentication signature information.
22. The method of claim 21 , wherein the metadata-related information is metadata digest information obtained by substituting the fragment data into a unidirectional function.
23. The method of claim 22, wherein the unidirectional function is a hash function.
24. The method of claim 21 , wherein the generated metadata authentication signature information is obtained by substituting the generated metadata-related information and the decrypted first encryption key into a unidirectional function.
25. The method of claim 24, wherein the unidirectional function is a hash function.
26. The method of claim 21 , wherein the fragment data, its corresponding metadata-related information, data format information, and metadata authentication signature information, and the encrypted first encryption key are received, being contained in a metadata container.
27. The method of claim 21 , wherein the data format information indicates whether the fragment data used to generate the metadata-related information has a binary XML format or a text XML format.
28. The method of claim 21 , wherein the fragment data is a predetermined semantic unit of the received metadata.
29. The method of claim 26, wherein an authentication level flag is further included in the metadata container.
30. The method of claim 26, wherein a plurality of fragment data and their respective metadata-related information and metadata authentication signature information are inserted into the metadata container, and each of the plurality of fragment data and its corresponding metadata-related information and metadata authentication signature information are connected to one another by pointer information.
EP03808905A 2002-10-15 2003-04-09 Method for managing metadata Withdrawn EP1552420A4 (en)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US41816002P 2002-10-15 2002-10-15
US418160P 2002-10-15
US42525902P 2002-11-12 2002-11-12
US425259P 2002-11-12
KR2003013002 2003-03-03
KR1020030013002A KR100860984B1 (en) 2002-10-15 2003-03-03 Method for managing metadata
PCT/KR2003/000713 WO2004036449A1 (en) 2002-10-15 2003-04-09 Method for managing metadata

Publications (2)

Publication Number Publication Date
EP1552420A1 true EP1552420A1 (en) 2005-07-13
EP1552420A4 EP1552420A4 (en) 2009-01-21

Family

ID=32110678

Family Applications (1)

Application Number Title Priority Date Filing Date
EP03808905A Withdrawn EP1552420A4 (en) 2002-10-15 2003-04-09 Method for managing metadata

Country Status (4)

Country Link
EP (1) EP1552420A4 (en)
JP (2) JP4397373B2 (en)
AU (1) AU2003235490A1 (en)
WO (1) WO2004036449A1 (en)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI20045201A (en) 2004-05-31 2005-12-01 Nokia Corp A method and system for viewing and enhancing images
US7860989B2 (en) * 2005-02-02 2010-12-28 Microsoft Corporation Efficient transformation of interchange format messages
US20060294383A1 (en) * 2005-06-28 2006-12-28 Paula Austel Secure data communications in web services
US8527563B2 (en) 2005-09-12 2013-09-03 Microsoft Corporation Remoting redirection layer for graphics device interface
CN103957102B (en) * 2014-03-11 2017-02-08 西南科技大学 Safety multicast source authentication method based on group data packet coupling

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001052178A1 (en) * 2000-01-13 2001-07-19 Digimarc Corporation Authenticating metadata and embedding metadata in watermarks of media signals
US20020103920A1 (en) * 2000-11-21 2002-08-01 Berkun Ken Alan Interpretive stream metadata extraction

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6389403B1 (en) * 1998-08-13 2002-05-14 International Business Machines Corporation Method and apparatus for uniquely identifying a customer purchase in an electronic distribution system
KR100279735B1 (en) * 1998-11-20 2001-02-01 정선종 Multimedia Content Delivery Method Using Metadata
JP2002023903A (en) * 2000-07-11 2002-01-25 Nippon Telegr & Teleph Corp <Ntt> Use interaction method, device for performing the same and storage medium storing program for performing the same
JP2002057662A (en) * 2000-08-07 2002-02-22 Sony Corp Information-processing device and method, and record medium
JP4296698B2 (en) * 2000-08-17 2009-07-15 ソニー株式会社 Information processing apparatus, information processing method, and recording medium
KR100417569B1 (en) * 2000-12-08 2004-02-05 학교법인 인하학원 Search method of distributed/heterogeneous gis databases using metadata interchange standard
KR100398610B1 (en) * 2001-01-30 2003-09-19 한국전자통신연구원 Method and apparatus for delivery of metadata synchronized to multimedia contents
JP2003051816A (en) * 2001-08-07 2003-02-21 Sony Corp Contents distribution system, contents distribution method, data processor, data processing method, and computer program
AUPR970301A0 (en) * 2001-12-21 2002-01-24 Canon Kabushiki Kaisha Content authentication for digital media based recording devices
JP2003248737A (en) * 2002-02-22 2003-09-05 Ntt Comware Corp System and method for providing reliability to meta- information
JP2004072184A (en) * 2002-08-01 2004-03-04 Nippon Hoso Kyokai <Nhk> Data tampering prevention apparatus and program therefor
JP4309629B2 (en) * 2002-09-13 2009-08-05 株式会社日立製作所 Network system
JP4009634B2 (en) * 2004-03-04 2007-11-21 日本電気株式会社 ACCESS CONTROL METHOD, ACCESS CONTROL SYSTEM, METADATA CONTROLLER, AND TRANSMISSION DEVICE

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001052178A1 (en) * 2000-01-13 2001-07-19 Digimarc Corporation Authenticating metadata and embedding metadata in watermarks of media signals
US20020103920A1 (en) * 2000-11-21 2002-08-01 Berkun Ken Alan Interpretive stream metadata extraction

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of WO2004036449A1 *

Also Published As

Publication number Publication date
JP4397373B2 (en) 2010-01-13
JP2006506025A (en) 2006-02-16
WO2004036449A1 (en) 2004-04-29
JP4740923B2 (en) 2011-08-03
EP1552420A4 (en) 2009-01-21
JP2008118653A (en) 2008-05-22
AU2003235490A1 (en) 2004-05-04

Similar Documents

Publication Publication Date Title
US8301884B2 (en) Method of managing metadata
KR100965886B1 (en) Method for managing metadata
US9569627B2 (en) Systems and methods for governing content rendering, protection, and management applications
US7668316B2 (en) Method for encrypting and decrypting metadata
KR100753932B1 (en) contents encryption method, system and method for providing contents through network using the encryption method
US8683602B2 (en) System and method for multilevel secure object management
US7200230B2 (en) System and method for controlling and enforcing access rights to encrypted media
US20130283051A1 (en) Persistent License for Stored Content
US20040139312A1 (en) Categorization of host security levels based on functionality implemented inside secure hardware
CN109067814B (en) Media data encryption method, system, device and storage medium
JP3695992B2 (en) Broadcast receiving apparatus and content usage control method
EP2466511B1 (en) Media storage structures for storing content and devices for using such structures
US20060161502A1 (en) System and method for secure and convenient handling of cryptographic binding state information
US20060106721A1 (en) Method for retransmitting or restoring contents key for decrypting encrypted contents data
US9311492B2 (en) Media storage structures for storing content, devices for using such structures, systems for distributing such structures
JP4740923B2 (en) How to manage metadata
CN101216869B (en) Method of managing metadata

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20050426

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL LT LV MK

DAX Request for extension of the european patent (deleted)
RBV Designated contracting states (corrected)

Designated state(s): DE FR GB IT NL

A4 Supplementary search report drawn up and despatched

Effective date: 20081223

17Q First examination report despatched

Effective date: 20090710

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SAMSUNG ELECTRONICS CO., LTD.

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20191101