JP2015055900A - Secure device management system, server, terminal device, and secure device management method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a secure device management system, server, terminal device, and secure device management method that integrally manage a plurality of secure devices.SOLUTION: In a secure device management system, a server 1 stores device management information including an individual device state and a virtual device state. The server 1 transmits a first command sequence which transits the virtual device state and the individual device state, each associating with the other, to a secure device. The secure device transmits an execution result of the received first command sequence to the server 1. The server 1 updates the device management information on the basis of the received execution result.

Description

  The present invention relates to a secure device management system, a server, a terminal device, and a secure device management method for handling a secure device, and in particular, a secure device management system, a server, a terminal device, and a secure device for managing a plurality of secure devices in a unified manner. It relates to the management method.

  Conventionally, a system for managing a plurality of secure devices such as an IC card, a SIM card, and a USB token is known. In such a system, it is necessary to manage and control in consideration of unique state transitions for each type of secure device. For example, when a new secure device type is added as a management target, it is necessary to individually create a management / control part of the system in consideration of the corresponding state transition. Further, during operation, it is necessary to execute processing individually while being aware of state transitions that differ depending on the type of each secure device. In recent years, the number of users of secure devices has increased, and the types of secure devices are expected to increase in the future. For this reason, it is expected that various users will use various secure devices depending on the purpose, and an increase in the work load related to management and control of the secure devices is expected.

  Conventionally, as a management system that does not require individual processing during operation, when a user who has multiple secure devices performs the same processing for the secure devices that are in possession, A method for performing the processing is known (for example, see Patent Document 1).

JP 2011-59922 A

  However, even with the above-described method, for example, in the case where an error such as a processing interruption occurs during operation, it is necessary to perform processing in consideration of the state transition of each secure device. For this reason, there is a concern that the operation becomes complicated and operator errors and operation costs increase.

  Accordingly, an object of the present invention made in view of such circumstances is to provide a secure device management system, a server, a terminal device, and a secure device management method for managing a plurality of secure devices in a unified manner.

In order to solve the above problems, a secure device management system according to the present invention includes:
A secure device management system comprising a plurality of types of secure devices each having different device state transition specifications depending on the type of secure device, and a server capable of communicating with the plurality of types of secure devices via a terminal device,
The server
Device management information including, for each secure device, an individual device state based on the individual device state transition specification and a virtual device state based on a virtual device state transition specification commonly used for the plurality of types of secure devices. Remember
Transmitting a first command sequence for transitioning the virtual device state and the individual device state in association with each other, to the secure device;
The secure device transmits the received execution result of the first command sequence to the server,
The server updates the device management information based on the received execution result.

The server according to the present invention is
A server capable of communicating via a terminal device with a plurality of types of secure devices each having different device state transition specifications depending on the type of secure device,
Device management information including, for each secure device, an individual device state based on the individual device state transition specification and a virtual device state based on a virtual device state transition specification commonly used for the plurality of types of secure devices. A storage unit for storing
A first command sequence for transitioning the virtual device state and the individual device state in association with each other is transmitted to a secure device, and the device is based on the execution result of the first command sequence received from the secure device. And a control unit for updating the management information.

The terminal device according to the present invention is
A terminal device that communicates between a server and a plurality of types of secure devices each having different device state transition specifications depending on the type of the secure device, and controls processing to be executed by the secure device,
First, from the server, an individual device state based on the individual device state transition specification and a virtual device state based on a virtual device state transition specification used in common for the plurality of types of secure devices are associated and transitioned. When one command sequence is received, processing to be executed by the secure device is controlled based on the received first command sequence.

The secure device management method according to the present invention includes:
A secure device management method for managing a plurality of types of secure devices each having different device state transition specifications depending on the type of secure device,
The server
Device management information including, for each secure device, an individual device state based on the individual device state transition specification and a virtual device state based on a virtual device state transition specification commonly used for the plurality of types of secure devices. The step of memorizing
Transmitting a first command sequence for causing the virtual device state and the individual device state to transition in association with each other; and
The secure device transmitting an execution result of the received first command sequence to the server;
The server includes updating the device management information based on the received execution result.

  According to the secure device management system, the server, the terminal device, and the secure device management method according to the present invention, a plurality of secure devices can be managed in a unified manner.

