KR20050103448A - Semiconductor memory card and computer readable program - Google Patents

Abstract

The present invention provides a semiconductor memory card which no longer allows an illegal practice of acquiring contents of a deleted file. Here, when a deletion event is generated, a deletion handler gives a priority to a null-clear operation of a file entry and a FAT for a file to be deleted over a null-clear operation to other constituents of the file. A null-clear operation to a file entity of the file is distributed to a plurality of event handlers including the deletion handler.

Description

Semiconductor memory card and computer readable program {SEMICONDUCTOR MEMORY CARD AND COMPUTER READABLE PROGRAM}

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a semiconductor memory card capable of storing data as a file, and more particularly to a file deletion technique.

Semiconductor memory cards, such as IC cards and SD cards, have been experimentally introduced in various industries, from mass media, including broadcasting and publishing, to financial institutions, governments, and local agencies. Semiconductor memory cards have caused great repercussions in these industries because of their inherent convenience. In a semiconductor memory card, data is managed in a layer model having a physical layer, a file system layer, and an application layer. Therefore, the user can create a file in the semiconductor memory card, and can delete the generated file by the same procedure as deleting the file stored in the computer.

Deletion of a file in a conventional semiconductor memory card includes overwriting management information, which is a file allocation table indicating a link relationship between a file fragment and a file entry. File Allocation Table (FAT). The reason why the deletion of the file causes the management information to be overwritten is as follows. If the management information for the file is overwritten, the position of the fragments constituting the filing entity in the semiconductor memory card is lost, and the link relation between the fragments that are discontinuously located in the semiconductor memory card is damaged and thus This is because reading becomes impossible.

Data management by a file system in a conventional semiconductor memory card is described in Japanese Patent Laid-Open No. 2001-188701, US Patent No. 5,479,638, and Japanese Patent No. 3389186.

According to the above-described method of file deletion, the FAT and the file entry are overwritten. However, the file entity of the deleted file and the fragments constituting the file entity still remain discontinuous on the semiconductor memory card. If such deleted file contains data relating to monetary transactions, there is a risk that the bank account number and ATM card number may be read from discrete fragments.

Further, the third party can track the discontinuous fragments on the semiconductor memory card to reproduce the deleted file to obtain the contents of the file that should have been deleted.

However, there is a reason why file deletion should include overwriting management information such as FAT and file entry. It is because of the processing time required for overwriting. Experimental calculations took 2 milliseconds to overwrite 512 bytes, 4 seconds to overwrite 1 megabyte, and 40 seconds to overwrite 10 megabytes. This represents the time taken to perform a complete delete operation, that is, the time taken to overwrite the file entity of the file to make the file completely unreadable. This complete deletion also implies a problem where data representing the location of the fragments constituting the deleted file should be stored. If data indicating the fragment's location as well as the fragment is stored in the nonvolatile memory, the third party will probably be able to read the fragment's location before a complete erase operation is achieved. Thus, the information about the file to be deleted is not sufficiently protected while the complete deletion operation is performed.

1 is a diagram illustrating an environment in which an SDeX memory card 400 is used.

2 is a diagram illustrating an internal configuration of a semiconductor memory card according to the present invention.

3 is a hardware configuration diagram of the TRM 1 (shown in FIG. 2)

4 is a software configuration diagram of a part composed of the mask ROM 6 and the CPU 7 (both shown in FIG. 3) of the TRM 1;

FIG. 5 shows the logical format of an external flash memory 2 and an internal EEPROM 3 (both shown in FIG. 3).

6 is an internal configuration diagram of an extended area 22, an authentication area 23, and an unauthenticated area 24 (shown in FIG. 5) for an EC client application.

7 is a configuration diagram of a partition

8A is a configuration diagram of a double FAT, FIG. 8B is a configuration diagram of a root directory entry, and FIG. 8C is a configuration diagram of a user area.

9 is a diagram showing a state in which the file name "EOB001.SE1" is divided into five fragments according to the size of the cluster, and the fragments are stored in the clusters 003, 004, 005, 00A, and 00C, respectively.

FIG. 10 shows an example of a root directory entry and a FAT for the file name "EOB001.SE1" which is divided and stored in a plurality of clusters.

11 is a schematic diagram of an API 10 (shown in FIG. 4).

12A illustrates how a write operation to a file is performed by the read / write handler 14, and FIG. 12B illustrates a read / write event handler 14 to a file. Drawing showing how it is done by

FIG. 13 is a diagram illustrating an internal configuration of the API 10 focusing on the characteristics of the delete handler 16.

14 is a diagram showing an example of an erase operation management table;

FIG. 15 is a flow chart showing the procedure of the event analysis handler 11 (shown in FIG. 11).

16 is a flow chart showing the procedure of the non-instruction execution handler 12.

17 is a flow chart showing the procedure of the read / write handler 14.

18 is a flow chart showing the procedure of the delete handler 16 (shown in FIG. 11).

19 is a flow diagram illustrating the procedure of a null-clear subroutine.

FIG. 20 illustrates the operation of the delete handler 16 when a delete event is generated with a stored file as shown in FIG. 10.

21 illustrates an overwriting operation by the non-command execution handler 12 and the deletion handler 16.

22 is a diagram showing an example of an erase operation management table according to the second embodiment.

FIG. 23 shows a procedure of a null-erase subroutine according to the second embodiment. FIG.

24 is a flow chart showing the procedure of reverse null-erase operation.

Fig. 25 is a configuration diagram of the memory module according to the fourth embodiment.

26 is a diagram comparing the performance of the flash memory and the performance of FeRAM.

FIG. 27 shows a FeRAM for storing periodically updated data such as a file entry, a FAT, and an erase operation management table.

28 is a configuration diagram of a memory 3 of the TRM 1 according to the fifth embodiment.

It is an object of the present invention to provide a semiconductor memory card capable of protecting a file entity of a file to be deleted from when a file deletion command is issued until the file is completely deleted.

The object is a non-volatile memory for storing a file consisting of the entity and management information; And a tamper proof module including a processor and an internal memory. The processing unit includes a deletion unit for generating a location table in the internal memory in the tamper resistant module when a deletion event for a file is generated, and (ii) overwriting management information. Here, the location table indicates the position of the entity and is referenced by the deleting unit when the deleting unit overwrites the entity.

The file entity of the file is overwritten with reference to the location table stored in memory in the tamper resistant module. Therefore, the information about the fragment can be sufficiently protected from when the deletion event is generated until the file is completely deleted.

The file entity is overwritten with reference to the location table at idle time after the delete event is generated. In this manner, the processing load of the file entity overwriting is divided to be performed in a plurality of idle time units. Because of this division, the semiconductor memory card can immediately return to the standby state, so that the user can complete the overwriting of the file entity without feeling that it takes a long time to delete the file.

In addition, overwriting of file management information that breaks the link relationship between the fragments constituting the file is given priority to overwriting the file entity. Since the overwriting operations are performed in the order described above, reverse analysis of the fragments becomes more difficult as time passes.

