JP5347417B2 - IC card system, its host device, program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To prevent a card access key from being leaked from an IC card reader/writer and further to eliminate the need to apply robust security measures to the IC card reader/writer. <P>SOLUTION: A high-order device 10 holds a card access key in a secure memory 14 for key information storage and applies robust security measures using a tamper-resistant case. The high-order device 10 then performs via a card reader/writer 20 processing of communication with a non-contact IC card 3, in particular, mutual authentication processing with encryption/decryption processing using the card access key. The card reader/writer 20 is configured basically to relay communication between the high-order device 10 and the non-contact IC card 3 and the card access key is not held in the card reader/writer 20. <P>COPYRIGHT: (C)2010,JPO&amp;INPIT

Description

  The present invention relates to an IC card system comprising an IC card reader / writer that mediates communication with an IC card and its host device.

Conventionally, there is an IC card system (also referred to as a card using device) in which a card reader / writer and a host device are connected.
The card reader / writer is located between the higher-level device and the customer's IC card, and performs card authentication, encrypted communication, and card information read / write in cooperation with the higher-level device, and electrical matching required for communication with the IC card. It controls the lower layers involved in communication such as communication rate matching of communication messages, transmission / reception of ACK responses, and communication timeout monitoring, thereby realizing a function of realizing an interface with an IC card. Furthermore, on behalf of the host device, control of communication procedures with the card, generation of communication messages, and generation and determination of the contents of some data may be performed.

  When performing card access with security, mutual authentication processing (including encryption processing) with the IC card is required before card access (actual data read / write, etc.), and subsequent communication (The above card access) is also generally encrypted. The encryption / decryption process related to the mutual authentication process is executed using a predetermined card access key registered in advance. On the other hand, the encryption / decryption process in the subsequent card access is executed using a key (referred to as a session key) that is temporarily generated based on predetermined data obtained by the mutual authentication process.

  The card access key necessary for encryption / decryption associated with the mutual authentication process has been registered in the card reader / writer as in the following examples (1), (2), etc. , It is passed from the host device to the card reader / writer.

  (1) A card access key is registered in the card reader / writer, the card reader / writer performs mutual authentication processing with the IC card, and the card reader / writer also performs read / write processing to the IC card after authentication.

  (2) Although the card access key is not registered in the card writer, it is registered in the host device. When it is necessary to authenticate with the IC card, the host device temporarily passes the card access key to the card writer, and the card reader / writer performs mutual authentication processing with the IC card. The card access key handed over to the card reader / writer is assumed to be held by the card reader / writer after the authentication is completed, or until the card reader / writer is turned off or an erase command is received. Is done. The card reader / writer performs read / write processing on the card after authentication.

Alternatively, the host device may be connected to a server device (referred to as a management server) such as an IC card issuing / operating company via a network such as the Internet. The management server is, for example, a server device that manages various information (such as history) related to IC card payment processing and encryption keys (such as card access keys). In particular, the card access key may be upgraded, and the management server distributes a new card access key such as the upgraded version to each host device via the network. Alternatively, in the case of an operation mode in which the card access key is erased except when the card using device side is operating, the card access key is periodically sent to the host device via the network (every time the card using device side starts operation). To deliver. The host device passes the distributed card access key to the card reader / writer for re-registration.

Moreover, the prior art described in Patent Document 1 is known.
For example, Patent Document 1 shows a mutual authentication processing procedure in FIG.
Japanese Patent No. 3897177

  The card access key required for mutual authentication with the above-described IC card is usually different for each type of IC card, in other words, it is a key common to all the same type of IC cards. So it must be absolutely avoided that this leaks.

  In the prior art, the card access key is registered in the card reader / writer (in the case of (1) above), or the card access key is transferred to the card reader / writer (in the case of (2) above). Even so, the card access key is held in the card reader / writer. Therefore, a strong security mechanism is required to prevent the card access key from leaking to the card reader / writer. For example, a strong security measure has been taken, such as a tamper-resistant case for the card reader / writer and a tamper-resistant memory for storing the card access key.

  In the case of (2) above, since the card access key is registered in the higher-level device, the high-level device has a strong security for preventing leakage of the card access key as in the case of the card reader / writer. A mechanism was necessary. Also in the case of (1) above, the management server holds (temporarily) the card access key distributed from the management server, and the upper device is a device directly connected to the card reader / writer. In view of this, it is necessary to have a strong security mechanism for preventing leakage of the card access key.

  As described above, conventionally, in an IC card system having a card reader / writer and a host device, it is necessary to take strong security measures for both the card reader / writer and the host device, resulting in high costs. Even if a strong security measure is applied to the card reader / writer, the possibility of leakage of the card access key is not zero as long as the card access key exists in the card reader / writer. In particular, the card reader / writer is generally more likely to be stolen than the host device, and if the card reader / writer is stolen, there is a risk that the card access key will be leaked from the card reader / writer. was there.

  An object of the present invention relates to an IC card system having a host device and an IC card reader / writer, can prevent leakage of a card access key from the IC card reader / writer, and further needs to take strong security measures for the IC card reader / writer. The purpose is to provide an IC card system and the like that will disappear.

  The IC card system of the present invention is an IC card system in which a host device is connected to a card reader / writer, and the host device uses a card access key storage means for storing a card access key and the card access key. A mutual authentication unit that performs mutual authentication processing with the IC card by encrypted communication, and the card reader / writer relays a packet that is transmitted and received between the host device and the IC card for the mutual authentication processing. Have means.

In the IC card system configured as described above, the card access key necessary for mutual authentication processing with the IC card is registered in the host device. Then, the host device communicates with the IC card via the card reader / writer, and performs mutual authentication processing with the IC card using the card access key. The card reader / writer performs packet relay processing, does not perform mutual authentication processing as in the prior art, and therefore does not need to hold a card access key.

Therefore, there is no possibility that the card access key is leaked from the card reader / writer, and leakage of the card access key from the card reader / writer can be prevented.
Further, as described above, the card access key is held by the host device and is not held by the card reader / writer. Therefore, it is not necessary for the card reader / writer to take a strong security measure as in the prior art.

  That is, for example, the host device has a tamper-resistant housing, and / or a strong security measure is taken with the card access key storage means being a tamper-resistant memory. Strong security measures are not necessary. Therefore, a cost reduction effect can be obtained as compared with the case where it is necessary to take a strong security measure for both the host device and the card reader / writer as in the prior art.

  In addition, for example, the higher-level device further includes a session key generation / transmission unit that generates a session key based on the specific information obtained in the mutual authentication process and transmits the session key to the card reader / writer. The card reader / writer further uses the session key to perform card access processing for the IC card after the mutual authentication processing succeeds, using the session key passed from the session key generation / transmission means. It has card access means for performing encrypted communication.

  With respect to the card access process that requires a relatively short process compared to the mutual authentication process, a session key is passed to the card reader / writer to be executed by the card reader / writer. As a result, it is possible to reduce processing in a short time and processing load on the host device.

  According to the IC card system and the like of the present invention, it is related to an IC card system having a host device and an IC card reader / writer, and it is possible to prevent leakage of a card access key from the IC card reader / writer. There is no need to take measures.

Embodiments of the present invention will be described below with reference to the drawings.
FIG. 1 is a configuration / function block diagram of the IC card system of this example.
The IC card system of this example basically comprises a higher-level device 10 and a card reader / writer 20 shown in the drawing (as will be described later, these may be collectively referred to as “card-using device”). Further, the IC card system of this example may be configured such that the higher-level device 10 is connected to an external device such as the management server 2 via the network 1 such as the Internet.