It is a figure explaining device state transition by the secure device management system concerning one embodiment of the present invention. It is a block diagram which shows schematic structure of the secure device management system which concerns on one Embodiment of this invention. It is a figure which shows the example of the virtualization conversion script and common component of FIG. It is a sequence diagram which shows operation | movement of the secure device management system which concerns on one Embodiment of this invention. It is a sequence diagram which shows operation | movement of the secure device management system which concerns on one Embodiment of this invention. It is a sequence diagram which shows operation | movement of the secure device management system which concerns on one Embodiment of this invention. It is a sequence diagram which shows operation | movement of the secure device management system which concerns on one Embodiment of this invention. It is a sequence diagram which shows operation | movement of the secure device management system which concerns on one Embodiment of this invention. It is a sequence diagram which shows operation | movement of the secure device management system which concerns on one Embodiment of this invention.

  Embodiments of the present invention will be described below.

  First, an overview of a secure device management system according to an embodiment of the present invention will be described with reference to FIG. FIG. 1 shows individual device state transition specifications defined for each type of secure device and virtual device state transition specifications defined in the secure device management system according to the present embodiment. Here, the device state transition specification refers to a relationship between a plurality of device states indicating the state of the secure device and transitions between the device states.

  The individual device state transition specification is a device state transition specification including a plurality of device states (individual device states) defined for each type of secure device. Specifically, different secure device A and secure device B having different device types define different individual device state transition specifications. For example, as shown in FIG. 1, the individual device state transition specifications possessed by the secure device A are six individual “Ready”, “RCkeyReady”, “Initialized”, “Secured”, “CMLocked”, and “Terminated”. Including device state. On the other hand, the individual device state transition specifications of the secure device B include five individual device states of “OP_READY”, “INITIALIZED”, “SECURED”, “CARD_LOCKED”, and “TERMINATED”. In addition, the solid line arrow of FIG. 1 shows the direction of a normal transition.

  The virtual device state transition specification is a device state transition specification including a plurality of device states (virtual device states) defined in the secure device management system according to the present embodiment, and is commonly used for different types of secure devices. For example, as shown in FIG. 1, the virtual device state transition specification includes five virtual device states of “before issue”, “in operation”, “locked”, “revoked”, and “error state”. Including.

  As an outline, the secure device management system according to the present embodiment associates an individual device state with a virtual device state in advance, and transitions the individual device state according to the transition of the virtual device state. For example, as indicated by a broken line in FIG. 1, the individual device states “Ready”, “RCkeyReady” and “Initialized” of the secure device A, and the individual device states “OP_READY” and “INITIALIZED” of the secure device B are virtual Is associated with the device status “before issue”. In addition, the individual device state “Secured” of the secure device A and the individual device state “SECURED” of the secure device B are associated with the virtual device state “in operation”. Here, when the virtual device state is changed from “before issue” to “in operation”, for the secure device A, the individual device states are changed in the order of “Ready”, “RCkeyReady”, “Initialized”, and the secure device For B, individual device states are changed in the order of “OP_READY” and “INITIALIZED”. The virtual device state “error state” is temporarily set when processing interruption (error) occurs between the server 1 and the secure device, that is, when processing is interrupted during the transition of the device state. The device state to be set. Specifically, when any state transition process is interrupted, the state transitions to an “error state” as indicated by the one-dot chain line arrow in FIG. As shown by the broken line arrow in 1, the transition is made to the device state of the transition destination in the interrupted transition process. In the present embodiment, an “error state” is defined without having a correspondence with an individual device state.

  Next, the configuration of the secure device management system according to the present embodiment will be described with reference to FIG. The secure device management system includes a server 1, a terminal device 2, and secure devices A and B. Hereinafter, an example in which two secure devices are provided will be described, but any number of secure devices can be provided.

  The server 1 includes a server communication unit 3, a storage unit 4, a virtualization unit 5, a virtualization conversion script 6, a common component 7, and a control unit 8.

  The server communication unit 3 communicates with the terminal device 2 by wire or wireless.

  The storage unit 4 stores device ID 9, device type 10, individual device status information 11, virtual device status information 12, and storage information 13 as device management information.

  The device ID 9 is an identifier that can uniquely identify the secure device.

  The device type 10 is information indicating the type of secure device corresponding to the device ID 9. The types of secure devices are, for example, IC cards and USB tokens, and have different device state transition specifications for each type.

  The individual device status information 11 is information indicating the current individual device status of the secure device corresponding to the device ID 9.

  The virtual device status information 12 is information indicating the current virtual device status of the secure device corresponding to the device ID 9.

  The stored information 13 is information related to the secure device corresponding to the device ID 9. The information regarding the secure device includes, for example, the PIN of the secure device.

  Based on the virtualization conversion script 6, the virtualization unit 5 generates a command APDU (Application Protocol Data Unit) to be transmitted to the secure device.

  The virtualization conversion script 6 is a script that defines a rule for converting an individual state transition specification into a virtual state transition specification, and includes a command sequence for causing a transition between an individual device state and a virtual device state in association with each other. . The virtualization conversion script 6 is defined for each type of secure device, and can be used in common for the same type of secure device. In FIG. 2, the virtualization conversion script 6A corresponds to the secure device A, and the virtualization conversion script 6B corresponds to the secure device B. Details of the virtualization conversion script 6 will be described later. The virtualization conversion script 6 is stored in, for example, a nonvolatile memory.

  The common component 7 is a common command sequence that can be commonly used in the same type of secure device in the virtualization conversion script 6 and is defined as a component. Details of the common component 7 will be described later. The common component 7 is stored in, for example, a nonvolatile memory.

  The control unit 8 controls the operation of the entire server 1.

  The terminal device 2 includes a terminal communication unit 14, a device control unit 15, and a GUI unit 16. The terminal device 2 is operated by an operator, for example, and communicates with the server 1 and the secure device to change the device state of the secure device.

  The terminal communication unit 14 communicates with the server 1 by wire or wireless.

  The device control unit 15 communicates with the secure device by contact or non-contact. The device control unit 15 also determines the type of secure device with which to communicate. Further, the device control unit 15 controls processing to be executed by the secure device based on the command APDU received from the server 1. For example, the device control unit 15 transmits the command APDU received from the server 1 to the secure device, or modifies and divides the command APDU according to the size of the received command APDU and the type of the secure device, and transmits the command APDU. Controls the process executed by the secure device.

  The GUI unit 16 displays a processing result in the secure device management system. Further, the GUI unit 16 functions as an input interface that receives an operator's operation. For example, when the process is interrupted between the server 1 and the secure device, the GUI unit 16 displays that the virtual device state is “error state”, and an operator operation for performing error recovery processing Accept.

  The secure devices A and B are devices having secure areas and different types of secure devices.

  Next, the virtualization conversion script 6 and the common component 7 will be described with reference to FIG. FIG. 3 is a diagram showing a virtualization conversion script 6A and a common component 7A corresponding to the secure device A.

  The virtualization conversion script 6 </ b> A includes a first command sequence 17 and a second command sequence 18.

  The first command sequence 17 is a command sequence for transitioning the virtual device state and the individual device state in association with each other, and is defined for each transition process of the virtual device state specification. For example, the first command sequence 17 shown in FIG. 6 is a command sequence for transitioning the virtual device state from “before issue” to “in operation”. In FIG. 6, the description of the first command sequence corresponding to the transition of another virtual device state is omitted for the sake of simplicity. As shown in FIG. 6, the first command sequences 17a, 17b, and 17c change the individual device states from “Ready” to “RCkeyReady”, “RCkeyReady” to “Initialized”, and “Initialized” to “Secured”, respectively. This is a command sequence to be executed. When the first command sequence 17 shown in FIG. 6 is executed between the server 1 and the secure device A, the individual device states of the secure device A are “Ready”, “RCkeyReady”, “Initialized”, “Secured”. And the virtual device state changes from “before issue” to “in operation”.

  The second command sequence 18 is a command sequence for recovering an error corresponding to an individual device state of the secure device A at the time of interruption (error) when processing is interrupted between the server 1 and the secure device A. . As shown in FIG. 6, the second command sequences 18a, 18b, and 18c are command sequences that are executed when the individual device states at the time of error are “Ready”, “RCkeyReady”, and “Initialized”, respectively. . For example, when the process of transitioning the individual device state from “Ready” to “RCkeyReady” is interrupted when transitioning the virtual device state from “before issue” to “in operation”, the second command sequence 18a is executed. The

  The common component 7A is a component formed by defining a common sequence portion as a tag in the command sequence included in the virtualization conversion script 6A. For example, the common component 7A shown in FIG. 3 defines a series of commands “Select file”, “Get challenge”, “External authenticate”, and “Internal authenticate” necessary for authentication processing with a tag “Authenticate”. ing.