Here, the processing unit performs (i) an operation corresponding to a command issued by a device to which a semiconductor memory card is connected, and (ii) an analysis for analyzing a command issued by the device and generating an event corresponding to the analysis result. It further includes wealth. The deletion unit may include: a main deletion unit generating a location table when the deletion event is generated and overwriting management information; And a sub-deletion unit for overwriting an entity by referring to the generated location table when an event different from the deletion event is generated.

Here, the semiconductor memory card further includes a timer that starts to measure the time at which the erase event is generated. The main deleting unit overwrites a part of the entity in addition to the management information until the timer notifies the timeout, and the sub deleting unit overwrites the remaining part of the entity not overwritten by the sub deleting unit. Thus, the overwriting operation in response to the instruction of file deletion continues until timeout. Thus, for example, if the timeout is adjusted based on the period required for the overwriting operation for the nonvolatile memory, the latency for the user can be optimized.

Here, the internal memory stores an encryption key for encrypting an entity, and when a deletion event is generated, the main deletion unit overwrites the encryption key before overwriting the management information of the file. Overwriting of encryption keys is given priority over overwriting of file entities. Therefore, decryption of the file becomes impossible. Since the overwriting operations are performed in the above-described order, reverse analysis of the fragments becomes more difficult as time passes.

Here, the semiconductor memory card is operated by contact or contactless power supply means from any device, but the processing device is overwritten only when the semiconductor memory card is operated by contact power supply means from the device. Do this. As a result, overwriting of the file entity is not performed during contactless powering. This realizes stable operation.

Hereinafter, embodiments of the semiconductor memory card of the present invention will be described. The semiconductor memory card according to the first embodiment is an SDeX memory card having a built-in tamper resistant module of an IC card. The SDeX memory card is used as a recording medium for an SD portable device similarly to an SD memory card, and has a built-in tamper resistant module of an IC card. In addition, the SDeX memory card 400 (FIG. 1) according to the first embodiment can communicate with external devices in a contact and contactless communication method.

First, how the semiconductor memory card (SDeX memory card 400) according to the present invention is used will be described. The SDeX memory card 400 is connected to an SD portable device such as a mobile phone and used in the environment shown in FIG. 1 illustrates an environment in which the SDeX memory card 400 is used.

The environment shown in FIG. 1 includes an Electronic Commerce (EC) server 100, a card reader / writer 200, a wireless base station 210, and an SD portable device 300.

The EC server 100 provides an e-commerce service to the SDeX memory card 400 via the card reader / writer 200, the wireless base station 210 and the network. In the EC server 100, a plurality of EC application programs operate, and each application program provides a unique e-commerce service to the SDeX memory card 400. The e-commerce applications running on the EC server 100 are server applications, each of which provides a different e-commerce service. In Fig. 1, EC server applications for n kinds of e-commerce services are briefly represented as S_APL1, 2, 3, ... n, respectively. There are n kinds of server applications here. The EC server 100 provides an electronic commerce service by issuing EC commands to the SDeX memory card 400 through the network, the card reader / writer 200 and the wireless base station 210.

The card reader / writer 200 is, for example, a device included in a cash dispenser of a credit card company and a financial institution or a cash register of a store. The card reader / writer 200 supplies power to the SDeX memory card 400 and performs input / output without contact with the SDeX memory card 400. The card reader / writer 200 is connected to a network. The SDeX memory card 400 receives an e-commerce service supplied by the EC server 100 through the card reader / writer 200.

The wireless base station 210 is located on top of the building and on the telephone pole. The wireless base station 210 performs input / output of data wirelessly with the mobile telephone type SD portable device 300. The wireless base station 210 is connected to a network. In addition, the SD portable device 300 receives an e-commerce service provided by the EC server 100 through the wireless base station 210.

The SD portable device 300 may access the SDeX memory card 400 by connecting the SDeX memory card 400 to the SD portable device 300. Since the SD portable device 300 is equipped with browser software, a user can access a file system (hereinafter, referred to as FS) of the SDeX memory through the browser's user interface. The access of this file system is such that the SD portable device 300 issues SD commands defined by the SD memory card to the SDeX memory card 400 and receives a response to the command from the SDeX memory card 400. Is performed. When the SD portable device 300 bootstraps the SDeX memory card 400, the SDeX memory card 400 is integrated into the SD portable device 300 to function as an IC card. Here, a helical antenna is built into the back of the SD portable device 300. When the SD portable device 300 functions as an IC card, the helical antenna supplies power from the card reader / writer 200 to the SDeX memory card 400. In addition, the SD portable device 300 exchanges commands / responses with the SDeX memory card 400 and exchanges commands / responses with the EC server 100. Specifically, the SD portable device 300 encapsulates an e-commerce command from the EC server 100 to generate an extended SD command, and outputs the extended SD command to the SDeX memory card 400. In addition, the SD portable apparatus 300 obtains an EC response from the SD response from the SDeX memory card 400 and outputs the EC response to the SDeX memory card 400. When the SD portable device 300 bootstraps the SDeX memory card 400, the SDeX memory card 400 functions as an IC card and enters the "EC mode". When the SD portable device 300 uses the SDeX memory card 400 as a storage medium, the SDeX memory card 400 is in the "SD mode".

 If the SDeX memory card 400 is in the SD mode, it is used as the SD memory card. In the SD mode, the SD portable device 300 is a host device of the SDeX memory card 400. In this case, the SDeX memory card 400 is used to store audio data and video data downloaded from the distribution server to the SD portable device. Therefore, the host device can reproduce audio data and video data stored in the SDeX memory card 400.

In the EC mode, the SDeX memory card 400 is used as an IC card. In addition, in the EC mode, the SDeX memory card 400 is connected to the SD portable device 300. However, the host device of the SDeX memory card 400 is not the SD portable device 300 but the EC server 100 on the network. The SDeX memory card 400 communicates with the EC server 100 by the SD portable device 300 to which the SDeX memory card 400 is connected together with the card reader / writer 200 and the wireless base station 210. Financial transactions are executed in this manner between the SDeX memory card 400 and the EC server 100.

Since the SDeX memory card 400 according to the present embodiment has a function as an IC card in addition to a function of storing supplied audio data and video data, it is more convenient for the user.

Here, the SDeX memory card 400 accesses the EC server 100 in the EC mode through the card reader / writer 200 according to FIG. 1. Alternatively, the SDeX memory card 400 may access the EC server 100 in such a manner that the SD portable device 300 accesses the EC server 100 through the wireless base station 210 and the network.

Hereinafter, a method of manufacturing a semiconductor memory card according to the present invention will be described. The semiconductor memory card according to the present invention has an internal configuration as shown in Figs. 2 and 3 and can be manufactured industrially.

As shown in Fig. 2, a connector, a Tamper-Resistant Module chip (TRM) 1, and a flash memory chip 2 having a capacity of 256 megabytes are a semiconductor memory card according to the present invention. Packaged in

There are various definitions of tamper-resistance. However, the general definition of tamper protection is as follows.

(1) Even though the TRM chip is physically open, its internal structure is unknown.

(2) Even if electromagnetic waves are irradiated on the TRM chip, its internal structure is unknown.

(3) There is a non-linear relationship between the length of data input to the TRM and the processing time of that data.

