JP6382521B2 - Portable electronic device and electronic circuit - Google Patents

Description

  Embodiments described herein relate generally to a portable electronic device and an electronic circuit.

  Conventionally, portable electronic devices such as IC (Integrated Circuit) cards have become widespread. In portable electronic devices, there are cases where the operating system describes the encryption method used when sending / receiving data to / from an external device and the authentication method such as user authentication. To change these, the operating system must be changed. There was a case. In this regard, an IC card invention having a first card manager capable of downloading a privileged application, which is a privileged application, is disclosed.

JP 2003-173427 A

The conventional technique has a problem that sufficient security cannot be ensured when a program is downloaded from an external device.
In order to solve the above-described problems, a portable electronic device and an electronic circuit that can improve security when a program is downloaded from an external device are provided.

The portable electronic device according to the embodiment includes a communication unit, an authentication unit, a storage unit, and a management unit. The communication unit communicates with an external device. The authentication unit is authentication performed in cooperation with the external device by executing the authentication application in a state where the authentication application downloaded from the external device is stored in the storage unit, and includes user authentication, At least one of authentication of the external device and authentication of another device connected to the external device is performed. When the authentication unit succeeds in the authentication, the management unit determines whether or not a predetermined authority is granted to the authentication application, and when the predetermined authority is granted to the authentication application In addition, the authentication application can be downloaded from the external device via the communication unit.