The contents of the symbols (commands) included in the virtualization conversion script 6A and the common component 7A are as follows.
#: Indicates a comment line.
State = “state 1 → state 2”: It is defined that the command sequence described below is a command sequence for causing the secure device A to transition from “state 1” to “state 2”.
Call “tag name”: defines that the command sequence defined by the “tag name” of the common component 7A is used.
Error state = “state 1”: It is defined that the command sequence described below is a command sequence executed when the state of the secure device A at the time of error occurrence is “state 1”.
Call state “State 1 → State 2”: The command sequence defined by state = “State 1 → State 2” is executed.
if (SW1 “judgment formula” “value”): When the SW value of the command executed immediately before corresponds to “judgment formula” and “value”, the command sequence up to End if is executed.
End if: indicates the end position of the command sequence indicated by if.
tag = “tag name”: Defines the tag name of the command sequence described below.

  Next, the operation of the secure device management system will be described with reference to FIGS. 4 to 9 show a series of processes for transitioning the individual device state from “Ready” to “Secured” so that the virtual device state of the secure device A is transitioned from “before issue” to “in operation”. Show. In addition, the process includes a process when a process interruption (error) occurs between the server 1 and the secure device A. Before the start of this process, the individual device status of the secure device A is “Ready”, and the virtual device status is “before issue”. In this process, the operator operates the GUI unit 16 of the terminal device 2 and an input (request) for changing the individual device status of the secure device A from “before issue” to “in operation” is transmitted to the server 1. Then it starts.

  As illustrated in FIG. 4, first, the terminal device 2 transmits a request for changing the virtual device state of the secure device A from “before issue” to “in operation” to the server 1 via the terminal communication unit 14. (Step S100).

  Next, when receiving the request in step S100 from the terminal device 2, the virtualization unit 5 of the server 1 interprets the content of the request and reads the virtualization conversion script 6A (step S101).

  Subsequently, the virtualization unit 5 reads the common component 7A (step S102).

  Subsequently, the virtualization unit 5 uses the first command sequence 17 to generate a command APDU for changing the device state of the secure device A, and requests the control unit 8 for processing (step S103). Specifically, the virtualization unit 5 repeatedly executes the processing from step S103 to step S109 as will be described later, and generates corresponding command APDUs in order from the first command in the first command sequence 17. For example, the virtualization unit 5 generates a command APDU corresponding to “Select file” of the first command sequence 17a in the first process of step S103.

  Next, the control unit 8 reads the storage information 13 corresponding to the secure device A from the storage unit 4 and modifies the command APDU generated in step S103 as necessary (step S104).

  Subsequently, the control unit 8 transmits the command APDU corrected in step S104 to the terminal device 2 via the server communication unit 3 (step S105).

  Next, when receiving the command APDU in step S105, the device control unit 15 of the terminal device 2 transmits the command APDU to the secure device A, and receives a response APDU indicating the result of the secure device A executing the command APDU. (Step S106). Here, the device control unit 15 may modify and divide the command APDU in step S105 according to the size of the command APDU and the type of the secure device, and transmit the corrected command APDU to the secure device A.

  Subsequently, the device control unit 15 transmits the response APDU received in step S106 to the server 1 (step S107).

  Next, the virtualization unit 5 of the server 1 interprets the content of the received response APDU and notifies the control unit 8 of the result (step S108).

  Next, based on the notified result, the control unit 8 updates device management information as necessary and stores it in the storage unit 4 (step S109). Specifically, when the individual device status information 11, the virtual device status information 12, or the storage information 13 is changed, the control unit 8 updates these and stores them in the storage unit 4.

