Communication device and system for mobile encrypted communication5926546Abstract An automatic collection system for automatically collecting a toll charge from an IC card is provided with transceivers in gantries installed along a vehicle road. This collection system uses the transceivers to perform communication with a vehicle-mounted device based on the use of encrypted data. The vehicle-mounted device performs the encryption and decryption of the communication data before its entry into the communication area of the gantries and after its passage therethrough. Also, writing of the data into the IC card, etc. are also performed using encrypted data. However, an algorithm which differs from that used in encrypting the data stored in the IC card and which enables the execution of the high speed processing is used for encrypting the communication data. As a result, since the encryption and decryption of the data is performed only in the roadside device side during communication and this encryption and decryption can be performed at a high speed, the communication time can be shortened to perform accurate data communications within a limited period of time while the vehicle is travelling. Claims What is claimed is: Description BACKGROUND OF THE INVENTION
TABLE 1
__________________________________________________________________________
1ST GANTRY COMMU. SIGNALS
CONTENTS
__________________________________________________________________________
1ST PILOT SIGNAL PILOT SIGNAL
(ROADSIDE DEVICE) LOCATION NO.
1ST PILOT RESPONSE SIGNAL
RESPONSE CODE
(VEHICLE-MOUNTED DEVICE)
RANDOM NUMBER R1
ENCRYPTION KEY Kn
ROADSIDE VERIFIC. MESSAGE
DATA RETRIEVAL COMMAND
(ROADSIDE DEVICE) RANDOM NUMBER R3
ENCRYPTION KEY Kc
1ST READ DATA RESPONSE CODE
(VEHICLE-MOUNTED DEVICE)
STATUS CODE* (ERROR CODE)
MODE OF PAYMENT*
VEHICLE-MOUNTED DEVICE CODE*
CSN*
BALANCE* (PARTLY ENCRYPTED)
CSN XOR CAN
CTC
INDEX OF KEY IN USE
1ST WRITE DATA WRITE COMMAND
(ROADSIDE DEVICE) VEHICLE-MOUNTED DEVICE CODE .dagger.
TOLL CHARGE TOTAL .dagger.
LOCATION NO. (PARTLY ENCRYPT.).dagger.
TRANSACTION TYPE
DATE
TIME
END SIGNAL (VEHIC-MTD DEVICE)
RESPONSE CODE
END ACK. SIGNAL (ROADSIDE DEV.)
END ACKNOWLEDGE
__________________________________________________________________________
NOTE:
*DENOTES DATA ENCRYPTED IN THE VEHICLEMOUNTED DEVICE
.dagger.DENOTES DATA ENCRYPTED IN THE ROADSIDE DEVICE
Next, the mutual verification process of step 200 between the IC card 2 and the crypto module 14 is executed as illustrated in FIG. 5. It is to be noted that in the operations of the IC card 2 and crypto module 14 that are explained below in connection with FIG. 5, functions that are based on the DES algorithm are used for generating the various data. That is, as illustrated in FIG. 5, when this mutual verification is performed, first, the controller 16 makes the IC card 2 generate card data including the serial number CSN, application number CAN, etc. (step 3100) and thereafter, the controller 16 retrieves such data (step 1100). The controller 16 transfers the retrieved card data (CSN, CAN) to the crypto module 14 and provides a random number R production command to the crypto module 14 (step 1200). Then, since the crypto module 14 produces a random number R in accordance with this command (step 2100), the controller 16 receives this random number R and provides this random number R to the IC card 2 along with a command for producing a verification encryption key Y (step 1300). Upon receiving the verification encryption key Y production command, the IC card 2 retrieves the card data from the memory position that corresponds to the transaction counter CTC and, using a verification key which is among the above-mentioned preset IC card keys, encrypts this card data to produce the verification encryption key Y (step 3200). Moreover, using this verification encryption key Y, the IC card 2 encrypts the random number R (step 3300). When the random number R has been encrypted in the IC card 2 as mentioned above, the controller 16 reads this encrypted data <R> and the card data that has been used for the production of the verification encryption key Y and provides a verification encryption key Y production command to the crypto module 14 along with these data (step 1400). Then, the crypto module 14 determines the exclusive OR (CSN XOR CAN) of the serial number CSN and application number CAN of the IC card 2 and, using this exclusive OR data and a prescribed master key, produces a verification key unique to the IC card 2. Then, using this verification key and the card data, the crypto module produces the verification encryption key Y (step 2200) and encrypts the random number R (step 2300) using this encryption key Y. Then, the crypto module 14 compares the encrypted data <R>' of the random number R that it has encrypted with the encrypted data <R> of the random number R that has been encrypted in the IC card 2 (step 2400). If both encrypted data match, the crypto module 14 determines that the IC card 2 that is loaded in the IC card drive 12 is normal (step 2500). It is to be noted that if both encrypted data do not match, the controller 16 determines that there is a verification error and so, control proceeds to the process of step 280. Upon completion of the above-mentioned verification of the IC card 2 in the crypto module 14 side, the controller 16 requests the crypto module 14 to generate the verification data that is used in the IC card side 2 for verifying the crypto module 14 (step 1500). Accordingly, the crypto module 14 produces an crypto module verification key SC possessed by the IC card 2 by using the exclusive OR (CSN XOR CAN) of the serial number CSN and application number CAN of the IC card 2, and a prescribed IC card key. Furthermore, the crypto module 14 encrypts this key SC by using the verification encryption key Y that has been generated in step 2200 to thereby produce verification data SC' (step 2600). Then, when the verification data SC' is generated as mentioned above, the controller 16 reads this verification data SC' and sends it to the IC card 2 together with a verification execution command (step 1600). Then, the IC card 2 decrypts the received verification data SC' using the verification encryption key Y that has been produced in step 3200 and determines whether the decrypted verification data SC' (=SC) matches the key it possesses (step 3400). When the verification data SC', SC match, the IC card 2 determines that the crypto module 14 (in other words, the vehicle-mounted device 10) of the vehicle-mounted device 10 loaded with the IC card 2 is normal (step 3500). When the IC card side 2 also verifies that the crypto module 14 is normal, the controller 16 determines that the mutual verification has been successfully performed (step 1700) and control then proceeds from step 210 to step 220. Conversely, when the crypto module 14 is not positively verified by the IC card 2 side, the controller 16 determines that this mismatch is a verification error and control proceeds to step 280. Next, FIG. 6 is a flowchart illustrating the communication process that is executed in transceivers 32, 34, respectively, which are provided in the first gantry 30 of the roadside device 20. It is to be noted that the subsequent explanation is made under the assumption that the following communication process is executed by the transceiver 32. As illustrated in FIG. 6, in step 4100 transmits a first pilot signal for activating the vehicle-mounted device 10 which is being kept in a sleep state. Thereafter, while transmitting a carrier wave signal which will be used by the vehicle-mounted device 10 in sending back a response signal during the prescribed time period T2, step 4200 determines whether a first pilot response signal has been received by the antenna 32a or not. When no first pilot response signal is received, control goes back again to step 4100 which again transmits the first pilot signal. In this way, the transceiver 32 transmits the first pilot signal for every prescribed time period t. That is, when a vehicle approaches the vicinity of the first gantry 30 and enters the communication area of the transceiver 32 that corresponds to the vehicle lane along which the vehicle is travelling, the vehicle-mounted device 10 installed in the vehicle receives the first pilot signal from the transceiver 32 and is activated from its sleep state. Then, as illustrated in FIG. 7, the vehicle-mounted device 10 sends back the first pilot response signal in response to this first pilot signal. Therefore, in steps 4100 and 4200, the transceiver 32 transmits the first pilot signal periodically to thereby determine whether the first pilot response signal has been received during this periodic transmission operation. In this way, the transceiver 32 keeps on waiting for the entry of the vehicle into its own communication area. Incidentally, as illustrated in TABLE 1, the first pilot signal that is transmitted by each of the transceivers 32, 34 of the first gantry 30 includes the pilot signal for starting the vehicle-mounted device 10 and a location number that indicates the transceiver from which the signal was transmitted. The first pilot response signal that is transmitted from the vehicle-mounted device 10 in response to the first pilot signal includes a response code, a random number R1 that constitutes the base of the communication key X1 used for producing the first read data, and the key number (encryption key number) Kn of the communication master key. When the first pilot response signal that is transmitted from the vehicle-mounted device 10 in response to the first pilot signal is received, control goes to step 4300 which provides the random number R1 and encryption key number Kn contained in the first pilot response signal and a communication key X1 production command to the crypto unit 32b. Then, based on the received random number R1 and encryption key number Kn, the crypto unit 32b uses the FX algorithm to produce the communication key X1 used by the vehicle-mounted device 10 in producing the first read data <RD1>. The crypto unit 32b also produces a random number R3, which constitutes the base of a communication key X2 which will be used by the vehicle-mounted device 10 in encrypting the next transmission data (second read data), and a key number of a communication master key (encryption key number) Kc. Step 4400 retrieves the random number R3 and the encryption key number Kc, and transmits a roadside device verification message (see Table 1) that includes these values and a read-out command of the first read data as shown in FIG. 7. Meanwhile, as mentioned earlier, when transmitting this roadside device verification message, the transceiver 32 subsequently transmits an unmodulated carrier signal during the prescribed time period T2. Also, as illustrated in FIG. 7, the transceiver 32 transmits the roadside device verification message, a first write data and an end acknowledge signal (described later), etc. for every predetermined time period t in the same way as when transmitting the first pilot signal during regular operation. Next, when transmitting the roadside device verification message to the vehicle-mounted device 10 as mentioned above, since the vehicle-mounted device 10 sends back the first read data <RD1>, which has been produced beforehand when the IC card 2 is loaded therein, in response to this message as illustrated in FIG. 7, step 4500 receives the first read data <RD1> until the carrier wave transmission time period T2 elapses. Then, when the carrier wave transmission time period T2 elapses, step 4600 determines whether the first read data <RD1> has been received during this transmission time period to check if a communication error has occurred. If a communication error has occurred, an error status code is set and after which this process is terminated temporarily. If there is no communication error, the operation proceeds to step 4700 which provides to the crypto unit 32b a command for decrypting the received first read data <RD1>. Upon reception of the request to decrypt the first read data <RD1>, the crypto unit 32b decrypts the first read data <RD1> in accordance with the FX algorithm using the communication key X1 that has been produced before based on the random number R1 and communication encryption key number Kc. In this way, after step 4700 generates the first read data <RD1> decryption command, step 4800 reads the decrypted RD1 data. Based on a status code in this decrypted data RD1, step 4900 determines whether an error is present in the decrypted first read data RD1. If a data error is present, control proceeds to step 5400. If no data error is present in the first read data RD1, control proceeds to step 5000. Step 5000 determines according to the first read data RD1 whether the IC card 2 in the vehicle-mounted device 10 is a prepaid card or a cash card. If the IC card 2 is a cash card, control proceeds to step 5100 which determines vehicle type based on, for example, the vehicle-mounted device code and the toll charge is calculated in accordance with the vehicle type and thereafter, control goes to step 5500. On the other hand, if the IC card 2 is a prepaid card, the operation proceeds to step 5200 which determines the vehicle type based on, for example, the vehicle-mounted device code and the toll charge is calculated in accordance with the vehicle type. Subsequent step 530 determines from the balance of the prepaid card whether the toll charge can be paid or not. Then, when step 5300 determines that the balance of the prepaid card is enough for paying the toll charge, control proceeds to step 5500. On the other hand, when step 5300 determines that the balance of the prepaid card is not enough for paying the toll charge, control goes to step 5400. Meanwhile, if there is an error in the decrypted first read data RD1 or if no toll charge can be collected from the IC card 2(specifically the prepaid card), step 5400 performs an error processing for transmitting an error data to this effect to the vehicle-mounted device 10 side and also setting an error status code. Upon completion of this error processing, the operation proceeds to step 5900. Next, step 5500 generates a first write data WD1 for collecting the toll charge from the vehicle-mounted device 10 side and provides the data to the crypto unit 32b and thus, the transceiver 32 drives the crypto unit 32b to encrypt the first write data WD1. After the crypto unit 32b encrypts the first write data WD1, the transceiver 32 retrieves this encrypted first write data <WD1> and transmits it to the vehicle-mounted device 10 as shown in FIG. 7. It is to be noted that during this transmission the transceiver 32 also transmits an unmodulated carrier wave signal during the prescribed time period T2 after transmitting the modulated signal that corresponds to the first write data <WD1>. Here, for example, as illustrated in Table 1, the first write data WD1 includes the write command for storing the payment result of the toll charge into the IC card 2 in the vehicle-mounted device 10 side, the vehicle-mounted device code, the total sum of the toll charges, the location number of the transceiver 32, the transaction type that indicates the type of charge collection (namely, flat charge collection, charge collection varying according to distance travelled, or time dependent charge collection), and the date and time. Among these data items, the vehicle-mounted device code, the total sum of the toll charges and part of the location number are respectively encrypted and the remaining data items are left untouched as unencrypted regular transmission data (first write data <WD1>). Also, when encrypting this first write data WD1, the crypto unit 32b performs its encryption processing in accordance with the FX algorithm using the communication key X1 generated before. That is, since the crypto unit 32b (also crypto unit 34b) is used only for communicating with the vehicle-mounted device 10, unlike the crypto module 14 in the vehicle-mounted device 10 side, the crypto unit 32b performs the production of the keys as well as the encryption and decryption of the data by using only the FX algorithm which is the communication encryption algorithm. Next, after receiving the transmitted first write data <WD1>, the vehicle-mounted device 10 transmits an end signal which includes the response code to this effect as illustrated in FIG. 7. Therefore, after transmitting the first write data <WD1>, the transceiver 32 executes the end signal reception processing (step 5700) during the prescribed time period T2. After the elapse of the prescribed time period T2, step 5800 determines whether the end signal has been received to check for the presence or absence of a communication error. If there is a communication error, the transceiver 32 sets the error status code and thereafter terminates this process. If there is no communication error, control proceeds to step 5900. Step 5900 provides the above-decrypted first read data RD1, error status that has been set in the error process (in step 5400), etc. to the local controller 26 that is built in the main body of the roadside device 20. Subsequent step 6000 transmits an end acknowledge signal to the vehicle-mounted device 10. This end acknowledge signal serves as a communication completion signal for informing the vehicle-mounted device 10 of the completion of the data communication and the first pilot signal (see FIG. 7) and thereafter this process terminates. Meanwhile, the first pilot signal is transmitted after the end acknowledge signal as mentioned above for quickly activating the vehicle-mounted device 10 that is loaded in the vehicle that has next entered the communication area. Through this transmission operation, it is possible to prevent the delays in activating the vehicle-mounted device 10 and thus, to provide a shorter communication time. Also, after transmitting the first pilot signal in step 6000, by performing a determination processing (not shown) similar to that of step 4200, the transceiver 32 determines whether the first pilot response signal has been transmitted by the vehicle-mounted device 10 in response to the first pilot signal. After receiving the first pilot response signal, control proceeds to step 4300 and communication with the vehicle-mounted device that has transmitted this first pilot response signal is started. When the first pilot response signal is not received, control proceeds to step 4100, whereby the operation returns to the normal operation of transmitting the first pilot signal for every prescribed time period t›msec.! Next, FIG. 8 is a flowchart illustrating the data process (first gantry passage process) which is executed by the vehicle-mounted device 10 after it receives the first pilot signal from the transceivers 32, 34, . . . provided in the first gantry 30 and after executing the communication processing with the transceiver that transmitted the first pilot signal following the above-mentioned procedure. As shown in FIG. 8, in the vehicle-mounted device 10, the communication circuit 18 activates the controller 16 after receiving the first pilot signal from the transceiver of the first gantry 30, e.g., the transceiver 32. Then, step 6100 executes a communication process for performing data communication with the transceiver 32 via the communication circuit 18. Upon receipt of the first write data <WD1> from the transceiver 32, the controller 16 transmits the end signal via the communication circuit 18, terminates the communication processing (step 6100) and executes the first gantry passage process of step 6200 and subsequent step s. Step 6200 determines whether the communication circuit 18 has received the end acknowledge signal from the transceiver 32. If the controller 16 has not yet received the end acknowledge signal, control proceeds to step 6300 in which the controller 16 transmits via the communication circuit 18 a command signal for requesting the transmission of the end acknowledge signal using the unmodulated carrier wave signal, which succeeds the first pilot signal or a transmission signal to the vehicle-mounted device 10 and which is transmitted by the transceiver 32 for every predetermined time period t. Also, subsequent step 6400 determines whether the transmission signal such as the first pilot signal from the transceiver 32 has been received by the communication circuit 18; in other words, the controller 16 determines whether or not the vehicle has left the communication area of the transceiver 32. If the vehicle is still inside the communication area, control again proceeds to step 6200 which determines whether the transceiver 32 has transmitted the end acknowledge signal in response to the above-mentioned request signal. If no end acknowledge signal has been received, control again proceeds to step 6300. Thereafter, steps 6200 to 6400 are repeated until the vehicle goes out of the communication area of the transceiver 32 or the end acknowledge signal is received. That is, if the end acknowledge signal cannot be received when passing the first gantry 30 after completing communication with the transceiver 32, the controller 16 transmits the end acknowledge signal request signal to the transceiver 32 to direct the same transceiver 32 to again transmit the end acknowledge signal. As a result, in the vehicle-mounted device 10 side, the controller 16 can reliably verify the completion of the communication with the transceiver 32. Even if no end acknowledge signal is received, the controller 16 can inform the roadside device 20 about this matter via the transceiver 32. This enables mutual verification of a communication error between them. When the controller 16 receives the end acknowledge signal or the vehicle departs from the communication areas of the transceivers 32, 34, . . . of the first gantry 30, control goes to step 6500 which generates to the crypto module 14 a command to decrypt the first write data <WD1> received from the roadside device 20. Then, since the crypto module 14 decrypts the first write data <WD1> in accordance with the FX algorithm using the communication key X1, subsequent step 6600 reads out the decrypted first write data WD1 and verifies the roadside device 20 (more specifically, the transceiver that has transmitted the first write data WD1) based on the vehicle-mounted device code contained in the first write data WD1 and the vehicle-mounted device code of the vehicle-mounted device 10. Step 6700 determines if the verification result of step 6600 for the roadside device 20 is positive or not. If the two vehicle-mounted device codes do not match and as a result, step 6700 determines that the roadside device cannot be positively verified, step 6800 sets an error status code to this effect and then, the controller 16 enters a sleep mode. If step 6700 determines the positive verification of the roadside device 20 when both vehicle-mounted device codes match, control proceeds to step 6900. When step 6900 sends the random number R3 and encryption key number Kc received during the previous data communication from the roadside device 20 side to the crypto module 14, the crypto module 14 is driven by the controller 16 to produce the communication key X2 used for the next data communication and changes the communication key from X1 to X2. It is to be noted that after receiving the random number R3 and the encryption key number Kc, the crypto module 1 generates the communication key X2 in accordance with the FX algorithm using data and the communication master key that corresponds to the random number R3 and the encryption key number Kc. When the communication key is changed from X1 to X2 as mentioned above, step 7000 determines the type of the IC card 2. If the IC card 2 is a prepaid card, step 7100 determines whether the prepaid card has enough balance for paying the toll charge. If the balance is insufficient, step 7200 sets the toll charge sum to zero and control goes to step 7300. If the balance is sufficient for the payment of the toll charge, control goes to step 7300. Step 7300 executes a toll charging process for subtracting the toll charge from the IC card 2 which is a prepaid card and step 7400 determines whether the toll charge has been properly subtracted from the IC card 2. If the toll charge cannot be subtracted from the prepaid card, that is, if the balance in the prepaid card is insufficient or the normal execution of the toll charging process has failed, control proceeds to step 7500 which sets an error status flag and thereafter, the controller 16 enters a sleep mode. Conversely, if the toll charge has been successfully and properly subtracted, control proceeds to step 7800. Also, when step 7000 determines that the IC card 2 is a cash card, control proceeds to step 7600 which reads out the account data for the payment of the toll charge using the cash card, and then control goes to step 7700 which determines whether the retrieved account data is proper or not. When the account data is improper, the controller 16 enters a sleep mode and, when the account data is proper, control proceeds to step 7800. Next, step 7800 provides to the crypto module 14 the vehicle-mounted device data (second read data) RD2 which will be next transmitted to the roadside device 20 and drives the crypto module 14 to encrypt this second read data RD2 using the communication key that has been changed to X2 by step 6900. It is to be noted that the FX algorithm is again used for this encryption operation. After the second read data RD2 is encrypted by the crypto module 14, step 7900 stores the encrypted data <RD2> as the next transmission data and step 8000 stores payment data, e.g., date, time and place at which the toll charge has been paid, to the IC card 2 to update the card data. Step 8100 reads the updated card data and stores the updated data and thereafter, the controller 16 enters a sleep mode. Here, incidentally, the toll charging process (step 7300) for subtracting the toll charge from the prepaid card and the card data updating process (step 8000) for updating the data of the IC card are executed using the data that has been encrypted in accordance with the DES algorithm using the above-mentioned toll charging key Z that is stored beforehand. Meanwhile, for example, as shown in Table 2, the second read data RD2 that is encrypted in step 7800 and stored as the transmission data in step 7900 includes the response code to the communication device of the roadside device 20, cash card file data (account data, etc.) in case the IC card 2 is a cash card, status code such as an error status code that indicates the operational state of the vehicle-mounted device 10 side, payment method, collection result of the toll charge, vehicle-mounted device code, application number CAN of the IC card 2, the random number R3, toll charge collection verification data for proving that the toll charge collection has been performed in the vehicle-mounted device 10 side, and the like. Among these data items, the response code and part of the cash card file data are left as is in their unmodulated ordinary state while all the remaining data items are encrypted. While the second read data RD2 is encrypted in accordance with the FX algorithm in the same way as that of the first read data RD1, it must be noted here that among the data items of the second read data RD2, the toll charge card 2 side in accordance with the DES algorithm using the IC card key and therfore, this verification data is twice encrypted by being further encrypted during transmission time using the FX algorithm. Next, FIG. 10 is a flowchart illustrating the communication process that is executed in the transceivers 42, 44, . . . which are provided in the second gantry 40 of the roadside device 20. It is to be noted that in the following explanation, it is assumed that this process is executed by the transceiver 42.
TABLE 2
__________________________________________________________________________
2ND GANTRY COMMU. SIGNALS
CONTENTS
__________________________________________________________________________
2ND PILOT SIGNAL 2ND PILOT SIGNAL
(ROADSIDE DEVICE) LOCATION NO.
2ND PILOT RESPONSE SIGNAL
RESPONSE CODE
(VEHICLE-MOUNTED DEVICE)
PAYMENT MODE DATA
DATA RETRIEVAL SIGNAL (VEHI-MTD.)
DATA RETRIEVAL COMMAND
2ND READ DATA RESPONSE CODE
(ROADSIDE DEVICE) CASH CARD FILE* (PARTLY ENCRYPTED)
STATUS CODE*
MODE OF PAYMENT*
CHARGE COLLECTION RESULT*
VEHICLE-MOUNTED DEVICE CODE*
CSN*
RANDOM NUMBER R3*
TOLL COLLECTION PROOF DATA*
2ND WRITE DATA WRITE COMMAND
(ROADSIDE DEVICE) DISPLAY COMMAND
DISPLAY MESSAGE
END SIGNAL (VEHI-MTD DEVICE)
RESPONSE CODE
END ACK. SIGNAL (ROADSIDE DEV.)
END ACKNOWLEDGE
__________________________________________________________________________
NOTE: *DENOTES DATA ENCRYPTED IN THE VEHICLEMOUNTED DEVICE
As illustrated in FIG. 9, as in the case of the transceivers 32, 34, . . . of the first gantry 30, step 9100 transmits the second pilot signal for starting the vehicle-mounted device 10 which is in a sleep mode. While transmitting during the prescribed time period T2 the carrier wave signal which will be used by the vehicle-mounted device 10 for sending the response signal, step 9200 determines whether the second pilot response signal has been received by the antenna 42a or not. While no second pilot response signal is received, the transceiver 42 keeps on transmitting the second pilot signal for every predetermined time period t›msec.! in such a way that control goes back again to step 9100 for transmitting the second pilot signal. When the vehicle-mounted device 10 receives the second pilot signal and is activated from the sleep state, it transmits the second pilot response signal in response to this second pilot signal as illustrated in FIG. 10. Then, after receiving this response signal, control proceeds to step 9300 which determines the type of the IC card 2 loaded in the vehicle-mounted device 10 based on the pilot response signal. That is, since the vehicle-mounted device 10 is arranged to transmit the payment mode data representing the response code and the charge collection method as the second pilot response signal (see Table 2) after receiving the second pilot signal, the transceiver 42 determines from this payment mode data whether the IC card 2 on the vehicle-mounted device 10 side is a cash card or a prepaid card. If the IC card 2 is a prepaid card, control proceeds to step 9500. If the IC card 2 is a cash card, step 9400 provides a display message search command to the local controller 26 of the main body of the roadside device 20 for searching a display message to be sent to the vehicle-mounted device 10 and thereafter, control proceeds to step 9500. It is to be noted that upon receipt of this display message search command, the local controller 26 searches the state of use of the cash card, etc. to thereby produce the display message that is to be transmitted to the vehicle-mounted device 10 side and transmits it to the transceiver 42 (see FIG. 10). Next, step 9500 sends a data read request signal to the vehicle-mounted device 10 for requesting the transmission of the second read data <RD2> and thereafter, step 9600 executes a process for waiting the reception of the second read data <RD2> from the vehicle-mounted device 10 while transmitting the unmodulated carrier wave signal during the prescribed time period T2. When the prescribed time period T2 has elapsed, step 9700 determines the occurrence or non-occurrence of a communication error by determining whether step 950 has succeeded in its reception of the second read data <RD2>. When there is a communication error, the transceiver 42 sets an error status code and then this process terminates for the time being. On the other hand, when the vehicle-mounted device 10 transmits the second read data <RD2> in response to the data read signal that has been transmitted by step 9500, control proceeds to step 9800 which generates a second write data WD2 and provides the same data to the vehicle-mounted device 10. As shown in Table 2, the second write data WD2 includes write/display commands for driving the vehicle-mounted device 10 to store and display information to indicate that the second read data <RD2> has been received by the second gantry 40, the display message retrieved and produced in the local controller 26 when the IC card 2 is a cash card or the like. Since the vehicle-mounted device 10 transmits the end signal consisting of the response code as illustrated in FIG. 10 after receiving the second write data WD2, step 9900 executes the reception processing in which it waits for the transmission of the end signal from the vehicle-mounted device 10 while transmitting the unmodulated carrier wave signal during the prescribed time period T2. When the prescribed time period T2 elapses, step 10000 determines the presence of a communication error by determining whether step 9900 has succeeded in receiving the end signal. When there is a communication error, the transceiver 42 sets an error status flag and then this process terminates. If there is no communication error, step 10100 sends the vehicle-mounted device data, namely, the second read data <RD2> received from the vehicle-mounted device 10 to the local controller 26 and subsequent step 10200 sends the end acknowledge signal and the second pilot signal (see FIG. 11) to the vehicle-mounted device 10 and then this process terminates. Incidentally, after step 10200 has transmitted the second pilot signal, as in the case of the processing executed by the transceiver 32, 34, . . . of the first gantry 30, the transceiver 42 executes determination processing (not shown) similar to step 9200 for determining if the second pilot response signal has been transmitted from the vehicle-mounted device 10 side in response to the second pilot signal. When the transceiver 42 receives the second pilot response signal, control proceeds to step 9300. When the transceiver 42 fails to receive the second pilot response signal, control proceeds to step 9100. Also, the second read data <RD2> that is sent by step 10100 to the local controller 26 is encrypted data that has been encrypted in accordance with the FX algorithm and the charge collection verification data contained therein is one which has been further encrypted in accordance with the DES algorithm. Therefore, the charge collection verification data is decrypted using the built-in encryptor of the local controller 26. When the charge collection verification data that has been decrypted using the FX algorithm is further decrypted using the DES algorithm, the local controller 26 determines the encryption key used by the IC card 2 during the encryption of the charge collection verification data in the following manner and uses this encryption key to decrypt the charge collection verification data. The local controller 26 determines the IC card key unique to the IC card 2 loaded in the vehicle-mounted device 10 using the index of the key in the first read data RD1 from the vehicle-mounted unit 10 and subsequently generates the decryption key. When the vehicle-mounted unit 10 activates after receiving the second pilot signal from the transceivers 42, 44, . . . of the second gantry 40 and the same vehicle-mounted unit 10 performs communication with the transceiver that sent the second pilot signal based on the above-mentioned procedure, the controller 16 of the vehicle-mounted device 10 executes a data processing procedure (second gantry 40 passage processing) which is shown by the flowchart of FIG. 11. As illustrated in FIG. 11, when step 11100 receives the second write data WD2 via data communication with transceivers 42, 44, . . . of the second gantry 40 and transmits the end signal to thereby terminate the data communication, step 11200 determines whether the end acknowledge signal has been received or not in the same way as during the time of completion of the communication with the first gantry 30. If the end acknowledge signal has not been received, step 11300 transmits the end acknowledge signal transmission request signal by utilizing the unmodulated carrier wave signal the transceiver 42, 44, . . . has sent. Furthermore, step 11400 determines whether the vehicle has left the communication area of the second gantry 40. If the vehicle is still within this communication area, control proceeds to step 11200. After the termination of the communication processing of step 11100, steps 11200 and 11400 are repeatedly executed until the vehicle leaves the communication area of the second gantry 40 or the controller 16 succeeds in its reception of the end acknowledge signal. When the end acknowledge signal is received or when the vehicle has left the communication area of the second gantry 40, control proceeds to step 11500 which makes the crypto module 14 produce again the communication key X1 for encrypting the transmission data as in the case of step 290 mentioned previously and step 11600 stores this communication key X1. Step 11700 reads the vehicle-mounted device data (first read data) RD1 that is to be transmitted next to the roadside device 20 and makes the crypto module 14 encrypt such data using the communication key X1 while step 11800 stores the encrypted first read data <RD1>. It is to be noted that the procedure for the production of the communication key X1 and the encryption operation of the first read data RD1 in the crypto module 14 are completely the same as those executed when the IC card 2 is loaded in the IC card drive 12. The only difference between them is that among the vehicle-mounted device data items that are included in the first read data RD1, the content of the data item regarding the IC card 2 is changed to the charged content that is stored by step 8100. When the above-encrypted first read data <RD1> is stored, step 11900 checks the state of the vehicle-mounted device 10 based on, for example, the error status flag that is set when there is an error. If there is an error, control proceeds to step 11300 which informs the passenger of the error using a buzzer or the like. If there is no error, control proceeds to step 11200 which informs the passenger of the vehicle of the state of the card using a buzzer and display device. Then, the controller 16 enters a sleep mode. It is to be noted that the displayed content of the state of the card is, for example, the balance of the card if the IC card 2 is a prepaid card. If the IC card 2 is a cash card, the contents of the display is, for example, the amount used and the message included in the second write data WD2. Next, FIG. 12 is a flowchart illustrating the data process (card removal process) executed by the controller when the IC card 2 is removed from the IC card drive 12 of the vehicle-mounted device 10. It is to be noted that this process is started when the removal of the IC card 2 has been detected by a sensor provided in the IC card drive 12 and the resulting detection signal has been provided to the controller 16 to activate this same controller 16. As illustrated in FIG. 12, when this process is started, step 12100 first sets an error status flag that indicates that the IC card 2 has been removed and that the vehicle-mounted device 10 has no card for paying the toll charge. Subsequent step 12200 reads the vehicle-mounted device data after the setting of the error status flag to update the content of the post-encryption first read data <RD1> to correspond with the error status flag. Then, step 12200 provides the vehicle-mounted device data to the crypto module 14 to drive the same to generate the encrypted first read data <RD1>. When the first read data <RD1> is produced by the crypto module 14, step 12300 updates the first read data <RD1> as the transmission data that will be next transmitted to the roadside device 20 and after step 12400 displays the state of use of the extracted IC card 2, etc., the controller 16 enters a sleep mode. As explained above, in the toll road toll charging system according to the present embodiment, the timing at which the vehicle-mounted device 10 performs the encryption of the transmission data and the decryption of the reception data is the timing when the IC card 2 for payment of the charge is loaded in the IC card drive 12, the time interval from the completion of the communication procedures between the controller 16 and the transceivers 32, 34, . . . provided in the first gantry 30 of the roadside device 20 up to the entry of the vehicle into the communication area of the transceivers 42, 44, . . . provided in the second gantry 40, after the completion of communications with the second gantry 40 and the time when the IC card 2 is removed from the IC card drive 12. That is, the controller 16 performs no encryption nor decryption during the communication with each of the roadside device 20 side transceivers 32, 34, . . . and 42, 44, . . . Also, similarly, regarding the reading of the card information from the IC card 2 and the updating of the card data, the controller 16 does not perform encryption and decryption operations during communication with each of the roadside device 20 side transceivers 32, 34, . . . and 42, 44, . . . . In this way, it is possible to drastically decrease the processing time consumed by the vehicle-mounted device 10 during data communication with the roadside device 20 and thus, the time period needed for the execution of the data communication can be decreased. This enables data communication to be executed accurately for a short period of time without limiting the travel speed of the vehicle or changing the crypto module 14 to an expensive one that enables the execution of high-speed processing. Also, when the IC card 2 has been loaded in the IC card drive 12, the vehicle-mounted device 10 executes the mutual verification procedure between the IC card 2 and the crypto module 14 and transmits the status information (error status) that represents the result of this verification procedure to the roadside device 20 as one item of the vehicle-mounted device data. Therefore, in case the IC card 2 or vehicle-mounted device 10 itself is forged, it is possible to detect this information in the roadside device 20. Accordingly, it is possible to control cheating of the vehicle passenger and thus, charge collection can be performed properly. Also, while data is encrypted using the DES algorithm that is employed generally in the art when such mutual verification or writing of the data into the IC card 2 is performed, during communication between the vehicle-mounted device 10 and the roadside device 20, data is encrypted in accordance with the FX algorithm which is different from and which enables higher speed encryption than the DES algorithm. For this reason, in transceivers 32, 34, . . . provided in the first gantry 30, it is possible to shorten the amount of time needed during data communication for performing the encryption of the transmission data and the decryption of the reception data, and thus, data communication can be performed at higher speeds and at higher levels of accuracy. Also, especially, if the previously mentioned encryption algorithm called "SAFER.multidot.K-64" or "FEAL" is used as the FX algorithm, the encryption unit can be implemented comparatively cheaply through a hardware construction. In this way, because the amount of time needed for performing the encryption operation can be shortened, and therefore the use of such an encryption algorithm is very effective. Also, as mentioned previously, in the present embodiment, the FX algorithm that is different from the DES algorithm, which is generally used, is used for the data communication between the vehicle-mounted device 10 and the roadside device 20 communication device. For this reason, even when the communication signal gets intercepted, it will be difficult to decrypt this same signal. This enhances communication security. In addition, in the present embodiment, when encrypting the transmission data, the entire data is not encrypted and part thereof is left as is in an ordinary unencrypted manner and furthermore, the communication keys (X1, X2) are each updated based on the use of the random number that is generated each time it is used. In this way, the data becomes more difficult to decrypt. This enables the further enhancement of the communication security. Also, since the communication keys X1 and X2 are set in each of the vehicle-mounted device 10 and the roadside device 20 communication device, even when the vehicle passenger tries to cheat paying toll charges by using a transmitter that generates a signal that is obtained by copying the transmission signal from the authorized vehicle-mounted device 10, this unlawful operation can be reliably detected in the roadside device 20 and thus, communication security can be enhanced. On the other hand, in the present embodiment, errors such as the result of the above-mentioned mutual verification which have occurred in the vehicle-mounted device 10 side are all transmitted as errors to the roadside device 20 side. Also, when an error has been detected by the roadside device 20, information on the presence of the error is similarly transmitted to the vehicle-mounted device 10. Therefore, both the vehicle-mounted device 10 and the roadside device 20 can know of the error and thus, both of these devices 10, 20 can employ countermeasures against this error. Although the present invention has been fully described in connection with a preferred embodiments thereof with reference to the accompanying drawings, it is to be noted that various changes and modifications will become apparent to those skilled in the art. For example, while the above described embodiment presents the case where the roadside device 20 provided at the entrance or exit of the toll road receives via data communication with the vehicle-mounted device 10 the uniform toll charge which varies depending on the type of the vehicle but is uniform with respect to the travelled distance and travel time, it goes without saying that the present invention can be applied also to a toll road toll charging system in which the toll charge is set in accordance with the travelled distance or the travel time. In this case, in order to enable the collection of the toll charge at the exit of the toll road in accordance with the travelled distance and the travel time, an entrance gantry constructed as in the case of the first gantry 30 at the entrance of the toll road may be provided. Such entrance gantry may perform the transmission and reception of the signals having constructions as illustrated in Table 3 between the vehicle-mounted device 10 loaded in the vehicle that passes through it. Further, a first exit gantry and a second exit gantry constructed as in the same way as that of the first gantry 30 and second gantry 40 in the exit of the toll road may be provided for performing the transmission and reception of the signals, whose formats are illustrated in Tables 4 and 2 and which are explained in connection with the above-mentioned embodiment, with the vehicle-mounted device 10 loaded in the vehicle that passes by to collect toll charges.
TABLE 3
__________________________________________________________________________
ENT. GANTRY COMMU. SIGNALS
CONTENTS
__________________________________________________________________________
ENTRY PILOT SIGNAL PILOT SIGNAL
(ROADSIDE DEVICE) LOCATION NO.
ENTRY PILOT RESPONSE SIGNAL
RESPONSE CODE
(VEHICLE-MOUNTED DEVICE)
RANDOM NUMBER R1
ENCRYPTION KEY Kn
DATA RETRIEVAL SIGNAL (VEHI-MTD)
DATA RETRIEVAL COMMAND
ENTRY READ DATA RESPONSE CODE
(ROADSIDE DEVICE) STATUS CODE*
MODE OF PAYMENT*
VEHICLE-MOUNTED DEVICE CODE*
ENTRY WRITE DATA WRITE COMMAND
(ROADSIDE DEVICE) VEHICLE-MOUNTED DEVICE CODE.dagger.
LOCATION NO. (PARTLY ENCRYPT.).dagger.
TRANSACTION TYPE
DATE OF ENTRY
TIME OF ENTRY
END SIGNAL (VEHI-MOUNTED DEVICE)
RESPONSE CODE
END ACK. SIGNAL (ROADSIDE DEV.)
END ACKNOWLEDGE
__________________________________________________________________________
NOTE:
*DENOTES VEHICLEMOUNTED DEVICE ENCRYPTED DATA
.dagger.DENOTES ROADSIDE DEVICE ENCRYPTED DATA
That is, as illustrated in Table 3, the entrance read data which includes the response code, status code, charge collection mode, vehicle-mounted device code, etc. may be generated, encrypted and stored beforehand in the vehicle-mounted device 10. Then, when the vehicle has entered the communication area of the communication device provided in the entrance gantry, the vehicle-mounted device 10 side is activated by the entrance pilot signal that is transmitted periodically and transmits the entrance pilot response signal constructed as in the case of the first pilot response signal (see Table 1) in the above-described embodiment. Then, when the communication device of the entrance gantry transmits the data read signal, the vehicle-mounted device 10 side transmits the entrance read data. On the other hand, after its reception of the entrance read data, the communication device of the entrance gantry is constructed to transmit the entrance write data which has a construction that can be obtained by removing the charged money sum from the construction of the first write data (see Table 1) in the above-mentioned embodiment. Thereafter, the communication device and vehicle-mounted device perform transmission and reception of the end signal and end acknowledge signal to complete the data communication operation. Also, after the vehicle has passed through the entrance gantry as mentioned above, as illustrated in Table 4 (described below), the entrance data that includes the response code, vehicle-mounted device code, inlet location number, date of entry, time of entry, etc. and the first read data constructed as in the case of the first read data in the above-mentioned embodiment are produced, encrypted and stored in the vehicle-mounted device 10 as the data to be transmitted when it passes through the first exit gantry. Then, when the vehicle has entered into the communication area of the communication device provided in the first exit gantry, the vehicle-mounted device 10 is activated by the first pilot signal that is transmitted periodically from this communication device and transmits the first pilot response signal constructed as in the case of the inlet pilot response signal. Thereafter, the vehicle-mounted device 10 receives the roadside device verification message which includes the response code, random number R3 and encryption key number Kc which is transmitted from the communication device of the first exit gantry and transmits the entrance data. Further, the vehicle-mounted device receives the data read-out signal that is transmitted thereafter from the roadside device side communication device and transmits the first read data. On the other hand, upon reception of this first read data, the communication device of the first exit gantry transmits the first write data which has been prepared by adding to the first write data of the above-mentioned embodiment the toll charging data that includes elapsed travel time after passing of entrance gantry or the exit number. Thereafter, the transmission and reception of the end signal and the end acknowledge signal are performed between the vehicle-mounted device and the exit gantry to complete the data communication.
TABLE 4
__________________________________________________________________________
1ST EXIT GANTRY COMMU. SIGNAL
CONTENTS
__________________________________________________________________________
1ST PILOT SIGNAL PILOT NO.
(ROADSIDE DEVICE) LOCATION NO.
1ST PILOT RESPONSE SIGNAL
RESPONSE CODE
(VEHICLE-MOUNTED DEVICE)
RANDOM NO. R1
ENCRYPTION KEY NO. Kn
ROADSIDE DEVICE VERI. MESSAGE
RESPONSE CODE
(ROADSIDE DEVICE) RANDOM NO. R3
ENCRYPTION KEY NO. Kc
ENTRANCE DATA RESPONSE CODE
(VEHICLE-MOUNTED DEVICE)
VEHICLE-MOUNTED DEV. CODE*
ENTRANCE NO.*
DATE OF ENTRY*
TIME OF ENTRY*
DATA RETRIEVAL SIGNAL (ROADSIDE DEV.)
DATA RETRIEVAL COMMAND
FIRST READ DATA RESPONSE CODE
(VEHICLE-MOUNTED DEVICE)
STATUS CODE*
MODE OF PAYMENT*
VEHICLE-MOUNTED DEV. CODE*
CSN*
BALANCE (PARTLY ENCRYPTED)*
CSN XOR CAN
CTC
INDEX OF KEY TO BE USED
FIRST WRITE DATA WRITE COMMAND
(ROADSIDE DEVICE) VEHICLE-MOUNTED DEV. CODE.dagger.
TOTAL CHARGE.dagger.
LOCATION NO..dagger. (PARTLY ENCRYPTED)
TRANSACTION TYPE
DATE
TIME
CHARGING DATA (TIME OR EXIT NO.)
END SIGNAL (VEHICLE-MOUNTED DEVICE)
RESPONSE CODE
END ACK SIGNAL (ROADSIDE DEVICE)
END ACKNOWLEDGE
__________________________________________________________________________
NOTE:
*DENOTE VEHICLEMOUNTED DEVICE ENCRYPTED DATA
.dagger.DENOTES ROADSIDE DEVICE ENCRYPTED DATA
Also, after the vehicle passes by the first exit gantry, as shown in Table 2, data that is the same as the second read data of the above-mentioned embodiment is produced, encrypted and stored in the vehicle-mounted device 10. Then, when the vehicle enters the communication area of the communication device provided in the second exit gantry, the vehicle-mounted device 10 performs data communication, which is the same as that when the vehicle-mounted device 10 side passes by the second gantry 40 in the above-mentioned embodiment, with the vehicle-mounted device 10 and thereafter writes the communication results into the IC card 2. In this way, using the above-mentioned constructions, it is possible to perform the automatic collection of the toll charges from the IC card 2 in both systems in which the toll charge is set in accordance with the travelled distance and the system in which the toll charge is set in accordance with the travelled time. Also, the only difference between the system in which the toll charge is set in correspondence with the travelled distance and the system in which the toll charge is set in correspondence with the amount of time travelled is with respect to setting the toll charging data in the first write data illustrated in Table 4 to be either the travelled time or the exit number from which the travelled distance is known. The construction of the data transmitted and received between the vehicle-mounted device and the roadside device and patterns of transmission and reception operations are completely the same for both systems. As a result of this, the vehicle-mounted device 10 can be used for both systems. Such changes and modifications are to be understood as being within the scope of the present invention as defined by the appended claims.
|
Same subclass Same class Consider this
| |||||||||||||||