(4) The output data is not obtained through reverse operation based on an error of the input data.

Because of these four characteristics, the TRM 1 defends against various kinds of reverse operations. Hereinafter, the hardware configuration of the TRM 1 will be described.

3 is a diagram illustrating a hardware configuration of the TRM 1. As shown in FIG. 3, the internal EEPROM 3, the external memory controller 4, the host interface module (HIM) 5, the mask ROM 6, and the CPU 7 configure the microcomputer system. It is packaged in (1).

The internal EEPROM 3 is an internal memory that can be read and written. Microcomputer systems packaged as TRM 1 have a high manufacturing cost per unit area. The internal EEPROM 3 of the TRM 1 has a capacity of 32 kilobytes. Hereinafter, the flash memory 2 shown in FIG. 2 is sometimes referred to as an external memory to distinguish it from the internal EEPROM 3.

The external memory control section 4 is a circuit exclusively used to access the external flash memory 2. Access to the external flash memory 2 is executed based on the SD command issued by the SD portable device 300.

The HIM 5 classifies SD commands issued by the SD portable device 300 by reference to the number of their commands. The number of SD commands is from 1 to m or extended to (m + 1) or more. If the number of SD commands is in the range of 1 and m, the HIM 5 outputs the SD commands to the external memory control section 4. If the number of SD instructions of the SD instruction is (m + 1) or more, the HIM 5 acquires an EC instruction and outputs it to the CPU 7. This EC command is encapsulated in an extended SD command.

The mask ROM 6 stores a Java virtual machine and an application program in advance. When the SDeX memory card 400 bootstraps the SD portable device 300, the bootstrap starts from a predetermined address of the mask ROM 6. Thus, the SD portable device 300 is activated to enter the EC mode.

The CPU 7 executes a program stored in the mask ROM 6.

FIG. 4 is a diagram showing a software configuration of a portion composed of the mask ROM 6 and the CPU 7 of the TRM 1 (shown in FIG. 3). The part surrounded by the dotted line wk1 is an equivalent module to an IC card. The rest of the TRM 1 is a module equivalent to an SD memory card.

The portion of the TRM 1 equivalent to the SD memory card includes an external memory controller 4 and a HIM 5. The HIM 5 not only functions as an SD memory card but also as a first contact portion between the SD memory card equivalent module and the IC card equivalent module.

IC card compatible modules have a hierarchical structure. In this hierarchy, the inner EEPROM 3 is the lowest layer (physical layer). The application interface (API) 10 is a layer just above the layer in which the internal EEPROM 3 resides. The Java virtual machine 9 is a layer just above the layer in which the API 10 exists. The EC client application 8 is the top layer. The external memory control section 4 of the SD memory card compatible section is located in a physical layer similar to the internal EEPROM 3.

Hereinafter, the software structure (EC client application 8, Java virtual machine 9, and API 10) shown in FIG. 4 will be described.

The EC client application 8 is a kind of EC application written in JAVA, and accesses the EC server 100 based on a user's instruction. Since different types of EC server applications corresponding to different EC services each run on the EC server 100, different types of EC client applications respectively corresponding to different EC services run on the SDeX memory card 400. In FIG. 4, the EC client applications C_APL1, 2, 3,.. N are shown to correspond to the EC applications S_APL 1, 2, 3,... N on the EC server 100, respectively. The EC client application 8 obtains various EC services by exchanging commands with the EC server application on the EC server 100 via the card reader / writer 200, the wireless base station 210, and the network. If the EC command received from the EC server application is a data write command, the EC client application 8 outputs the EC command to the API 10 via the Java virtual machine 9.

In addition, the EC client application 8 accesses the external flash memory 2 and the internal EEPROM 3 in EC mode based on the instruction of the user. This access includes file access such as generating a file, performing a read operation and a write operation on the generated file.

The Java virtual machine 9 (Java Card VM (registered trademark) in FIG. 4) converts the Java language in which the EC client application 8 is written into the source code of the CPU 7, and causes the CPU 7 to execute the EC. Run the client application 8.

The API 10 performs read / write to the external flash memory 2 and the internal EEPROM 3 based on the instructions of the EC client application 8. The software structure of the SDeX memory card 400 has been described above.

Hereinafter, the logical formats of the external flash memory 2 and the internal EEPROM 3 will be described. 5 shows the logical format of the external flash memory 2 and the internal EEPROM 3. The external flash memory 2 and the internal EEPROM 3 have two memory spaces, namely sm1 and sm2. The memory space sm1 is accessible by the CPU 7 in the TRM 10 and consists of an area 21 for the EC client application and an extended area 22 for the EC client application. The memory space sm2 is accessible from the SD portable device 300 without going through the CPU 7 in the TRM 1. The memory space sm2 is composed of an authentication area 23 and an unauthentication area 24. The authentication area 23 and the non-authentication area 24 are memory areas of the SD memory card, which are described in detail in Japanese Patent No. 3389186.

FIG. 6 is a diagram showing the configuration of an extended area 22, an authentication area 23, and an unauthenticated area 24 for an EC client application having a file system structure in accordance with ISO / IEC 9293. FIG. However, the ISO / IEC 9293 file system structure is only one example and is chosen for convenience only. The extended area 22, the authenticated area 23, and the non-authenticated area 24 for the EC client application may have other file systems, such as Universal Disk Format (UDF). Generally speaking, it is possible to use a file system structure in which the length of the fragment is changeable and the start address and data length are indicated in the entry information.

The extended area 22 for the EC client application consists of an area 22a on the internal EEPROM 3 and a secure flash area 22b on the external flash memory 2. The secure flash area 22b has partitions 1, 2, 3, ... n, i.e., file system areas. On the other hand, the area 22a in the internal EEPROM 3 includes reference tables (partition tables 1, 2, 3, ... n) for the master boot recorder and partitions.

The partitions in the extended area 22, authentication area 23, and non-authentication area 24 for the EC client application have the same internal structure. 7 shows the structure of such a partition.

The partition includes a partition boot sector, a dual file allocation table (FAT), a root directory entry, and a user area.

The partition boot sector is a table showing information about a partition.

Dual FAT includes two FATs according to ISO / IEC 9293. Each FAT includes a plurality of FAT entries corresponding one-to-one with a cluster. Each FAT entry indicates whether the corresponding cluster is used. If the corresponding cluster is not used, the value of the FAT entry is set to "0". If the corresponding cluster is used, the value of the FAT entry is set to the value of the number of clusters representing the link relationship between the clusters, that is, the next cluster to be read after the corresponding cluster. A dotted line ff1 in FIG. 8A shows a plurality of FAT entries 002, 003, 004, 005, ... included in the FAT. The number given to each FAT entry 002, 003, 004, 005, ... represents the cluster number of the corresponding cluster, that is, the cluster corresponding to the FAT entry.

The root directory entry includes a plurality of file entries in the root directory, each file entry corresponding to one file. Each file entry has a "file name" representing the name of the file, a "file extension" representing the file extension of the file, a "first cluster number" representing the cluster storing the beginning of the file, and a "file attribute" representing the attribute of the file. Entries include a "storing time" indicating the time the file is stored, a "storing date" indicating the date the file is stored, and a "file length" indicating the data length of the file.

