Patent Grant
7346718
This application claims benefit of priority under 35 U.S.C. § 119 to Japanese Patent Application No. 2002-169315, filed on Jun. 10, 2002, the entire contents of which are incorporated by reference herein.
1. Field of the Invention
The present invention relates to an integrated circuit (IC) card, more specifically, to an autonomous IC card which is configured to directly and autonomously communicate with another device connected to an IC card terminal directly or via a network.
2. Description of the Related Art
Here, the IC card terminal includes an IC card reader/writer 200 and an IC card terminal main body 300. Although an IC card 100 and the IC card reader/writer 200 are schematically illustrated as being separated herein, the IC card 100 and the IC card reader/writer 200 may be configured into a contact less type as described therein, or alternatively, the IC card 100 and the IC card reader/writer 200 may be configured into a contact type in which the IC card 100 is typically inserted into the IC card reader/writer 200.
Upon processing by use of the IC card 100 as described above, the IC card terminal main body 300 serves as a master device and the IC card 100 serves as a slave device. In other words, when an operator intends to execute processing by use of the IC card 100, the operator firstly inputs an instruction to an input terminal (not shown) provided to the IC card terminal main body 300. In response to the instruction, the IC card terminal main body 300 being the master device transmits a command to the IC card 100 via the IC card reader/writer 200. Upon receipt of the command, the IC card 100 being the slave device executes processing corresponding to the command, and returns an execution result to the IC card terminal main body 300 via the IC card reader/writer 200.
In the drawing, an IC card reader/writer 200b is connected to the IC card terminal main body 300 in addition to the configuration shown in
As similar to the case in
The operations are basically the same when the above-described exchanges between the IC card 100a and the IC card 100b continue. In other words, the IC card terminal main body 300 always plays a role to perform relaying operations of information exchanged between the IC card 100a and the IC card 100b.
Incidentally, in conventional communication between IC cards, the IC card terminal main body always plays the role to perform relaying operations of information concerning the communication between the IC cards as described above. Therefore, conventionally, an intermediate device as represented by the IC card terminal main body has been capable of falsification or theft of the information communicated between the IC cards. Hence there has been conventionally a problem that communication of accurate information between the IC cards is not ensured.
The present invention has been made in the light of the foregoing problem. It is an object of the present invention to provide an autonomous IC card capable of ensuring safe communication of accurate information by directly communicating with another communication device seemingly without interposing an intermediate device, such as an IC card terminal, between the IC card and the another communication device when the IC card communicates with the another communication device connected to the IC card terminal directly or via a network.
To attain the foregoing object, there is provided an autonomous IC card comprising a logic host interface which is connected to an IC card terminal via a physical layer, a logic external communication interface which communicates with a communication device connected thereto via the IC card terminal physically, and an IC chip configured to recognize connection of the communication device and directly communicate with the communication device via the logic external communication interface.
According to the present invention, the autonomous IC card can autonomously recognize the communication device connected thereto via the IC card terminal, and directly communicate with the communication device.
In a preferred embodiment of the present invention, the IC chip includes a communication control unit being a software module which directly communicates with the communication device via the logic external communication interface.
According to the present invention, the communication control unit can execute processing by use of the software module which is not conscious of the connected IC card terminal.
In a preferred embodiment of the present invention, the communication control unit includes a session management command group which establishes a session communication path for the communication device, and a transaction management command group which establishes a transaction session for the communication device.
In a preferred embodiment of the present invention, the IC chip includes an encryption processing unit which performs mutual authentication processing with the communication device and encrypts and decrypts information concerning communication with the communication device.
According to the present invention, the encryption processing unit performs the mutual authentication processing with the communication device, and encrypts and decrypts the information concerning the communication with the communication device.
In a preferred embodiment of the present invention, the IC chip includes an assigned unique identifier. Here, the IC chip identifies the communication device and performs the mutual authentication processing based on the identifier.
In a preferred embodiment of the present invention, the encryption processing unit selects an appropriate authentication process and an appropriate encryption process out of a plurality of authentication processes and a plurality of encryption processes respectively to perform those processes, depending on a type of the identified communication device.
In a preferred embodiment of the present invention, the IC chip includes a storage unit which stores value information. Here, the IC chip communicates with the communication device concerning the value information.
The nature, principle and utility of the invention will become more apparent from the following detailed description when read in conjunction with the accompanying drawings.
In the accompanying drawings:
Now, an embodiment of an autonomous IC card according to the present invention will be described in detail with reference to the accompanying drawings.
In
Here, the above-described configuration is a mixture of a physical configuration (hardware) and a logical configuration (software). Description will be made below severally regarding both the configurations.
The host device interface 17 is a conventionally provided physical interface for performing external communication. As similarly to the related art, the host device interface 17 includes a contact type and a contactless type. The CPU 10 is a central processing unit which executes all kinds of operations except part of floating-point operations. Note that a floating-point processing unit (not shown) is specially provided for executing some floating-point operations. The ROM 11 is a read-only memory in which software (such as an operating system (OS) or programs) unique to the autonomous IC card 1 and a chip ID of the present invention to be described later are stored. The RAM 12 is a random access memory in which data treated by the software which operates inside the autonomous IC card are temporarily stored. Contents in the RAM 12 are completely deleted when power supply to the IC card is stopped.
The nonvolatile memory 13 stores value information to be described later. The value information is equivalent to data containing values such as electronic tickets and electronic money. Note that since the nonvolatile memory 13 is a memory designed to preserve contents, the contents therein are preserved even if the power supply is stopped.
These are the physical configuration elements.
The external communication interface 16 is a logical interface which allows a chip of the present invention to be described later, which includes the CPU 10 and the like, to perform direct communication with the outside. A conventional IC card only includes a logic interface for communicating only with a device which is physically connected thereto, typically, only with an IC card terminal. However, the autonomous IC card 1 of the present invention includes the external communication interface 16 which performs direct communication with an external device (a service client with the chip of the present invention incorporated therein, which will be described later) in addition to the logic host interface. Note that this external communication interface 16 is an interface which performs communication in accordance with a protocol to be described in detail later in “4. API protocol for the present chip”.
The communication control unit 15 is a software module which controls communication with the external device via the external communication interface 16. The communication control unit 15 is the software module which realizes the entirety of “10. API specification for the present chip” to be described later. The software module is closely related to “10.1 Session management command group” and “10.2 Transaction management command group” in particular. Communication is performed directly with the external device by use of this module.
The encryption processing unit 14 is a module for enabling various types of mutual authentication and encryption communication as defined in “3.4 Authentication, access control and encryption”, “5. eTP key certificate”, and “6. key entity”, which will be described later. The encryption processing unit 14 selects and switches appropriate mutual authentication and appropriate encryption communication out of a plurality of options of mutual authentication and a plurality of options of encryption communication respectively. Here, the risk of theft of the data contents or falsification of the data via the intermediate device such as the IC card terminal will be further reduced by performing the mutual authentication and the encryption communication by use of the encryption processing unit 14.
Note that a configuration unit according to the present invention shown in
Now, description will be made regarding overall characteristics of the IC chip to be incorporated in the autonomous IC card of the present invention.
The IC chip according to the present invention is designed to function as anode in a distributed environment. Therefore, if a device, in which the IC card of the present invention is connected to an IC card terminal main body including an IC card reader/writer either in a contact mode or in a contactless mode to operate the device, is configured to be capable of physically communicating with, for example, another IC card via a network, each of those IC cards severally including the IC chips according to the present invention has a function as a node on the communication network. Moreover, in this event, the IC card reader/writer and the IC card terminal main body play a role as a gateway (bridge) for making communicable a physical layer of contactless communication with the network. In other words, the above-described external communication interface 16 controls the IC card communication as the node in a distributed system, while the host device interface 17 plays the role for making communicable the physical layer of the contactless communication.
Therefore, in order to function as the node in the distributed environment, the IC chip according to the present invention has a unique identifier (ID) in the entire distributed system, which is represented by the above-described network as the simplest example.
Moreover, the IC chip incorporated in the autonomous IC card of the present invention identifies a plurality of devices which are connected via the network and severally provided with the similar IC chips, and performs mutual authentication with those devices first. The IC card is designed to then perform communication with those devices after confirming those devices as qualified entities. There are two modes upon the authentication, namely, an (information) issuer mode and an owner mode. These modes will be described in detail later.
Furthermore, the IC chip according to the present invention adopts an access control list based on the above-described ID to protect resources owned by the IC chip. That is, the access control list is added to each of chips and files (and records).
The IC chip according to the present invention deals with “owner”, “issuer”, and “other” service clients uniformly. The IC card issues an application programming interface (API) for changing the access control list in accordance with authority owned by each service client. In this way, the IC chip can flexibly perform control such as restriction, release, or transfer of access rights.
Meanwhile, the IC chip according to the present invention supports a hybrid mode for retaining contents while distributing the contents among a plurality of contents holders, for example, between the chip of the present invention and a value information storage server on the network. The IC chip according to the present invention further provides a link function between the contents as a mechanism for supporting the hybrid mode.
Next, description will be made regarding a concrete example of communication by use of the autonomous IC card of the present invention.
In the drawing, an autonomous IC card 1a is connected to an IC card reader/writer 2a provided on an IC card terminal main body 3 either in a contact mode or in a contactless mode. Meanwhile, an autonomous IC card 1b is similarly connected to an IC card reader/writer 2b provided on the IC card terminal main body 3 either in a contact mode or in a contactless mode.
In the configuration as described above, when an operator intends to cause the autonomous IC card 1a to communicate with the autonomous IC card 1b, the operator inputs an instruction to an input terminal (not shown) provided to the IC card terminal main body 3. In response to the instruction, the IC card terminal main body 3 transmits a command to the IC card 1a via the IC card reader/writer 2a. Upon receipt of the command, the autonomous IC card 1a directly and autonomously communicates with the autonomous IC card 1b in a software manner via the external communication interface 16 shown in
Upon the communication by use of the autonomous IC card of the present invention, the other one to communicate with does not need to be an IC card, but may be another communication device. In the drawing, the IC card terminal main body 3 is connected to a communication device 5 via a network 4. When the autonomous IC card 1 communicates with the communication device 5 via the network 4, the autonomous IC card 1 which has received a command from the IC card terminal main body 3 communicates with the communication device 5 directly and autonomously in a software manner.
Now, description will be made regarding detailed specifications of the IC chip (hereinafter simply referred to as the “present chip”) which is incorporated in the autonomous IC card of the present invention. In the following description, contents holders (CHs) correspond to the above-described autonomous IC cards 1 and 1a, and service clients (SCs) correspond to all the devices communicating with the autonomous IC cards 1 and 1a, that is, to the above-described IC card terminal main body 3, the autonomous IC card 1b, and the communication device 5.
Here, in order to facilitate understanding of the overview, a table of contents will be provided hereunder and indexes will be provided to the respective configurations of the IC chip in the following description.
1.1 The present chip as a node in the distributed environment
1.2 Mutual authentication method specified with the present chip ID
1.3 Resources protection mechanism by the access control list method based on the present chip ID
1.4 Realization of comprehensive access control on the chip owner, the value information issuer, and the value information user
1.5 Transaction mechanism with roll-back capability
1.6 Storage structure having the link function
1.7 Consistency with related chip systems
1.8 Moderate standardization corresponding to various chips
2.1 System architecture
2.2 The present chip identifier (the present chip ID)
3.1 The present chip
3.2 Data structure model
3.3 The present chip API
3.4 Authentication, access control and encryption
4.1 Packet type
4.2 List of command identifiers (command ID)
4.3 List of error codes
4.4 MAC, trailer
4.5 Session communication and non-session communication
Utilization of the certificate upon authentication during session establishment
10.1 Session management command group
10.2 Transaction management command group
10.3 File management command group
10.4 Record management command group
10.5 Key entity management command group
10.6 Authentication assistance management command group
1. Introduction
The present chip (a value information-added chip) is a computer system (such as an IC card) which constitutes a storage medium for value information in a highly functional distributed system which a project related to the present invention aims for, and external specifications of the computer system. Based on the assumption of future technological advance, the present chip is put into a series of the 8-bit CPU version, the 16-bit CPU version, and the 32-bit CPU version, and the present chip provides a common command and a common message format concerning a common operation. Among various systems of the specifications of the present chip, this description particularly explains an overview of the specifications in the case of adopting the IC chip of the 16-bit CPU version as a target hardware.
In this chapter, description will be made regarding characteristics of the present chip in comparison with other existing tamper-resistant chips.
1.1 The Present Chip as a Node in the Distributed Environment
Unlike a conventional IC chip which is designed as a computer peripheral unit to be operated via a reader/writer, the present chip is designed as a node in a distributed environment. A service provider module on a network and the chip, and the chip and a card, perform peer-to-peer communication on an equal basis. A reader/writer device constitutes a gateway (bridge) for making communicable a physical layer of contactless communication with a local area network (LAN).
In architecture of the present chip, the present chip has an identifier (the present chip ID) which is unique in the entire distributed system. The present chip ID is used not only for identifying the chip physically, but also for controlling a path in the distributed environment. Here, upon authentication communication, the present chip ID is utilized by the other one to communicate with as an identifier.
Therefore, the target for authentication of the present chip is not the reader/writer, but is calculation entities (contents holders) on the network, the calculation entities exchanging information with the chip via the network and the reader/writer.
1.2 Mutual Authentication Method Specified with the Present Chip ID
The present chip performs communication after performing mutual authentication and thereby confirming that the other one to communicate with is a qualified entity. In the present chip architecture, the present chip-incorporated contents holders (CHs) and the present chip-incorporated service clients (SCs) both include consistent unique identifiers (the present chip ID), and identify the present chip ID of the other one to communicate with after the mutual authentication.
1.3 Resources Protection Mechanism by the Access Control List Method Based on the Present Chip ID
The present chip specifies a SC which issues the present chip API through the mutual authentication. Therefor, an access control list based on the present chip ID is used to protect resources owned by the present chip. The present chip at the moment expresses attributes such as an “issuer”, an “owner” and the like by use of the present chip ID with respect to the resources. Moreover, it is possible to designate commands which can be issued by the “issuer”, the “owner”, and “other” SCs by use of the access control list.
1.4 Realization of Comprehensive Access Control on the Chip Owner, the Value Information Issuer, and the Value Information User
Various applications storing value information may be implemented in the present chip. The value information includes various types. For example, the following types of information are conceivable as the information in the chip:
The present chip uniformly treats the “issuer”, the “owner”, and the “other” SCs in the access control list, and issues an API for changing the access control list in accordance with authority owned by each SC. In this way, the present chip can flexibly perform control such as restriction, release, or transfer of access rights.
1.5 Transaction Mechanism with Roll-back Capability
It is essential to safely transfer the value information to the present chip. Therefor, concerning creation and deletion of the value information in particular, the present chip provides a transaction mechanism to ensure atomicity of processing. After starting a transaction, an operation attributable to an issued command is reflected by a commit command upon ending the transaction. If an abort command is issued, or if the commit command does not reach on or before a defined timeout duration, then the issued command is subjected to roll-back. Similarly, if the present chip is powered off in the course of the transaction due to any trouble, then roll-back processing takes place in an initial state when the present chip becomes active again.
1.6 Storage Structure Having the Link Function
Various types of tamper-resistant chips currently exist in terms of information processing capability and also in terms of resources such as storage capacity or the like. Among all, there may be a case where hardware with small resources cannot store all the value information of conceivable applications into the chip. Meanwhile, it is also desirable in view of processing efficiency to adopt a method of distributing the value information into the chips for retention. Therefore, the present invention supports a hybrid method for distributing and retaining the contents among a plurality of the contents holders of the present invention, such as the present chip and a value information storage server on a network. Moreover, the present invention provides a link function between the contents as a mechanism for supporting the hybrid method.
1.7 Consistency with Related Chip Systems
The present chip has consistency with other architectures of the project related to the present invention regarding API command conventions, error codes, methods of statically and dynamically treating the resources, and the like. For example, general parts of the error codes are in common between a related chip and the present chip. In this way, the present invention assists an engineer having experience in development on the related chip architecture in developing the present chip applications.
1.8 Moderate Standardization Corresponding to Various Chips
The present chip provides API systems consistent with various IC cards including 8-bit to 32-bit CPUs, contact/contactless/dual interfaces, and smart cards to radio frequency identifications (RF-IDs).
2. System Specifications
2.1 System Architecture
The present chip architecture is distributed system architecture for safely storing tamper-resistant value information and for safely exchanging the tamper-resistant value information on a computer network. The present chip architecture essentially includes the following elements.
(A) Value Information Network Infrastructure (Entity Network Infrastructure)
This is the architecture for exchanging the value information and includes the following two elements.
A-i) The Present Chip-incorporated Content Holders (CHs)
The present chip-incorporated contents holders are calculation entities on the distributed system. The present chip-incorporated content holders store the value information and provides the present chip-incorporated API, thereby allowing operation of this value information from the outside. For example, the present chip-incorporated content holders include the following.
The present chip: A tamper-resistant LSI chip which safely stores the value information.
A present chip box: A large-volume electronic safe housed in a tamper-resistant casing, which safely stores the value information.
A-ii) The Present Chip-incorporated Service Clients (SCs)
The present chip-incorporated service clients are calculation entities for accessing the value information stored in the present chip-incorporated content holder through the present chip API. For example, the present chip-incorporated service clients include the following types.
The present chip: A sophisticated one of the present chips also has a function as a client.
An issuing server: A server which issues the value information and stores the value information in the present chip-incorporated content holder.
A service field system: An application system which uses the value information stored in the present chip. The service field system includes an electronic ticketing gate, for example.
*Attention: There exists also a calculation entity which serves as the present chip-incorporated service client as well as the present chip box.
(B) Authentication/Encryption Network Infrastructure (AENI)
This is an authentication system in the case where the present chip implements authentication and encryption of a public key encryption system. An authentication station plays a main role.
(C) Application Network Infrastructure (ANI)
This is equivalent to various communication systems which depend on applications. In the case of the electronic ticketing, for example, the application network infrastructure includes network protocols for instructing search or purchase of tickets, and the like. The instructions up to the purchase are conducted within the ANI frames, and transfer of the ticket being the value information is conducted in the ENI which applies the functions of the present chip.
2.2 The Present Chip Identifier (The Present Chip ID)
The present chip-incorporated content holders and service clients severally have unique identifiers, each of which is referred to as the present chip identifier (the present chip IDs). The present chip ID is used on the network for authentication of the present chip-incorporated content holders and service clients, path control of messages, and the like. The present chip ID is expressed by a 16-octet (128-bit) number.
* The present chip ID is an exchange format of an identifier used in the ENI communication protocols. The present chip ID does not define an internal saving format within the present chip.
* Considering facility of implementing the path control, it is also conceivable to adopt a implementing method which defines an identifier in a protocol on a network layer of the ENI directly as the present chip ID. For example, lower bits of a network address may be applied to the present chip ID without modification.
* The present chip ID for the owner will be defined as “0x00˜00” (all “0”).
For example, if the present chip-incorporated service client having the present chip ID “X” establishes a session after being authenticated in an owner authentication mode and then creates a file in the session, an issuer ID column of the file stores “0”.
* The present chip ID for an administrative superuser will be defined as “0xff˜ff” (all “1”).
3. Outlines of the Present Chip
3.1 The Present Chip
The present chip is a small-size calculation entity used for allowing a user, who directly receives services using the value information from various enterprises, to carry the value information. The present chip is an object to be mainly handled by these specifications. In general, the present chip is thought to be implemented principally on hardware such as an IC card, a smart card, or a portable terminal. Considering large differences in information processing capabilities and resources provided in these pieces of hardware, and also considering the fact that the tamper-resistant technology still remains at a stage of development, the specifications of the present chip provide various specifications corresponding to various types of hardware while standardizing only the interfaces, whereby the present chips are made into series.
3.2 Data Structure Model
The value information to be stored in the present chip box or the present chip will be visible from outside as a following hierarchical data structure.
● Folder
A structure for compiling a plurality of sets of files.
Only a route folder exists in the present chip /16.
● File
The resources for storing the value information. Whereas a record is stored in the file, the present chip /16 adopts a structure in which only a single record is stored in one file.
3.3 The Present Chip API
The present chip is operated by the present chip API from the present chip-incorporated service client.
Basically, the present chip API is a protocol based on a session using the following procedures:
→ Establishment of a session (transaction);
*A session/transaction method involves a high frequency of message exchanges and therefore may be unsuitable for an application which requires high responsiveness such as “& Go”. Accordingly, authentication or encryption is applied to each command message. A non-session protocol is also adopted concerning part of commands.
* A command issued as “session ID=0” will be treated as a non-session mode.
▪ Session Commands
eopn_ses Open Session
ecfm_ses Confirm Session
ecls_ses Close Session
▪ Transaction Commands
eopn_tra Open Transaction
ecfm_tra Confirm Transaction
ecom_tra Commit Transaction
eabo_tra Abort Transaction
▪ File Operation Commands
ecre_fil Create File
edel_fil Delete File
etra_fil Transfer File
eupd_fim Update File Mode
eenc_fil Encrypt File
edec_fil Decrypt File
▪ Record Operation Commands
eupd_rec Update Record
erea_rec Read Record
▪ Key Entity Operation Commands
ecre_key Create Key
edel_key Delete Key
eupd_key Update Key
▪ Authentication Ancillary Command
ecfm_cer Confirm Certificate
▪ Control Commands
epol_chp Polling Chip
eini_car Initialize Card
eupd_cer Update My Certificate
eupd_cpk Update CA Public Key
3.4 Authentication, Access Control and Encryption
The present chip and the present chip-incorporated service client perform the mutual authentication upon establishing the session. Being specialized in the hardware or the like which is incorporated in the chip, various types of concrete algorithms for this authentication can be used.
• Authentication Modes
Authentication includes an (information) issuer mode and an owner mode, which are designated upon authentication. The authentication algorithm is (generally) different depending on each mode.
The (Information) Issuer Mode:
A mode to authenticate the present chip-incorporated service client as an issuer of the file. After being authenticated by the issuer mode, the file created by the present chip-incorporated service client becomes accessible with the issuer authority, and other resources become accessible with other authority.
The Owner Mode:
A mode to authenticate the present chip-incorporated service client as an owner of the chip. A human-friendly authentication method such as a password is usually used. The present chip-incorporated service client authenticated by the owner mode possesses the owner authority.
• Status of the Present Chip After the Mutual Authentication
After the authentication, the present chip retains the following information:
• Access Control
The following information is attached to the chip and the file (and the record):
The access is restricted in accordance with the authority to be owned by the session defined as below.
• File Access Mode
The mode for allowing the SC having the present chip ID=eid to access a file F in the present chip (the present chip ID of the present chip SC which has created the file F=F.eid) includes the following three types.
1. The Owner Access:
Access in the session after clearing the owner authentication
* In this case, eid=0x00 (all “0”)
2. The (Information) Issuer Access:
Access in the session after clearing the (information) issuer authentication, where eid=F.eid.
3. Other Access
Access in the session after clearing (information) creator authentication, where eid !=F.eid, or access in a non-session mode.
• The Access Control List for a Route Folder
• The access control list for a file
• The Access Control List for a Key Entity
4. The Present Chip API Protocol
4.1 Packet Type
* The mark “□” on the right end of the packet type represents a unencrypted portion and the mark “▪” represents an encrypted portion in an encoding session, respectively.
* Numeric data equal to or more than 2 octets are stored using Little Endian format.
A Routing Header
The Present Chip Session Unit (Forward)
The Present Chip Session Unit (Backward)
MAC, Trailer
4.2 List of Command Identifiers (Command ID)
A command identifier (command ID) of the present chip API is expressed by a positive 1-byte integer.
The command identifiers are commonly defined in the series of the present chips /8, 16, and 32, which are as follows.
4.3 List of Error Codes
An error code of a command in the present chip is expressed by a signed integer. When an operation is closed normally, either E_OK=0 or a positive number representing a result of the operation is returned. If the operation is not closed normally and some errors occur, a negative number is returned. The error code is expressed by the following conventions.
• Description “E_” represents a general error that occurs in local command processing in the chip (common to the error codes of a related chip).
• Description “EN_” represents a general error concerning communication (common to the error codes of a related chip except session error).
• Description “ES_” mainly represents a general error concerning security (dedicated to the present chip).
4.4 MAC, Trailer
1 Check SUM
Used in a session/transaction encryption communication path.
First 64 bytes in a key of a secret key encryption for the encryption communication path is used as a key K. Here, HMAC is calculated by the following formula.
MD5 (K xor opad|MD5 (K xor ipad|TEXT))
* In the case of performing the encryption communication after establishment of the session, a number obtained by repeating a 16-byte encryption key for 4 times, in other words, an exchanged random number in the case of RSA authentication of eopn_ses ( ), is used as the 64-byte secret key by appending as follows.
K=Ra|Rb|Ra|Rb|Ra|Rb|Ra|Rb|
4.5 Session Communication and Non-session Communication
Regarding communication with the present chip, the session/transaction as the “encryption” communication path is established after the “mutual authentication”, and “encrypted” message communication is performed thereafter. Concerning the “erea_rec command” (i.e. read the contents of the record), non-session communication, which is directly executed without passing through an “authentication” phase, is supported. In this event, it is possible to start up by retrieving the command with the “session ID=0”, instead of establishing a session. This access by the non-session communication will be successful if the relevant file permits “the other access”. At this point, an access packet is not encrypted. This is used in places where a “touch & go application” is highly required, such as in ticket gating.
* A service provider will bear a higher risk by use of this mode. The following sound source chip is incorporated.
5. eTP Key Certificate
Utilization of the certificate upon authentication during session establishment
1. Outline
The mutual authentication upon establishing a session with the present chip /16 is based on the premise of a public key basis and existence of PKI.
*Although it is assumed that there will be a plurality of the present chip-incorporated CA in the future, the present chip-incorporated CA is limited to one in this version.
As a step prior to an authentication step, the present chip-incorporated nodes (which refer to the present chip-incorporates SC and the present chip-incorporated CH collectively) transmit the public keys of the present chips of their own to each other as the certificates signed by the present chip device issuer. * see Note (1)
The present chip-incorporated node has a public key of a key signed by a certificate issuer in the form of a certificate. Validity is confirmed by use of this key.
Then, the following is verified. *see Note (2)
“Validity of the public key transmitted from the opponent node”
=“the official signature by the issuer”+“the certificate in validity period”
When the validity is not confirmed, the communication is cut off without establishing the session. *see Note (3)
* Note (1)
In the authentication on the public key basis, consideration should also be made regarding the case where the certificate is “cancelled and nullified” upon transferring/exchanging a high value in a session thereafter. The present chip /16 uses either one of the following:
1. a CRL (nullified list), (however, the data size becomes large); or
2. server access for inquiring whether or not a specific certificate is “cancelled and nullified”.
* Note (2)
In addition, it is also possible to place an inqury whether or not the certificate is “cancelled and nullified” as described in Note (1).
* Note (3)
Before confirmation of the validity of the certificate is completed, it is effective to start the authentication step tentatively and adopt an implementation in which the validity is confirmed by another task, while transmitting a packet necessary for the authentication to the opponent, or waiting for a packet necessary for the authentication from the opponent. Although such an implementation requires interruption and a multi-task OS to be achieved in the chip, it is still effective means for implementing the entire authentication in a short processing time period.
The foregoing description is a device for reducing the time required for initial setting of communication of the node such as the present chip or a card. The node implemented on a server machine should always complete confirmation of the signature off-line in the first place and then proceed to confirmation of “cancellation and nullification”. This is for preventing a DoS which is a waste of server inquiry processing attributable to transmission of an invalid certificate from a device having the invalid certificate.
The format of the eTP key certificate (ver. 0.1)
• ver: a version number of the certificate format, which is set as ver=“1” in ver. 0.1
• Certificate number: a certificate serial number of the key for the present chip ID
• Signature method: signature algorithm specifiers
0: the portion up to the key field portion of the certificate is subjected to SHA-1 hash, and the result is subjected to RSA encryption (implementation)
1: Reserved
2: Reserved
3: Reserved
• Issuer ID: an ID of the issuer (a CA station) of the certificate, which is fixed to “0” in ver. 0.1
• Start of Effective duration, End of Expiration Date: effective duration of the certificate
• Unsigned 4 octet integers (Accumulation of seconds starting from 0:00 AM on Jan. 1, 2000)
• CAKEY#: an ID number of a key for distinction when a plurality of keys are used by the CA for key signature
• Key length: a bit-length size of a key having an added end.
* When the key is not a multiple number of 8 octets in the certificate, “0” is added (null padding) to the end of the key field for storing the key, and the key is thereby stored as 8-octet multiple number data. The “key length” bit in the key field is an effective key.
• Signature length: A bit length of the hash (such as sha-1) used for the signature to be added to the end
* The hash obtains 8-octet multiple number data with null padding at the last if necessary, and then creates the signature by encrypting the number with the CA key.
When the signature is confirmed, this 8-octet multiple number data added to the end are decrypted with the public key of a CA server saved in the present chip-incorporated node. The head signature length bit among the decrypted values becomes a hash value to be used for confirmation.
• Concrete example of the length (when RSA/sha-1 signature is applied):
This byte length is made to be a multiple of 8 by null padding, and the 24-byte data are signed by RSA encryption.
The overall length of the certificate is calculated as follows:
the length of the certificate is equal to
• a fixed length portion (40 bytes); and
the length of the key portion is equal to
• a signature portion (128 bytes),
accordingly, the overall length is equal to the sum of the two portions (168 bytes).
Since the signature portion after encryption requires 1024 bits, the length of 128 bytes is used.
However, it should be noted that the key portion is not simply equal to 128 bytes.
This is because, regarding the RSA key, a common quotation of 1024 bits as the public key takes the pair of N of 1024 bits and an exponent e(e, N) into account. Therefore, it is necessary to input the both (e, N) into the key portion.
In the case of RSA, the e and N will be inputted to the key field as described below.
The byte length for e: (1 byte)
The value e itself: This is expanded into a byte unit as required to be buried as a byte sequence. Subsequently, the value N is buried as a byte sequence.
Considering the case where e=3 in (e, N), as an example, the byte data of 130 bytes is inputted to the key field as described below.
Public Key=0x01|0x03| byte sequence of N (128 bytes)
Since 130 is not a multiple of 8, the value is padded to 136 bytes. Hence, the key data occupies 136 bytes.
Accordingly, the overall length can be calculated as follows:
In this way, the aggregate length is equal to 304 bytes when e=3.
6. Key Entity
The key entity is a system data format which compiles an encryption key and information necessary for value information operation by use of the encryption key. The encryption key and the information are stored in a normal file by the present chip.
Encryption Mode Specifier: Specifies which encryption algorithm each of KEY (1) and KEY (2) is a key for. As described below, such specification is performed by the same mode as specification of the encryption algorithm for the encryption communication path in “eopn_ses”.
7. Standard Content Format of the Invention
The standard content format is a standard content data format which manipulates a value information operation inside the present chip. By operating the key entity, it is possible to add an encryption/decryption operation and to change accounting information inside the key entity to be atomic in this event.
Basically, an assumption is made herein that a sales model that charges money for decrypting of the encrypted contents is surely performed inside the present chip.
▪ Overall Content Format
(A) Content Header
(B) Accounting Header
(C) Encrypted Contents
(D) Signature Trailer
K is created by the following method using K1 and K2 obtained by decrypting the encryption key (1) and the encryption key (2) included in the contents with a key in the key entity as 64-byte secret keys in the case of HMAC with MD 5 [RFC 2085]
K=K1|K2|K1|K2|K1|K2|K1|K2
▪ Accounting Header
▪ Encrypted Contents
▪ Signature Trailer
Similar specifications to the packet of the present chip
8. Settlement Processing in Operating Standard Contents of the Invention by the Key Entity
The following method is adopted as a calculation method using the key entity.
(1) Calculation of a charged amount of the accounting header in the present encryption contents (which is only a fixed amount in the present chip /16).
(2) Subtraction processing for an amount of settlement from a MONEY field of the key entity.
9. Specifications of the Present Chip API (Data Type Definitions)
• Definition Examples by C Language Expressions
10. Specifications of the Present Chip API (Command Definitions)
10.1 Session Management Command Group Session Construction Open/Confirm Session
[Feature Outline]
A safe session transmission path is constructed for the present chip. The “eopn_ses” is used in the case of using authentication when 1 path is satisfactory, and the “eopn_ses” and “ecnf_ses” are used in this order in the case of using authentication which requires 2 paths.
By this session construction, a temporarily common encryption key, which is effective only during the session between the present chip-incorporated service client side, Caller and the present chip side, a Callee side, is shared in common.
The mode of authentication and the encryption type are selectable in accordance with parameters in the packet. An error occurs when authentication/encryption unusable on the present chip side is specified.
[Outbound Packet Format]
[Return Packet Format]
[Function Expression]
[Outbound Packet Format]
[Return Packet Format]
[Detailed Feature]
The “open/confirm session” command establishes a session as the safe encryption communication path after the mutual authentication between the present chip-incorporated service client and the present chip. The concrete actions depend on the authentication and encryption modes, and the modes usually depend on an encryption supporting function of the present N chip hardware (implementation dependency). A session establishment protocol includes authentication in the issuer mode and authentication in the owner mode, which are distinguished by the authmode parameter in the “open session” command.
▪ Authentication in the Issuer Mode (Authmode=ISSUER) by the Public Key Encryption
DES encryption is performed by use of Rb as the key.
In this event, Ra is used as the session ID.
▪ Authentication in the Owner Mode (Authmode=OWNER) According to the Secret Key Encryption
An example of an operation for establishing the session according to the 2-path mode owner authentication using the “eopn_ses” and “ecfm_ses” will be described below. This mode basically applies the following method. Specifically, the present chip retains a password depending on the owner, and authentication is performed by use of the password. When authentication is started, the present chip creates a random number and transmits the random number to the R/W. Thereafter, the R/W side uses the random number to encrypt the password, and then transmits the password to the present chip.
[Outbound Packet Format]
[Return Packet Format]
[Access Control]
This command is always usable by the present chip-incorporated service client which constructed the session.
[Outbound Packet Format]
[Return Packet Format]
[Outbound Packet Format]
[Return Packet Format]
[Detailed Feature]
Similar to “eopn_ses” and “ecfm_ses” Concerning authentication and encryption
However, only the following present chip APIs can be issued after establishment of the transaction. An error will occur if any other API is issued.
• Create File ecre_fil
• Delete File edel_fil
• Create Record ecre_rec
• Delete Record edel_rec
• Update Record eupd_rec
It must be guaranteed that the command sequences issued herein are reflected when “econ_tra” is issued, and that the command sequences are completely rolled back either in the event of issuance of “eabo_tra” or in the event of timeout after passage of a certain time period without issuance of “ecom_tra”.
[Outbound Packet Format]
[Return Packet Format]
[Outbound Packet Format]
[Return Packet Format]
[Access Control]
This command is always usable by the present chip-incorporated service client which constructed the session.
[Detailed Feature]
• The established transaction is committed or aborted.
• When the transaction is committed, all the commands issued between “ecfm_tra” and “ecom_tra” are reflected to a nonvolatile memory of the present chip.
• When the transaction is aborted or when no commitment arrives after waiting for a certain time period, then all the commands issued between “ecfm_tra” and “ecom_tra” are reflected to a nonvolatile memory of the present chip.
10.3 File Management Command Group
[Outbound Packet Format]
[Return Packet Format]
[Access Control]
• Always usable in the issuer mode (the present chip ID of the ISSUER of a parent folder is equals to the present chip ID of the SC which constructed the Session)
• Usable in the owner mode and the other mode if permitted in the access control list of the parent folder
[Outbound Packet Format]
[Return Packet Format]
[Access Control]
• The following conditions must be satisfied to execute “edel_fil”. Attention is needed herein because two types of access control lists are involved.
(CASE 1) Case of the Owner Authentication Access
1. It must be permitted that the route folder may be subjected to the command “edel_fil” as the “owner access”. In other words, “ACL2 of the route folder==1” must be satisfied.
2.It must be permitted that the object file may be subjected to the command “edel_fil” as the “owner access”. In other words, “ACL8 of the file==1” must be satisfied.
(CASE 2) Case of the Issuer Authentication Access
1. It must be permitted that the route folder may be subjected to the command “edel_fil” as the “other access”. In other words, “ACL3 of the route folder==1” must be satisfied.
2. It does not depend on ACL on the object file side (always OK).
(CASE 3) Case of the Other Access
1. It must be permitted that the route folder may be subjected to the command “edel_fil” as the “other access”. In other words, “ACL3 of the route folder==1” must be satisfied.
2. It must be permitted that the object file may be subjected to the command “edel_fil” as the “other access”. In other words, “ACL9 of the file==1” must be satisfied.
[Detail of Operation]
The file having the file ID specified by fid is deleted. A control block specifying a physical position of the file is cleared and the nonvolatile memory is released, and in addition, all data in the memory is set to “0” or “1”.
Request for Transferring a File
Request File Transfer
[Feature Outline]
The contents of the file are transferred to other present chip-incorporated contents holder.
[Packet Format]
[Return Packet Format]
[Detail of Operation]
A chip in which this system call occurred performs a series of processing described below.
The following present chip API sequences are issued to the transfer destination chip.
The transaction is aborted if any abnormality is detected in mid-course. Meanwhile, the commands in the session are not reflected unless the commit command arrives normally.
[Return Packet Format]
[Detailed Feature]
▪ Operaton of edic_fil( )
▪ Operation of eenc_fil( )
[Outbound Packet Format]
[Return Packet Format]
[Access Control]
• Always usable in the issuer mode (the present chip ID of the ISSUER of a parent folder is equals to the present chip ID of the SC which constructed the Session) with respect to the object file
• Usable in the owner mode and the other mode if permitted in the access conrol list of the object file
[Feature Outline]
The access control list of the file is changed to a specified value.
[Return Packet Format]
[Access Control]
• Always usable in the issuer mode (the present chip ID of the ISSUER of a parent folder is equals to the present chip ID of the SC which constructed the Session) with respect to the object file
• Usable in the owner mode and the other mode if permitted in the access control list of the object file
10.4 Record Management Command Group
[Packet Format]
[Return Packet Format]
[Access Control]
• Always usable in the issuer mode (the present chip ID of the ISSUER of a parent folder is equals to the present chip ID of the SC which constructed the Session) with respect to the object file
• Usable in the owner mode and the other mode if permitted in the access control list of the object record
[Detail of Operation]
A request for writing data of cnt octets from the beginning in a blk record is issued. An upper limit may be provided to cnt depending on hardware conditions. The actually written octet number is returned to rCnt.
[Return Packet Format]
[Access Control]
• Always usable in the issuer mode (the present chip ID of the ISSUER of a parent folder is equals to the present chip ID of the SC which constructed the Session) with respect to the object record
• Usable in the owner mode and the other mode if permitted in the access control list of the object record
[Detail of Operation]
A request for reading data of cnt octets from the beginning in the blk record is issued. An upper limit may be provided to cnt depending on hardware conditions. The octet number actually read is returned to rCnt.
The command is normally issued and executed when the session is established. However, it is also possible to call the command with sid=0 by the present chip-incorporated service client which does not establish the session, by specialization of “touch & go” applications. In this case, execution of the command succeeds when reading out with the other authority is permitted in the access control list of the record.
10.5 Key Entity Management Command Group
[Restricted Items for Implementation]
A key entity in this system has the following restrictions.
[Return Packet Format]
[Return Packet Format]
[Return Packet Format]
[Return Packet Format]
[Return Packet Format]
[Return Packet Format]
[Access Control]
• Always usable in the issuer mode (the present chip ID of the ISSUER of a parent folder is equals to the present chip ID of the SC which constructed the Session) with respect to the object key entity
• Usable in the owner mode and the other mode if permitted in the access control list of the object key entity
10.6 Authentication Assistance Management Command Group
Checking the eTP Certificate
Confirm Certificate
[Return Packet Format]
▪ 5.3 Quasi Present Chip API Command Definitions
The API commands described below have formats similar to the present chip API commands. Nevertheless, the following commands are not always issued by the present chip-incorporated service client but also issued by other entities. These commands are mainly centered on management and operation depending on the hardware, and interfaces for supporting lower layer of communication. These commands may be issued by a chip reader/writer unit or issued by a computer in the event of fabrication.
[Return Packet Format]
[Access Control]
This API is always usable.
It does not have to be during the session.
[Detailed Feature]
The present chip ID of the chip is stored and returned to a srcID portion in a routing header portion of the return packet of “epol_car”. Accordingly, anybody can use this API for obtaining the present chip ID in the beginning.
Anybody can issue this command even if it is not during the session.
[Return Packet Format]
[Detailed Feature]
A system control block is initialized in accordance with a given argument.
All other memory areas are cleared and set to “0”.
[Access Control]
This command is accepted only when the source present chip ID of the present chip=0xff . . . ff (all “1”).
[Return Packet Format]
[Return Packet Format (Example)]
[Return Packet Format]
[Return Packet Format (Example)]
▪ DES
Method of Creating a 56-bit DES Key Out of a 64-bit Secret Key
The lowest bit of each octet is assigned as a parity bit as shown below (a chip just ignores the parity bit but does not check it). The 56 bits obtained by adding the upper 7 bits of 8 octets are used as the DES.
As described above, according to the present invention, the autonomous IC card of the present invention autonomously identifies a communication device to be connected via an IC card terminal and communicates directly with the communication device. Therefore, it is possible to guarantee safe communication of accurate information. Moreover, when the autonomous IC card of the present invention includes an encryption processing unit for performing authentication processing mutually with the communication device and for encrypting and decrypting information concerning communication with the communication device, then it is possible to judge propriety of the communication device and to sufficiently reduce a risk of theft of the data contents or falsification of the data via the intermediate device. The significance of such reduction of the risk is particularly high when the data are related to value information such as an electronic ticket. Furthermore, when the encryption processing unit selects and performs appropriate authentication processing and encryption processing out of a plurality of authentication processing and a plurality of encryption processing depending on the type of the identified communication device, it is possible to perform the processing suitable for the identified communication device.
It should be understood that many modifications and adaptations of the invention will become apparent to those skilled in the art and it is intended to encompass such obvious modifications and changes in the scope of the claims appended hereto.
| Number | Date | Country | Kind |
|---|---|---|---|
| P2002-169315 | Jun 2002 | JP | national |
| Number | Name | Date | Kind |
|---|---|---|---|
| 4907270 | Hazard | Mar 1990 | A |
| 5204512 | Ieki et al. | Apr 1993 | A |
| 5434395 | Storck et al. | Jul 1995 | A |
| 5491692 | Gunner et al. | Feb 1996 | A |
| 5532689 | Bueno | Jul 1996 | A |
| 5668875 | Brown et al. | Sep 1997 | A |
| 5710421 | Kokubu | Jan 1998 | A |
| 5771227 | Benayoun et al. | Jun 1998 | A |
| 5778071 | Caputo et al. | Jul 1998 | A |
| 5867577 | Patarin | Feb 1999 | A |
| 5889272 | Lafon et al. | Mar 1999 | A |
| 5901303 | Chew | May 1999 | A |
| 5905245 | Tanaka | May 1999 | A |
| 5923884 | Peyret et al. | Jul 1999 | A |
| 6073198 | Meyer et al. | Jun 2000 | A |
| 6073236 | Kusakabe et al. | Jun 2000 | A |
| 6157966 | Montgomery et al. | Dec 2000 | A |
| 6182215 | Tatebayashi et al. | Jan 2001 | B1 |
| 6185681 | Zizzi | Feb 2001 | B1 |
| 6212649 | Yalowitz et al. | Apr 2001 | B1 |
| 6247644 | Horne et al. | Jun 2001 | B1 |
| 6516997 | Tanazawa et al. | Feb 2003 | B1 |
| 6644554 | Shiro et al. | Nov 2003 | B1 |
| 6704872 | Okada | Mar 2004 | B1 |
| 6708878 | Eguchi et al. | Mar 2004 | B2 |
| 6751671 | Urien | Jun 2004 | B1 |
| 6769609 | Ono et al. | Aug 2004 | B2 |
| 6810521 | Gelgon et al. | Oct 2004 | B1 |
| 7149816 | Port et al. | Dec 2006 | B1 |
| 20010050989 | Zakiya | Dec 2001 | A1 |
| 20020082847 | Vandewalle et al. | Jun 2002 | A1 |
| 20020083317 | Ohta et al. | Jun 2002 | A1 |
| 20030037191 | Baranowski et al. | Feb 2003 | A1 |
| Number | Date | Country |
|---|---|---|
| 1 158 750 | Nov 2001 | EP |
| 09-190515 | Jul 1997 | JP |
| Number | Date | Country | |
|---|---|---|---|
| 20040034766 A1 | Feb 2004 | US |