The management server 2 is a server device or the like of the IC card issuing / operating company described above. Therefore, the operation of the management server 2 will not be described in detail, but if it is briefly described, it manages various information (history etc.) related to IC card payment processing and encryption key (card access key etc.). In particular, the card access key may be upgraded, and the management server 2 distributes a new card access key such as the upgraded version to the host device 10 via the network 1. Alternatively, in the case of an operation mode in which the card access key is erased except when being operated on the card using device side, the card access key is periodically transferred to the host device via the network 1 (every time the card using device side starts operation). Deliver to 10.

  The host device 10 includes a CPU 11 that controls the operation of the entire device, a program memory 12 that stores a predetermined application program to be executed by the CPU 11, a data memory 13 that temporarily stores data being processed, and a card access key that is registered in advance. The key information storing secure memory 14 for storing various key information such as, the card reader / writer communication control unit 15 and the card reader / writer connection I / F 16 for communicating with the card reader / writer 20 by a reader / writer command, and the entire system are monitored. The network communication control unit 17 and the network communication I / F 18 for communicating with the management server 2 are configured.

  The card reader / writer 20 includes a CPU 21 that controls the operation of the card reader / writer 20 as a whole, a program memory 22 that stores a predetermined application program to be executed by the CPU 21, a data memory 23 that temporarily stores data being processed, An RF circuit 24 and an antenna 25 for performing contactless communication with the contactless IC card 3, a host device communication control unit 26 for communicating with the host device 10, a host device connection I / F 27, and the like. .

  The host device 10 and the card reader / writer 20 are connected by connecting the card reader / writer connection I / F 16 and the host device connection I / F 27, and the card reader / writer communication control unit 15 and the host device communication control unit 26 connect the host device. Communication between the 10 and the card reader / writer 20 is performed. The communication between the host device 10 and the card reader / writer 20 is communication by a reader / writer command as described above, but the communication between the card reader / writer 20 and the non-contact IC card 3 is communication by a card command. These will be described later.

  Here, the communication procedure with the non-contact IC card 3 is as follows. First, mutual authentication processing is performed as described in the above-mentioned conventional patent document 1 and the like, and when mutual authentication is successful, card access processing (read / write of card information). Etc.). The mutual authentication process is performed using a predetermined card access key registered in advance. The read / write process after successful mutual authentication is performed using a session key generated each time the mutual authentication process is performed.

  Here, in this method, the card reader / writer 20 does not hold the card access key. That is, the card access key is not registered in advance in the card reader / writer 20, and the host device 10 does not pass the card access key to the card reader / writer 20 when necessary.

  In this method, the card access key is registered in the host device 10. Thus, the host device 10 is protected by the tamper-resistant housing in order to prevent leakage of the card access key. Although the tamper resistant casing is not shown, the tamper resistant casing includes, for example, an unauthorized opening detection sensor of the casing. Further, the key information storing secure memory 14, which is a memory in which key information is stored, uses a secure memory (tamper resistant memory) in which a memory chip itself is provided with a tamper resistant function. In other words, strong security measures are taken. It should be noted that as a strong security measure method, it is not always necessary to use both a tamper-resistant housing and a tamper-resistant memory, and only one of them may be used.

  Although not shown, when an alarm is received from the tamper-resistant detection sensor of the case attached to the tamper-resistant case, the key information (especially card access stored in the key information storage secure memory 14) is received. It is desirable to have a function to delete keys.

On the other hand, with respect to the card reader / writer 20, the card access key is not registered in advance as described above, and the card access key is passed from the host device 10 and temporarily held only when communicating with the non-contact IC card 3. There is nothing to do. That is, the card access key is never held in the card reader / writer 20. Therefore, the card access key cannot be leaked from the card reader / writer 20. Further, it is not necessary to take a strong security measure against the leakage of key information (the tamper-resistant housing, the tamper-evident detection sensor, or the tamper-resistant memory) as in the host device 10.

  However, with respect to the card reader / writer 20, a key for mutual authentication with the host device 10 for temporarily storing a session key or for encrypting communication with the host device 10 in some cases is registered. However, although not shown, necessary and sufficient information leakage countermeasures are generally taken (prevention of analysis of circuit board by casing, encrypted storage of information, bus scramble processing, etc.). However, it is not necessary for the card reader / writer 20 to take strong security measures such as the tamper-resistant housing and the tamper-resistant memory.

  As described above, the card access key is held by the host device 10 and is not held by the card reader / writer 20 even temporarily. Thus, in this method, the host device 10 performs processing that requires the use of the card access key in a series of communication processing (session) with any one contactless IC card 3, that is, the mutual authentication processing. . However, since the host device 10 cannot directly communicate with the non-contact IC card 3, it is performed via the card reader / writer 20. The card reader / writer 20 includes a processing function unit (not shown) that relays packets transmitted and received between the host device 10 and the non-contact IC card 3 during the mutual authentication process.

  On the other hand, the data reading / writing processing of the IC card 3 after successful mutual authentication is performed by the card reader / writer 20 by passing the session key generated by the host device 10 to the card reader / writer 20.

  The program memory 12 of the host device 10 stores an application program for causing the CPU 11 to execute the mutual authentication process with the IC card 3 and the process of generating a session key and passing it to the card reader / writer 20. Yes. The program memory 22 of the card reader / writer 20 stores a card access process (data read / write process, etc.) using the session key and a process for relaying communication between the host device 10 and the IC card 3 (packet relay). An application program for causing the CPU 11 to execute (transfer processing) is stored.

  As described above, in the proposed method, the host device 10 holds the card access key, and does not deliver the card access key to the card reader / writer 20, but performs encrypted communication using the card access key. In the example, mutual authentication processing with the non-contact IC card 3) is performed. Further, communication with the IC card in the session after successful mutual authentication (communication for card access processing) is performed by encrypted communication using a session key.

  Here, the session key is a secret key for communication that is temporarily generated in both the IC card and the card-using device for each session, and is therefore limited to the session. This key cannot be used if the combination is different, and cannot be reused in the next and subsequent sessions if the session is interrupted even if communication is performed between the same IC card and the card-using device.

For this reason, even if the session key leaks because the security performance of the card reader / writer 20 is inferior to the case where strong security measures are taken, this is key information that is not worth using after the session ends. It becomes. In the worst case, even if it is possible to illegally take over the card access without interrupting the session, it will be performed only for one IC card used in the session. It is possible to avoid a situation such as a security collapse of the entire card system (not the meaning of the IC card system but the entire system managed by the management server 2) due to information leakage.

  Further, since the card reader / writer 20 performs the polling processing for capturing the IC card and the actual card access processing (read / write processing, etc.) for the IC card, the program processing load increase on the host device 10 side is increased. Can be suppressed.

The “card using device” here is “the upper device 10 + card reader / writer 20”.
In the case of this method, since there is no need to install a program for mutual authentication processing with an IC card in the card reader / writer 20, the card authentication algorithm leaks when the card reader / writer 20 is analyzed due to theft or the like. It is also possible to prevent this. Alternatively, even if it is necessary to support different authentication procedures and encryption specifications at the time of authentication for each of a plurality of card standards, the card reader / writer 20 does not need to be equipped with many corresponding functions.

  In general, for the generation of encryption information for authentication between the card and the device used by mutual authentication and the session key generation algorithm, a complicated encryption method that emphasizes safety is adopted even if it takes some time. However, the encryption of communication for subsequent card access using the generated session key is required to reduce the time by a relatively light process. In particular, in the case of a non-contact IC card, the communication is limited to the communication during a short session only while the IC card exists within a communicable distance with the card reader / writer 20, and the communication processing time is the card user. Therefore, in the encryption process using a session key, shortening the processing time tends to be regarded as important.

  In other words, the card access key and the authentication process using it are important information for authenticating with a large number of cards, so security measures are regarded as important. Encrypted communication that is limited to sessions using, requires handling with consideration for convenience.

  According to this method, the card access key can be prevented from leaking from the card reader / writer. Furthermore, it is not necessary to take strong security measures such as a tamper-resistant housing and tamper-resistant memory for the card reader / writer, and a cost reduction effect can be obtained. Further, regarding the card access process after the authentication process, the session key used for the card access process is passed to the card reader / writer, and the card reader / writer executes the card access process. Therefore, the relay process by the card reader / writer is not necessary. Therefore, it is possible to perform processing in a short time, without impairing the convenience for the card user, and to reduce the processing load on the host device.