Steps S103 to S109 described above are repeatedly executed. Here, step S103 to step S109 are performed three times, and the processing up to “Pin update” of the first command sequence 17a is completed. Note that the PIN of the secure device A is updated from the initial PIN ₀ to a new PIN ₁ by executing “Pin update”, that is, the third step S106. Further, the storage information 13 is updated by the third step S109 to include PIN ₁ in addition to PIN ₀ .

  Next, as illustrated in FIG. 5, the virtualization unit 5 generates a command APDU corresponding to “Store data”, and requests the control unit 8 to perform processing (step S <b> 110).

  Next, the control unit 8 reads the storage information 13 corresponding to the secure device A from the storage unit 4, and modifies the command APDU generated in step S110 as necessary (step S111).

  Subsequently, the control unit 8 transmits the command APDU corrected in step S111 to the terminal device 2 via the server communication unit 3 (step S112).

  Next, when receiving the command APDU in step S112, the device control unit 15 of the terminal device 2 transmits the command APDU to the secure device A, and receives a response APDU indicating the result of the secure device A executing the command APDU. (Step S113).

  Subsequently, the device control unit 15 of the terminal device 2 transmits the response APDU received in step S113 to the server 1 (step S114).

  Here, when the server 1 cannot receive the response APDU of step S114 due to communication disconnection or the like, the control unit 8 of the server 1 determines that there is an error and updates the device management information (step S115). Specifically, the control unit 8 sets the virtual device state information 12 stored in the storage unit 4 to “error state”. The individual device status information 11 remains “Ready”.

  Next, the control unit 8 of the server 1 transmits a notification indicating that an error has occurred to the terminal device 2 via the server communication unit 3 (step S116).

  Next, when receiving the notification in step S116, the GUI unit of the terminal device 2 displays that the virtual device state is “error state”, and requests the server 1 to request error recovery processing based on the operation of the operator. (Step S117).