In the user space, files are stored and the smallest unit is a cluster. The dotted line ff2 in Fig. 8C shows a plurality of clusters 002, 003, 004, 005, ... in the user area. In Fig. 8C, the numbers 002, 003, 004, 005, 006, 007, 008, ... are hexadecimal three-digit cluster numbers for the purpose of identifying each cluster. Since access to the data area is performed in units of the smallest cluster, the position in the data area is indicated by the cluster number.

Here, an example of a method in which the file name EOB001.SE1 is stored in the root directory, that is, a file storing method will be described with reference to FIG. 9. Here, "EOB" of "EOB001.SE1" is a short form of an EC object, and "SE" is an extension named after "Secure EC". As described above, since the smallest unit accessible in the data area is a cluster, the file EOB001.SE1 needs to be stored in the data area in a cluster of the smallest unit. First, the file EOB001.SE1 is divided into fragments each of which has a cluster size, and each divided fragment is written to the cluster. FIG. 9 shows that the file EOB001.SE1 is divided into five fragments according to the cluster size, and the fragments are stored in clusters 003, 004, 005, 00A, and 00C, respectively.

If the file EOB001.SE1 is a fragment as described above, the directory entry and the FAT need to be set as shown in FIG.

Fig. 10 is a diagram showing a directory entry and a FAT as an example when EOB001.SE1 is stored separately in a plurality of clusters. According to Fig. 10, since the beginning of the file EOB001.SE1 is stored in the cluster 003, the "first cluster number" entry in the root directory entry indicates 003, that is, the cluster number of the cluster storing the beginning. It can be seen from FIG. 10 that two subsequent fragments of the file EOB001.SE1 are stored in clusters 004 and 005, respectively. The cluster 003 storing the beginning of the file EOB001.SE1 corresponds to the FAT entry 003 (004). Here, FAT entry 003 represents 004 indicating cluster 004 which stores what follows at the beginning. Also, clusters 004 and 005 storing two fragments following the beginning correspond to FAT entries 004 (005) and 005 (00A). These FAT entries represent 005 and 00A indicating clusters 005 and 00A storing subsequent fragments.

If the cluster number in the FAT entry is tracked along the arrows fk1, fk2, fk3, fk4, and fk5, all fragments constituting the file EOB001.SE1 can be read. From the above description, it can be seen that the smallest unit accessible to the user area of the SDeX memory card 400 is a cluster, and these clusters correspond one-to-one with FAT. The FAT entry corresponding to the cluster storing the end of the EOB file (cluster 00C in FIG. 9) represents "FFF", which represents the corresponding cluster storing the last fragment of the file.

Hereinafter, the structure of the API 10 will be described. Here, an event is a generic term that describes an input to the API 10, such as, for example, an EC command, occurrence of hardware interruption, and input of communication data. The API 10 is composed of programs that start in response to events occurring in and out of the API 10. Such a program is called an "event handler" and is shown in FIG. As shown in FIG. 11, the API 10 includes an event analysis handler 11, a non-command execution handler 12, a timer handler 13, a read / write handler 14, an encryption key table 15, and Event handlers such as the delete handler 16.

The event analysis handler 11 analyzes an event occurring in and out of the API 10 and generates an API-internal event according to the analysis result. One of the most common events occurring outside of the API 10 is an EC command issued by the EC client application 8. The event analysis handler 11 analyzes the content of the EC command. If the EC command indicates read and write operations to the file, the event analysis handler 11 generates an internal event of the file read / write event and the command start event. If the EC command indicates file deletion, the event analysis handler 11 generates an internal event of the file deletion event and the command start event. By generating these internal events, an event handler for reading and writing to a file or an event handler for deleting a file is operated, respectively.

API internal events include events (completion events) that represent procedures completed by the event handler. When the event handler executing the EC command generates a completion event, the event analysis handler 11 outputs the EC response to the EC client application 8 that issued the EC command.

The non-command execution handler 12 operates if none of the other event handlers in the API 10 execute a command. The driving period of the non-command execution handler 12 and the driving period of another event handler that executes the EC command are mutually exclusive. In other words, the non-command execution handler 12 operates when no other event handler is running at all.

The timer handler 13 starts measuring the time at which the command start event is generated, and notifies the timeout when the measured time becomes equal to a predetermined time period. The event analysis handler 11 monitors whether the timer handler 13 notifies the timeout, and thus can forcibly interrupt the long operation by the event handler. This abort is accomplished by an abort event by the event analysis handler 100.

The read / write handler 14 reads / writes files on the external flash memory 2 and the internal EEPROM 3 when a read / write event is generated. 12A shows how a write operation to a file is performed by the read / write handler 14.

The write operation to the file is performed in the following manner. The read / write handler 14 receives the file name to which data is written and the written data from the EC client application 8 (C_APL 1, 2, 3, ... n) (1 in Fig. 12A). And ②). In addition, an encryption key assigned to a file to which data is written is obtained from the encryption key table 15 by the read / write handler 14 (3). The data received from the EC client application 8 (C_APL 1, 2, 3, ... n) is then encrypted (4) by the encryption key obtained from the encryption key table 15 and written to the file. (⑤). 12B shows how the read operation on the file is performed by the read / write handler 14.

The read operation on the file is performed in the following manner. The read / write handler 14 receives the file name to be read from the EC client application 8 (C_APL1, 2, 3, ... n). After the encrypted data is read from the external flash memory 2 (1 in FIG. 12B), the encryption key assigned to the file to be read is obtained from the encryption key table 15 (2). The read data is then decrypted with the obtained encryption key (3) and transmitted to the EC client application 8 (C_APL1, 2, 3, ... n) (4) and (5).

The encryption key table 15 shows the one-to-one correspondence between the file encryption key and the file name encryption key. The encryption key is generated by the read / write handler 14 and registered in the encryption key table 15 when the EC client application 8 generates the file. The registered encryption key in the encryption key table 15 is referenced when the file is opened, and reading and writing operations are performed on the file.

The delete handler 16 operates when a delete event is generated. When a delete event is generated, the file entry, FAT, and file entity constituting the file are overwritten by the delete handler 16 with a null code after the erase operation management table is generated. . File deletion in this embodiment indicates overwriting an encryption key, a file entry, and a FAT for a file, and overwriting a file entity of a file. Here, overwriting refers to overwriting in null code or in a particular way (for null-erasing). The delete handler 16 gives priority to the former overwriting. The latter overwrite requires enormous processing time and can be performed by other event handlers. However, according to the present invention, the overwriting of file entities to a file, which requires enormous processing time, is reliably separated and executed in a plurality of idle periods.

