WO2019078411A1 - History verification method using block chain configuration between epcis history events - Google Patents

Abstract

A history verification method using block chain configuration between electronic product code information service (EPCIS) history events is disclosed. The history verification method according to one embodiment comprises the steps of: forming a block chain between respective events in the EPCIS; and verifying the history information of the events through the block chain formed between the respective events.

Description

History verification method by block chain structure between EPCIS history events

The following description relates to a method and system for verifying the history of events in EPCIS.

The GS1 EPCGlobal framework includes the EPCIS standard for sharing event information and the Pedigree standard for accumulating signatures based on user signatures between occurrence events.

1 is an example of a comparison of event data recording methods of EPCIS and Pedigree standard. Assume that the order of occurrence of events is A> B> C. In the EPCIS standard, event data can be stored in the event repository EPCIS according to the order of occurrence of events. For example, an A event may be stored in Alice's EPCIS, a Bob event may be stored in Bob's EPCIS, and a Carol event may be stored in Carol's EPCIS.

In the Pedigree standard, when A event is stored in EPCIS of Alice, B event is stored in EPCIS of Bob, and A event and B event are signed using Bob's private key and stored. Also, in storing the C event in the Carol's EPCIS, the B event including the signed A event is included in the C event using the private key of Bob, and signed and stored using the private key of the carol.

In the case of the Pedigree standard, it is possible to guarantee safety by accumulating events based on user signatures every time a new event is added to the EPCIS standard. However, since the size of data increases every time events are accumulated, .

[Prior Art]

Korean Patent Publication No. 10-2010-0137868, Korean Patent Publication No. 10-2010-0098863

It is possible to provide a secure history verification method and system provided by Pedigree without accumulating data in the event repository EPCIS.

The history verification method includes: forming a block chain between respective events in an electronic product code information service; And verifying the history information of the event through a block chain formed between the respective events.

Wherein the step of forming the block chain generates a Nth hash value for the Nth event when a plurality of events exist and an N (N is a natural number) event is generated for the first time, Signing the Nth signature value with the private key of the object recording the Nth event and writing the Nth signature value obtained for the Nth event to the extension field of the Nth event can do.

Wherein the step of forming the block chain comprises: generating an N + 1 hash value for the (N + 1) -th event through the (N + 1) -th event and the N-th signature value, 1 signature value obtained for the (N + 1) -th event is acquired as an extension field of the (N + 1) -th event, In the second step.

The step of verifying the history information of the event may include verifying the history information of the event and the validity of the object by using the public key of each object as the signature value recorded in the extension field of each event .

The step of verifying the history information of the event may include extracting a Nth hash value for the Nth event by performing validity verification using the public key of the object recording the Nth signature value, .

The verification of the history information may include decrypting the (N + 1) -th signature value using the public key of the object recording the (N + 1) -th event, 1 event and the hash value extracted by the N-th signature value, and verifying the validity.

The step of verifying the history information may include performing a validation for each of the block chains and a verification of a signature value for each object by separating a block chain formed between the events and a signature value generated for the event .

A computer program stored in a computer-readable recording medium for executing a history verification method includes: forming a block chain between respective events in an electronic product code information service; And verifying the history information of the event through a block chain formed between the respective events.

The history verification system includes a block chain forming unit for forming a block chain between respective events in an electronic product code information service; And a verification unit for verifying the history information of the event through a block chain formed between the respective events.

Wherein the block chain forming unit generates an Nth hash value for the Nth event when a plurality of events exist and an N (N is a natural number) event is generated for the first time, An Nth signature value may be acquired by signing with the private key of the object recording the Nth event, and an Nth signature value obtained for the Nth event may be recorded in the extension field of the Nth event.

Wherein the block chain forming unit generates an N + 1 hash value for the (N + 1) -th event through the (N + 1) -th event and the N-th signature value, 1 signature value obtained for the (N + 1) -th event by signing with the private key of the object recording the event, and writing the (N + 1) .

The verification unit may verify the history information of the event and the validity of the object by using the signature value recorded in the extension field of each event using the public key of each object.

The verifying unit may extract the Nth hash value for the Nth event by performing the validity verification using the public key of the object recording the Nth signature value.

