JP2005260676A - Security system, information processing system, control method of security system, control method of information processing system, program capable of implementation in system for performing control method and ticket system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a security system, an information processing system, a control method of the security system, a control method of the information processing system, a program capable of implementation in system for performing the control method, and a ticket system. <P>SOLUTION: The security system 12 includes: a non-volatile type storing unit 22 for storing correctness inspection unit including a counter, which is renewed every time a signature function means 30 is called; a non-volatile type storing unit 24 for reading a counter array from an outer non-volatile storing unit for storing the counter array, in which a hash value generated for each signature key and a number-of-signature counter for counting the number of signature formed with the signature key are arranged in pairs, and storing the counter array; and a hash function unit 28 for reading the counter array from the non-volatile storing unit 24, generating a hash value, and feeding the hash value to the correctness inspection unit for correctness checking. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

  The present invention relates to prevention of unauthorized use of a digital ticket, and more particularly, a security device and information processing for managing security of a digital ticket by preventing unauthorized use of a digital ticket with a limited number of times. The present invention relates to a device, a security device control method, an information processing device control method, a device-executable program for executing the control method, and a ticket system.

  In recent years, with the widespread use of type information processing devices such as personal computers, PDAs, and cellular phones, a technology for providing services using so-called digital tickets (hereinafter simply referred to as tickets in the present invention) has become widespread. Conceivable. Since tickets are electronic data, unauthorized duplication is possible, and the act of making multiple accesses using illegally duplicated tickets (hereinafter referred to as multiple use) may be prevented. It is assumed that it will be required more and more.

  Although such fraud must be eliminated, the ticket in the present invention is electronic data, and it is difficult to prevent a plurality of duplicated tickets from being used only by the software unit.

  Therefore, in order to eliminate the above-described fraud, it is necessary to depend on hardware to some extent. However, in a security device implemented in hardware, hardware resources that can be allocated for this purpose are limited. For this reason, it is assumed that conventionally used security devices need to store data for preventing fraud in an area other than the security device. At this time, a complicated encryption process can be executed with the external area, but there is a disadvantage in that a response delay occurs in a transaction and the efficiency of using an electronic ticket is impaired. On the other hand, storing data for preventing fraud in the external area has the disadvantage that the reliability of the security device itself is lost due to unauthorized access to data for preventing fraud. It was.

  Up to now, a method of storing an encryption key in an encrypted form outside the security device is known, but in terms of limiting the number of signatures, that is, limiting the use of multiple signatures, sufficient measures have been taken. I can't say. In this case, it may be possible to add a counter to the key Blob. However, since it is also necessary to guarantee the reliability of the counter at the same time, by simply adopting a data format in which the counter is added, it is possible to eliminate unauthorized multiple use. The point is not enough.

In addition, a technique for erasing a token representing a ticket from hardware after use has been proposed (Non-Patent Document 1). Again, it is necessary to verify that the token is trustworthy. For this reason, the key from the authentication site is kept in the hardware. However, in order to guarantee that this key is stored securely, in addition to adding complexity, a new reliability is added. It will also add threats.
Terada et al., “General-purpose original guarantee method for electronic rights distribution infrastructure”, Journal of Information Processing Society of Japan, Vol. 42, No. 8, August 2001, pp. 2017-2029.

  That is, until now, it has been necessary to give highly reliable identification to the data such as digital tickets that need to be prevented from unauthorized use. In addition, in order to prevent unauthorized use of data such as tickets with high reliability, it is necessary to cope with the addition of a minimum amount of hardware resources.

  In the present invention, if a security device that counts the number of times of signing with high reliability can be realized by applying a digital signature technology to data that needs to be prevented from unauthorized use, the minimum hardware resources can be realized. This is based on the idea that unauthorized use of data can be prevented effectively and with high reliability under the use of. In the present invention, it is calculated from a counter (master counter: MC) that is updated every time signature processing is executed in the security device, a counter array stored outside, and the above-described MC value. And a validity check unit including a counter array register (CIR) for storing a hash value.

  The validity checking unit concatenates the counter array (CA) value read from the external nonvolatile storage unit and the latest MC value to generate a hash value of the concatenated value. This hash value is compared with the value stored in the CIR, and if it does not match, it indicates that the CA has been changed regardless of the signature processing. For this reason, if the hash value and the CIR value do not match, the security device does not issue a command for calling the signature function means, and the processing via the digital signature is stopped inside the security device, and the unauthorized use Can be prevented.

  In addition, since the CA value can be read from the external nonvolatile storage means, it is possible to correspond to a plurality of signature keys without worrying about memory resources of the security device.