Next, the control unit 8 of the server 1 stores individual device status information 11 (
"Ready") is acquired (step S118) and notified to the virtualization unit 5 (step S119).

  Next, as illustrated in FIG. 6, the virtualization unit 5 generates a command APDU for recovering an error using the second command sequence 18 and requests the control unit 8 to perform processing (step S <b> 120). . Here, the virtualization unit 5 uses the second command sequence 18a corresponding to the individual device status information 11 (“Ready”) acquired in step S119. Then, the virtualization unit 5 generates a command APDU corresponding to “Select file” that is the first command of the second command sequence 18a.

  Next, the control unit 8 reads the storage information 13 corresponding to the secure device A from the storage unit 4 and modifies the command APDU generated in step S120 as necessary (step S121).

  Subsequently, the control unit 8 transmits the command APDU corrected in step S121 to the terminal device 2 via the server communication unit 3 (step S122).

  Next, upon receiving the command APDU in step S122, the device control unit 15 of the terminal device 2 transmits the command APDU to the secure device A, and receives a response APDU indicating the result of the secure device A executing the command APDU. (Step S123).

  Subsequently, the device control unit 15 transmits the response APDU received in step S123 to the server 1 (step S124).

  Next, the virtualization unit 5 of the server 1 interprets the content of the received response APDU and notifies the control unit 8 of the result (step S125).

  Next, based on the notified result, the control unit 8 updates the device management information as necessary and stores it in the storage unit 4 (step S126).

  Next, the virtualization unit 5 uses the second command sequence 18 to generate a command APDU for error recovery, and requests the control unit 8 to perform processing (step S127). Here, the virtualization unit 5 generates a command APDU corresponding to the “Verify” command described in the second line of the second command sequence 18a.

Next, the control unit 8 reads the storage information 13 corresponding to the secure device A from the storage unit 4 and modifies the command APDU generated in step S127 as necessary (step S128). Here, since there is a possibility that the PIN has not been updated on the secure device A side due to an error, the control unit 8 acquires the initial PIN ₀ from the storage information 13 and executes “Verify” using the initial PIN _0. Modify the command APDU as follows:

  Subsequently, the control unit 8 transmits the command APDU corrected in step S128 to the terminal device 2 via the server communication unit 3 (step S129).

Next, upon receiving the command APDU in step S129, the device control unit 15 of the terminal device 2 transmits the command APDU to the secure device A, and receives a response APDU indicating the result of the secure device A executing the command APDU. (Step S130). Here, since the secure device A is normally updated to PIN ₁ by the third step S106 (see FIG. 4), the response APDU to the “Verify” command by the initial PIN ₀ is abnormally terminated (SW! = 9000). (See FIG. 6).

  Subsequently, the device control unit 15 of the terminal device 2 transmits the response APDU received in step S130 to the server 1 (step S131).

  Next, the virtualization unit 5 of the server 1 interprets the content of the received response APDU, generates a command APDU for recovering an error using the second command sequence 18, and performs processing on the control unit 8. A request is made (step S132). Here, the virtualization unit 5 generates a command APDU corresponding to the “Verify” command described in the fourth line of the second command sequence 18a.