13 is an internal configuration diagram of an API 10 that focuses on the features of the present invention described above. As shown by arrow cw1 in Fig. 13, when a delete event is generated, an erase operation management table is created by the delete handler 16 and written to the memory 3 in the TRM 1. The erase operation management table shows how overwriting is performed. This erase operation management table is created before overwriting the file entry and the FAT so that it can tell other event handlers the existence of fragments to be null-erased and how much file data should be null-erased. Once the erase operation management table is created, the non-instruction execution handler 12, read / write handler 14 and delete handler 16 refer to the erase operation management table (as shown by arrows nc1 and nc2) of the fragment. Overwrite X bytes. Then, the erase operation management table is updated. As indicated by arrows nc1 and nc2, files stored in both the external flash memory 2 and the internal EEPROM 3 can be null-erased in this embodiment. However, only the null-erasing operation on the file stored in the external flash memory 2 is described here in order to avoid complicated description. In this embodiment, the null-erase operation may be performed when the file entity for the file is fragmented or not fragmented in this embodiment. However, here only the null-erasing operation performed when the file entity for the file is fragmented, to avoid complications. (For this reason, the following description will consistently replace "file entities" with "fragments.")

14 is a diagram showing an erase operation management table as an example. The erase operation management table is composed of fragments and a plurality of records corresponding one-to-one. Each record has four entries: "valid flag", "start ADR", "erased ADR", and "end ADR". The "valid flag" indicates whether the corresponding fragment has been erased or completely erased, the "start ADR" indicates the start address of the fragment, and the "erased ADR" indicates how many fragments if the erase operation for the fragment is insufficient. Indicates an erase complete address showing whether or not the data of? Is null-erased, and " end ADR " indicates the end address of the fragment. The delete handler 16 sets the value of the start ADR or end ADR based on the FAT or file entry described above.

The event analysis handler 11, the non-instruction execution handler 12, the read / write handler 14, and the delete handler 16 in the API 10 may program a program to perform the procedures shown in FIGS. 15 to 19. It is created by writing in a language. 15 to 18 are flowcharts illustrating procedures of the event analysis handler 11, the non-command execution handler 12, the read / write handler 14, and the delete handler 16, respectively. 19 is a flowchart illustrating a procedure of a null-erase operation. The null-erasure operation indicates overwriting the X bytes of the fragment with a null code. The null-erase operation is considered to be a subroutine because it is executed by the non-instruction execution handler 12, the read / write handler 14, and the delete handler 16.

15 is a flowchart illustrating a procedure of the event analysis handler 11.

In FIG. 15, steps S101 to S103 form a loop procedure for scanning an event. This loop procedure checks whether an external event occurs (step S101), checks whether or not the operation by the read / write handler 14 and delete handler 16 has completed (step S102), and a timer handler. It is checked whether or not the procedure of (13) is completed (step S103).

Steps S104 to S109 are performed when an occurrence of an external event is detected in step S101.

In step S104, event analysis for determining whether or not the external event is an EC command is performed, and if the external event is an EC command, the content of the EC command is analyzed. If the external event is an EC command instructing a read and write operation on a file on the external flash memory 2, that is, a read / write command, a read / write event and a command start event are generated (step S106). The procedure of the event analysis handler 11 then returns to the loop procedure of steps S101 to S103.

If the external event is an EC command to delete a file on the external flash memory 2, that is, a delete command, a delete event and a command start event are generated (step S108). The procedure of the event analysis handler 11 then returns to the loop procedure of steps S101 to S103.

If an external event other than the above-described example occurs, an operation corresponding to the event is performed (step S109). The procedure of the event analysis handler 11 then returns to the loop procedure of steps S101 to 103.

Steps S110 and S111 are performed when the procedure by the read / write handler 14 and the delete handler 16 is completed. In these steps, an EC response is output to the EC client application 8 that issued the command, and a command end event is generated in the API 10.

Step S112 is performed when the timer handler 13 announces the timeout. At this stage, an abort event is generated.

16 is a flowchart illustrating a procedure of the non-instruction execution handler 12. Steps S1 and S2 form a loop procedure, and it is checked whether or not an instruction start event has been generated in this loop procedure (step S1), and whether an erase operation management table exists (step S2). It is determined whether or not the erase operation management table exists in step S2 every cycle of steps S1 and S2. If the erase operation management table exists as a result of the determination, the null-erase subroutine is called (step S4). Here, the overwriting of the fragments by the non-instruction execution handler 12 is performed in an idle period in which no other event handlers operate at all. Therefore, even though it takes time to overwrite a file due to the nature of the semiconductor memory card, the user is not tired of such time.

 17 is a flowchart showing the procedure of the read / write handler 14. The encryption key corresponding to the file on which the read operation and the write operation are performed is obtained from the encryption key table 15 in step S20. In step S21, it is determined whether or not a write operation is performed. When the write operation is performed, the data from the EC client application 8 is encrypted with the encryption key obtained in step S20 (step S22), and the encrypted data is written into the secure flash memory 2 (step S23).

On the other hand, if the determination in step S21 indicates that the read operation is performed, the encrypted data required by the EC client application 8 is read out from the secure flash memory 2 (step S24). The encrypted data read out from the secure flash memory 2 is decrypted using the encryption key obtained in step S20, and transferred to the EC client application 8 (step S25).

In step S26, it is determined whether the erase operation management table exists. If the erase operation management table does not exist, the procedure is completed. However, if the erase operation management table exists, the null-erase operation is performed in step S27.

18 is a flowchart illustrating a procedure of the delete handler 16. First, in step S11, a record is generated in one-to-one correspondence with a file fragment. In step S12, the value of the start ADR and the end ADR of each record are set to the value of the start address and the end address of the corresponding file fragment. In step S13, the value of the valid flag in each record is set to " 1 " indicating that the corresponding fragment is being erased. In step S14, the value of the erased ADR in each record is set to the value of the start address of the corresponding file fragment.

In step S15, the encryption key corresponding to the file to be deleted among the plurality of encryption keys in the encryption key table 15 is deleted. Deletion of this encryption key makes it impossible to decrypt the file.

After the file entry is null-erased in step S16, it is determined whether a break event is generated in step S17. The procedure of the delete handler 16 ends when the abort event is generated.

If no abort event is generated, the FAT is null-erased in step S18. Since the file entry and the FAT are null-erased at this stage, the fragments constituting the file entry of the file lose the linkage relationship between them and the linkage relationship is disconnected from each other.

Thereafter, it is determined whether or not a stop event is generated in step S19. Once the abort event is generated, the procedure of the delete handler 16 ends. If no abort event is generated, the fragment of the file is null-erased in step S20.

After that, the procedure of steps S19 to S20 is repeated. In this manner, overwriting of fragments by the delete handler 16 continues until the timer handler 13 announces a timeout.

19 is a flowchart illustrating a procedure of a null-erase subroutine. In step S31, the first record (first record) among the records having the value of the valid flag set to "1" is selected as the record s. It is determined whether the data length from the erase complete address to the end address is longer or shorter than the unit length X, and a step performed after step S31 is determined. This determination is made in step S32. That is, in step S32, it is determined whether the address obtained by adding the overwriting unit length X to the erased address is smaller than the end address of the record s. As a result of the determination, if the obtained address is smaller than the end address of the record s, steps S33 to S35 are continued. In these steps, the external memory control section 4 is instructed to overwrite the data of X bytes starting from the erase complete address of the corresponding fragment (step S33). When overwriting by the external memory control section 4 is completed (step S34), the erase completed address is updated to (erase completed address + X) (step S35).