That is, according to the present invention, a security device for restricting multiple use of signed data, the device comprising:
A non-volatile storage unit that stores a validity checking unit including a counter that is updated each time the signature function unit is called;
A counter array is stored from an external non-volatile storage unit that stores a counter array in which a hash value generated for each signature key and a signature number counter for counting the number of times the signature key is signed are paired. A volatile storage for reading and storing; and
There is provided a security device including a hash function unit that reads a counter array from the volatile storage unit, generates a hash value, and passes the counter value to a validity checking unit for validity checking.

  The validity checking unit may further include key means for assuring the validity of the security device, and the immediately preceding hash value generated from the counter array in the past. The hash function unit further reads the value of the counter and calculates a hash value of a concatenated value with the counter array. The security device according to the present invention includes a unit that compares the generated hash value with the immediately preceding hash value. Further, the security device executes a digital signature in response to a validity determination by the validity checking unit, updates a signature number counter, and stores the updated signature number counter value in the external nonvolatile storage unit. Write is executed.

According to the present invention, there is provided an information processing apparatus including a function for restricting the use of signed data, wherein the information processing apparatus includes:
A security device as described above;
An interface unit including a non-volatile storage unit that stores a counter array in which a hash value generated for each signature key and a signature number counter for counting the number of times the signature key is signed are paired An information processing apparatus is provided.

Further, according to the present invention, there is provided a control method for controlling a security device for restricting multiple use of signed data, the control method comprising:
A counter array is stored from an external non-volatile storage unit that stores a counter array in which a hash value generated for each signature key and a signature number counter for counting the number of times the signature key is signed are paired. Reading and storing in the volatile storage;
The stored counter array is read to generate a hash value, and includes a key means for guaranteeing the validity of the security device for the validity check and a previous hash value generated from the counter array in the past. Passing to the validity checking unit; calling the signature function means in response to the determination of validity in the validity checking unit;
There is provided a security device control method for causing a security device to execute a step of updating a counter each time a signature function means is called.

  In the present invention, a step of storing the immediately preceding hash value generated in the past from the counter array can be executed. In the present invention, the hash function unit may further read the counter value and calculate a hash value of a concatenated value with the counter array. In the present invention, a step of comparing the generated hash value with the immediately preceding hash value is further executed.

Furthermore, in the present invention, a step of executing a digital signature in response to a determination of validity by the validity checking unit;
Corresponding to the execution of the digital signature, the signature number counter is updated, and the step of writing the updated value of the signature number counter into the external nonvolatile storage unit can be executed.

Further, in the present invention, there is provided a control method for controlling an information processing apparatus including a function for restricting multiple use of signed data, the control method comprising:
Executing the processing steps described above;
A counter array from an interface unit including a storage unit that stores a counter array in which a hash value generated for each signature key and a signature number counter for counting the number of times the signature key is signed are paired A method for controlling the information processing apparatus is provided.

  In the present invention, an apparatus executable program for executing the above control method is provided.

Furthermore, according to the present invention, a ticket system using a digital ticket, the ticket system comprising:
A ticket issuer terminal that issues a ticket;
Storing the issued ticket, and the information processing apparatus described above;
A network interconnecting the ticket issuer terminal and the information processing device;
And a service terminal that issues a ticket use request to the information processing apparatus. The information processing apparatus can acquire and store the ticket from another information processing apparatus and access the service terminal.

