BACKGROUND OF THE INVENTION1. Field of the Invention[0001]
The present invention relates to a verification data generating apparatus, a data verification apparatus and a storage medium for storing a verification data generating program and in particular relates to a verification data generating program that provides a signature to a data group to generate verification data, a data verification apparatus that verifies the verification data with a signature and a storage medium for storing a verification data generating program to attach a signature to a data group.[0002]
2. Discussion of the Related Art[0003]
Recently, networks have developed and various kinds of information are digitized to be distributed through a network. The information such as the character information, still pictures, animations, sound information, programs can be digitized and we can obtain various services on the network that are combinations of those pieces of digital information. However, the digital information has a major defect that it is easily copied. A copy of a piece of digital information is completely the same as the original. Once the digital information is distributed through the network, there occurs a possibility that the information would be copied and used without authorization by the author. Therefore, the author can hardly receive a justifiable reward to which he/she deserves. Thus the easiness of copying has been a factor that prevents distribution of the digital information on the network.[0004]
To overcome the problem, systems such as “CD-Showcase” (Trademark of International Business Machines Corporation) have been offered, wherein digital information is encrypted to be freely distributed and used with a decryption key acquired through the telephone network at some charge. However, in this method it is impossible to impose a charge to a user according to the frequency of use.[0005]
To impose the charge to the user according to the frequency of use, it is necessary to collect charge imposing information such as a using history. The collection of the using history requires a system for assuring legitimacy of the using history because it is also a piece of digital information.[0006]
As disclosed by Japanese Patent Application Laid-Open No. Hei. 3-25605 “Charge imposing information transmission method” (1991) and Japanese Patent Application Laid-Open No. Hei. 6-180762 “Charge imposing information collection system” (1994), devices for outputting the charge imposing information are connected to the communication network to automatically collect the charge imposing information. If the communication network is utilized, the legitimacy of the charge imposing information can be assured by a digital signature method or the like using the RSA (Rivest, Shamir, Adleman) encryption (see “Encryption Theory Introduction”, Eiji Okamoto, Kyoritsu Publishing company, 1993, pp. 134-138).[0007]
The above cases are suggested on the premise that a terminal device for using the digital information is always connected to a network. The premise is supposed because of the bad effects such as the tampering with the data by the user or system troubles caused by the storage of the data in the off-line terminal devices for a long time. However, in general, most of the users utilize the digital information off-line. Therefore it is hardly acceptable to constantly control the user's terminal device through the network considering the communication costs or operability of the system.[0008]
An Integrated Circuit (IC) card attracts attentions as a medium for storing secret information. The charge imposing information or the like can be securely collected by the IC card. Japanese Patent Publication No. Hei. 6-95302 (1994) discloses “Software administration method” applied to a system that imposes a charge for using software according to an amount of using and collects the charge by utilizing the IC card. More specifically, a user buys an IC card at a predetermined agency. The price is then written in a balance memory of the card. When the user activates the software, the balance memory of the IC card is checked and the amount corresponding to the charge for using the software is subtracted from the balance memory. When the user spends the whole amount of money written in the balance memory of the card, the card is forwarded to a Software Service Association (hereinafter, referred to as SS association). Particulars of use of the software is stored in the IC card. The SS association pays the charge for using to the author of the software based on the particulars. Therefore, it is possible to allow the user to use the software off-line and impose the charge to the user for the use of the software.[0009]
However, the method of forwarding the IC card that stored the using particulars to the SS association has problems in that whenever the amount of money stored in the balance memory of the card has been exhausted, the user has to wait for re-distribution of the card from the SS association or to buy a new IC card at the agency. In addition, the history data generally tends to be long. Accordingly, if the history data is stored in the IC card, it is necessary to frequently renew the card because it has merely a small memory capacity.[0010]
Therefore, a technology is required for securely saving the data, such as the charge imposing information generated by the IC card in the terminal device which should be certainly forwarded to the SS association. If the charge imposing information can be securely saved in the terminal device, frequent reissue of the IC card is unnecessary despite the small memory capacity of the card. The off-line services are available as a matter of course. The history data such as the charge imposing information is output many times. Consequently, it is necessary to maintain the order of the output pieces of the history data. The SS Association must verify the history data including the order of the pieces of the history data. If a piece of the history data is missed, the charge corresponding thereto cannot be collected.[0011]
Summary Of The InventionThe present invention has been made in view of the above circumstances and has an object to provide a verification data generating apparatus capable of generating data that can be saved in a terminal device without sustaining unauthorized operations and is assured to have continuity in the order of being output.[0012]
Another object of the present invention is to provide a data verification apparatus that can verify the data to be saved in a terminal device without sustaining unauthorized operations, where the continuity in the order of outputting pieces of the data is also verified.[0013]
Still another object of the present invention is to provide a storage medium storing a program to have a computer generate verification data that can be saved in a terminal device without sustaining unauthorized operations and is assured to have continuity in the order of being output.[0014]
Additional objects and advantages of the invention will be set forth in part in the description which follows and in part will be obvious from the description, or may be learned by practice of the invention.[0015]
To achieve the objects and in accordance with the purpose of the invention, as embodied and broadly described herein, a verification data generating apparatus of the present invention comprises a verification value holding element that holds a verification value and a data generating element that generates data bodies. The apparatus also comprises a verification value generating element that generates a new verification value based on both the verification value held in the verification value holding element and the data body whenever the data body is generated and updates the verification value held in the verification value holding element with the new verification value. The apparatus further comprises a data storing element that stores the data bodies generated by the data generating element in order of being generated and a verification data outputting element that generates a signature value by using the new verification value on receiving a verification data outputting request and outputs verification data including the data bodies and the signature value.[0016]
A data verification apparatus according to the present invention comprises a verification value holding element that holds a verification value and a reference verification value generating element that receives verification data that is a set of data bodies and a signature value attached thereto and generates a reference verification value based on the verification value and the set of data bodies. The apparatus also comprises an authenticating element that collates a verification value obtained from the signature value with the reference verification value and authenticates the verification data if the signature value and the reference verification value are consistent with each other. The apparatus further comprises a verification value updating element that updates the verification value with the reference verification value if the verification value obtained from the signature value and the reference verification value are consistent with each other.[0017]
BRIEF DESCRIPTION OF THE DRAWINGSThe accompanying drawings, which are incorporated in and constitute a part of this specification illustrate embodiment of the invention and, together with the description, serve to explain the objects, advantages and principles of the invention. In the drawings:[0018]
FIG. 1 shows a basic configuration of a verification data generating apparatus according to the present invention;[0019]
FIG. 2 shows a schematic configuration of a history management system using an IC card;[0020]
FIG. 3 shows a configuration of an encapsulated software;[0021]
FIG. 4 shows a hardware configuration of the IC card;[0022]
FIG. 5 is a block diagram showing processing functions of the IC card;[0023]
FIG. 6 is a flow chart showing procedures of starting execution of the encapsulated software;[0024]
FIG. 7 shows an example of a log configuration;[0025]
FIG. 8 shows a configuration of a log set with a signature;[0026]
FIG. 9 shows an example of configuration of a plain text attached as a signature value to the log set;[0027]
FIG. 10 is a flow chart showing procedures of outputting the log set from the IC card;[0028]
FIG. 11 shows an example of a user database managed by a history management center;[0029]
FIG. 12 is a flow chart showing procedures of verification of the log set in the history management center;[0030]
FIG. 13 shows details of procedures of verification of a verification value;[0031]
FIG. 14 shows an example of configuration of use extension data; and[0032]
FIG. 15 shows an authentication process for the use extension data in a second embodiment.[0033]
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTSFIG. 1 shows a basic configuration of a verification data generating apparatus according to the present invention.[0034]
A verification[0035]value holding element1 holds a verification value. Adata generating element2 generates a data body at a predetermined timing. For example, when a certain data processing request is received, a history of the previous data processing is generated as the data body.
Whenever the data body is generated by the[0036]data generating element2, a verificationvalue generating element3 generates a new verification value based on the verification value held by the verificationvalue holding element1 and the newly generated data body. With the new verification value, the preceding verification value held by the verificationvalue holding element1 is updated. Adata storing element4 stores the data bodies generated by thedata generating element2 in order. On receiving a verification data outputting request, a verificationdata outputting element5 generates a signature value based on the verification value held by the verificationvalue holding element1 and outputs verification data that is a combination of the generated signature value and the data body stored in thedata storing element4.
Accordingly, whenever the data processing request is executed, a new data body is stored in the[0037]data storing element4 and the verification value held in the verificationvalue holding element1 is updated. When the verification data outputting request is made, verification data with a signature value generated based on the verification value in the verificationvalue holding element1 is output.
The verification data is thus output with the signature attached. Therefore, the content of the data body cannot be tampered with even though the data is stored in the terminal devices or the like. In addition, since the new verification values are generated using the data bodies generated in order and the verification values previously generated, the continuity in the order of the output verification data is assured. (In the case where a large number of pieces of the verification data are generated, if a piece of the verification data is missed, the data cannot be authenticated by the verification apparatus such as a server. ) As a result, the verification data can be frequently output to the outside and stored in the off-line terminal device or the like. Consequently, though the memory capacity of the[0038]data storing element4 is small, no problem occurs.
The verification data generating apparatus of the present invention can be implemented on the IC card. In this case, the history data is not forwarded with the card. The verification value is held by the IC card and the history data is read from the IC card and temporarily saved in the terminal device. The history data is then transmitted from the terminal device to the history management center through the network. Thus the off-line collection of the histories and assurance of the legitimacy of the history data are possible. The IC card capable of securely obtaining the history data or the like using a technique such as the digital signature has already been distributed as a commercial product. It is also prescribed as a secure messaging technique in ISO/IEC-7816.[0039]
A first embodiment of the verification data generating apparatus and the data verification apparatus according to the present invention is described with an example where information such as the history data is read from the IC card and saved in a terminal device and then charge imposing information is transmitted to the history management center at an arbitrary timing.[0040]
First Embodiment[0041]
FIG. 2 shows a schematic configuration of a history management system using the IC card. A personal computer (PC)[0042]110 of a user is connected to a history management center130 through anetwork120 such as the Internet. The history management center130 performs the user registration and management of user data, histories of services offered to the users or the like. The history management center130 also provides encapsulated software (hereinafter, referred to as “capsule”)300 at the request of thePC110. Here, encapsulation means the encryption of the software with an encryption algorithm, for example, Data Encryption Standard (DES), such that the software cannot be used without decryption. It is possible to offer thecapsule300 to the users by a medium such as a CD-ROM.
A reader/writer[0043]140 is connected to thePC110 with an interface such as an RS-232C (a data communication interface prescribed by the Electronic Industries Association). The user connects anIC card200 to the reader/writer140 to obtain a decryption key for thecapsule300 or the using history provided by the history management center130.
The[0044]IC card200 is given to the user by a provider who offers the software or the history management center130 at the request of the provider. In this example, the user obtains the services through thePC110. However, a local terminal device for utilizing the services is not limited to a PC. For example, a workstation, a server, an Automatic Teller Machine (ATM) and so forth may also be used.
FIG. 3 shows a configuration of the encapsulated software. The content of the[0045]capsule300 consists of aheader310 and theencrypted software320. Theheader310 includes acapsule ID311 for identifying the capsule,charge imposing information312 used for calculating the charge for using and decryptionkey generation data313 for generating the decryption key for the software. Software created by a provider is encapsulated by the history management center or similar facilities.
FIG. 4 shows a hardware configuration of the IC card. The[0046]IC card200 is a computer system including aCPU210. Other elements are connected to theCPU210 through an internal system bus. A Random Access Memory (RAM)220 temporarily stores data to be processed by theCPU210. A Read Only Memory (ROM)230 stores a program that makes theCPU210 execute functions necessary to theIC card200. An input/output terminal device (I/O)240 performs data communication with the reader/writer140 in accordance with a predetermined standard. A Programmable Read Only Memory (PROM)250 stores secret information necessary for generating the decryption key from the decryptionkey generation data313 that has been encrypted, and so forth. ThePROM250 can be replaced with another storage device as long as the data can be overwritten and the data can be saved even when a power source is turned off (namely, nonvolatile memory).
FIG. 5 is a functional block diagram showing processing functions of the IC card.[0047]
A[0048]log generation unit201 receives the header from thePC110 and generates a log. If a value of alog counter204ais the same as that of a storable number oflogs201a,thelog generation unit201 returns an error status to thePC110 instead of generating the log. The storable number oflogs201ais a number of logs which can be stored in a log setstorage unit204. The number is predetermined corresponding to the capacity of thePROM250 of theIC card200.
A verification[0049]value storage unit202 stores a verification value to be used in verification of the continuity of the order of logs by theIC card200 and the history management center130. The verification method will be described later.
Whenever a new log is generated by the[0050]log generation unit201, anMD5 operation unit203 generates a new verification value. Specifically, at first, the log generated by thelog generation unit201 is combined with the verification value stored in the verificationvalue storage unit202. A message digest is then calculated based on the combined value using a one-way hash function “MD5” (see “The MD5 Message-Digest Algorithm, R. Rivest, Internet RFC 1321 (1992)) to generate the verification value. With the newly generated verification value, the verification value in the verificationvalue storage unit202 can be updated.
In this example, the verification value is generated by using the one-way hash function “MD5”. Here, “one-way” characteristic means that the value before calculation cannot be obtained from the calculation result by the inverse operation. “MD5” can be replaced with a function that has or is considered to have the above-mentioned one-way characteristic.[0051]
The log set[0052]storage unit204 stores a log set which is a set of plural logs and concatenates the logs generated by thelog generation unit201 to the log set one after another.
The[0053]log counter204acounts the number of logs stored in the log setstorage unit204. The value of the counter is reset to zero when the log set in the log setstorage unit204 is deleted.
When the log is generated by the[0054]log generation unit201, a decryptionkey generation unit205 generates the decryption key based on the secret information data in theIC card200 and the decryptionkey generation data313 in thecapsule300 and forwards it to thePC110.
On receiving a log set outputting request from the[0055]PC110, alog management unit206 outputs the log set stored in the log setstorage unit204 to thePC110. At this time, a value of a log setserial number counter206ais attached to the output log set. The log setserial number counter206astores the serial number of the log set. Every time the log set is deleted, the log setserial number counter206aincrements its value by one. Whether the deletion of the log set is possible is managed based on a log set outputtingstatus206b.When the log set outputtingstatus206bis “FALSE”, the log set cannot be deleted. When the log set outputtingstatus206bis “TRUE”, it is possible to delete the log set.
An[0056]operation controlling unit207 controls activating and suspending of the basic functions of theIC card200. More specifically, when the current time exceeds the range of a term ofuse207aor a value of a subtraction counter for the logs that can be generated207bis zero, the functions of theIC card200 are suspended. The suspended functions are activated again in accordance with an instruction of a use extensiondata authentication unit208. The term of the use of theIC card200 is set in the term ofuse207a.In the subtraction counter for the logs that can be generated207b,a limit of the number of times of use of the capsule before the forwarding of the log set to the history management center130 is set as an initial value. Every time the log is generated by thelog generation unit201, a decrement of the value of thesubtraction counter207bis performed by one.
The use extension[0057]data authentication unit208 receives the use extension data from thePC110 and authenticates it. If the authentication is succeeded, the use extensiondata authentication unit208 updates the values of the term ofuse207aand the subtraction counter for the logs that can be generated207bby utilizing the use extension data.
The encrypted software in the[0058]capsule300 is executed using the IC card having the above-described functions as follows.
The user connects the[0059]IC card200 to the reader/writer140 and makes thePC110 activate thecapsule300.
FIG. 6 is a flow chart showing capsule execution starting procedures. The processes shown in the left side of the dotted line are performed by the[0060]PC110 and those shown in the right side of the dotted line are performed by theIC card200.
S1: The[0061]PC110 transmits theheader310 in thecapsule300 to theIC card200.
S2: After the[0062]IC card200 receives theheader310, thelog generation unit201 generates a new log and transmits it to theMD5 operation unit203 and the log setstorage unit204.
S3: The[0063]MD5 operation unit203 generates a new verification value based on the received log and the verification value previously stored in the verificationvalue storage unit202 and updates the previous verification value in the verificationvalue storage unit202.
S4: The log set[0064]storage unit204 concatenates a new log with the log set stored therein. At this time, if the log set outputtingstatus206bis “TRUE”, thelog management unit206 changes it into “FALSE”.
S5: An increment of the value of the[0065]log counter204ais performed by one. A decrement of the value of the subtraction counter for the logs that can be generated207bis performed by one.
S6: The decryption[0066]key generation unit205 generates the decryption key by utilizing the decryptionkey generation data313 and secret information data and forwards it to thePC110.
S7: On receiving the decryption key, the[0067]PC110 decrypts the encrypted software with the decryption key to execute the software.
Thus, whenever the user executes the software in the capsule, the using history is saved as a log in the[0068]IC card200.
FIG. 7 shows a configuration of the log. The[0069]log400 includes acapsule ID401, alog generation time402 andcharge imposing information403. Since thelog400 is temporarily stored in theIC card200, the small number of bytes constituting each element is preferable. Here, it is assumed that the system time is represented by four bytes corresponding to the Coordinated Universal Time (UTC). It is unnecessary to include all UTC four bytes in the log generation time. For example, if a detailed value is not required, it may be sufficient to include the upper three bytes in the log generation time. If only a relative value is required, the lower three bytes may be included.
Then a method of collecting and verifying the log set saved in the[0070]IC card200 by the history management center130 is described as follows. The plural logs in the log setstorage unit204 are concatenated in order of generation and stored as a log set in the nonvolatile memory (PROM250) in theIC card200. However, it is impossible to store a large amount of log data in theIC card200 because the memory capacity of theIC card200 is not very large. Therefore, the storable number oflogs201ais set in theIC card200 in advance. When the value of thelog counter204areaches the value of the storable number of thelogs201a,thelog generation unit201 cannot generate a new log and the decryptionkey generation unit205 does not output a decryption key. Accordingly, it is impossible to execute the software.
In this condition, the user operates the[0071]PC110 so that thePC110 makes a log set outputting request to theIC card200. On receiving the log set outputting request, theIC card200 attaches its signature to a log set and outputs the log set with the signature. The output of the log is also available before the value of thelog counter204areaches the storable number oflogs201a.
FIG. 8 shows a configuration of a log set with a signature. The log set with a[0072]signature500 includes a user ID501, a log setgeneration time502, a log set serial number503, asignature value504, a number oflogs511 and logs (to the number of n)512.
FIG. 9 shows a configuration of a plain text attached as a[0073]signature value504 to the log set. The case of encryption of aplain text700 with a signature key (secret key) of theIC card200 is now explained. The encryption method is not limited to a public-key cryptosystem. If the secret key can be securely shared by the history management center130 and theIC card200, a symmetric cryptosystem may be used.
The[0074]plain text700 to be signed includes a user ID701, a log setgeneration time702, a log setserial number703, a number oflogs704 and averification value705. Theverification value705 is the same as that stored in the verificationvalue storage unit202 of theIC card200 when the log set500 is output. Theplain text700 including these pieces of information is encrypted by the secret key of theIC card200 to obtain thesignature value504.
FIG. 10 is a flow chart showing procedures of outputting the log set from the IC card. The processes shown in the left side of the dotted line are performed by the[0075]PC110 and those shown in the right side of the line are performed by the IC card.
S11: The[0076]PC110 makes a log set outputting request to theIC card200.
S12: In the[0077]IC card200, thelog management unit206 receives the log set outputting request and changes the log set outputtingstatus206binto “TRUE”. Then the log set with asignature500 as shown in FIG. 8 is output.
S13: The[0078]PC110 obtains the log set from theIC card200.
S14: The[0079]PC110 determines whether the log set is normally obtained. If thePC110 normally obtained the log set, the process proceeds to the step S15. Otherwise, the process returns to the step S11 where thePC110 makes the log set outputting request to theIC card200, and the processes of the steps S11 through S15 are repeated.
S15: The[0080]PC110 makes a log set deletion request to theIC card200
S16: In the[0081]IC card200, the log setmanagement unit206 receives the log set deletion request and determines whether the log set outputtingstatus206bis “TRUE”. If it is “TRUE”, the process proceeds to the step S17. Otherwise, the process proceeds to the step S21.
S17: The[0082]log management unit206 deletes the log set in the log setstorage unit204.
S18: The[0083]log counter204aresets its value to zero.
S19: The log set[0084]serial number counter206aperforms an increment of the log set serial number held therein by one.
S20: The[0085]log management unit206 returns a status indicating normal end to thePC110 and then the process is completed.
S21: If the log set outputting[0086]status206bis “FALSE”, thelog management unit206 does not delete the log set and returns an error status to thePC110.
If the[0087]IC card200 is in a reset condition, the log set outputtingstatus206bbecomes “FALSE” considering the case where an error is generated during the output of the log set.
In the log set output procedures, the output of the log set and the deletion of the log set are performed according to the respective instructions as described above. The reason of the separate instructions is related to the protocol format of the[0088]IC card200 described as follows. With the data transmission protocol T=0 and/or T=1 (ISO/IEC 7816-3) of theIC card200, theIC card200 outputs the data to an interface device (here, indicating the PC110) and then changes its status to a reception waiting status. Therefore, it is impossible to execute the processes in theIC card200. If the output and deletion of the log set is to be performed in accordance with a single command, a log set must be output after another log set is deleted. In the case where the output of the log set is failed during the communication, the log set is lost.
To the contrary, suppose that two commands, the log set output command and the log set deletion command, are merely prepared. If the user issues the log set deletion command to the IC card before the output of the log set by mistake, the log set is lost. Therefore, in the present invention, the IC card has the log set outputting[0089]status206b.Only when the log set203 is output, the log set outputtingstatus206bbecomes “TRUE” and the log set can be deleted. If the software is activated after the output of the log set, a new log is generated in theIC card200 and the log set outputtingstatus206bbecomes “FALSE”. Accordingly, the log set cannot be deleted until the log set is output.
The log set[0090]500 output from theIC card200 is temporarily stored in thePC110. The history management center130 collects the log set500 stored in thePC110 at predetermined intervals. Based on the content of the collected logs, the history management center130 collects the charges from the users to distribute the charges to the author of the software. For efficiently collecting the histories (logs), the term ofuse207aand a number of logs that can be generated are set in theIC card200 in advance. The term ofuse207arepresents the date when the validity of the card expires. After the term ofuse207a,the use of theIC card200 is suspended and thecapsule300 cannot be utilized. To use theIC card200 and thecapsule300 again, it is necessary to transmit the log set output so far to the history management center130 and obtain the use extension data. The number of logs that can be generated, namely, the number of times capable of using thecapsule300 before transmitting the log set to the history management center130 is set as an initial value of the subtraction counter for the logs that can be generated207b. When the value of thecounter207bbecomes zero, the status of theIC card200 is changed to the suspended status. Therefore thecapsule300 cannot be used. To use theIC card200 and thecapsule300 again, the log set must be forwarded to the history management center130 to obtain the use extension data.
For verification of the log set forwarded by each user is performed in the history management center, the center is required to have the user database as described below.[0091]
FIG. 11 shows an example of a user database managed by the history management center. The[0092]user database900 storeshistory management data910 for each user. Thehistory management data910 includes auser ID911, a last serial number912 of a log set in the last verification, averification value913 of the log set corresponding to the serial number912 and user-unique data914 used for authentication or the like.
When the capsule becomes unavailable because the term of use expires, or in an earlier arbitrary timing, the user forwards all of the log sets output from the[0093]IC card200 to the history management center130. It is preferred that the user transmits the log sets output from theIC card200 in order of the log set serial numbers. This is unnecessary if the history management center130 can sort the log set serial numbers. However, the complete output log sets without lacking are required.
FIG. 12 is a flow chart showing procedures of verification of the log sets in the history management center. All processes are executed by a computer of the history management center[0094]130.
S31: The log sets are received.[0095]
S32: The received log sets are sorted in order of the serial numbers. In addition, corresponding[0096]history management data910 is obtained from theuser database900 based on the user ID. It is confirmed that the minimum value of the serial numbers of the log sets received this time succeeds to the log set serial number912 of the user verified immediately before. Then the continuity of the serial numbers of the log sets received this time is confirmed. If no log set is missed, the process proceeds to the step S33. Otherwise, the process proceeds to the step S35.
S33: The continuity of the logs is verified by using the[0097]verification value705 stored in the signature of the log set. If the verification is correctly performed, the process proceeds to the step S34. Otherwise, the process proceeds to the step S35. The details of the verification procedures are described later.
S34: The use extension data is issued and forwarded to the[0098]PC110.
S35: An error status is returned to the[0099]PC110.
In this way, the user can obtain the use extension data.[0100]
FIG. 13 shows procedures of verifying of the verification value. The following processes are executed by the computer of the history management center[0101]130.
S331: The log set is verified. For the verification, plural logs[0102]512athrough512nand thesignature value504 in the log set500 are used. If plural log sets exist, the verification is performed in order of the serial numbers.
At first, the legitimacy of the log set is verified. Specifically, the[0103]signature value504 in the log set500 is verified with the public key of theIC card200 corresponding to the user ID501. Thus the conformity between the user ID501 in the log set500 and theuser ID201 in theplain text700 of the signature value is confirmed.
Then the first log[0104]512ais concatenated with the precedingverification value913 and a new verification value is generated in the same say as theIC card200 generates the verification value. That is, a message digest is calculated for the concatenated value using the one-way hash function MD5 to generate the new verification value913a.
Next the log[0105]512bis concatenated with the verification value913ato generate a new verification value913b.The same operation is performed on thelogs512cthrough512n.As a result, a verification value913nthat is a message digest for the concatenated value of the log512nand theverification value 913 m is generated.
S332: The verification values[0106]705 and913nare compared. If the values are consistent with each other, the process proceeds to the step S333. Otherwise, the process proceeds to the step S334.
S333: If the next log set exists, the verification value is verified in the same way as the above procedures. If the next log set does not exist, that is, the verification of all log sets received by the user is completed, the last serial number[0107]912 of the preceding verification in the history management data of the user managed by the history management center is updated with the serial number of the last log set verified this time. In addition, thelast verification value913 of the preceding verification is updated with the verification value of the last log set verified this time.
S334: An error status is returned to the user and the process is completed.[0108]
In this way, the history management center[0109]130 verifies the log set and issues the use extension data.
FIG. 14 shows an example of a configuration of the use extension data. Specifically, the figure shows a plain text[0110]800 of the use extension data before the signature is attached. The plain text800 includes a number of logs that can be generated801, aneffective term802 and averification value803. Here, theverification value803 is the verification value of the log set verified at last. The history management center130 attaches a signature to the plain text800 by using the secret key and forwards it as the use extension data to the user.
The user inputs the received use extension data to the[0111]IC card200. In theIC card200, the use extensiondata authentication unit208 verifies the signature of the use extension data with the public key registered in advance at the history management center130. If theverification value803 in the use extension data and the verification value in the verificationvalue storage unit202 are consistent with each other, the term ofuse207aof theIC card200 is updated with theeffective term802 in the use extension data. In addition, the value of the subtraction counter for the logs that can be generated207bis updated with the number of logs that can be generated801 described in the use extension data. If theIC card200 is in the suspended status, theoperation controlling unit207 cancels the suspended status.
In the above description, the case where the log set can be collected is taken as the example. However, though a part of the log set is destroyed from an accident, the verification of the log set except the destroyed part is possible according to the present invention because the log sets are managed based on the log serial numbers and signature of the IC card is attached to each log set.[0112]
Second Embodiment[0113]
In a second embodiment, the[0114]capsule300 can be used during the period from the output of the log set to the reception of the use extension data. In the first embodiment, if thecapsule300 is executed between the transmission of the log set500 to the history management center130 and the reception of the use extension data, a new log is generated in theIC card200 and the verification value is updated. Therefore, the use extension data cannot be verified. To prevent this problem, it is considered that the use of the capsule is prohibited during the period from the transmission of the log set from the user to the history management center130 to the reception of the use extension data. However, even though the network is utilized, thecapsule300 is unavailable for some time. This causes inconvenience to the user. Accordingly, the second embodiment allows thecapsule300 to be used if the log can be stored in the IC card even after the user forwards the log set to the history management center130.
The second embodiment is the same as the first embodiment except the processing function of the use extension[0115]data authentication unit208. Therefore, the second embodiment is described utilizing the reference numbers assigned to the elements of the first embodiment.
FIG. 15 shows the process of authentication of the use extension data in the second embodiment. Suppose a case where the user forwards the log sets output so far to the history management center[0116]130 and after that the user utilizes the capsule for the n times. As shown in the figure, logs to the number ofn204athrough204nare stored in the log setstorage unit204. With this condition, the user receives the use extension data800 from the history management center130 and inputs it to theIC card200. Then the following processes are executed.
S41: In the[0117]IC card200, the use extensiondata authentication unit208 verifies the signature of the use extension data with the public key of the history management center130 to obtain averification value803 in the use extension data. Thefirst log204ain the log setstorage unit204 is then concatenated with theverification value803 in the use extension data and a verification value803ais generated in the same way as theMD5 operation unit203 generates the verification value. Similarly, the new verification values are generated based on thelogs204bthough204nin order and the generated verification values803athrough803mand finally a verification value803nis generated.
S42: The use extension[0118]data authentication unit208 compares the verification value202ain the verificationvalue storage unit202 with the verification value803n.If the values are consistent with each other, the process proceeds to the step S43. Otherwise, the process proceeds to the step S44.
S43: The use extension[0119]data authentication unit208 updates the term ofuse207aof theIC card200 with theeffective term802 in the use extension data. In addition, the value of the subtraction counter for the logs that can be generated207bis updated with the value obtained by subtracting the value of thelog counter204a(=n) from the number of logs that can be generated801 in the use extension data. If theIC card200 is in the suspended status, theoperation controlling unit207 cancels the suspended status.
S44: If the verification values[0120]202aand803nare not consistent with each other, the use extensiondata authentication unit208 interrupts the process and returns an error status.
In this embodiment, the verification value in the use extension data is verified in the IC card by the verifying of the verification value stored in the log set. However, the verification method is not limited thereto. It may be considered that the verification value of the log set output last time is stored as a second verification value separate from the verification value stored in the verification[0121]value storage unit202 and the verification value in the use extension data is compared with the second verification data to be verified.
The functions of the IC card are realized by the CPU therein by executing a program stored in the ROM. The program can be stored in a storage medium readable by other computers. As such a storage medium, a magnetic storage device, a semiconductor memory or the like may be used. For the distribution in the market, the program can be stored in the portable storage medium such as a CD-ROM or a floppy diskette, or stored in the storage medium of the computer connected to the network and transferred to other computers. For executing the program by the computer, the program is stored in the hard disk device or the like in the computer and then loaded into the main memory.[0122]