If the data length from the erase complete address to the end address is longer than the unit length X, steps S36 to S39 are performed to process the excess data length. By these steps, the unit length X is converted to be equal to the value obtained by subtracting the erase completed address from the end address (step S36). Thereafter, the external memory control section 4 is instructed to overwrite the X byte data starting from the erase complete address with a null code (step S37). When the overwriting is completed, the value of the valid flag of the record s is set to "0" (step S39). In step S40, it is determined whether or not the value of the valid flag is set to "0" in all records. If the value of the valid flag is set to "0" in all records, the procedure goes to step S41, and the erase operation management table is deleted.

Here, for the operation by the non-command execution handler 12, the read / write handler 14, and the delete handler 16 for deleting a file whose file name is EOB001.SE1 stored in the root directory, for example, FIG. 20 This will be described with reference to FIG. 21. FIG. 20 is a diagram showing FAT and root directory entries for files after the delete handler 16 operates in response to a delete event for the stored file as shown in FIG. When a delete event for file "EOB001.SE1" is generated, an erase operation management table for a fragment of the file is created, a file name entry, a file extension entry, and a first cluster entry, and a FAT entry of a file entry for the file. 003, 004, 005, 00A and 00C are overwritten with null codes. After this overwriting by the delete handler 16, the operation by the non-instruction execution handler 12 is started.

FIG. 21 is a diagram showing a root directory and a FAT after overwriting by the non-command execution handler 12 and the deletion handler 16. Since the erase operation management table for the fragment of the file is generated by the delete handler 16, the clusters 003, 004, 005, 00A and 00C storing the fragment are overwritten with null codes.

As described above, when an EC command issued by the EC client application 8 instructs file deletion, a null-erase operation is continuously performed by the deletion handler 16 until the timer handler 13 notifies the timeout. . The operation of the delete handler 16 ends by the occurrence of the timeout. Therefore, the period from the EC command issued by the EC client application 8 to the EC response made by the event analysis handler 11 can be shortened. This can shorten the time required to process the EC command, so as not to disappoint the user of the EC client application 8.

Overwriting of data in a file that has not yet been null-erased is performed by other event handlers, such as non-instruction execution handler 12 and read / write 14, except for delete handler 16 within a plurality of idle periods. It is split to run. Therefore, even if the overwriting operation on the EEPROM 3 requires a long time and each fragment has a large size of data, the overwriting of the file entity is completed without causing the user boredom due to the long deletion procedure. can do.

In addition, an encryption key important for reading an encrypted file is null-erased at its very first location. Therefore, even if the user roughly ejects the SDeX memory card 400 from the SD portable device 300 during the deletion procedure by the delete handler 16, the encrypted file is still sufficiently protected.

(Second embodiment)

Overwriting the fragment with a null code according to the first embodiment is performed from the start address toward the end address of the fragment, ie in the forward direction. The overwriting according to the second embodiment is not only forward but also performed in various different ways.

Fig. 22 is a diagram showing an example of the erase operation management table according to the second embodiment. As shown in Fig. 22, the records of the table further have entries of the erasing method.

The erase method entry is set to one of forward, reverse, even / odd, and odd / even. If the erase method entry is set in the forward direction, overwriting the fragment with a null code is performed sequentially from the erase complete address toward the end address as in the first embodiment. If the erase method entry is set in the reverse direction, overwriting is performed from the erase complete address toward the start address.

If the erasing method entry is set to even / odd, first the data of the even number address is null-erased, and then the data of the odd number address is null-erased from the erase complete address toward the end address.

When the erase method entry is set to odd / even, first, data of an odd number address is null-erased, and then data of an even number address is null-erased from the erase complete address toward the end address.

The erase method for the fragment may in turn be selected by the delete handler 16. More specifically, the forward null-erase operation is selected for the first fragment, the reverse null-erase operation is selected for the second fragment, and the even / odd null-erase operation is selected for the third fragment, and odd / even The null-erase operation can be selected for the fourth fragment. In addition, forward, reverse, even / odd, and odd / even operations may be selected for the fifth fragment and subsequent fragments, respectively.

Alternatively, the erase method for the fragment may be randomly selected. Specifically, random numbers 1 to 4 are generated by the delete handler 16, and a null-erase operation is performed by the erase method indicated by one of the random numbers.

In addition, the erasing method may be determined according to a parameter received from the EC client application 8.

FIG. 23 is a diagram showing a null-erase subroutine procedure according to the second embodiment. In step S31, the first record (first record) of the records having the value of the valid flag set to "1" is selected as the record s. The erase method entry of the record s refers to step S51. If the erase method entry is set in the forward direction, the null-erase operation is performed in the same procedure as in steps S32 to S40 shown in the flowchart of FIG. 19 in step S50.

If the erase method entry is set in the reverse direction (step S53), the null-erase operation is performed with the procedure shown in the flowchart of Fig. 24 (step S60).

If the erase method entry is set to even / odd (step S54), the data of the even number address following the erase completed address is null-erased by the same procedure as that of steps S32 to S40 shown in the flowchart of Fig. 19 (step S55). If the data of the even-numbered address is completely null-erased (step S56), the data of the odd-numbered address following the erased address is null-erased by the same procedure as that of steps S32 to S40 shown in the flowchart of FIG. 19 (step S57). .

If the erase method entry is set to odd / even (step S58), the data of the odd-numbered address following the erase complete address is null-erased by the same procedure as that of steps S32 to S40 shown in the flowchart of Fig. 19 (step S57). If the data of the odd-numbered address is completely null-erased (step S59), the data of the even-numbered address following the erased address is null-erased by the same procedure as that of steps S32 to S40 shown in the flowchart of Fig. 19 (step S55). .

24 is a flowchart illustrating a procedure of reverse null-erase operation. Compared with the null-erase subroutine shown in Fig. 19, the relationship between the start address and the end address is opposite to the reverse null-erase operation. In step S61, it is determined whether or not the address obtained by subtracting the overwriting unit length X from the erased address is larger than the start address of the record s. As a result of the determination, if the subtracted address is larger than the start address of the record s, in step S62, the external memory control section 4 is instructed to overwrite X-byte data from the address (erase address -X) of the fragment. When overwriting by the external memory control section 4 is completed (step S63), in step S64, the erase completed address is updated to the address of (erase complete address-X).

If the address (erasure address-overwriting unit length X) is smaller than the start address of record s, the unit length X is converted to be equal to the value obtained by subtracting the start address from the erased address (step S65). In step S66, the external memory control section 4 is instructed to overwrite the X-byte data from the start address with a null code. When overwriting is completed (step S67), the value of the valid flag of record s is set to " 0 " (step S68). In step S69, it is determined whether or not the value of the valid flag is set to "0" in all records. As a result of the determination, if the value of the valid flag is set to " 0 " in all records, the erase operation management table is deleted in step S70.

As described above, in the second embodiment, different fragmentation methods may be assigned to each fragment. As a result, since various kinds of erasing methods are combined, the contents of the fragment to be deleted can be protected without leakage.