1. Hardware Configuration FIG. 1 is a diagram showing a schematic configuration of an information processing system including a security device of the present invention. The information processing system 10 illustrated in FIG. 1 includes a security device 12, an external device 14, and an interface unit 16 for providing various processes based on determinations in the security device 12. According to the present invention, the security device 12 uses the digital signature and the signature count counter of the digital signature to control access to the external device 14 such as a storage device or a computer device via the interface unit 16. . In addition, the interface unit 16 includes an external nonvolatile storage unit 20 composed of a nonvolatile memory provided outside the security device 12. The external non-volatile storage unit 20 stores a counter array (CA), which will be described later in more detail. In addition, the information processing system 10 of the present invention can control access to application software for providing a requested task.

  Furthermore, as shown in FIG. 1, the security device 12 generally includes a nonvolatile storage unit 22 and a volatile storage unit 24. The nonvolatile storage unit 22 is an area for storing data unique to the security device 12. These storage units can be configured using a RAM, a flash memory, or the like. The volatile storage unit 24 is an area for storing transient data of the security device 12. Furthermore, two types of cryptographic algorithms are implemented in the security device 12, and one of them is a one-way hash algorithm such as SHA-1. The other is a signature algorithm such as RSA. Among these, a hash algorithm such as SHA-1 realizes a hash function, and a signature algorithm such as RSA realizes a signature function unit.

  FIG. 2 is a diagram showing a more detailed functional configuration of the security device 12 of the present invention. As shown in FIG. 2, the security device 12 of the present invention is implemented including a nonvolatile storage unit 22, a volatile storage unit 24, a control unit 26, a hash function unit 28, and a signature function unit 30. ing. The signature function means 30 generates data such as a private key and a public key used for signing, and executes the signature using these data. The signature function means 30 can be configured to include a counter unit for counting the number of calls in response to a normal call of a digital signature function to be described later. In another embodiment of the present invention, the counter unit can be configured in any area of the security device 12 instead of the signature function unit 30. In the embodiment shown in FIG. 2, the instruction interface unit (I / O) 32 is configured as one module of the security device 12, and performs mutual communication with the interface unit 16 connected to the outside. Yes. These functional units are interconnected by an internal bus, and transmit / receive data or commands to / from each other. In accordance with the present invention, the control unit 26 controls each storage unit and each functional unit so as to prevent unauthorized use.

  The non-volatile storage section 22 generally includes a master key (MK) storage section 34, a master counter value (MC) storage section 36, and a counter integrity register (CIR) area 38 for external access. Is highly protected against. The master key storage unit 34 stores an MK for storing the signature key externally. The MK stored in the master key storage unit 34 can be, for example, a 128-bit AES key, and is used to encrypt the key Blob. Typically, this MK is registered at the time of manufacture and is not changed during the lifetime of the security device of the present invention. The MC storage unit 36 stores a master counter (MC). The MC value is counted up in response to a signal from the counter unit that is output in response to the signature function means being properly called. For this reason, when a predetermined signature function is called and executed, the MC value in the MC storage unit 36 is always set to a different value.

  Further, the MC value is configured to monotonously increase in response to the execution of any processing of the signature function means executed by the security device 12. Thus, the MC value provides a good monitor for calling the signature function means of the security device 12. In the present invention, the signature function means can include a key generation instruction (genkey), a key deletion instruction (delkey), and a signature instruction (sign) which are programs written in microcode, but is not limited thereto. Is not to be done. The size of the MC storage unit 36 can be set to such a size that the counter does not overflow during the lifetime of the security device 12, and specifically, for example, even when a state change instruction is executed once per second. If it is 32 bits, 100 years can be fully supported.

  Also, the MC value is initially set to 0 in the manufacturing process, and is incremented when the signature function means is called and the state of the security device is changed. The counter integrity register (CIR) area 38 is a functional unit that provides a function for guaranteeing the validity of the counter. The CIR area 38 has a value of CIR = Hash (MC + CA) (hereinafter, referred to as a value). Simply referred to as the CIR value). In the above formula, “+” means “concatenation” of character strings.

  The volatile storage unit 24 temporarily stores data of the CA 40 because the security device 12 executes the processing of the counter array (CA) 40. The CA 40 includes data of a pair of a hash value of a key Blob and a signature number counter as many as the number of signature keys, and is the data that consumes the most memory resources in terms of hardware. Therefore, in the present invention, a signature key list is configured in an external non-volatile storage unit (not shown) provided outside the security device 12. Therefore, the security device 12 can cope with unauthorized use without worrying about restrictions on memory resources with respect to the number of signature number counters.

  FIG. 3 is a diagram showing a schematic configuration of a signature key entry stored in the CA 40 in the present invention. As shown in FIG. 3, the signature key entry 42 is configured to include 0 to n−1 n pieces. The entered pair includes a hash value 44 of the key Blob for each signature key and a signature count counter 46 for the corresponding key. The signature number counter 46 is incremented each time a signature key is newly registered, the corresponding signature number counter is set to zero, and a signature is executed with the corresponding signature key.

  At the same time, the CA 40 can also include usage information for indicating whether a key identification value, for example, Key0 is in use or not used. In the specific embodiment of the present invention, this usage information is not in use by providing an additional bit area and not setting the use flag in this additional bit area if it is not in use. Can be shown. In another embodiment of the present invention, a specific counter value such as a value (−1) can be set to indicate the non-use of a signature key, or a specific key Blob such as 0 × 0. Can also be used. In this way, by identifying a signature key that is not in use, it is possible to prevent the unused signature key from being deleted by a key deletion function to be described later.