The verification unit decrypts the (N + 1) -th signature value using the public key of the object for recording the (N + 1) -th event, and outputs the hash value for the It is possible to verify the validity by judging whether or not it is the same as the hash value extracted by the Nth signature value.

The verification unit may perform validation of each block chain and verification of a signature value for each object by separating a block chain formed between the events and a signature value generated for the event.

The history verification system according to an exemplary embodiment can clarify responsibility by separately storing the signature values for each event as the EPCIS inter-event block chain is generated.

The history verifying system according to an embodiment can verify the history of the block chain formed between the events using the public key and perform the history verification without accumulation of data securely.

The history verification system according to an embodiment verifies the validity of the history information for each event by verifying the block chain formed between the events using the public key, as well as the signature information for each event.

1 is an example of a comparison of event data recording methods of EPCIS and Pedigree standard.

FIG. 2 is a diagram for explaining a history verification process in the history verification system according to the embodiment.

3 is a block diagram illustrating a configuration of a history verification system according to an exemplary embodiment of the present invention.

FIG. 4 is a flowchart for explaining a history verification method in the history verification system according to the embodiment.

5 and 6 are views for explaining a method of forming an inter-event block chain in the history verification system according to an embodiment.

FIG. 7 is a diagram for explaining a method of verifying the validity of inter-event block chains in the history verification system according to the embodiment.

FIG. 8 is a diagram for explaining another method for verifying the validity of an inter-event block chain in the history verification system according to the embodiment.

9 is a diagram for explaining a method of managing a livestock history by applying the present invention to a logistics environment in a history verification system according to an embodiment.

Hereinafter, embodiments will be described in detail with reference to the accompanying drawings.

FIG. 2 is a diagram for explaining a history verification process in the history verification system according to the embodiment.

The history verification system can form a block chain between each event in the electronic product code information service, and can verify the history information of the event through a block chain formed between the respective events. The history verification system can provide a secure history authentication verification system provided by Pedigree without accumulating data in the event repository EPCIS.

For example, assume that each EPCIS including the A event 210, the B event 220, and the C event 230 exists and the order of generation of the event is A-> B-> C. In other words, there may be an A event 210 in Alice's EPCIS, a B event 220 in Bob's EPCIS, and a C event 230 in Carol's EPCIS. At this time, the number of events in each EPCIS is not limited. In the embodiment, A, B and C events existing in each EPCIS will be described by way of example.

The history verification system can build Pedigree's event accumulation method by forming a block chain between EPCIS. Specifically, the history verification system can generate a block chain for each event present in the EPCIS.

Referring to FIGS. 5 and 6, a process for forming an inter-event block chain in the history verification system is described. First, when there are a plurality of events, the history verification system can determine whether the event is the first occurrence of the N (N is a natural number) event. The history verification system generates a first hash value for the Nth event when the Nth event (N is a natural number) event is generated for the first time, signs it with the private key of the object that records the Nth event in the Nth hash value And may record the Nth signature value obtained for the Nth event in the extension field of the Nth event. FIG. 5 is for generating a signature value in Alice's EPCIS, where the history verification system may generate a hash value (Hash (A)) for the A event 210 residing in Alice's EPCIS. The history verifying system _checks the signature value (Signature _Alice ) by signing with Alice's private key 211 which records the A event 210 in the hash value (Hash (A)) for the A event 210 Can be obtained. The history verification system may record the signature value (Signature _Alice ) obtained for the A event 210 in the extended field of the A event 210. [

The history verification system generates an (N + 1) -th hash value for the (N + 1) -th event through the (N + 1) 1 signature value by signing with the private key and recording the (N + 1) -th signature value obtained for the (N + 1) -th event in the extension field of the (N + 1) -th event. Thus, the history verification system can form a block chain between each event in the EPCIS. To 6 is for generating a signature value for EPCIS of rice, the history verification system a signed value (Signature _Alice) obtained for the B event 220 and the previous signature, A event (210) present in the EPCIS Bob A hash value (Hash (B + Signature _Alice )) for the B event 220 can be generated. The history verifying system may be configured to sign with the Bob's private key (Sign _BobPrivkey ) 221 that records the B event 220 in the hash value (Hash (B + Signature _Alice )) for the B event 220, _Bob. &_Lt; / RTI > The history verification system may record the signature value obtained for the B event 220 (Signature _Bob ) in the extended field of the B event 220. [