Hereinafter, further details will be described with reference to FIG.
FIG. 2 is a schematic communication sequence example between the card using device and the IC card.
Note that the schematic sequence itself shown in FIG. 2 may be substantially the same as that of the prior art. Also, the processing content itself of the mutual authentication process shown in FIG. 3 to be described later may be substantially the same as in the prior art (however, as described above, the mutual authentication process has been executed by the card reader / writer 20 in the past, The method is executed by the host device 10).

In addition, as described above, the “card using device” is “the higher-level device 10 + card reader / writer 20” here, but the card reader / writer 20 physically communicates with the IC card.
It is. In this example, as shown in FIG. 1, a non-contact IC card 3 is shown as an example of an IC card. Therefore, the card reader / writer 20 is a non-contact IC card reader / writer. The method is not limited to this example, and the present technique can also be applied to an IC card system related to a contact IC card, for example. However, here, an IC card system related to the non-contact IC card 3 will be described as an example. In the following description, the non-contact IC card 3 may be simply referred to as an IC card 3 or the like.

  In addition, the “non-contact IC card” is not limited to a card type, and may be in the form of an IC tag or a wristband, or may be in the form of a mobile phone with a built-in IC card function, Therefore, here, the term “non-contact IC card” includes these various forms. As described above, the “IC card” means not only the “non-contact IC card” but also a contact IC card.

  As shown in FIG. 2, the card-using device periodically issues a card capture command, and a response to the card (card capture response) is returned from the IC card 3 to confirm the presence of the card. The card capture command and the card capture response may be plaintext communication and need not be encrypted.

  When the card using device receives the card capture response, the card using device performs a mutual authentication process using a card access key registered in advance. In the communication between the card using device and the IC card 3 related to the mutual authentication processing, as shown in the figure, the card using device first transmits a first mutual authentication command, and the first mutual authentication from the IC card 3 in response thereto. When the response is received, the second mutual authentication command is subsequently transmitted, and the second mutual authentication response from the IC card 3 is received.

The mutual authentication process is performed by encrypting and exchanging random numbers generated by both the card using device and the IC card 3 with the card access key, and confirming that the card access keys possessed by both are the same. Are mutually valid connection partners, and a detailed processing example thereof is described in the above-mentioned Patent Document 1 and the like, and will be described later with reference to FIG. If the authentication is OK, a session key for secretly encrypting subsequent communication is generated based on the exchanged random number in each of the card using device and the IC card 3.
Thus, the command / response for card data access after successful authentication (the card access command and the card access response shown in the figure) is encrypted by this session key and transmitted / received.

FIG. 3 is a diagram showing an example of the mutual authentication process. Here, as described above, an example of processing described in Patent Document 1 and the like is shown.
The illustrated process generally includes a card access key Ka that a random number RndA arbitrarily generated on the card using device side and a random number RndB arbitrarily generated on the IC card 3 side are included in both the card using device and the card. , Encrypted and exchanged by Kb. If both card access keys Ka and Kb are the same, the other party's generated random number will be returned from the other party, so check that the other party's card access key is the same as the card access key they own. Since the card access keys are the same, it is determined that the communication partners are valid communication partners.

  Specifically, first, the card using device generates a random number RndA (step S1), encrypts this RndA with its own card access key Kb to generate encrypted data [RndA] Kb (step S2), RndA] The first mutual authentication command including Kb is generated and transmitted (step S3).

  The IC card 3 that has received this first mutual authentication command obtains RndA by decrypting [RndA] Kb with its own card access key Kb (step S21), and stores this RndA in a memory or the like. (Step S22) The RndA is encrypted with its own card access key Ka to generate encrypted data [RndA] Ka (Step S23). Further, an arbitrary random number RndB is generated (step S24), and this RndB is encrypted with its own card access key Ka to generate encrypted data [RndB] Ka (step S25). Then, the first mutual authentication response including the generated [RndA] Ka and [RndB] Ka is generated and transmitted (step S26).

  Upon receiving the first mutual authentication response, the card using device first decrypts [RndA] Ka with its own card access key Ka (step S4), and generates the decrypted data in step S1 (step S1). Compared with (stored) RndA, it is determined whether or not they match (step S5). If they do not match, this processing is terminated as an authentication failure. If they match, then [RndB] Ka of the first mutual authentication response is decrypted with its own card access key Ka to obtain RndB (step S6), and this RndB is stored in its own memory or the like. At the same time (step S7), this RndB is encrypted with its own card access key Kb to generate encrypted data [RndB] Kb (step S8), and the second mutual authentication command including this [RndB] Kb is generated. (Step S9).

  The IC card 3 that has received the second mutual authentication command decrypts the [RndB] Kb with its own card access key Kb to obtain decrypted data (step S27). It is determined whether or not they match with the generated (stored) RndB (step S28). If they do not match, a mutual authentication NG response is transmitted as the second mutual authentication response (not shown), and this process ends. If they match, a mutual authentication completion (OK) response is transmitted as the second mutual authentication response (step S29), and RndA stored in step S22 and RndB generated (stored) in step S24. And generates a session key Ks (step S30).

  Similarly, when the mutual authentication completion response is received on the card-using device side, RndA generated (stored) in step S1 and stored (stored) in step S1 as having been successfully authenticated. A session key Ks is generated from RndB (step S10). The session key Ks can be generated by any method, but the session key Ks generated on the card using device side and the session key Ks generated on the IC card 3 side should be the same (for example, simply Ks = RndA + RndB etc. And).

  In this way, both the card using device and the IC card 3 generate the session key Ks from the random numbers RndA and RndB exchanged at the time of authentication processing, and the subsequent communication is encrypted by encrypting with the session key Ks. Done.

That is, thereafter, during the session period, encrypted communication is performed using the session key Ks generated in steps S10 and S30. That is, on the card using device side, the card access command is encrypted with the session key Ks generated in step S10 and transmitted. The IC card 3 that has received this command decrypts it using the session key Ks generated in step S30. Similarly, the card access response is encrypted and transmitted using its own session key Ks, and the card-using device decrypts this response using its own session key Ks.

As described above, since the session key is generated every time mutual authentication is performed between the card using device and the IC card, a different key is generated every time mutual authentication is performed. The key information is valid only after the mutual authentication is completed between the cards and before the IC card 3 is out of the communication range with the card reader / writer 20 and stops operating.

  Therefore, since encryption is performed with a different session key every time communication is performed with each IC card, an unauthorized operation that can be performed by unauthorized acquisition of the session key is performed within the period of the session in which the leaked key is used (1 Communication with one IC card). On the other hand, the card access key is generally common to all IC cards of the same type, and if the card access key is obtained illegally, the unauthorized operation is also performed on other IC cards of the same type as the IC card. (Serious manipulation may occur).

  For this reason, the risk of leakage is less for the session key than for the card access key. In this method, the session key is held in the card reader / writer 20 during the session period (communication period after successful authentication), but the card reader / writer 20 does not hold any card access key. Even if a strong countermeasure (such as tamper resistance) for the key information leakage as in the host device 10 is not applied to 20, the above-mentioned serious illegal operation can be prevented.

FIG. 4 is an example of a communication sequence between the host device, the card reader / writer, and the IC card according to this method.
Although not shown or described in particular, mutual authentication is performed between the host device 10 and the card reader / writer 20 as a process preceding the execution of the illustrated communication sequence, and subsequent reader / writer command communication (the host device 10). -Communication between the card reader / writer 20) may be performed encrypted.

  In the communication sequence example and packet configuration example, the ACK / NACK packet is not mentioned, but there are cases where it is given according to the communication specifications and cases where it is not necessary. Is not particularly relevant, either of which may be used and will not be described in particular.