The hash value of the key Blob establishes a cryptographic reference between the signature key and its signature count counter and prevents the use of the already deleted key Blob of the same key identification value. This key blob hash value can be shorter than the value of a normal one-way hash function such as 160-bit SHA-1 in response to policy data. More specifically, a maximum of 2 ³² key blobs can be assumed for the entire lifetime of a given security device (since the master counter is 32 bits long), any pair of 2 ³² key blobs are their The probability of having the exact same lower 64 bits of the hash value is significantly less. For this reason, in the present invention, if the number of bits that is twice the number of bits of the MC value (that is, 32 × 2 = 64) is obtained from the hash value of the key Blob, it is considered that the hash value is generally sufficient to prevent an attack. However, it can be longer or shorter than the hardware resources allow.

2. CA Update and Security Mechanism CA40 update and security mechanism is essentially a signature function means of key generation (genkey), signature (sign), and key deletion (delkey) configured as microcode. Realized by the event that a legitimate call was executed. FIG. 4 is a flowchart showing processing executed by genkey for generating a key. The genkey process shown in FIG. 4 starts from step S10, and the interface unit instructs the security device to generate a key. In step S12, the interface unit reads the entire CA entry from the non-volatile storage unit and passes it to the volatile storage unit of the security device. In step S14, the security device calculates a hash value from the MC value and the CA value, and simultaneously reads the CIR value. In step S16, the calculated hash value is compared with the CIR value.

  As a result of the comparison, if the hash value = CIR value, since the CA received by the security device is valid, the process proceeds to step S18, where the signature function means generates a signature key <Ks, Kv> and encrypts it with MK. Return to the interface. Here, Ks is a private key, and Kv is a public key. In step S18, the signature key generated for the interface unit is written in an unused entry, which is entry # 4 in the embodiment shown in FIG. In this case, the signature count counter to be paired is set to 0. On the other hand, in step S20, the security device updates the MC value, simultaneously generates a new hash value using the new CA value, updates the CIR value as new hash value = CIR value, In S22, the genkey process is terminated. Further, if the result of the comparison in step S16 is not the CIR in which the hash value is stored, it indicates that the CA has been changed, so the process proceeds to step S24 and stops.

  FIG. 5 is a flowchart showing the processing executed by the sign for signing in the present invention. In step S30, the security device first receives a signature command for the message m from the interface unit. In step S32, the CA holds the i-th (specifically, for example, fourth) key Blob for signing. To the security device. In step S34, a hash value is calculated from the MC value and the CA value, and the CIR value stored in the security device is read. In step S36, the calculated hash value is compared with the CIR value. If hash value = CIR value, the process proceeds to step S38, where the hash value of the passed key Blob is calculated, and the CA key Blob is calculated. If they are the same, it is determined that the CA and the key correspond to each other. In step S40, the security device uses the key in the corresponding key Blob to use the message m and the key in the CA. The signature is applied to the concatenation of the signature count counter values. In step S42, when the interface unit receives the signature, the interface unit increments the signature number counter. In step S42, the security device updates the MC value and the CIR value, and at the same time, the security device issues a command for incrementing the signature number counter of the corresponding key Blob to the interface unit. On the other hand, if either of them does not match in the comparison of step S36 and step S38, the process proceeds to step S44 and the process is stopped. The sign process shown in FIG. 5 allows the signature number counter to be safely incremented while maintaining the correspondence between the key Blob and the usage counter.

  FIG. 6 is a flowchart showing delkey processing for deleting an entry. In the delkey process, in step S50, the security device receives a key deletion request from the interface unit, and simultaneously receives the CA stored in the nonvolatile storage unit from the interface unit. In step S52, the security device determines the validity of the CA using the process described above. If it is determined in step S52 that the CA is valid (yes), the process proceeds to step S54, where the corresponding CA portion is initialized and stored in the volatile storage unit. In step S56, the security device calculates MC and CIR, stores them in the nonvolatile storage unit, and updates them. Further, the security device initializes the corresponding CA entry for the interface unit, and stores the updated CA in the external nonvolatile storage unit of the interface unit. If it is determined in step S52 that there is no validity (no), the delkey process branches the process to step S58 and stops the process.