Next, the control unit 8 reads the storage information 13 corresponding to the secure device A from the storage unit 4 and modifies the command APDU generated in step S132 as necessary (step S133). Here, the control unit 8 modifies the command APDU so as to acquire PIN ₁ from the storage information 13 and execute “Verify” using PIN ₁ because “Verify” by the initial PIN ₀ was abnormally terminated in step S130. To do.

  Subsequently, the control unit 8 transmits the command APDU corrected in step S133 to the terminal device 2 via the server communication unit 3 (step S134).

  Next, upon receiving the command APDU in step S134, the device control unit 15 of the terminal device 2 transmits the command APDU to the secure device A, and receives a response APDU indicating the result of the secure device A executing the command APDU. (Step S135). Here, the response APDU indicates normal termination (SW = 9000).

  Subsequently, the device control unit 15 of the terminal device 2 transmits the response APDU received in step S135 to the server 1 (step S136).

  Next, the virtualization unit 5 of the server 1 interprets the content of the received response APDU and notifies the control unit 8 of the result (step S137).

  Next, the control unit 8 updates the device management information as necessary based on the notified result, and stores the updated device management information in the storage unit 4 (step S138).

  Next, as illustrated in FIG. 7, the virtualization unit 5 generates a command APDU for recovering an error using the second command sequence 18 and requests the control unit 8 to perform processing (step S <b> 139). . Specifically, the virtualization unit 5 repeatedly executes the processing from step S139 to step S145 as will be described later, and sequentially handles the “Pin update” command described in the sixth line of the second command sequence 18a. A command APDU is generated. Therefore, the virtualization unit 5 generates a command APDU corresponding to “Pin update” in the first process of step S139.

  Next, the control unit 8 reads the storage information 13 corresponding to the secure device A from the storage unit 4 and modifies the command APDU generated in step S139 as necessary (step S140).

  Subsequently, the control unit 8 transmits the command APDU corrected in step S140 to the terminal device 2 via the server communication unit 3 (step S141).

  Next, upon receiving the command APDU in step S141, the device control unit 15 of the terminal device 2 transmits the command APDU to the secure device A, and receives a response APDU indicating the result of the secure device A executing the command APDU. (Step S142).

  Subsequently, the device control unit 15 transmits the response APDU received in step S142 to the server 1 (step S143).

  Next, the virtualization unit 5 of the server 1 interprets the content of the received response APDU and notifies the control unit 8 of the result (step S144).

  Next, the control unit 8 updates the device management information as necessary based on the notified result, and stores the updated device management information in the storage unit 4 (step S145).

Steps S139 to S145 described above are repeatedly executed. Here, it is assumed that the processing by “Internal authenticate” of the common component 7A referred to by “Call Authenticate” in the first command sequence 17c is completed in “Call state Initialized → Secured” in the second command sequence 18a. . Note that the PIN of the secure device A is updated from PIN ₁ to a new PIN ₂ by executing “Pin update”, that is, the first step S142. Also, the storage information 13 is updated by the first step S145, and includes PIN ₂ in addition to PIN ₀ and PIN ₁ . In addition, since the processing of the first command sequence 17b referred to by “Call state RCkeyReady → Initialized” of the second command sequence 18a has been completed, the individual device state information 11 is updated to “Initialized”. However, the virtual device state information 12 remains “error state”.

  Next, as illustrated in FIG. 8, the virtualization unit 5 generates a command APDU for recovering an error using the second command sequence 18, and requests the control unit 8 to perform processing (step S <b> 146). . Here, a command APDU corresponding to “Read data” of the first command sequence 17 c referred to by “Call state Initialized → Secured” of the second command sequence 18 a is generated.

  Next, the control unit 8 reads the storage information 13 corresponding to the secure device A from the storage unit 4 and modifies the command APDU generated in step S146 as necessary (step S147).

  Subsequently, the control unit 8 transmits the command APDU corrected in step S147 to the terminal device 2 via the server communication unit 3 (step S148).

  Next, upon receiving the command APDU in step S148, the device control unit 15 of the terminal device 2 transmits the command APDU to the secure device A, and receives a response APDU indicating the result of the secure device A executing the command APDU. (Step S149).

  Subsequently, the device control unit 15 transmits the response APDU received in step S149 to the server 1 (step S150).

  Here, when the server 1 cannot receive the response APDU in step S150 due to communication interruption or the like, the control unit 8 of the server 1 determines that there is an error and updates the device management information (step S151). Specifically, the control unit 8 sets the virtual device state information 12 stored in the storage unit 4 to “error state”. The individual device status information 11 remains “Initialized”.

  Next, the control unit 8 of the server 1 transmits a notification indicating that an error has occurred to the terminal device 2 via the server communication unit 3 (step S152).

  Next, when receiving the notification in step S152, the GUI unit of the terminal device 2 displays that the virtual device state is “error state”, and requests the server 1 to request error recovery processing based on the operation of the operator. (Step S153).