Likewise, the hash value (Hash (C + 1)) for the C event 230 through the signature value (Signature _Bob ) obtained for the C event 230 in the Carol's EPCIS and the B event 220, Signature _Bob ). The history verifying system _signs a private key (Sign _CarolPrivkey ) 231 that records a C event 230 in a hash value (Hash (C + Signature _Bob )) for the C event 230, _Carol ). The history verification system may record the signature value (Signature _Carol ) obtained for the C event 230 in the extension field of the C event 230. [ In this way, the history verification system can form a block chain between events. The history verification system can keep the signature values for the events individually.

The history verification system according to the embodiment can prevent the size of the data from increasing by forming a block chain between events and can reduce the overall amount of operation that occurs as the events are accumulated continuously.

FIG. 7 is a diagram for explaining a method of verifying the validity of inter-event block chains in the history verification system according to the embodiment.

* The history verification system can verify the validity of the signature value through the block chain for each link of each block chain. The history verification system may extract the Nth hash value for the Nth event by performing the validity verification using the public key of the object recording the Nth signature value. The history verification system decrypts the (N + 1) -th signature value using the public key of the object recording the (N + 1) -th event, and outputs the hash value for the extracted (N + 1) It is possible to verify whether the hash value is the same as the hash value extracted by the value. In this case, the hash value for the (N + 1) -th event extracted by decoding the (N + 1) -th signature value using the public key of the object for recording the (N + 1) If it matches the extracted hash value, it is judged as True.

It is assumed that an event shares a public key between each participant (e.g., Alice, Bob, and Carol) to validate the block chain.

History verification system hash value for the A event 210 in accordance with carrying out the validation using the public Alice's key to record a signature value (Signature _Alice) to A event 210 on A event 210 (Hash (A)) can be extracted. At this time, a signature value (Signature _Alice ) for the A event 210 is decrypted with the public key of Alice, which records the A event 210, and the hash value of the extracted A event 210 is stored in the A event 210 The validity of the hash value can be verified. In other words, it can be determined whether the Verify _{AlicePublickey} (Signature _Alice ) and the Hash (A) match. At this time, if the Verify _{AlicePublickey} (Signature _Alice ) matches the Hash (A), the validity of the B event is verified.