FIG. 7 shows the input and output of microcode and the processing for executing the above-described genkey, delkey, and sign processing. In any process, first, the validity of the CA value given as a parameter is determined using the CIR, and each process is executed. For this reason, when CA is changed illegally, each process is not performed and the safety | security with respect to unauthorized use can be improved. In addition, the CA has a plain interface
Since it is stored in the text format, it can be referred to without executing encryption / decryption processing, so that the processing speed can be improved.

  Furthermore, even if an unauthorized access is made to an externally registered CA to obtain it and try to execute a signature, the MC value of the security module is different, so the CIR value does not match, and unauthorized use is prevented. Can do. Furthermore, even for unauthorized access such as deleting the key and initializing the usage counter, the key before the deletion and the hash value of the key Blob are different in the CA, so the subsequent processing cannot be executed and unauthorized use is performed. Can be prevented. Even if the interface unit itself attempts to sign, the key Blob is encrypted by the MK and cannot be decrypted by the interface unit itself, and signatures by other than the security device can be highly prevented. Further, since the security device does not encrypt the CA and send it to the interface unit, the load on the instruction interface can be reduced. On the other hand, since the interface unit stores the CA as it is, the value of the signature number counter is referred to at high speed without performing the decryption process.

3. Implementation of security device (embodiment)
FIG. 8 shows an embodiment of a ticket system in which the security device of the present invention is installed. The ticket system 50 of the present invention includes a ticket issuer terminal 54 via a network 52, a user terminal 56 including the security device of the present invention, and a service terminal 58 capable of mutual data communication with the user terminal 56. It is out. As a ticket issuer, in a specific embodiment of the present invention, for example, an event provider having a ticket issue right for various events, a service provider providing a paid information service, a ticket for a vehicle, aircraft, train, etc. It may be anything that is expected to issue a predetermined ticket to receive a specific service, such as a passenger service provider with rights. In FIG. 8, the service terminal 58 is described as being connected to the network 52. However, in the present invention, since it is not necessary to receive information such as a manufacturer key from a certificate authority or the like, the service terminal 58 does not necessarily have to be connected to the network 52.

  Further, each of the terminals 54 and 56 may be any information processing apparatus known so far, and specific examples include a personal computer, a workstation, a cellular phone, and a PDA. Further, the user terminal 56 may include, for example, an infrared communication function and a barcode display function, and may be able to access the service terminal. In addition, the ticket issuer is provided with a digital signature function for proving that it is a ticket issuer.

  When providing and using the ticket in the ticket system shown in FIG. 8 is outlined, first, the ticket issuer terminal 54 transmits a predetermined ticket t to the user terminal 56. This ticket t includes the contents data of the ticket t of the service to be received. The user terminal 56 receives this ticket t and stores it in an appropriate storage area. The user terminal 56 includes the security device of the present invention, and allows access to the service terminal 58 via the interface unit. On the other hand, the service terminal 58 receives the signature number counter included in the CA held by the user terminal 56 from the user terminal 56 together with the message, and issues an access permission with reference to the maximum signature number Cmax. It can be adapted to a certain ticket.

  FIG. 9 is a schematic diagram showing a functional configuration of the user terminal 56 in the ticket system 50 of the present invention. As shown in FIG. 9, the user terminal 56 includes a communication device 60, a security device 62 of the present invention, a central processing unit (CPU) 64 for executing various processes, and a memory for storing various data. 66 and an I / O interface unit 68. The user terminal 56 receives a message specifying the service content from the ticket issuer terminal 54 via the communication device 60. This content is stored in the memory 66 and is sent to the I / O interface unit 68 when the service is to be received, so that the service terminal 58 can process it. The I / O interface unit 68 may be a wireless or infrared communication device, or may be a unit for displaying a barcode or the like.

  The security device 62 stores a private key master signature key MK used for signing, and proves that the generated key is generated in the security device 62 when receiving a service. Used for signing. The security device 62 can be configured as a chip in the described embodiment of the invention. The CPU 64 reads and executes a program for realizing the interface unit used in the present invention from an appropriate storage area, and realizes the I / O interface unit 68 in the user terminal 56. Further, the I / O interface unit 68 may include an I / O interface function that enables mutual communication with an external device and an I / interface function including a function for displaying a request message as a barcode.

  FIG. 10 shows a schematic configuration of the service terminal 58 used in the ticket system 50 of the present invention. The service terminal 58 includes a CPU 70, an I / O interface 72, a memory 74, a message analysis unit 76, a signature count determination unit 78, an access command unit 80, and a communication device 82. The maximum use count Cmax may be transmitted from the ticket issuer terminal 54 to the service terminal 58, but the service terminal 58 may receive the maximum signature count Cmax from the user terminal 56 and store it in the memory 74. . When the communication device 82 acquires the request message via the network, the service terminal 58 analyzes the request message in the message analysis unit 76, specifies the requested service, and simultaneously transmits the request message from the user terminal 56 together with the request message. The used counter value C is acquired and stored in the memory 74. Thereafter, the signature count determination unit 78 reads the value C of the signature count counter from the memory 74, and further refers to the maximum signature count Cmax for the specified service to determine whether the value C of the signature count counter satisfies C ≦ Cmax. Judge whether or not.

  In another embodiment of the present invention, when the request message is converted into a bar code and displayed, the bar code reader of the service terminal 58 reads the bar code, and the I / O interface 72 reads the request message. And request message analysis can be executed.

  On the other hand, when the service terminal 58 determines the validity of the user from the request message, the service terminal 58 determines whether C ≦ Cmax. When C ≦ Cmax, since the access request does not exceed the maximum number of signatures, the signature number determination unit 78 notifies the access command unit 80, and the service terminal is connected via the I / O interface 72. Access to the gate device 84 or application 86 to be managed is made possible.

  FIG. 11 collectively shows processing and parameters used by the security device 62 included in the user terminal 56 used in the ticket system of the present invention. The key generation (genkey) is a process of generating a set of private key Ks and public key Kv and signing the public key Kv with the master signature key MK. At this time, the use counter C = 0 is set at the same time. At this time, the CA can be stored in the memory 66 or the like by the interface unit of the user terminal 56 other than the security device 62. The signature corresponds to the process sign. When the user terminal 56 issues a message transmission request specifying the service, the corresponding message and the value of the signature count counter are combined, and the signature is signed by the private key Ks. Then, the signature number counter C is incremented by one.

  The key deletion (delkey) has a function of deleting a designated private key Ks without using an input parameter. The MK and private key Ks are stored in the security device 62 and are not transmitted to the outside. Further, the numbers of the private key Ks and the signature number counter C do not necessarily correspond to 1: 1 depending on the number of services to be requested, and the usage counter C may be set for each request message.

  FIG. 12 shows a ticket protocol executed by the ticket system 50 of the present invention. In step S70, when the user terminal commands to obtain a ticket from the ticket issuer terminal, in step S72, a genkey process is executed to generate a private key / public key pair <Ks, Kv>. At this time, the signature number counter is set to zero. The user terminal transmits M [Kv] obtained by signing the generated public key Kv with the master signature key MK in the security device 62 to the ticket issuer terminal. This signature is checked, and the ticket issuer terminal confirms that the user terminal is a security device including the master signature key MK in a genuine chip. After that, when the purchase of the ticket is properly completed, the digital ticket A [M [Kv] + t] is transmitted to the user terminal in step S74. In the described embodiment, the value of Cmax is also included in the ticket t, and both are received by the user terminal. M indicates a signature performed by the master MK.

  In step S80, the service terminal transmits a signal n prompting the user terminal to use the ticket t. The signal n can be multicast to the user terminal when the user terminal enters the effective range by performing mutual communication by wireless communication or infrared communication function having an angle range. In step S82, when the user terminal receives the signal n and the user terminal uses the ticket, the user terminal activates the security device and sends the signature Ks [n + C] and the ticket A [M [Kv] + t] to the service terminal. And send.

  In step S84, in order to determine access to the user terminal, the service terminal determines the ticket content t, the validity of the signature ticket A [M [Kv] + t], the validity of the signature M [Ks], and the user terminal. The validity of the signature Ks [n + C] and the value of C are acquired. If the validity of the ticket and the validity of each signature are confirmed in step S86, it is determined in step S88 whether C ≦ Cmax. If it is determined in step S88 that C ≦ Cmax (yes), an access permission command is issued in step S92 to permit access to the user terminal. In step S88, if C exceeds Cmax, the process is stopped in step S90, and the user terminal access permission is not issued.

  These ticket protocols are advanced while performing security checks using the value of the master counter, the CIR value, and the CA value by the security device of the present invention included in the user terminal. It has safety.

  FIG. 13 shows another embodiment of the ticket protocol of the present invention. Depending on the business model, it may be desirable to allow resale of tickets. As long as they use the same security device (chip) and ticket protocol, the tickets can be resold as shown in FIG.

  In this embodiment, as shown in FIG. 13, the procedure up to the point where the user terminal 90 purchases a ticket from the ticket issuer terminal 54 is the same as the protocol described in FIG. The user terminal 90 transfers the ticket to the third party terminal 92 having the same MK. The third party terminal 92 activates the security device and generates a key K2s for its ticket. It is assumed that there is a secure communication path including mutual authentication between the user terminal 90 and the third party terminal 92. The third party terminal 92 transmits the public key K2v for K2s to the user terminal 90 with a signature certifying that the key is coming from a genuine chip.

  When the user terminal 90 agrees with the conditions relating to the resale of the ticket including payment between the user terminal 90 and the third party terminal 92, the user terminal 90 uses the ticket key K1s of the user terminal 90 to sign the signature M2 [K2v] of the third party terminal 92. Create and return to third party terminal 92. At the same time, the ticket signature ticket A [M1 [K1v] + t] is also passed to the third party terminal 92. The third party terminal 92 verifies that the value of the counter C1 included in this signature is 0, and confirms that this ticket has not been used.

  Next, processing when the third party terminal 92 uses this ticket will be described. The service terminal 58 sends a signal n urging the third party terminal 92 to use the ticket. The third party terminal 92 receives this signal n, signs it with K2, and returns it. At the same time, the “signature indicating that Bob has transferred the ticket to Carol” K1s [M2 [K2v] + C1] and the ticket A [M1 [K1v] + t] received from the user terminal 90 are also sent to the service terminal 58. Send. The service terminal 58 confirms that neither C1 nor C2 is Cmax, and that each signature is correct. Since both the transfer signature K1s [M2 [K2v] + C1] of the user terminal 90 and the ticket use signature K2s [n + C2] of the third party terminal 92 can be determined based on the respective signature count counters, it is determined whether a plurality of tickets are used. can do.

  In the above-described embodiment, storing a plurality of tickets requires one private key and one signature counter. For example, assuming that a 1024-bit RSA key is used and the usage counter is 1 byte, a total of 129 bytes of non-volatile memory is used per ticket. When a large number of tickets are stored, this value can be assumed to be a burden from the viewpoint of hardware resources.

  In order to cope with this, a method of encrypting the RSA key and storing it in an inexpensive external storage (such as a hard disk) can be mentioned. The security device stores the hash of the RSA key and the counter for this purpose. Further, one master storage key is prepared for the entire security device, and this can also be stored in the security device. When the ticket key is generated, the security device outputs the ticket key encrypted with the master storage key. When using the ticket key, the ticket key can be used after decryption by returning the encrypted ticket key to the security device.

  Since the ticket key can only be used within the security device, the ticket key can effectively be considered to exist in the security device. When requested to use the ticket key, the security device decrypts the encrypted ticket key and generates its hash. As a result, it can be understood which signature number counter corresponds to the key, so that the use of a plurality of signatures can be restricted by incrementing the corresponding signature number counter after the signature.

  In this embodiment, the master storage key is, for example, a 128-bit AES key, which is preferably one for the entire security device. For the ticket key, for example, a 20-byte hash and a 1-byte counter use a 21-byte non-volatile memory per ticket.

  The control method of the present invention can be provided as a device-executable program, such as a machine language, C language, C ++ language, Java (registered trademark), Applet (registered trademark), etc. It can be written in any programming language.