Further, communication between the host device 10 and the card reader / writer 20 is performed by a reader / writer command, and communication between the card reader / writer 20 and the IC card is performed by a card command. A packet configuration example of the card command is shown in FIG. 5A, and a packet configuration example of the reader / writer command is shown in FIG. 6A. These will be described later.
In FIG. 4, first, the communication processing related to card capture may be the same as that in the prior art.

  That is, the host device 10 transmits a card capture command based on the reader / writer command to the card reader / writer 20 when starting communication with the IC card. When receiving the card capture command, the card reader / writer 20 continuously transmits a card capture command based on the card command.

  When the IC card is a contactless IC card 3, when the IC card 3 enters the communicable range of the card reader / writer 20, the IC card 3 that has received the card capture command by the card command sends a card capture response by the card command to the card. A reply is sent to the reader / writer 20. The card reader / writer 20 that has received the card capture response from the IC card 3 transmits a card capture response based on the reader / writer command to the higher-level device 10.

In this example, the card reader / writer 20 that has received the card capture command (reader / writer command) from the host device 10 sends the card capture command (card command) multiple times until the response from the IC card 3 is returned. Although it continues to transmit, a card command may be issued only once in response to one reader / writer command reception. Such a process for transmitting a corresponding card command only once for a single reader / writer command, or a process for transmitting multiple times or a combination of multiple types of commands, is mounted on the card reader / writer. It does not affect the essence of the present invention.

  In the following explanation, explanations such as “by reader / writer command” and “by card command” will not be given one by one. However, as described above, communication between the host device 10 and the card reader / writer 20 is not performed. All communication is performed by a reader / writer command, and all communication between the card reader / writer 20 and the IC card is performed by a card command.

  The host device 10 that has successfully captured the card performs mutual authentication processing with the captured IC card 3 via the card reader / writer 20. The host device 10 uses the card access key held by itself to perform mutual authentication processing with the IC card 3 according to the procedure shown in FIG.

  At this time, the card reader / writer 20 exists between the higher level device 10 and the IC card 3. For example, the card reader / writer 20 changes the reader / writer command to the card command in response to the mutual authentication command from the higher level device 10. Conversion and parameter part (especially encrypted data; for example, [RndB] Kb etc.) are relayed, but without being involved in the parameter part itself (without conversion or the like), the operation is directly transferred to the IC card 3 To do. Similarly, when the mutual authentication response is received from the IC card 3, the card reader / writer 20 performs conversion from the card command to the reader / writer command and relays the parameter portion. An operation of handing over to the higher-level device 10 is executed. These will be described in detail later.

  By performing such an operation, it is possible to execute the mutual authentication process between the host device 10 and the IC card 3 even if the card reader / writer 20 does not hold the card access key. In particular, since the card access key is not passed to the card reader / writer 20, only the random number encrypted with the card access key is exchanged between the IC card 3 and the host device 10 via the card reader / writer 20. There is no risk of the card access key leaking from the reader / writer 20.

  As already described in FIG. 3, the “mutual authentication command from the host device 10” is the first mutual authentication command and the second mutual authentication command shown in FIG. The card 3 sends back the first mutual authentication response and the second mutual authentication response shown in the figure.

  Generally, when value information such as electronic money is stored in a contactless IC card and used for payment processing, the IC card user pays his IC card to the card reader / writer 20 (touches) for payment. Since the processing is performed, the card reader / writer 20 is often placed in a place where a customer can easily reach, such as the cash register. Furthermore, the card reader / writer 20 is usually very small compared to at least the host device 10. On the other hand, the host device 10 is, for example, a POS cash register terminal, which is a larger device than the card reader / writer 20 and has a function of storing money, so that measures against theft may be taken. It is common. Further, unlike the card reader / writer 20, it is not necessary for the IC card user to operate, so that it can be installed in a place where the IC card user cannot see. Thus, the card reader / writer 20 is more likely to be stolen than the host device 10.

Conventionally, both the host device 10 and the card reader / writer 20 have been provided with strong security measures such as a tamper-resistant housing and a tamper-resistant memory. However, if the card reader / writer 20 is stolen, the card reader / writer There is a possibility that the card access key is leaked from 20 (the possibility is not 0 because it is held inside). On the other hand, in this method, since the card reader / writer 20 does not hold the card access key (even temporarily), even if the card reader / writer 20 is stolen, the card reader / writer 20 does not hold the card access key. There is no possibility of leakage. Furthermore, in this method, since it is not necessary to apply the above-mentioned strong security measures to the card reader / writer 20, the cost reduction effect regarding the card reader / writer 20 can also be obtained.

  In the configuration example shown in FIG. 1, one card reader / writer 20 is connected to one host device 10 (one-to-one relationship), but the present invention is not limited to this example. A plurality of card reader / writers 20 may be connected to the higher-level device 10 (one-to-many relationship). In the case of such a configuration, conventionally, it has been necessary to take a strong security measure for each of a plurality of card reader / writers 20, but this method is not necessary, so the cost reduction effect described above can be achieved. Even more noticeable. Furthermore, since the session key after mutual authentication is delivered to the card reader / writer 20, even when a plurality of card reader / writers 20 are controlled by a single higher-level device 10, the processing load of the higher-level device 10 can be reduced. It is remarkable.

  As for the higher level device 10, the management server 2 may distribute a new card access key to the higher level device 10 via the network 1 due to version upgrade or expiration of the card access key. For this reason, even if the card reader / writer holds the card access key as in the conventional case, the card access key is present in the host device at the time of the above distribution, and therefore, the tamper resistant against the host device. Strong security measures such as a case and tamper-resistant memory were taken.

  Thus, in the past, it was necessary to take strong security measures for both the host device and the card reader / writer, but according to this method, such measures are not necessary for the card reader / writer.

The description of FIG. 4 is continued.
The host device 10 performs mutual authentication processing with the IC card 3 by the above-described operation, and when mutual authentication is successful (case 1) or before (case 2), the mutual authentication processing is obtained. The session key Ks is generated based on random numbers (RndA, RndB). Then, the generated session key Ks is transmitted to the card reader / writer 20.

  That is, in the case 1 described above, when the mutual authentication is successful, the host device 10 generates the session key Ks and includes it in the session key set command shown in FIG. 4 and transmits it to the card reader / writer 20. Upon receiving this, the card reader / writer 20 returns a session key set response for notifying that the session key Ks has been normally received / set.

  On the other hand, when the method of case 2 is used, the session key set command / response is not transmitted / received. Instead, the second mutual authentication command is transmitted including the session key Ks. That is, in case 2, at the stage of transmitting the second mutual authentication command in the middle of the mutual authentication process, the higher-level device 10 generates a session key Ks and passes it to the card reader / writer 20. In this case, although the mutual authentication success is not yet confirmed, the session key Ks is generated and delivered to the card reader / writer 20 on the assumption that the mutual authentication is successful. Therefore, if the mutual authentication fails thereafter (for example, when the IC card 3 does not return an authentication success response to the second mutual authentication command), the delivered session key becomes invalid.