The history verification system extracts a hash value for the B event 220 by performing a validity check using a public key of Bob that records a signature value (Signature _Bob ) for the B event 220, can do. Signature values for the B event 220 (Signature _Bob) the hash value for the B event 220 extracted by decrypting the public key of the rice to record B event 220 B event 220 and the A event (210 (Signature _Alice ), and verify the validity of the hash value. In other words, it can be determined whether the Verify _BobPublickey (Signature _Bob ) and the Hash (B + Signature _Alice ) match. At this time, if the Verify _BobPublickey (Signature _Bob ) matches the Hash (B + Signature _Alice ), the validity of the C event is verified.

The history verification system extracts a hash value for the C event 230 by performing a validation verification using a KAOL public key that records a signature value (Signature _Carol ) for the C event 230 to the C event 230 can do. The hash value for the extracted C event 230 is obtained by decrypting the signature value (Signature _Carol ) for the C event 230 with the public key of the carol recording the C event 230 as the C event 230 and the B event 220 (Signature _Bob ) of the hash value of the hash value. In other words, it is possible to judge whether Verify _{CarolPublickey} (Signature _Carol ) matches Hash (C + Signature _Bob ). At this time, if Verify _{CarolPublickey} (Signature _Carol ) matches Hash (C + Signature _Bob ), validation is completed.

Thus, the history verification system can determine whether the signature value recorded in the extended field of the event is the same as the hash value for each event extracted using each public key. In this case, if the extracted value does not match the hash value of the event, the link of the next block chain can not be verified. If the extracted value matches the hash value of the event, You can verify the link.

In this way, the history verification system determines whether the extracted value of the signature value recorded in the extended field of the event is equal to the hash value by using each public key, and thereby not only verifies the history of the overall history event, To verify the validity of the signer who signed it.

FIG. 8 is a diagram for explaining another method for verifying the validity of an inter-event block chain in the history verification system according to the embodiment.

The history verification system can divide the block chain and the signature information (signature value) and divide the validation into a plurality of steps. In the embodiment, the validity check can be performed in two steps. At this time, the validity verification can be performed through sharing of some public keys without sharing all the shared keys among the respective participants.

First, another method of generating a hash value for each event that exists in each EPCIS will be described. As described in FIG. 2, it is assumed that each EPCIS including the A event 210, the B event 220, and the C event 230 exists and the order of generation of the event is A-> B-> C. In other words, there may be an A event 210 in Alice's EPCIS, a B event 220 in Bob's EPCIS, and a C event 230 in Carol's EPCIS. At this time, contrary to the foregoing description, the history verification system can generate the hash value (Hash (A)) for the A event 210. [ It is also possible to generate a hash value Hash (Hash (A) + B) for the B event 220, including the hash value for the A event 210 and the B event 220. [ (Hash (B) + C) for the C event 230, including the hash value for the B event 220 and the C event 230. [

The history verification system can generate a signature value by signing the generated hash value for each event with the private key of the object recording each event. In other words, the history verification system may generate a signature value (Signature _Alice ) for the A event 210 using Alice's private key as the hash value (Hash (A)) for the A event 210, A signature value (Signature _Bob ) for the B event 220 can be generated using Bob's private key as a hash value (Hash (A) + B) for the event 220, and a C event 230 A signature value (Signature _Carol ) for the C event 230 can be generated using the private key of the carol as the hash value (Hash (Hash (B) + C) At this time, the signature value can be recorded in the extension field of each event.

The history verification system can verify the validity of the inter-event block chain through the hash value. At this time, it is not necessary to exchange the public key between each participant. In other words, the history verification system can perform validation of block chaining between events without exchanging public keys.

In addition, the history verification system can verify the signature of each event in each EPCIS by verifying the validity of the block chain. At this time, the history verification system needs to exchange the public key for each object in order to verify the signature value for each event. Accordingly, the history verification system can determine whether the signature information signed by the event is correct through the exchange of the public key. For example, the history verification system extracts a signature value (Signature _Alice ) recorded in the extension field of the A event 210 using a public key of Alice, a hash value (Hash (A)) for the A event 210 can do. At this time, if the hash value of the extracted A event 210 matches the hash value of the A event, the validity of the B event can be verified. If the signature value (Signature _Bob ) recorded in the extension field of the B event 220 is a hash value of the B event 220 extracted using the public key of Bob and the hash value of the A event 210 and B It is possible to verify whether the hash value extracted through the event 220 matches the hash value and verify the validity. The hash value of the B event 220 extracted using the public key of Bob is calculated by using the hash value for the A event 210 and the hash value Hash (A) extracted through the B event 220, + B)), the validity of the C event can be verified.