It is a figure which shows an example of a function structure of the IC card 1 which concerns on this embodiment. 3 is a diagram illustrating an example of information stored in an EEPROM 40. FIG. It is a figure which shows an example of the information stored in RAM50. 4 is a diagram illustrating an example of information stored in a ROM 60. FIG. FIG. 3 is a diagram schematically showing how the IC card 1 downloads a new authentication application 42 from the external device 100. It is a sequence diagram which shows simply an example of the flow of the download process which the external apparatus 100 and IC card 1 perform in cooperation. It is a figure which shows an example of the authentication command transmitted to the IC card from the external device 100. 6 is a diagram illustrating an example of a response returned from the IC card 1 to the external device 100. FIG. 4 is a flowchart illustrating an example of a flow of processing realized by an authentication application 42 in the IC card 1. 10 is a flowchart illustrating an example of a flow of processing realized by an operating system 61 when a downloadable notification is performed. 10 is a flowchart illustrating an example of a flow of processing realized by an operating system 61 when a session key notification is performed. 10 is a flowchart illustrating an example of a flow of processing realized by an operating system 61 when a download start request command is received from an external device 100. 7 is a flowchart illustrating an example of a flow of processing realized by the operating system 61 after downloading of the authentication application 42 is completed.

  Hereinafter, embodiments of a portable electronic device and an electronic circuit will be described with reference to the drawings. In the following description, an IC card will be described as an example of a portable electronic device. However, the present invention is not limited to this, and the portable electronic device may be applied to a mobile phone, a tablet terminal, or the like. IC cards can be used for various purposes such as cash cards, credit cards, transportation cards, licenses, and resident number cards.

  The IC card is activated upon receiving power supply from an external device (becomes operable). For example, in the case of a contact type IC card, the IC card is activated by receiving an operation power supply and an operation clock from an external device via a contact unit as a communication interface. In the case of a non-contact type IC card, the IC card receives a radio wave from an external device via an antenna as a communication interface and a modulation / demodulation circuit, and is operated by a power supply unit (not shown) based on the radio wave The power and the operation clock are generated and activated.

  FIG. 1 is a diagram illustrating an example of a functional configuration of an IC card 1 according to the present embodiment. The IC card 1 includes, for example, a communication unit 20 that constitutes an electronic circuit 10, a CPU (Central Processing Unit) 30, an EEPROM (Electrically Erasable Programmable Read-Only Memory) 40, a RAM (Random Access Memory) 50, and a ROM (Read Only). Memory) 60 and a communication member 70. The IC card 1 has an electronic circuit 10 embedded in a card-like casing (main body) made of plastic or the like. The electronic circuit 10 is integrally formed with the housing in a state where it is connected to the communication member 70.

  The communication unit 20 communicates with an external device using the communication member 70. When the IC card 1 is a contact type IC card, the communication member 70 includes the contact portion described above. On the other hand, when the IC card 1 is a non-contact type IC card, the communication member 70 includes the antenna described above, and the communication unit 20 includes a modulation / demodulation circuit and the like.

  The CPU 30 implements various controls described below by executing programs stored in the EEPROM 40 and the ROM 60.

  FIG. 2 is a diagram illustrating an example of information stored in the EEPROM 40. The EEPROM 40 stores application management information 41 managed by an operating system 61 (described later), an authentication application 42, and the like. Here, the authentication application 42 is, for example, an application program downloaded to the IC card 1 from an external device, and when user authentication, authentication of the external device, and the external device are connected to a server device or the like via a network, A process for authenticating the server device is described. Although a single authentication application 42 is illustrated in FIG. 2, a plurality of authentication applications 42 may be stored in the EEPROM 40. In addition to the program code, the authentication application 42 includes information such as a public key 42-1, a secret key 42-2, and authentication information 42-3. Hereinafter, the public key 42-1 may be referred to as a public key (2).

  The application management information 41 is associated with application identification information (AID; Application Identifier), the start address of the EEPROM 40 in which the application program is stored, privilege information, and the like for each application program such as the authentication application 42 stored in the EEPROM 40. Information. The privilege information is set by the operating system 61 when the application program is installed, and includes information indicating delegation of authority to download the program. Information stored in the EEPROM 40 is defined by standards such as ISO / IEC 7816, ISO / IEC 14443, ISO / IEC 10536, ISO / IEC 15693, and ETSI. Note that the IC card 1 may include a readable / writable nonvolatile memory such as a flash memory instead of the EEPROM 40.

  FIG. 3 is a diagram illustrating an example of information stored in the RAM 50. The RAM 50 functions as a working memory that temporarily stores information being processed by the CPU 30. For example, current application information 51, a download permission flag 52, a session key storage area 53, a download permission flag 54, and the like are set in the RAM 50. These pieces of information are managed by the operating system 61. The current application information 51 stores the AID and privilege information of the authentication application 42 currently set to be active. Of the current application information 51, the content of the AID of the authentication application 42 is determined by the SELECT command. When the AID is determined, the corresponding privilege information is read from the EEPROM 40 by the operating system 61 and written into the RAM 50 as the privilege information of the current application information 51. The download permission / prohibition flag 52 is normally set to a download-disabled state, and is set to a downloadable state when a notification is made from the authentication application 42 upon successful authentication. The session key storage area 53 stores a session key generated by the authentication application 42. The download permission flag 54 is normally set to a non-permitted state, and is set to a permitted state when preparation for downloading a program from an external device is completed.

  FIG. 4 is a diagram illustrating an example of information stored in the ROM 60. The ROM 60 stores an operating system 61 that provides, for example, an API (Application Programming Interface) 62-1 and API 62-2 to the authentication application 42. The operating system 61 is an operating system capable of downloading and adding a program such as the authentication application 42 such as a Java (registered trademark) card. The API 62-1 is an API for causing the authentication application 42 to notify the operating system 61 of a downloadable state. The API 62-2 is an API for causing the authentication application 42 to perform session key notification to the operating system 61. Part or all of the operating system 61 may be stored in the EEPROM 40.

  The IC card 1 configured as described above can download the authentication application 42 from an external device. FIG. 5 is a diagram schematically illustrating how the IC card 1 downloads a new authentication application 42 from the external device 100. The external device 100 includes, for example, an authentication device 110, a CPU 120, a card reader / writer 130, and a storage unit 140.

  The authentication device 110 includes, for example, an input device for a user to input a password, a biometric information acquisition device for acquiring biometric information such as a fingerprint, a palm print, and an iris pattern. The CPU 120 implements various controls described below by executing a program stored in the storage unit 140. The card reader / writer 130 has a configuration corresponding to the system of the IC card 1. When the IC card 1 is a contact type IC card, the card reader / writer 130 includes a contact part for physically and electrically connecting with the contact part of the IC card 1. When the IC card 1 is a non-contact type IC card, the card reader / writer 130 includes an antenna for performing wireless communication with the IC card 1 and a communication control unit. The card reader / writer 130 performs power supply to the IC card 1, reset control, data transmission / reception, and clock supply in the case of the contact type. The storage unit 140 includes ROM, RAM, EEPROM, flash memory, HDD (Hard Disk Drive), and the like. The storage unit 140 stores a new authentication application (new authentication application 150) transmitted to the IC card 1, an external device side authentication application 160 that performs processing for transmitting the new authentication application 150 to the IC card 1, and other information. Stored. The new authentication application 150 is, for example, a version upgrade program for the authentication application 42. The new authentication application 150 may replace the authentication application 42 stored in the IC card 1 at that time, or may supplement the authentication application 42.

  FIG. 6 is a sequence diagram simply showing an example of the flow of download processing performed in cooperation between the external device 100 and the IC card 1. When the external device 100 detects that the IC card 1 is connected for communication (step S200), it transmits an authentication command to the IC card 1 (step S202). FIG. 7 is a diagram illustrating an example of an authentication command transmitted from the external device 100 to the IC card. The authentication command is generated, for example, in a format according to ISO / IEC 7816-4. The authentication command includes CLA (class byte), INS (instruction byte), P1 (parameter byte 1), P2 (parameter byte 2), Lc (data length), authentication data, public key (1), Le (response) Length). The authentication data is information acquired by the authentication device 110 and includes a password, biometric information, and the like. The public key (1) is information transmitted from the external device 100 to the IC card 1 in order to perform key sharing encryption processing.

  The IC card 1 that has received the authentication command performs, for example, the processes of FIGS. 9 to 11 described later (step S204) and transmits a response to the external device 100 (step S206). This process includes a session key generation process corresponding to the session key generated by the external apparatus 100. FIG. 8 is a diagram illustrating an example of a response returned from the IC card 1 to the external device 100. The response includes the public key (2), SW1 (status byte 1), and SW2 (status byte 2). The external device 100 generates a session key based on the public key (2) included in the response and a secret key (not shown) held therein (step S208), and transmits a download start request command to the IC card 1 (step S208). Step S210).

  When the download start request command is received, the IC card 1 performs, for example, the process of FIG. 12 described later (step S212), and notifies the external device 100 that the download permission state is set (step S214). In response to this, the external apparatus 100 encrypts the download file (new authentication application 150) and a predetermined authentication code using the session key (step S216). Then, the external device 100 includes the encrypted download file in the command shown in FIG. 7, and further transmits information to which the encrypted authentication code is added to the IC card 1 (step S218). The IC card 1 decrypts the download file by using the session key generated inside, and verifies the validity of the authentication code. If the authentication code is valid, the downloaded file is stored in the EEPROM 40 and a new authentication application is stored. 42 (step S220). The new authentication application 42 may be added to an empty area of the EEPROM 40 or may be stored in an area where the old authentication application 42 is deleted. Further, the IC card 1 performs a process of transferring the privilege information to the new authentication application 42 as shown in FIG. 13 to be described later (step S222).

  In the following, processing at each stage in the sequence diagram of FIG. 6 will be described. FIG. 9 is a flowchart illustrating an example of a flow of processing realized by the authentication application 42 in the IC card 1. The processing of this flowchart is started when an authentication command is received from the external device 100. First, the authentication application 42 performs an authentication process for authentication data (step S300). The authentication process is performed, for example, by comparing a password or biometric data included in the authentication data with the authentication information 42-3. The authentication process may be performed by the external device 100 and an “authentication result” may be transmitted from the external device 100 to the IC card 1.

  The authentication application 42 determines whether the authentication in step S302 is successful (step S302). If the authentication is successful, the authentication application 42 verifies the validity of the public key (1) (step S304). The validity verification of the public key (1) is performed by referring to the key length of the public key (1) and a specific value included in the data of the public key (1). The authentication application 42 determines whether or not the public key (1) is valid (step S306).

  If the public key (1) is valid, the authentication application 42 generates a session key based on the public key (1) and the secret key 42-2 (step S308). The session key is generated by a method such as EX-OR or SHA-1. Then, the authentication application 42 notifies the download possibility using the API 62-1 (step S310), notifies the session key using the API 62-2 (step S312), and sends the public key (2) to the external device 100. (Step S314).

  On the other hand, when a negative determination is obtained in either step S304 or step S308, the authentication application 42 sends an error response to the external device 100 (step S316).

  FIG. 10 is a flowchart illustrating an example of a flow of processing realized by the operating system 61 when a download enable notification is performed. The operating system 61 refers to the current application information 51 and determines whether or not the download authority is delegated to the notification source authentication application 42 (step S400). When the download authority is delegated to the authentication application 42 as the notification source, the operating system 61 sets the download enable / disable flag 52 to a state indicating that download is possible (step S402). On the other hand, when the download authority is not delegated to the authentication application 42 as the notification source, the operating system 61 sets the download enable / disable flag 52 to a state indicating that download is not possible (step S404).

  FIG. 11 is a flowchart illustrating an example of a flow of processing realized by the operating system 61 when a session key notification is performed. The operating system 61 refers to the current application information 51 and determines whether or not the download authority is delegated to the notification source authentication application 42 (step S500). When the download authority is delegated to the notification source authentication application 42, the operating system 61 stores the session key generated by the authentication application 42 in the session key storage area 53 (step S502). On the other hand, when the download authority is not delegated to the authentication application 42 as the notification source, the operating system 61 clears the session key storage area 53 (step S504).

  FIG. 12 is a flowchart illustrating an example of a flow of processing realized by the operating system 61 when a download start request command is received from the external device 100. The operating system 61 refers to the application management information 41 and determines whether there is an authentication application to which the download authority has been delegated (step S600). If there is an authentication application to which the download authority has been delegated, the operating system 61 determines whether or not the download enable / disable flag 52 is set to a download enable state (step S602). When the download permission / prohibition flag 52 is set to the downloadable state, the operating system 61 sets the download permission flag 54 to the download permission state (step S604). When the command including the download file and the authentication code are received from the external device 100 with the download permission flag 54 set to the download permission state, the operating system 61 uses the session key stored in the session key storage area 53. Then, the validity of the authentication code is verified and the download file is decrypted, and the decrypted download file is stored in the EEPROM 40. As a result, the new authentication application 150 is downloaded from the external device 100.

  Even when it is determined in step S600 that there is no authentication application to which the download authority has been delegated, the operating system 61 sets the download permission flag 54 to the download permission state (step S604). In this case, the operating system 61 has already performed the same processing as that of the authentication application 42 described so far, and generates a session key and stores it in the session key storage area 53. Therefore, when receiving a command and an authentication code including a download file from the external device 100, the operating system 61 uses the session key stored in the session key storage area 53 to verify the validity of the authentication code and decrypt the download file. The decrypted download file is stored in the EEPROM 40.

  On the other hand, if it is determined in step S602 that the download enable / disable flag 52 is not set to the download enable state, the operating system 61 does not set the download enable flag 54 to the download enable state, and ends the processing of this flowchart.

  As a result of the processing shown in FIG. 12, before the download authority is transferred from the operating system 61 to the authentication application 42, the operating system 61 downloads the authentication application 42 alone, and once from the operating system 61 to the authentication application 42. After the download authority is transferred, the authentication application 42 is downloaded only by the cooperation of the operating system 61 and the authentication application 42. This is because the download permission / non-permission flag 52 is not set to the downloadable state unless the authentication application 42 is processed, and in this case, the download permission flag 54 is not set to the download permission state. This can prevent the authority delegation relationship from becoming complicated.

  FIG. 13 is a flowchart illustrating an example of a flow of processing realized by the operating system 61 after the download of the authentication application 42 is completed. When the download of the authentication application 42 is completed, the operating system 61 determines whether it is necessary to change the authority transfer destination (step S700). This determination is made with reference to, for example, information notified from the external device 100, information notified from the old authentication application 42 before downloading, or the program ID of the downloaded new authentication application 42. If it is determined that the authority transfer destination should be changed in principle as the authentication application 42 is downloaded, the determination in step S700 may be omitted. If it is determined that the authority transfer destination needs to be changed, the operating system 61 rewrites the application management information 41 (step S702). That is, the operating system 61 deletes the download authority delegation information from the privilege information of the old authentication application 42, and writes the download authority delegation information to the privilege information of the new authentication application 42.

  According to at least one embodiment described above, when the authentication performed by the authentication application 42 in cooperation with the external device 100 is successful, the download authority is delegated to the authentication application 42 (the predetermined authority is When the program is downloaded from the external device 100 in order to enable the program to be downloaded from the external device 100 via the communication unit 20 when the authority is delegated. Security can be improved.

  Further, according to the embodiment, when the download authority is delegated to the authentication application 42 that has been successfully authenticated, a session key that can decrypt and authenticate the program received from the external device 100 is stored in the session key storage area 53. Since registration is performed, the security when downloading the program from the external device 100 can be further enhanced.

  In addition, according to the embodiment, once the download authority is transferred from the operating system 61 to the authentication application 42, the authentication application 42 is downloaded only by the cooperation of the operating system 61 and the authentication application 42. . As a result, it is possible to prevent the authority delegation relationship from becoming complicated. In addition, according to the embodiment, it is possible to change to an algorithm that can perform cryptographic processing with higher strength than the authentication function of the operating system 61, and / or Users can be broadened. This is because if the authentication function for the operating system 61 to download alone remains, that part may become a weak part in terms of security.

  The function realized by the authentication application 42 being executed by the CPU 30 is an example of the “authentication unit”, and the function realized by the operating system 61 being executed by the CPU 30 is the “management unit”. It is an example. The EEPROM 40 and the RAM 50 are examples of the “storage unit”.

  Although several embodiments of the present invention have been described, these embodiments are presented by way of example and are not intended to limit the scope of the invention. These novel embodiments can be implemented in various other forms, and various omissions, replacements, and changes can be made without departing from the scope of the invention. These embodiments and modifications thereof are included in the scope and gist of the invention, and are included in the invention described in the claims and the equivalents thereof.

1 IC card 10 electronic circuit 20 communication unit 30 CPU
40 EEPROM
41 Application management information 42 Authentication application 50 RAM
51 Current application information 52 Download permission flag 53 Session key storage area 54 Download permission flag 60 ROM
61 Operating System 62-1 and 62-2 API
70 Communication member 100 External device

Claims (11)

A communication unit that communicates with an external device;
A storage unit;
Authentication performed in cooperation with the external device by executing the authentication application in a state where the authentication application downloaded from the external device is stored in the storage unit, and includes user authentication, An authentication unit that performs at least one of authentication and authentication of another device connected to the external device;
When the authentication unit succeeds in the authentication, it is determined whether or not a predetermined authority is granted to the authentication application, and when the predetermined authority is granted to the authentication application, the communication A management unit that enables downloading of an authentication application from the external device via the unit;
A portable electronic device comprising: The management unit cooperates with the external device in a state where the authentication application to which the predetermined authority is given is not stored in the storage unit, and performs user authentication, authentication of the external device, and the external device Authentication including at least one of the authentications of other devices connected to the device, and when the authentication is successful, performs processing for downloading the authentication application from the external device via the communication unit,
The portable electronic device according to claim 1. The management unit is a session key generated by the authentication unit when a predetermined authority is given to the authentication application downloaded from the external device , and the authentication unit receives the authentication application received from the external device. A session key that enables at least one of decryption and authentication to be registered in the storage unit;
The portable electronic device according to claim 1 or 2. The management unit does not register the session key in the storage unit when a predetermined authority is not granted to the authentication application downloaded from an external device ;
The portable electronic device according to claim 3. A storage unit,
In a case where a predetermined authority is given to the authentication application downloaded from an external device , the management unit changes the communication unit according to information notified from the authentication unit upon successful authentication. Setting information to permit downloading of the authentication application from the external device via the storage unit,
The portable electronic device according to any one of claims 1 to 4. The management unit, when a predetermined authority is not given to the authentication application downloaded from an external device , regardless of the information notified from the authentication unit with a successful authentication, Do not set information in the storage unit to permit download of the authentication application from the external device via
The portable electronic device according to claim 5. The authentication unit notifies the management unit of predetermined information when the authentication is successful, and generates a session key that enables at least one of decryption and authentication of the authentication application received from the external device. Output to the management unit
The portable electronic device according to claim 1. The management unit functions by executing an operating system,
The authentication unit notifies the management unit of information through an API provided by the management unit.
The portable electronic device according to claim 1. In the state where the authentication application downloaded from the external device is stored in the storage unit, the management unit can connect the external device via the communication unit only in cooperation with the authentication application to which the predetermined authority is granted. Download the authentication application from the device,
The portable electronic device according to claim 1. The storage unit stores authority information indicating whether or not the predetermined authority is granted to each of one or a plurality of authentication applications,
The management unit refers to the authority information and determines whether or not a predetermined authority is given to an authentication application that causes the authentication unit to function successfully.
The portable electronic device according to claim 1. A communication unit that communicates with an external device;
A storage unit;
Authentication performed in cooperation with the external device by executing the authentication application in a state where the authentication application downloaded from the external device is stored in the storage unit, and includes user authentication, An authentication unit that performs at least one of authentication and authentication of another device connected to the external device;
When the authentication unit succeeds in the authentication, it is determined whether or not a predetermined authority is granted to the authentication application, and when the predetermined authority is granted to the authentication application, the communication A management unit that enables downloading of an authentication application from the external device via the unit;
An electronic circuit comprising:

Images