The host device 10 that has passed the session key Ks to the card reader / writer 20 by either of the above methods 1 and 2 and confirmed that the card is a valid card by the success of the mutual authentication, reads the data from the IC card 3 and the IC In order for the card reader / writer 20 to execute card access processing such as data write to the card 3, the card access command (read command, write command, etc.) shown in FIG. 4 is transmitted to the card reader / writer 20.

  The card reader / writer 20 that has received the card access command encrypts the card access command to the IC card 3 using the session key Ks obtained from the higher-level device 10 by any one of the methods described above. Here, when the mutual authentication is successful, the session key Ks based on the random number (the RndA and RndB) can be generated on the IC card 3 side as well as the host device 10. Thus, the IC card 3 that has received the card access command decrypts it using its own session key Ks. Then, processing corresponding to this card access command is executed (reading data from a specified area or writing data to a specified area), and based on the processing result, further using its own session key Ks , Generate and send an encrypted card access response. Receiving this, the card reader / writer 20 decrypts this card access response using its own session key Ks.

  As described above, the card reader / writer 20 uses the session key Ks for card access processing such as data read from the IC card 3 or data write to the IC card 3 in accordance with an instruction from the host device 10. Execute by encrypted communication.

  In the example shown in FIG. 4, the card reader / writer 20 generates and transmits one card command in response to one reader / writer command from the higher-level device 10, but the present invention is not limited to this example. For example, by registering a plurality of types of card commands for one reader / writer command in advance in the card reader / writer 20, the card reader / writer 20 can output a plurality of types of card commands corresponding to the received reader / writer command. Alternatively, the information may be sequentially transmitted to the IC card 3.

  In the case of the above configuration, for example, the card access command transmitted by the host device 10 shown in FIG. 4 does not mean the above-described read command or write command, but literally means “card access command”. The card reader / writer 20 that has received this can consider processing such as continuously executing transmission of a read command (not shown) and reception of a response thereof, and transmission of a write command and reception of the response thereof.

  FIG. 5A shows a packet configuration example of the “card command”. That is, this is a configuration example of a packet used for communication between the card reader / writer 20 and the IC card 3. Note that the present invention is not limited to this configuration example, and usually has a configuration conforming to the communication standard of the IC card to be used.

  A card command packet 30 shown in FIG. 5A includes a preamble part 31 for synchronizing communication timing of communication data, a synchronization code part 32 for detecting the head part of the packet, and data indicating the data amount of the card command. A length 33, a card command unit 34 in which various command data / response data to be actually exchanged between the card reader / writer 20 and the IC card 3 are stored. In order to confirm whether packet data has not changed due to noise or the like during communication. The check code 35, the postamble part 36 added at the end of communication, and the like.

  Various commands / responses transmitted / received between the card reader / writer 20 and the IC card 3 shown in FIG. 4 are represented as command data / response data stored in the card command section 34 in the card command packet 30 as shown in FIG. Any one of the various command data / response data shown in (i) is stored.

For example, the “card capture command” transmitted from the card reader / writer 20 shown in FIG. 4 to the IC card 3 is sent to the card command section 34 in the card command packet 30 as shown in FIG.
The card capture command 40 shown in (b) is stored. The same applies to other various commands / responses, which will be described in the following description of FIGS. 5C to 5I. However, although not described one by one, none of them are in communication between the card reader / writer 20 and the IC card 3. Command / response.

Hereinafter, configuration examples of various command data / response data shown in FIGS. 5B to 5I will be described. In addition, these structural examples are examples and are not limited to this example.
First, the card capture command 40 shown in FIG. 5 (b) is a command code indicating a command type (here, a card capture command / command code 41) and parameters for designating the attribute type of the IC card 3 to be captured. It consists of a certain command parameter 42 and the like.

  The command parameter 42 is a parameter that is specified to narrow down the IC cards 3 to be responded from the beginning by, for example, specifying the card type to be captured in advance. In the case of targeting a non-contact IC card, in addition to this parameter, designation of the number of response time slots for responding to simultaneous responses from a plurality of IC cards may be included. The detailed explanation is omitted because it does not affect the essence.

  The card capture response shown in FIG. 4, which is a response from the IC card 3 to the card capture command, is stored in the card command packet 34 in the card command portion 34 as shown in FIG. Is.

  The card capture response 50 shown in FIG. 5C is composed of a response code (card capture command response code 51) indicating a card capture response and a card ID 52. The card ID is an identification code that is uniquely set and stored for each IC card 3 in advance, and the card ID 52 is the card ID of the IC card 3 itself that is the transmission source of the card capture response 50 packet. The card ID 52 is assigned to allow the IC card 3 responding to the card capture command to identify itself, and designates the IC card 3 that is the target of mutual authentication when the host device 10 performs mutual authentication with the IC card 3. (For example, this card ID 52 is an authentication destination card ID 62 described later).

  The first mutual authentication command shown in FIG. 4 is obtained by storing the first mutual authentication command 60 shown in FIG. 5D in the card command part 34 in the card command packet 30.

  The first mutual authentication command 60 shown in FIG. 5D includes a command code indicating the command type (here, the first mutual authentication command / command code 61), and an authentication destination card ID 62 for designating the IC card 3 to be mutually authenticated. Authentication condition information 63 indicating the conditions for authenticating with the IC card 3, and encrypted data A64 for authentication (in the example of FIG. 3, [RndA] Kb (data obtained by encrypting the random number RndA with the card access key Kb)) It is composed of

  The authentication condition information 63 is a parameter for designating what information of the IC card 3 is to be authenticated when mutual authentication with the IC card 3 is performed. For example, which service block in the card is accessed This is data for designating whether to perform authentication for

The first mutual authentication response shown in FIG. 4 is obtained by storing the first mutual authentication response 70 shown in FIG. 5E in the card command part 34 in the card command packet 30.
The first mutual authentication response 70 shown in FIG. 5 (e) is a response code (first mutual authentication command response code 71) indicating that it is a response to the first mutual authentication command, and encrypted data B for authentication.
72 ([RndA] Ka in the example of FIG. 3 (data obtained by encrypting the random number RndA with the card access key Ka)) and encrypted data C73 for authentication ([RndB] Ka in the example of FIG. 3 (card access to the random number RndB) Data encrypted with key Ka)).

  Although not shown, the card ID 52 may also be included in the first mutual authentication response 70 and the second mutual authentication response 90 described later. Similarly, the second mutual authentication command 80 described later may include the authentication destination card ID 62 (not shown).

  The second mutual authentication command shown in FIG. 4 is obtained by storing the second mutual authentication command 80 shown in FIG. 5 (f) in the card command part 34 in the card command packet 30.

  The second mutual authentication command 80 shown in FIG. 5 (f) includes a command code indicating a command type (here, the second mutual authentication command / command code 81), authentication encrypted data D82 ([RndB] in the example of FIG. 3). Kb (data obtained by encrypting the random number RndB with the card access key Kb)).

The second mutual authentication response shown in FIG. 4 is obtained by storing the second mutual authentication response 90 shown in FIG. 5G in the card command part 34 in the card command packet 30.
The second mutual authentication response 90 shown in FIG. 5G shows a response code (second mutual authentication command response code 91) indicating that the response is for the second mutual authentication command, and an authentication result by the IC card 3 (authentication). OK / NG etc.) authentication result data 92 etc.

  The card access command shown in FIG. 4 (here, it is assumed that it is a card read command) is the card command packet 30 in which the card access command 100 shown in FIG. It is.

  A card access command 100 (card read command example) shown in FIG. 5 (h) includes a command code indicating a command type (card read command / command code 101), read target portion specifying information 102 for specifying a read target, and the like. It is configured. This designation information 102 is information for designating which information in the IC card 3 is to be read, and designates, for example, the block number of the block to be read in the memory in the card. It should be noted that other than the command code is generally encrypted and concealed with a session key. Therefore, the read target part designation information 102 is encrypted data encrypted with the session key Ks.

  A configuration example of a card access response 110 that is a response to the card access command 100 shown in FIG. 5 (h) is shown in FIG. 5 (i). The illustrated card access response 110 is stored in the card command unit 34 in the card command packet 30.

  The card access response 110 shown in FIG. 5 (i) is a response code (card read command / response code 111) indicating that it is a response to the card read command, and read data 112 that is data read from the IC card 3. Etc. As in the case of the card access command, other than the response code is generally encrypted by a session key and kept secret. Therefore, the read data 112 is encrypted data obtained by the IC card 3 encrypting the read data with its own session key Ks.