Next, the control unit 8 of the server 1 stores individual device status information 11 (
"Initialized") is acquired (step S154) and notified to the virtualization unit 5 (step S155).

  Next, as illustrated in FIG. 9, the virtualization unit 5 generates a command APDU for error recovery using the second command sequence 18, and requests the control unit 8 to perform processing (step S156). . Specifically, the virtualization unit 5 repeatedly executes the processing from step S156 to step S162 as will be described later, and sequentially handles from “Call state Initialized → Secured”, which is the first command of the second command sequence 18c. A command APDU is generated. Accordingly, in the first process of step S156, the virtualization unit 5 sets “Select file” of the common component 7A referred to by “Call Authenticate” of the first command sequence 17C in “Call state Initialized → Secured”. A corresponding command APDU is generated.

  Next, the control unit 8 reads the storage information 13 corresponding to the secure device A from the storage unit 4 and modifies the command APDU generated in step S156 as necessary (step S157).

  Subsequently, the control unit 8 transmits the command APDU corrected in step S157 to the terminal device 2 via the server communication unit 3 (step S158).

  Next, upon receiving the command APDU in step S158, the device control unit 15 of the terminal device 2 transmits the command APDU to the secure device A, and receives a response APDU indicating the result of the secure device A executing the command APDU. (Step S159).

  Subsequently, the device control unit 15 transmits the response APDU received in step S159 to the server 1 (step S160).

  Next, the virtualization unit 5 of the server 1 interprets the content of the received response APDU and notifies the control unit 8 of the result (step S161).

  Next, based on the notified result, the control unit 8 updates the device management information as necessary and stores it in the storage unit 4 (step S162).

  Steps S156 to S162 described above are repeatedly executed. Here, it is assumed that the processing by “Set status” of the first command sequence 17c referred to by “Call state Initialized → Secured” of the second command sequence 18c is completed. Therefore, since all the processes of the second command sequence 18c are completed, the individual device status information 11 is updated to “Secured”, and the virtual device status information 12 is updated to “in operation”.

  Then, the control unit 8 transmits a notification indicating that the process of the virtual device state transition (from “before issue” to “in operation”) is completed to the terminal device 2 via the server communication unit 3 (step S163). ), The fact is displayed on the GUI unit 16 of the terminal device 2 (step S164). For example, the GUI unit 16 displays that the virtual device state of the secure device A is “in operation”.

  As described above, according to the secure device management system according to the present embodiment, the server 1 stores device management information including individual device state information 11 and virtual device state information 12 for each secure device. When the first command sequence 17 for changing the individual device state is transferred to the secure device so as to change the device state, and the execution result of the first command sequence 17 is received from the secure device, the device management information is updated. Thus, a plurality of secure devices having individual device state transition specifications that differ depending on the type of secure device can be converted into a virtual device state transition specification that can be used in common and managed in a unified manner.

  Further, according to the secure device management system according to the present embodiment, when the server 1 interrupts processing between the server 1 and the secure device (an error occurs), the individual device status information 11 at the time of the interruption is stored. When the corresponding second command sequence 18 is transmitted to the secure device and the execution result of the second command sequence 18 is received from the secure device, the device management information is updated. Thereby, when an error occurs during the state transition of the secure device, the recovery operation can be performed without being aware of the state transition of each secure device, and the processing omission and work load of the operator can be reduced.

  Further, according to the secure device management system according to the present embodiment, when the server 1 interrupts processing between the server 1 and the secure device (an error occurs), the virtual device state information 12 is changed to “error state”. When the execution result of the second command sequence 18 is received from the secure device, the virtual device state information 12 is updated to a state other than the “error state”. In this way, it becomes possible to unify the secure devices in which the device state transition processing is interrupted due to an error without being aware of which state transition the individual secure device has interrupted, and the operator The processing omission and work burden can be further reduced.

  Further, according to the secure device management system according to the present embodiment, the server 1 updates the virtual device state information 12 included in the device management information, and the terminal device 2 stores the updated virtual device state information 12. indicate. In this way, the operator can determine at a glance whether the device state transition processing of the secure device has been performed normally or whether the processing has been interrupted due to an error based on the display of the terminal device 2. Thus, the processing omission and work burden on the operator can be further reduced.

  Further, according to the secure device management system according to the present embodiment, the server 1 includes a command sequence that can be commonly executed by a plurality of secure devices as the common component 7. For this reason, for example, when the virtualization conversion script 6 is newly created or modified, the common component 7 can be reused, and productivity and maintainability can be improved.

  Although the present invention has been described based on the drawings and examples, it should be noted that those skilled in the art can easily make various modifications and corrections based on the present disclosure. Therefore, it should be noted that these variations and modifications are included in the scope of the present invention. For example, the functions included in each component, each step, etc. can be rearranged so that there is no logical contradiction, and multiple components, steps, etc. can be combined or divided into one It is.

  For example, the virtual state transition specification includes five virtual device states in the above-described embodiment, but may include any number of virtual device states.

  Further, the common component 7 may be a command sequence that can be commonly used among different types of secure devices.

  Further, when the virtual device state of the secure device becomes “error state”, the second command sequence 18 may be automatically executed without receiving a request for error recovery processing from the terminal device 2. Good.