The figure which showed schematic structure of the information processing system containing the security apparatus of this invention. The figure which showed the more detailed functional structure of the security apparatus of this invention. The figure which showed the schematic structure of the signature key list stored in CA in this invention. The flowchart which showed the process which genkey which produces | generates a key performs. The flowchart which showed the process which sign which performs a signature in this invention performs. The flowchart which showed the process of delkey which deletes an entry. The figure which showed the input and output of the microcode for performing each process of genkey, delkey, and sign, and its process. The figure which showed embodiment of the ticket system which mounted the security apparatus of this invention. Schematic which showed the function structure of the user terminal in the ticket system of this invention. The figure which showed schematic structure of the service terminal 58 used in the ticket system of this invention. The figure which showed the process and parameter which the security apparatus contained in the user terminal used in the ticket system of this invention uses. The figure which showed the ticket protocol which the ticket system of this invention performs. The figure which showed other embodiment of the ticket protocol of this invention.

Explanation of symbols

DESCRIPTION OF SYMBOLS 10 ... Information processing system, 12 ... Security device, 14 ... External device, 16 ... Interface part, 20 ... External non-volatile storage part, 22 ... Non-volatile storage part, 24 ... Volatile storage part, 26 ... Control part, 28 ... Hash function unit, 30 ... signature function means, 32 ... instruction interface (I / O) unit, 34 ... MK storage unit, 36 ... MC storage unit, 38 ... CIR storage area, 40 ... counter array (CA), 42 ... Signature key entry, 44 ... Hash value of key Blob, 46 ... Signature count counter, 50 ... Ticket system, 52 ... Network, 54 ... Ticket issuer terminal, 56 ... User terminal, 58 ... Service terminal, 60 ... Communication device, 62 ... Security device (chip), 64 ... CPU, 66 ... Memory, 68 ... I / O interface unit, 70 ... CPU, 72 ... I / O interface Esu, 74 ... memory, 76 ... message analyzing unit, 78 ... signature number determination unit, 80 ... access command section, 82 ... communication device, 84 ... gate device 86 ... application, 90 ... user terminal 92 ... third party terminal