FIG. 6A shows a packet configuration example of the “reader / writer command”. That is, this is a configuration example of a packet used for communication between the card reader / writer 20 and the host device 10. Note that the present invention is not limited to this configuration example. In general, the card reader / writer 20 and the host device 10 are not limited.
A packet configuration suitable for the communication interface standard is applied.

  The reader / writer command packet 120 in the example shown in FIG. 6A indicates a preamble portion 121 for synchronizing communication timing of communication data, a start code portion 122 indicating the head portion of the packet, and a data amount of the reader / writer command. Data length 123, reader / writer command unit 124 storing various command data / response data to be exchanged between the host device 10 and the card reader / writer 20, and whether packet data has not changed due to noise during communication For example, a check code 125, a postamble unit 126 added at the end of communication, and the like.

  Here, the conversion from the card command to the reader / writer command by the card reader / writer 20 is the conversion from the packet configuration shown in FIG. 5 (a) to the packet configuration shown in FIG. 6 (a). Similarly, the conversion from the reader / writer command to the card command by the card reader / writer 20 is the conversion from the packet configuration shown in FIG. 6 (a) to the packet configuration shown in FIG. 5 (a).

  With regard to this conversion processing, the card reader / writer 20 originally communicated with the IC card 3 in the format shown in FIG. 5A, and similarly with the host device 10 as shown in FIG. 6A. Since communication is performed using a format packet, for example, when a packet of the format shown in FIG. 5A is received from the IC card 3, the content data is transmitted to the host device 10 using the packet of the format shown in FIG. 6A. That's fine. The content data is, for example, the data length 33 and the card command section 34, and these may be stored as the data length 123 and the reader / writer command section 124. However, it is not limited to this example. In particular, the part other than the command code / response code in the card command part 34 / reader / writer command part 124 may be referred to as a parameter part. Alternatively, in particular, the encrypted data portion may be referred to as a parameter portion.

  Even in the same command / response, the command code / response code in the card command unit 34 and the command code / response code in the reader / writer command unit 124 are not always the same. / Response code conversion is also performed.

  For example, taking the card capture commands 40 and 130 shown in FIGS. 5B and 6B as an example, the code 41 indicating the card capture command in the “card command” is, for example, “01”, and the “reader / writer command” The code 131 indicating the card capture command may be different even for the same “card capture command”, such as “0012”. Since codes indicating various commands / responses are determined in advance for each of the “card command” and “reader / writer command”, the card reader / writer 20 stores them in association with each other (in the above example, , “01” and “0012” are stored for the card capture command), and the command code / response code can be converted.

  Various commands / responses transmitted / received between the card reader / writer 20 and the host device 10 shown in FIG. 4 are stored as command data / response data stored in the reader / writer command section 124 in the reader / writer command packet 120 as shown in FIG. Any one of various command data / response data shown in FIGS. 7B to 7F and FIGS. 7A to 7F is stored.

For example, the “card capture command” transmitted from the host device 10 shown in FIG. 4 to the card reader / writer 20 is sent to the reader / writer command unit 124 in the reader / writer command packet 120 by the card capture command 130 shown in FIG. It is stored. The same applies to other various commands / responses, and will not be particularly described here. Also,
Although not described one by one, the various command data / response data shown in FIGS. 6B to 6G and FIGS. 7A to 7F are all packets in communication between the card reader / writer 20 and the IC card 3. Various command data / response data in 120.

  Hereinafter, configuration examples of various command data / response data shown in FIGS. 6B to 6G and FIGS. 7A to 7F will be described. In addition, these structural examples are examples and are not limited to this example.

  First, a card capture command 130 shown in FIG. 6B includes a command code indicating a command type (here, a card capture command / command code 131), a command parameter 132 for designating an attribute type of an IC card to be captured, and the like. It is composed of

  As shown in the figure, this configuration example has the same configuration as the card capture command 40 of the card command described above. The same applies to other various commands / responses. That is, the reader / writer command having the same command name as the card command has a configuration similar to that of the card command. However, the configuration is not limited to this example, and the configuration may be different (not only the command code / response code as described above is different, but the configuration itself is different).

  In the present example, because of the above, the configuration examples of various command data shown in FIGS. 6B to 6G and FIGS. 7A to 7F have the same configuration regarding the “card command”. Has already been described with respect to the above-mentioned “card command”, and therefore only a brief description will be given here without detailed description.

  A card capture response 140 shown in FIG. 6C is returned from the IC card 3 responding to the card capture command 130. As an example of the configuration, a response code (card capture command response code indicating a card capture response) is shown. 141), and the card ID 142 of the IC card itself.

  The first mutual authentication command 150 shown in FIG. 6D includes a command code indicating a command type (here, a first authentication command / command code 151), an authentication destination card ID 152 for designating an IC card to be mutually authenticated, an IC It comprises authentication condition information 153 which is a condition for authenticating with a card, and authentication encrypted data A154 ([RndA] Kb in the example of FIG. 3).

  The first mutual authentication response 160 shown in FIG. 6E is a response code (first authentication command response code 161) indicating that it is a response to the first mutual authentication command, and encrypted data B162 for authentication (example of FIG. 3). [RndA] Ka, etc.) and authentication encrypted data C163 ([RndB] Ka, etc. in the example of FIG. 3).

  The second mutual authentication command 170 shown in FIG. 6F includes a command code indicating the command type (here, the second authentication command / command code 171), and authentication encrypted data D172 ([RndB] Kb in the example of FIG. 3). Etc.). Further, in case 2 described above, the illustrated session key 173 is also included.

  The session key 173 is generated based on the random number RndA and the random number RndB as described above. That is, the host device 10 generates a session key Ks from the random number RndA generated by itself and the random number RndB acquired from the IC card 3 and delivers it to the card reader / writer 20. In case 2 as described above, Since the process is performed before the mutual authentication process is completed, the session key Ks is added to the second mutual authentication command 170.

  In both cases 1 and 2, there is a possibility that the session key 173 may be leaked in the middle of transmission from the higher-level device 10 to the card reader / writer 20. In some cases, a process such as encryption is added for this purpose, but since this is not particularly relevant to the present invention, the method of the concealment process is not specified / explained.

  The second mutual authentication response 180 shown in FIG. 6G is a response code (second authentication command response code 181) indicating a response to the second mutual authentication command, and an authentication indicating the authentication result on the IC card 3 side. It consists of result data 182 (data corresponding to OK / NG, etc.).

  Parameter parts (parts other than the command code / response code part (especially encrypted data) given to the first mutual authentication command 150, the first mutual authentication response 160, the second mutual authentication command 170, and the second mutual authentication response 180. )) Is basically added to the “card command” as it is as the parameter portion of the “card command” as described above by the command relay process of the card reader / writer 20 and transmitted to the IC card 3 (similarly). The parameter part assigned to the response by the “card command” from the IC card 3 is added to the parameter part of the “reader / writer command” as it is).

  However, in the case where the second mutual authentication command 170 has the session key 173, the session key 173 is stored and stored by the card reader / writer 20, and is not given to the "card command" to the IC card 3.

  On the other hand, in the case 1 described above, the session key Ks is not delivered to the card reader / writer 20 within the communication during mutual authentication, so no session key information is given to the parameter part of the second mutual authentication command. Instead, the session key Ks is delivered from the higher-level device 10 to the card reader / writer 20 by the session key set command described in FIG.

FIG. 7A shows a configuration example of a session key set command, and FIG. 7B shows a configuration example of a session key set response that is a response to the command.
The session key set command 190 in the example shown in FIG. 7A includes a command code indicating a command type (here, a session key set command / command code 191), and a session key (key information 192) to be delivered to the card reader / writer 20. It is configured.

  As already described, the illustrated session key set command 190 is stored in the reader / writer command section 124 of the reader / writer command packet 120 and transmitted and received (this will be described later with reference to FIGS. 7B to 7B). The same applies to each command / response in FIG. Further, the key information 192 may be a session key concealed (encrypted), but the concealment processing of the key information 192 is the case of the session key 173 of the second mutual authentication command 170. Similarly, the method of concealment processing is not particularly specified / explained.

  The session key set response 200 in the example shown in FIG. 7B is a response code (session key set command response code 201) indicating that it is a response to the session key set command, and whether or not the session key has been successfully delivered. The result data 202 and the like corresponding to OK / NG are shown.

Two examples of the configuration of the card access command and card access response as the reader / writer command shown in FIG. 4 are shown in FIGS. 7 (c) to 7 (f). 7C and 7D are configuration examples of the card access command and the card access response (part 1), and FIGS. 7E and 7F are configuration examples of the card access command and the card access response ( Part 2).