DESCRIPTION OF SYMBOLS 1 Server 2 Terminal device 3 Server communication part 4 Memory | storage part 5 Virtualization part 6, 6A, 6B Virtualization conversion script 7, 7A, 7B Common component 8 Control part 9 Device ID
10 Device type 11 Individual device status information 12 Virtual device status information 13 Storage information 14 Terminal communication unit 15 Device control unit 16 GUI unit 17, 17a, 17b, 17c First command sequence 18, 18a, 18b, 18c Second Command sequence

The terminal device according to the present invention is
A terminal device that communicates between a server and a plurality of types of secure devices each having different device state transition specifications depending on the type of the secure device, and controls processing to be executed by the secure device,
A request for transitioning a virtual device state based on a virtual device state transition specification commonly used for the plurality of types of secure devices is transmitted to the server;
From the server, the individual and the individual device status based on the device state transition specification, a device state before Kikari virtual receives the first command sequence to transition associates, the first command received Based on the sequence, the process to be executed by the secure device is controlled.

Claims (8)

A secure device management system comprising a plurality of types of secure devices each having different device state transition specifications depending on the type of secure device, and a server capable of communicating with the plurality of types of secure devices via a terminal device,
The server
Device management information including, for each secure device, an individual device state based on the individual device state transition specification and a virtual device state based on a virtual device state transition specification commonly used for the plurality of types of secure devices. Remember
Transmitting a first command sequence for transitioning the virtual device state and the individual device state in association with each other, to the secure device;
The secure device transmits the received execution result of the first command sequence to the server,
The secure device management system, wherein the server updates the device management information based on the received execution result. When the processing is interrupted with the secure device, the server transmits a second command sequence for recovering an error corresponding to the individual device state at the time of the interruption to the secure device,
The secure device transmits the received execution result of the second command sequence to the server,
The secure device management system according to claim 1, wherein the server updates the device management information based on the received execution result. The virtual device state transition specification includes an error state indicating processing interruption as a virtual device state,
The server
When processing is interrupted with the secure device, the virtual device status is updated to an error status,
The secure device management system according to claim 2, wherein when the execution result of the second command sequence is received from the secure device, the virtual device state is updated to a state other than the error state. The server is capable of transmitting information indicating that the device management information has been updated to the terminal device,
The secure device management system according to any one of claims 1 to 3, wherein the terminal device displays the virtual device state based on the received information.   5. The secure device management system according to claim 1, wherein the server includes a command sequence that can be commonly executed by a plurality of secure devices as a common component. A server capable of communicating via a terminal device with a plurality of types of secure devices each having different device state transition specifications depending on the type of secure device,
Device management information including, for each secure device, an individual device state based on the individual device state transition specification and a virtual device state based on a virtual device state transition specification commonly used for the plurality of types of secure devices. A storage unit for storing
A first command sequence for transitioning the virtual device state and the individual device state in association with each other is transmitted to a secure device, and the device is based on the execution result of the first command sequence received from the secure device. A control unit that updates management information. A terminal device that communicates between a server and a plurality of types of secure devices each having different device state transition specifications depending on the type of the secure device, and controls processing to be executed by the secure device,
First, from the server, an individual device state based on the individual device state transition specification and a virtual device state based on a virtual device state transition specification used in common for the plurality of types of secure devices are associated and transitioned. A terminal device that controls processing to be executed by the secure device based on the received first command sequence when the command sequence is received. A secure device management method for managing a plurality of types of secure devices each having different device state transition specifications depending on the type of secure device,
The server
Device management information including, for each secure device, an individual device state based on the individual device state transition specification and a virtual device state based on a virtual device state transition specification commonly used for the plurality of types of secure devices. The step of memorizing
Transmitting a first command sequence for causing the virtual device state and the individual device state to transition in association with each other; and
The secure device transmitting an execution result of the received first command sequence to the server;
A secure device management method comprising: the server updating the device management information based on the received execution result.

Images