The signature value recorded in the extension fields of the C event 230 (Signature _Carol) the hash value and C events for the hash value for the C event 230 B event 220 using the public key of the Karol 230 It is possible to judge whether or not the hash value is identical with the extracted hash value. When the hash value of the C event extracted using the public key of the carol matches the hash value (Hash (Hash (B) + C) through the hash value for the B event 220 and the C event 230 , And validation of the C event can be completed.

The history verifying system according to an embodiment can perform verification of whether each block chain event has one flow by individually storing each event in the EPCIS through the history verification through the block chain.

FIG. 3 is a block diagram illustrating a configuration of a history verification system according to an embodiment. FIG. 4 is a flowchart illustrating a history verification method in a history verification system according to an exemplary embodiment.

The processor 300 of the history verifying system 100 may include a block chain forming unit 320 and a verifying unit 320. The components of such a processor 300 may be representations of different functions performed by the processor 300 in accordance with control commands provided by the program code stored in the history verification system 100. The processor 300 and the components of the processor 300 may control the history verification system 100 to perform the steps 410 to 420 included in the history verification method of FIG. At this time, the components of the processor 300 and the processor 300 may be implemented to execute an instruction according to code of an operating system and code of at least one program included in the memory.

The processor 300 may load the program code stored in the file of the program for the history verification method into the memory. For example, when a program is executed in the history verification system 100, the processor can control the history verification system to load the program code from the file of the program into the memory under the control of the operating system. At this time, each of the block chain forming unit 310 and the verifying unit 320 included in the processor 300 and the processor 300 executes a command of a corresponding one of the program codes loaded in the memory, 420 may be different functional representations of the processor 300. For example,

In block 410, the block chain forming unit 310 may form a block chain between respective events in the electronic commodity code information service. The block chain forming unit 310 generates a Nth hash value for the Nth event when a plurality of events exist and an N (N is a natural number) event is generated for the first time, N signature value by signing with a private key owned by an object (e.g., a person, business, etc.) that records the N event, and acquiring the N-signature value obtained for the N-th event as an extension Field. The block chain forming unit 310 generates an (N + 1) -th hash value for the (N + 1) -th event through the (N + 1) 1 signature value by signing with the private key of the object to be recorded, and writing the (N + 1) -th signature value acquired for the (N + 1) -th event to the extension field of the (N + 1) -th event.

In operation 420, the verification unit 320 may verify the history information of the event through a block chain formed between the respective events. The verification unit 320 can verify the validity of the history information through the block chain verification for each block chain link. The verification unit 320 can verify the validity of the history information and the object by using the public key of each object as the signature value recorded in the extension field of each event. The verification unit 320 may extract the Nth hash value for the Nth event by performing the validity verification using the public key of the object recording the Nth signature value. The verification unit 320 decrypts the (N + 1) -th signature value using the public key of the object recording the (N + 1) -th event, It can be verified whether or not the hash value extracted from the signature value is equal to the hash value extracted from the signature value. In addition, when the block chain formed between the events and the signature value generated for the event are separated, the verification unit 320 may perform validation for each of the block chains and verification of the signature value for each object.

9 is a diagram for explaining a method of managing a livestock history by applying the present invention to a logistics environment in a history verification system according to an embodiment.

A method of managing the livestock history by applying to the logistics environment will be described. The history verification system can form a block chain for the livestock event and verify the validity of the formed block chain. For example, breeding history can be communicated to consumers through breeding farms, slaughterhouses, pavement shops, and stores.

More specifically, there may be producers and breeding farms that raise cattle, and at least one cattle may be in breeding farms. For example, the EPCIS for the breeding farm may contain information relating to each cattle present in the breeding farm (eg, cattle identification code, cattle date of birth, cattle breeding information, etc.). The history verification system can generate a hash value for the production event (910) occurring in the breeding farmer's EPCIS and obtain the signature value by signing the hash value for the production event with the producer's private key. The signature value generated for the production event 910 may be recorded in the extension field of the production event 910. [ At this time, some cows present in the breeding farm can be moved to the slaughterhouse.

Cattle can be slaughtered as cows are moved to slaughterhouses. Accordingly, a slaughter event 920 may occur in the EPCIS of the slaughterhouse. The history verification system generates a hash value for the slaughter event 920 through the signature value obtained for the slaughter event 920 and the production event 910 and generates a hash value for the slaughter event 920 using the private key of the slaughterer The signature value can be obtained by signing. The signature value obtained for the slaughter event 920 may be recorded in the extension field of the slaughter event 920. [

Cattle slaughtered at the slaughterhouse can be moved to the paving shop. Packing can be processed for each slaughtered portion of the slaughtered poultry. A packaging event 930 may occur in the EPCIS of the packaging processing shop. The history verification system generates a hash value for the packaged event 930 through the signature value obtained for the packaged event 930 and the slaughter event 920 and stores the hash value for the packaged event 930 The signature value can be obtained by signing with the key. The signature value obtained for the wrapping event 930 may be recorded in the extension field of the wrapping event 930. [

Packaged goods can be moved to a shop and sold at the packaging processing shop. A sales event 940 may occur in the EPCIS of the shop. The history verification system generates a hash value for the sales event 940 through the signature value obtained for the sales event 940 and the packaging event 930 and generates a hash value for the sales event 940 by using the seller's private key The signature value can be obtained by signing. The signature value obtained for the sales event 940 may be recorded in the extended field of the sales event 940. [

Through this process, the products circulated can be purchased by the consumers at the shop. The consumer can perform the history validation on the purchased product. For example, validation of a block chain formed between events can be performed as the EPC of a product is recognized by the consumer through the terminal. In other words, the history verification system can perform a history verification on a product. Specifically, the history verification system checks the signature value recorded in the extension field of the production event 910 by using the public key of the producer, which records the production event 910, The value can be extracted. At this time, if the public key of the producer is not a normal public key, even if the hash value is extracted, the extracted hash value and the previously stored hash value do not match, and the validity verification fails.

The history verification system checks the signature value recorded in the extension field of the slaughter event 920 by using a public key of the slaughterhouse which records the slaughter event 920 and performs hash verification for the extracted slaughter event 920 Is identical to the hash value extracted as the signature value for the slaughter event (920) and the production event (910). At this time, if each hash value is the same, it can be determined to be True and the next block chain link verification can be performed.

The history verification system checks the signature value recorded in the extension field of the packaging event 930 by using the public key of the packager 9 that records the packaging event 930, Value is the same as the hash value extracted as the signature value for the wrapping event 930 and the slaughter event 920. [ At this time, if each hash value is the same, it can be determined to be True and the next block chain link verification can be performed.

The history verification system checks the signature value recorded in the extension field of the sales event 940 by using the public key of the seller that records the sales event 940 and performs hash verification for the extracted sales event 940 Is identical to the hash value extracted as the signature value for the sales event 940 and the packaging event 930. [ At this time, when each hash value is the same, it is determined as True, and the verification of the next block chain can be completed.

Thus, the history information of the event can be verified through the block chain formed between the respective events.

The history verification system according to one embodiment can be applied to various fields such as medicine, food, and aviation as well as livestock history.

The apparatus described above may be implemented as a hardware component, a software component, and / or a combination of hardware components and software components. For example, the apparatus and components described in the embodiments may be implemented within a computer system, such as, for example, a processor, a controller, an arithmetic logic unit (ALU), a digital signal processor, a microcomputer, a field programmable gate array (FPGA) , A programmable logic unit (PLU), a microprocessor, or any other device capable of executing and responding to instructions. The processing device may execute an operating system (OS) and one or more software applications running on the operating system. The processing device may also access, store, manipulate, process, and generate data in response to execution of the software. For ease of understanding, the processing apparatus may be described as being used singly, but those skilled in the art will recognize that the processing apparatus may have a plurality of processing elements and / As shown in FIG. For example, the processing unit may comprise a plurality of processors or one processor and one controller. Other processing configurations are also possible, such as a parallel processor.

The software may include a computer program, code, instructions, or a combination of one or more of the foregoing, and may be configured to configure the processing device to operate as desired or to process it collectively or collectively Device can be commanded. The software and / or data may be in the form of any type of machine, component, physical device, virtual equipment, computer storage media, or device As shown in FIG. The software may be distributed over a networked computer system and stored or executed in a distributed manner. The software and data may be stored on one or more computer readable recording media.

The method according to an embodiment may be implemented in the form of a program command that can be executed through various computer means and recorded in a computer-readable medium. The computer-readable medium may include program instructions, data files, data structures, and the like, alone or in combination. The program instructions to be recorded on the medium may be those specially designed and configured for the embodiments or may be available to those skilled in the art of computer software. Examples of computer-readable media include magnetic media such as hard disks, floppy disks and magnetic tape; optical media such as CD-ROMs and DVDs; magnetic media such as floppy disks; Magneto-optical media, and hardware devices specifically configured to store and execute program instructions such as ROM, RAM, flash memory, and the like. Examples of program instructions include machine language code such as those produced by a compiler, as well as high-level language code that can be executed by a computer using an interpreter or the like.

While the present invention has been particularly shown and described with reference to exemplary embodiments thereof, it is to be understood that the invention is not limited to the disclosed exemplary embodiments. For example, it is to be understood that the techniques described may be performed in a different order than the described methods, and / or that components of the described systems, structures, devices, circuits, Lt; / RTI > or equivalents, even if it is replaced or replaced.

Therefore, other implementations, other embodiments, and equivalents to the claims are also within the scope of the following claims.

Claims (15)

1. In the history verification method,

   Forming a block chain between respective events in an electronic product code information service; And

   Verifying the history information of the event through a block chain formed between the respective events

   ≪ / RTI >
2. The method according to claim 1,

   Wherein forming the block chain comprises:

   When there are a plurality of events, generating an N-th hash value for the N-th event when an N-th (N is a natural number) event occurs first, and recording the N-th event in the N-th hash value Acquiring an N-th signature value by signing with an object's private key, and writing an N-signature value obtained for the N-th event in an extension field of the N-th event

   ≪ / RTI >
3. 3. The method of claim 2,

   Wherein forming the block chain comprises:

   1 hash value for the (N + 1) -th event through the (N + 1) th event and the (N + 1) Acquiring an (N + 1) -th signature value by signing with the private key, and writing the (N + 1) -th signature value acquired for the (N + 1)

   ≪ / RTI >
4. The method according to claim 1,

   Wherein the step of verifying the history information of the event comprises:

   Verifying the history information of the event and the validity of the object by using the public key of each object as the signature value recorded in the extension field of each event

   ≪ / RTI >
5. 5. The method of claim 4,

   Wherein the step of verifying the history information of the event comprises:

   Extracting a Nth hash value for the Nth event by performing validation using an Nth signature value using a public key of an object recording a Nth event

   ≪ / RTI >
6. 6. The method of claim 5,

   Wherein the step of verifying the history information comprises:

   The hash value of the extracted (N + 1) -th event is decrypted using the public key of the object for recording the (N + 1) -th event as the Determining whether the extracted hash value is the same as the extracted hash value, and verifying the validity

   ≪ / RTI >
7. The method according to claim 1,

   Wherein the step of verifying the history information comprises:

   Separating a block chain formed between the events and a signature value generated for the event to perform validation of each block chain and verification of a signature value for each object

   ≪ / RTI >
8. A computer program stored in a computer-readable recording medium for executing a history verification method,

   Forming a block chain between respective events in an electronic product code information service; And

   Verifying the history information of the event through a block chain formed between the respective events

   And a computer program stored in the computer readable recording medium.
9. In the history verification system,

   A block chain forming unit for forming a block chain between respective events in an electronic product code information service; And

   A verification unit for verifying the history information of the event through a block chain formed between the respective events,

   The history verification system comprising:
10. 10. The method of claim 9,

    Wherein the block chain forming portion comprises:

    When there are a plurality of events, generating an N-th hash value for the N-th event when an N-th (N is a natural number) event occurs first, and recording the N-th event in the N-th hash value Acquiring an Nth signature value by signing with an object's private key, and writing an Nth signature value obtained for the Nth event in an extension field of the Nth event

    The history verification system comprising:
11. 11. The method of claim 10,

    Wherein the block chain forming portion comprises:

    1 hash value for the (N + 1) -th event through the (N + 1) th event and the (N + 1) 1 signature value obtained for the (N + 1) -th event is recorded in the extension field of the (N + 1) -th event by obtaining the (N + 1)

    The history verification system comprising:
12. 10. The method of claim 9,

    Wherein the verifying unit comprises:

    The signature value recorded in the extension field of each event is verified by using the public key of each object to verify the history information of the event and the validity of the object

    The history verification system comprising:
13. 13. The method of claim 12,

    Wherein the verifying unit comprises:

    And extracts the N-th hash value for the N-th event by performing validity verification using the public key of the object for recording the N-th event as the N-th signature value

    The history verification system comprising:
14. 14. The method of claim 13,

    Wherein the verifying unit comprises:

    The hash value of the extracted (N + 1) -th event is decrypted using the public key of the object for recording the (N + 1) -th event as the It is judged whether or not the extracted hash value is the same as the extracted hash value and the validity is verified

    The history verification system comprising:
15. 10. The method of claim 9,

    Wherein the verifying unit comprises:

    A block chain formed between the events and a signature value generated for the event are separated to perform validation for each of the block chains and verification of the signature value for each object

    The history verification system comprising:

Images