First, a configuration example (No. 1) shown in FIGS. 7C and 7D will be described.
This configuration example (part 1) is an example in which the card access command is a card read command for reading data from the IC card 3.

  A card access command (1) 210 (card read command example) shown in FIG. 7C is a command code indicating a command type (here, a card read command / command code 211) and information for designating a reading target. It consists of read target part designation information 212 and the like.

  A card access response (1) 220 (card read command example) shown in FIG. 7C, which is a response to the host device 10 in response to the command 210, is a response indicating that it is a response to the card read command 210. Code (card read command response code 221 and read data 222 read from the IC card. The read data 222 is read data 112 which is encrypted data by the session key, and is read from the card reader / writer. 20 is obtained by decrypting with its own session key.

Next, a configuration example (No. 2) shown in FIGS. 7E and 7F will be described.
This configuration example (No. 2) is an example in which the card access command is a card write & read command as a command when the card reader / writer 20 processes a plurality of card commands for one reader / writer command. is there. This card write & read command is a process for writing data to the information (address, etc.) specified by this command in the IC card 3, a process for reading back the part that was written after the writing was completed, and the data read back. Is a processing command for causing the card reader / writer 20 to execute a process of returning the message to the host device 10.

  A card access command (2) 230 (card write & read command example) shown in FIG. 7E is a command code indicating a command type (here, a card write & read command / command code 231), a card for writing and reading back. It includes write & read target portion designation information 232 indicating the information part (address, etc.), write data 233 which is data to be written, and the like.

  Further, the card access response (2) 240 (example of card write & read command) shown in FIG. 7 (f), which is a response to the command 230 for the command 230, is a response to the card write & read command. A response code (card write & read command response code 241), read-back data 242 as read data read back from the IC card, and the like.

  The card reader / writer 20 that has received the command 230 sequentially generates and transmits to the IC card 3 packets (“card command” packet 30) for executing the various processes. That is, first, a packet 30 in which the designation information 232 and the write data 233 are added as parameters to the card write command is generated / transmitted, and subsequently, a packet 30 in which the designation information 232 is assigned as a parameter to the card read command By transmitting, the written data is read back. Then, the card reader / writer 20 obtains the read-back data 242 by decrypting the read-back data (encrypted with the session key) returned from the IC card 3 with its own session key. Is added to the card access response (2) 240 and transmitted to the host device 10.

  Note that the reader / writer command example for executing the plurality of card commands is not limited to this example, and various combinations and addition of determination processing by the card reader / writer 20 are conceivable.

Here, FIGS. 8 to 11 illustrate differences between the above-described technique and the prior art by showing communication sequence examples and packet configuration examples in the prior art.
Although not particularly shown, the upper device and the card reader / writer in the prior art are given reference numerals 4 and 5 respectively, and are hereinafter referred to as the upper device 4 and the card reader / writer 5. Since the IC card itself may be the same, it is described as an IC card 3.

  As described above, conventionally, not only the host device 4 but also the card reader / writer 5 is provided with the same strong security measures (tamper-resistant housing, tamper-resistant memory, etc.) as the host device 4. Then, the card access key is stored in the tamper resistant memory in the card reader / writer 5. This may be registered in advance and stored, or may be transferred from the host device 4 and temporarily stored. In any case, conventionally, the card reader / writer 5 executes mutual authentication processing with the IC card 3 using this card access key.

FIG. 8 is an example of a communication sequence in the conventional example (part 1).
The conventional example (No. 1) is a sequence example when the card access key is registered in the card reader / writer 5.

  The conventional example (No. 2) described later is an example in which the card access key is not temporarily registered in the card writer 5, but the card access key is temporarily transferred from the host device 4 when necessary.

In the communication sequence of the conventional example (part 1), as shown in FIG. 8, the card capture may be substantially the same as the present method shown in FIG. 4 and will not be described here.
At the time of mutual authentication with the IC card 3, the card reader / writer 5 executes the process of FIG. That is, for example, a card command, random number generation necessary for mutual authentication, generation of encrypted data, and the like are performed. Further, the card reader / writer 5 also executes determination of response contents from the IC card 3 (in this case, decryption of encrypted data) and generation of a session key as internal processing. Only the success / failure result is notified to the host device 4 as a result of mutual authentication.

  In the example shown in FIG. 8, the command / response transmitted / received between the host device 4 -card reader / writer 5 or between the card reader / writer 5 -IC card 3 in the example shown in FIG. Send a mutual authentication command to Upon receiving this command, the card reader / writer 5 first generates a first mutual authentication command and transmits it to the IC card 3. When the first mutual authentication response from the IC card 3 is received, When a mutual authentication command is generated and transmitted to the IC card 3 and a second mutual authentication response from the IC card 3 is received, a mutual authentication response including the response content (success / failure result) is generated and the upper device 4 Send to.

  Since the card reader / writer 5 holds the card access key as described above, the generation and decryption of the encrypted data related to the processing at the time of the mutual authentication are performed using this card access key.

  The mutual authentication process is performed, for example, by the process shown in FIG. 3 described above. In the conventional example (part 1), the card reader / writer 5 executes all the processes of the card using device shown in FIG. The processing on the IC card 3 side is as shown in FIG. 3 and may be the same as this method.

  If the authentication is successful as a result of the mutual authentication process, the card reader / writer 5 can generate the session key for the card access process by the subsequent card access command. The card reader / writer 5 executes card access processing (read / write of card data, etc.) in the same sequence as this method using the session key generated by itself. To do.

FIG. 9A is a packet configuration example of a reader / writer command used for communication between the host device 4 and the card reader / writer 5 in the conventional example (part 1).
The illustrated reader / writer command packet 250 includes a preamble 251, a start code 252, a data length 253, a reader / writer command unit 254, a check code 255, and a postamble 256. Thus, the packet configuration itself may be the same as the reader / writer command packet 120 of the present technique shown in FIG. Although not particularly shown, the card command packet in the conventional example (part 1) may be the same as the card command packet 30 of the present method shown in FIG.

  Here, regarding the card command packet, the configuration of the card command section 34 may be the same as that of the present method. That is, it may be the same as the structure of the said FIG.5 (b)-(i).

  On the other hand, regarding the reader / writer command packet 250, the configuration of the reader / writer command unit 254 may be different from that of the reader / writer command unit 124 of the present method, and this will be described with reference to FIGS. explain.

FIGS. 9B to 9G are configuration examples of various command data / response data stored in the reader / writer command unit 254.
First, the card capture command 260 shown in FIG. 9B includes a card capture command / command code 261 and a command parameter 262, and the card capture response 270 shown in FIG. 9C includes a card capture command / response code 271 and a card ID 272. Consists of. As described above, the card capture may be the same as the configuration shown in FIGS. 6B and 6C of the present method.

The difference from the configuration example of this method is basically the part related to the mutual authentication command.
That is, in this method, since the card access key is registered in the host device 10 and is not passed to the card reader / writer 20, random number generation necessary for mutual authentication with the IC card 3 and card access key for the generated random number are used. The higher-level device 10 executes the encryption process and the like by the higher-level device 10, and the higher-level device 10 transmits and receives packets including the command / response shown in FIGS. 6 (d) to 6 (g).

  On the other hand, in the case of the conventional example (part 1), the card access key is registered in the card reader / writer 5 as shown in the description of FIG. The card and the authentication condition are specified, the start of mutual authentication is instructed, and the result of mutual authentication success / failure is simply received from the card reader / writer 5. That is, the mutual authentication command described in FIG. 8 is generated and transmitted, and the mutual authentication response is received.

FIG. 9D shows a configuration example of the mutual authentication command. The illustrated mutual authentication command 280 includes a command code indicating a command type (in this case, a mutual authentication command / command code 281), an authentication destination card ID 282 for designating an IC card as a mutual authentication target, and an optional for authentication with the IC card. Authentication condition information 283, which is the above condition. As described above, since the host device 4 cannot generate encrypted random number data for authentication, the command 280
No encrypted random number data is assigned as a parameter.

  The mutual authentication response 290 shown in FIG. 9E is a response code (mutual authentication command / response code 291) indicating that it is a response to the mutual authentication command, and authentication result data 292 indicating an authentication result (OK / NG; success / failure). It is composed of

  The configuration examples of the card access command 300 (read command) and the card access response 310 shown in FIGS. 9 (f) and 9 (g) are the same as the configurations of FIGS. 7 (c) and (d) of the present method. . Although not specifically shown, the same applies to the write command. The card access command 300 shown in FIG. 9F includes a card read command / command code 301 and read target portion designation information 302. A card access response 310 shown in FIG. 9G includes a card read command response code 311 and read data 312.

FIG. 10 is an example of a communication sequence in the conventional example (part 2).
Here, only the difference from the communication sequence of the conventional example (part 1) of FIG. 8 will be described.

  As described above, in the conventional example (No. 2), the card access key is registered in the higher-level device 4, but the card access key is passed to the card reader / writer 5 before starting communication with the IC card. is there.

  That is, as shown in FIG. 10, the upper device 4 transmits a card access key set command to which the card access key held by itself is added to the card reader / writer 5 before transmitting the card capture command. Upon receiving this set command, the card reader / writer 5 acquires the card access key, stores it in its own memory (tamper resistant memory), and returns a card access key set response. The subsequent communication sequence is the same as that of the conventional example (part 1).

  FIGS. 11A and 11B show configuration examples of the card access key set command and the card access key set response. Of course, these commands / responses are stored in the packet reader / writer command section 254 shown in FIG. Other commands / responses are the same as those in the conventional example (No. 1) and have already been described with reference to FIGS. 9B to 9G, and therefore are not particularly illustrated or described here.

  A card access key set command 320 shown in FIG. 11A includes a command code indicating a command type (here, an access key set command / command code 321) and key information 322 which is a card access key to be passed to the card reader / writer 5. Consists of. As for the concealment of the key information 322, the detailed method is not mentioned as in the concealment of the session key in this method.

  The card access key set response 330 shown in FIG. 11B is a response code (access key set command / response code 331) indicating that it is a response to the card access key set command, and whether or not the card access key has been successfully stored. This is composed of result data 332 corresponding to OK / NG.

In this method, since the card access key is not passed to the card reader / writer, naturally, the process for generating / transmitting / receiving the command 320 and the response 330 as described above is not necessary.
As described above, according to this method, first, it is possible to prevent the card access key from leaking from the card reader / writer. Furthermore, it is not necessary to take strong security measures such as a tamper-resistant housing and tamper-resistant memory for the card reader / writer, and a cost reduction effect can be obtained. Further, regarding the card access process after the authentication process, the session key used for the card access process is passed to the card reader / writer, and the card reader / writer executes the card access process, which impairs the convenience of the card user. And the processing load on the host device can be reduced.

It is a structure and functional block diagram of the IC card system of this example. It is an example of a schematic communication sequence between a card utilization apparatus and an IC card. It is a figure which shows an example of a mutual authentication process. It is an example of a communication sequence by this method. (A)-(i) are various structural examples regarding a card command. (A)-(g) is the various structural examples (the 1) regarding a reader / writer command. (A)-(f) is the various structural examples (the 2) regarding a reader / writer command. It is a figure for demonstrating the example of a communication sequence in a prior art example (the 1), and explaining the difference with this method. It is a figure for demonstrating the packet structure example etc. of a prior art example (the 1), and demonstrating the difference with this method. It is a figure for demonstrating the example of a communication sequence in a prior art example (the 2), and demonstrating the difference with this method. It is a figure for demonstrating the example of command structure of a prior art example (the 2), etc., and demonstrating the difference with this method.

Explanation of symbols

1 Network 2 Management Server 3 Contactless IC Card 10 Host Device 11 CPU
12 Program memory 13 Data memory 14 Secure memory for storing key information 15 Card reader / writer communication control unit 16 Card reader / writer connection I / F
17 Network communication control unit 18 Network communication I / F
20 Card reader / writer 21 CPU
22 Program memory 23 Data memory 24 RF circuit 25 Antenna 26 Host device communication control unit 27 Host device connection I / F
30 Card command packet 31 Preamble 32 Synchronization code 33 Data length 34 Card command part 35 Check code 36 Postamble 40 Card capture command (card command)
41 Card capture command / command code 42 Command parameter 50 Card capture response (card command)
51 Card capture command response code 52 Card ID
60 First mutual authentication command (card command)
61 First mutual authentication command / command code 62 Authentication card ID
63 Authentication condition information 64 Authentication encrypted data A
70 First mutual authentication response (card command)
71 First mutual authentication command response code 72 Authentication encrypted data B
73 Encrypted data C for authentication
80 Second mutual authentication command (card command)
81 Second mutual authentication command / command code 82 Encryption data D for authentication
90 Second mutual authentication response (card command)
91 Second mutual authentication command response code 92 Authentication result data 100 Card access command (card command)
101 Card read command / command code 102 Read target part designation information 110 Card access response (card command)
111 Card read command / response code 112 Read data 120 Reader / writer command packet 121 Preamble unit 122 Start code unit 123 Data length 124 Reader / writer command unit 125 Check code 126 Postamble 130 Card capture command (reader / writer command)
131 Card capture command / command code 132 Command parameter 140 Card capture response (reader / writer command)
141 Card capture command response code 142 Card ID
150 First mutual authentication command (Reader / Writer command)
151 First mutual authentication command / command code 152 Authentication card ID
153 Authentication condition information 154 Authentication encrypted data A
160 First mutual authentication response (Reader / Writer command)
161 First mutual authentication command response code 162 Encrypted data B for authentication
163 Authentication encrypted data C
170 Second mutual authentication command (Reader / Writer command)
171 Second mutual authentication command / command code 172 Authentication encrypted data D
173 Session Key 180 Second Mutual Authentication Response (Reader / Writer Command)
181 Second mutual authentication command response code 182 Authentication result data 190 Session key set command (reader / writer command)
191 Session key set command / command code 192 Key information 200 Session key set response (reader / writer command)
201 Session key set command response code 202 Result data 210 Card access command (1) (reader / writer command)
211 Card Read Command / Command Code 212 Read Target Part Specification Information 220 Card Access Response (1) (Reader / Writer Command)
221 Card Read Command / Response Code 222 Read Data 230 Card Access Command (2) (Reader / Writer Command)
231 Card Write & Read Command / Command Code 232 Write & Read Target Part Specification Information 233 Write Data 240 Card Access Response (2) (Reader / Writer Command)
241 Card write & read command response code 242 Read back data

Claims (2)

An IC card system in which a host device is connected to a card reader / writer,
The host device is
Card access key storage means for storing a card access key;
Mutual authentication means for performing mutual authentication processing with the IC card by encrypted communication using the card access key,
The card reader / writer is
Relay means for relaying packets transmitted and received between the host device and the IC card for the mutual authentication processing;
The host device is provided with a tamper-resistant housing, or the card access key storage means is a tamper-resistant memory, and has a strong security measure,
The card reader / writer is not subjected to the strong security measures ,
The host device further has a session key generation / transmission means for generating a session key based on the specific information obtained in the mutual authentication process and transmitting the session key to the card reader / writer,
The card reader / writer further uses the session key passed from the session key generation / transmission means to perform card access processing for the IC card after the mutual authentication processing has succeeded in encrypted communication using the session key. An IC card system comprising card access means for performing according to the above . The host device in an IC card system in which a host device is connected to a card reader / writer,
Card access key storage means for storing a card access key;
Strong security measures are taken, including a tamper-resistant housing, or the card access key storage means as a tamper-resistant memory,
Communication with an arbitrary IC card is performed via the card reader / writer that is not subjected to the strong security measures, and mutual authentication processing with the IC card is performed by encrypted communication using the card access key. Mutual authentication means;
A session key is generated based on the specific information obtained in the mutual authentication process, and the session key is transmitted to the card reader / writer, whereby the IC card using the session key is sent to the card reader / writer. A host device in an IC card system, further comprising session key generation / transmission means for executing card access processing .