(Third embodiment)

According to the third embodiment, if the semiconductor memory card is powered from the card reader / writer 200, the overwriting by the null code described in the first embodiment is limited. When the SDeX memory card 400 accesses the EC server 100 via the card reader / writer 200, the SDeX memory card 400 is helical on the back of the SD portable device 300 described in the first embodiment. Power is supplied through the antenna. Since power supply by radio waves is unstable and insufficient, it is desirable to avoid unnecessary burden on the SDeX memory card 400. According to the third embodiment, the following operations are performed by the SD portable device 300 and the deletion handler 16.

When the SD portable device 300 approaches the card reader / writer 200, the card reader / writer 200 outputs the extended SD command to notify the SDeX memory card 400 that power has been supplied contactlessly. do. On the other hand, when the SD portable device 300 is moved away from the card reader / writer 200, the card reader / writer 200 outputs an extended SD command to indicate that power supply has been stopped in a contactless manner. Notify Whether the SD portable device 300 is close to or away from the card reader / writer 200 is determined by whether the SD portable device 300 has received a polling command from the card reader / writer 200. do.

When an extended SD command is received from the SD portable device 300 to notify the presence of the contactless power supply, the erase handler 16 enters the contactless powering mode. If the delete handler 16 is in this mode, a backup copy of the file entry and the FAT is created, and only the file entry and the FAT are overwritten according to the creation of the delete event. That is, only backup entries of file entries and FATs are created, and no erase operation management table is created. Thus null-erasing operations are not performed by other event handlers.

Next, if the SD portable device 300 does not output an extended SD command to notify that the contactless power supply is not interrupted, the delete handler 16 exits from the contactless power supply mode, and the file An erase operation management table is created based on the entry and the backup copy of the FAT. Since the erase operation management table is created, the null-erase operation by other event handlers except the delete handler 16 is started.

According to the third embodiment, when the SDeX memory card 400 is operated by the power supply from the card reader / writer 200 as described above, the null-erase operation on the file entity of the file is not performed. Therefore, unnecessary burden is not applied to the SDeX memory card 400. This realizes stable operation of the SDeX memory card 400.

(Example 4)

In the first, second and third embodiments, the memory 3 and the external memory 2 in the TRM 1 are each composed of an EEPROM and a flash memory. However, according to the fourth embodiment, the memory 3 and the external memory 2 in the TRM 1 are each composed of two memory modules. FIG. 25 is a diagram showing the respective structures of the internal memory 3 and the external memory 2 according to the fourth embodiment. As shown in Fig. 25, the EEPROM 3a and the flash memory 2a are main memory modules, which are the same as the EEPROM 3 and the flash memory 2 of the first to sixth embodiments, respectively. In the fourth embodiment, in addition to these main memory modules, the auxiliary memory module 2b and the auxiliary memory module 3b are provided in the external memory 2 and the internal memory 3, respectively. These auxiliary memory modules 2b and 3b are Ferro Elelctric Random Access Memory (FeRAM), and their performance is quite different from that of flash memory. 26 is a diagram comparing the performance of the flash memory with the performance of FeRAM. According to FIG. 26, the flash memory is inexpensive and suitable for storing a large amount of data (indicated by ○ in the figure). However, the unit of data writing is a block (indicated by * 1). Here, the size of these blocks increases as the capacity of the flash memory increases. Therefore, writing a small size of data occupies a large capacity. In addition, the time for writing is long (10,000ns) and the number of possible write operations is small (1,000,000 times). In addition, since data writing is performed only after the stored data is once deleted, the writing performance becomes unstable (indicated by * 2).

On the other hand, although FeRAM is expensive and not suitable for storing large data (denoted by Δ), the unit of data writing is bytes and the time for writing is short (30ns to 100ns). In addition, the number of possible write operations is large.

In consideration of such a difference in performance, when FeRAM is used as an auxiliary memory module for storing frequently updated file entries, FATs, etc., the write performance of the flash memory 2a can be compensated. FIG. 27 shows FeRAM storing frequently updated data such as file entries, FATs, and erase operation management tables.

According to the fourth embodiment, FeRAM is used as an auxiliary memory module for storing frequently updated small size data such as file entries and FATs. This achieves fast rewrite operations for file entries and FATs.

FeRAM has the characteristic of destructive read out (indicated by * 4). That is, once stored data is read, the contents of the stored data are deleted from the storage medium. This property is desirable to fully protect the secret. However, according to this property, all data reads require rewriting the read data, which in turn increases the number of times data is written. In order to avoid such destructive reading, magnetoresistive random access memory (MRAM) is preferably used.

(Example 5)

In the fourth embodiment, FeRAM is used as the auxiliary memory module. However, in the fifth embodiment, only FeRAM is used as the memory in the TRM 1. FIG. 28 is a diagram showing an internal configuration of an internal memory 3 according to the fifth embodiment. Here, the memory 3 in the TRM 1 is small. Therefore, even if FeRAM is used for the internal memory 3, the manufacturing cost of the memory 3 does not increase significantly. Note that in the fifth embodiment, the memory 3 in the TRM 1 is composed only of FeRAM, but may be composed only of MRAM.

(Example 6)

According to the sixth embodiment, management information for a file is encrypted with a key different from the encryption key for the file entity of the file. This encryption key for the file management information is stored in the memory 3 in the TRM 1. If instructed to delete the file, overwriting of the encryption key for the file management information is performed by the procedure and deletion handler 16 described in the first embodiment prior to overwriting the encryption key for the file entity.

The management information for the file is encrypted with a different encryption key. Therefore, when the deletion of the file is instructed, reading of the file cannot be performed immediately despite the size of the management information.

(Modification example)

The foregoing description does not refer to all embodiments of the present invention. The present invention can be realized by the embodiment including the following modifications (A) to (E). However, if one of ordinary skill in the art can come up with the following modifications based on the detailed description of the present invention, the accompanying drawings, and the techniques known at the time of filing, the following modifications include the invention described in the claims. Examples of are not included.

In the embodiment (A), the EC client application is taken as an example, but the present invention can be applied to other applications. For example, the present invention can be applied to server applications and corresponding client applications on server devices owned by the transportation industry, such as railway, aviation, bus and highway companies. Thus, the SDeX memory card 400 can be used for boarding procedures at railway ticket gates.

Alternatively, the present invention can be applied to server applications and corresponding client applications on server devices owned by government agencies and local authorities. Accordingly, the SDeX memory card 400 may be used for resident cards and various certificates and registrations.

(B) Information processing by the programs shown in Figs. 15 to 19, 23, and 24 are physically realized by hardware resources such as CPU and EEPROM. That is, a physical device formed by combining a program and a hardware resource performs information processing to achieve a specific purpose. In this way, the SDeX memory card 400 described in the first to sixth embodiments can be realized.

Information processing by a program is physically realized by hardware resources. Therefore, the program whose procedure is shown in the above-described drawings can be considered as a product of technical idea using natural law, and the program itself can also be regarded as an invention. Thus, Figures 15-19, 23 and 24 show an embodiment of a program according to the invention.