Claims (16)

A security device for restricting multiple uses of signed data, the device comprising:
A non-volatile storage unit that stores a validity checking unit including a counter that is updated each time the signature function unit is called;
A counter array is stored from an external non-volatile storage unit that stores a counter array in which a hash value generated for each signature key and a signature number counter for counting the number of times the signature key is signed are paired. A volatile storage for reading and storing; and
A security device comprising: a hash function unit that reads a counter array from the volatile storage unit, generates a hash value, and passes the counter value to a validity checking unit for validity checking. The validity checking unit further includes:
Key means to guarantee the correctness of the security device;
The security device according to claim 1, comprising: a previous hash value generated in the past from the counter array. The security device according to claim 1, wherein the hash function unit further reads a value of the counter and calculates a hash value of a connection value with the counter array. The security device according to claim 2, wherein the security device includes a unit that compares the generated hash value with the immediately preceding hash value. The security device executes a digital signature in response to the validity determination by the validity checking unit, updates the signature number counter, and writes the updated signature number counter value in the external nonvolatile storage unit. The security device according to claim 1 to be executed. An information processing apparatus including a function for restricting multiple use of signed data, wherein the information processing apparatus
The security device according to any one of claims 1 to 5,
An interface unit including a non-volatile storage unit that stores a counter array in which a hash value generated for each signature key and a signature number counter for counting the number of times the signature key is signed are paired Including information processing apparatus. A control method for controlling a security device for restricting multiple uses of signed data, the control method comprising:
A counter array is stored from an external non-volatile storage unit that stores a counter array in which a hash value generated for each signature key and a signature number counter for counting the number of times the signature key is signed are paired. Reading and storing in the volatile storage;
The stored counter array is read to generate a hash value, and includes a key means for guaranteeing the validity of the security device for the validity check and a previous hash value generated from the counter array in the past. Passing to the validity checking unit; calling the signature function means in response to the determination of validity in the validity checking unit;
A security device control method for causing a security device to execute a step of updating a counter each time a signature function unit is called. The control method according to claim 7, further comprising a step of storing a previous hash value generated in the past from the counter array. The control method according to claim 7, further causing the hash function unit to read a value of the counter and calculate a hash value of a connection value with the counter array. The control method according to claim 8, further comprising a step of comparing the generated hash value with the immediately preceding hash value. Executing a digital signature in response to a determination of validity by the validity checking unit;
The control method according to claim 7, further comprising: updating a signature number counter in response to the execution of the digital signature and writing the updated value of the signature number counter in the external nonvolatile storage unit. A control method for controlling an information processing apparatus including a function for restricting multiple use of signed data, the control method comprising:
A step of executing the processing step according to any one of claims 7 to 11,
A counter array from an interface unit including a storage unit that stores a counter array in which a hash value generated for each signature key and a signature number counter for counting the number of times the signature key is signed are paired A method for controlling the information processing apparatus, comprising:   An apparatus-executable program for executing the control method according to any one of claims 7 to 11.   An apparatus-executable program for executing the control method according to claim 12. A ticket system using a digital ticket, the ticket system comprising:
A ticket issuer terminal that issues a ticket;
Storing the issued ticket, and the information processing apparatus according to claim 8;
A network interconnecting the ticket issuer terminal and the information processing device;
And a service terminal that issues a ticket use request to the information processing apparatus. The ticket system according to claim 15, wherein the information processing apparatus acquires and stores the ticket from another information processing apparatus and accesses the service terminal.

Images