The first to sixth embodiments describe embodiments relating to the use of the program according to the present invention, wherein the program is integrated in the SDeX memory card 400. However, the programs illustrated in the first through sixth embodiments may be separated from the SDeX memory card 400 for use. Here, the use of the program itself may include (1) the manufacture of the program, (2) the free or payable transfer of the program, (3) the act of renting the program, (4) the act of importing the program, and (5) bidirectional posting Supply the program to the public through a communications line; and (6) transfer or lease the program to public users by advertising the program through display and distribution of brochures and catalogs.

Typical examples of the act of supplying a program via a bidirectional telecommunication line 5 include a program download service and an application service provider (ASP) service. The program download service allows a provider to send a program to a user so that the user can use the program. In addition, the application service provider service provides the user with the function of the program through a telecommunication line, but the program itself is owned by the provider.

(C) The temporal order for the procedure, such as the order of the steps in each of the flowcharts of Figs. 15 to 19, 23, and 24, is considered as basic for specifying the present invention. Therefore, the procedure shown in each of the above-described flowcharts shows how the control method is used. Therefore, these flowcharts show an embodiment of the use of the control method according to the invention. If the steps in each flowchart are executed in the order of time described above to achieve the original objects and effects of the present invention, then the procedures of these flowcharts will undoubtedly be an embodiment of a control method for a semiconductor memory card according to the present invention. to be.

(D) In the first to sixth embodiments, EEPROM was used as a nonvolatile memory for the inside and outside of the TRM 1. However, the internal memory and the external memory may be other nonvolatile memories such as FeRAM.

(E) The mobile telephone format was taken as an example of the SD portable apparatus 300. However, SD devices can be consumer portable audio devices, set top boxes (STBs), or mobile phones.

The invention defined in the claims of the present invention extends or generalizes the above-described embodiments and modifications thereof. The extent of extension and generalization is based on the state of the art at the time of filing.

However, since the invention defined in the claims is based on means for solving the technical problems of the related art, the scope of the present invention does not depart from the scope of the related art realized by one of ordinary skill in the art. Therefore, each invention defined in the present claims corresponds substantially to the contents described in the detailed description.

 The semiconductor memory card according to the present invention provides high protection against deleted files and is therefore ideal for storing reliable data. Thus, the semiconductor memory card according to the present invention can be used in various fields of the industry, such as in the field of consumer goods.

Explanation of the sign

1: TRM 2: External EEPROM

3: internal EEPROM 4: external memory controller

5: HIM 6: mask ROM

7: CPU 8: Client Application

9: Virtual Machine 10: API

11: event analysis handler 12: non-command execution handler

13: timer handler 14: read / write handler

15: Delete handler 21: Area for application program

22: security realm 23: authentication realm

24: unauthorized region 100: card reader / writer

210: wireless base station 300: portable device

Claims (17)

Non-volatile memory for storing a file consisting of the entity and management information; And A tamper proof module including a processor and an internal memory, The processing unit, When a deletion event for the file is generated, (i) a location table is created in the internal memory in the tamper proof module, and (ii) a deletion unit for overwriting the management information, And the location table indicates the position of the entity, and is referenced by the deletion unit when the deletion unit overwrites the entity. The method of claim 1, The processor may include (i) performing an operation corresponding to a command issued by a device connected to the semiconductor memory card, and (ii) analyzing the command issued by the device and generating an event corresponding to the analysis result. Additionally, The deletion unit, A main deletion unit generating the location table and overwriting the management information when the deletion event is generated; And And a sub-deletion unit which overwrites the entity with reference to the generated location table when an event different from the deletion event is generated. The method of claim 2, A timer for starting to measure a time at which the deletion event is generated, The main deletion unit overwrites a part of the entity in addition to the management information until the timer notifies the timeout, And the sub-deletion unit overwrites the rest of the entity that is not overwritten by the main deletion unit. The method of claim 3, wherein The location table indicates (i) an erase complete address indicating how many of the entities have been overwritten, and (ii) a method of overwriting an entity selected from a plurality of overwriting methods. The sub-deletion unit overwrites the entity according to the overwriting method indicated by the location table, and updates the erase completion address appearing in the location table whenever the sub-deletion unit overwrites a predetermined length of the entity. A semiconductor memory card characterized by the above-mentioned. The method of claim 2, The deletion event is generated by the analyzing unit when the device to which the semiconductor memory card is connected issues a command to delete the file, And the other event is a command end event generated by the analyzing unit when the processing unit completes an operation corresponding to the command. The method of claim 5, The main deletion unit is a deletion handler that starts to operate in response to the generation of the deletion event, And the sub-deletion unit is a non-instruction execution handler starting to operate in response to the generation of the instruction termination event. The method of claim 2, The deletion event is generated by the analyzing unit when the device to which the semiconductor memory card is connected issues a command to delete the file, The other event is one of a read event and a write event, wherein the read event is generated by the analyzing unit when the device commands to read another file in the semiconductor memory card, and the write event is generated by the device. And characterized in that it is generated by the analyzing section when a command is given to write the other file in the semiconductor memory card. The method of claim 7, wherein The main deletion unit is a deletion handler starting to operate in response to the generation of the deletion event, And the sub-deletion section is included in a read / write handler which starts to operate in response to the generation of one of the read event and the write event. The method of claim 2, The internal memory stores an encryption key for encrypting the entity, And when the deletion event is generated, the main deletion unit overwrites the encryption key before overwriting the management information of the file. The method of claim 9, The management information of the file is encrypted with an encryption key different from the encryption key for the entity, the encryption key for the management information is stored in the internal memory, And when the deletion event is generated, the main deletion unit overwrites the encryption key for the management information before overwriting the encryption key for the entity. The method of claim 9, The entity of the file is divided into fragments, The location table is set to (i) the start address of each of the fragments constituting the entity, and (ii) "off" if each of the fragments is not completely overwritten, and "on" if the fragment is completely overwritten. And a flag set to ". &Quot; The method of claim 1, Operated by contact or contactless power supply means from any device, And said processor performs said overwriting only when said semiconductor memory card is operated by said contact power supply means from said device. The method of claim 1, The nonvolatile memory includes a first memory module and a second memory module. A unit of writing to the second memory module is smaller than a unit of writing to the first memory module, And the management information is stored in the second memory module. The method of claim 13, And the second memory module is one of a ferroelectric random access memory (FeRAM) and a magnetoresistant random access memory (MRAM). The method of claim 1, The internal memory is composed of a first memory module and a second memory module, A unit of writing to the second memory module is smaller than a unit of writing to the first memory module, And the location table is stored in the second memory module. The method of claim 15, And the second memory module is one of a ferroelectric memory (FeRAM) and a magnetoresistive memory (MRAM). A control program executed by a CPU in a tamper resistant module included in a semiconductor memory card, wherein the tamper resistant module includes an internal memory, the semiconductor memory card stores a file consisting of entities and management information, When a deletion event for the file is generated, the control program (i) creates a location table on the internal memory in the tamper resistant module, (ii) overwrites the management information, And the location table indicates the location of the entity and is referenced by the control program when the control program overwrites the entity.