JP5180203B2 - System and method for controlling information supplied from a memory device - Google Patents

Description

  The present invention generally relates to a memory system, and more particularly to a memory system having a general-purpose content control function.

This application claims the benefit of US Provisional Patent Application No. 60 / 819,507, filed July 7, 2006.

  This application is related to US patent application Ser. No. 11 / 313,870, filed Dec. 20, 2005, which is US Provisional Patent Application No. 60/638, filed Dec. 21, 2004. , 804 (Patent Document 3). The present application further relates to US patent application Ser. No. 11 / 314,411 filed on Dec. 20, 2005. The present application further relates to US patent application Ser. No. 11 / 314,410 filed Dec. 20, 2005. The present application further relates to US patent application Ser. No. 11 / 313,536, filed Dec. 20, 2005. The present application further relates to US patent application Ser. No. 11 / 313,538, filed Dec. 20, 2005. The present application further relates to US patent application Ser. No. 11 / 314,055, filed Dec. 20, 2005. The present application further relates to US patent application Ser. No. 11 / 314,052, filed Dec. 20, 2005. The present application further relates to US patent application Ser. No. 11 / 314,053, filed Dec. 20, 2005.

  This application is based on US Patent Application No. 11 / 557,028 entitled “Content Control Method Using Certificate Chains” filed on November 6, 2006, and “Applications on November 6, 2006”. US Patent Application No. 11 / 557,010 entitled “Content Control System Using Certificate Chains” by Holtzman et al. And “Content Control Method Using Certificate” by Holtzman et al. Filed on November 6, 2006. US Patent Application No. 11 / 557,006 entitled “Revocation Lists” and US Patent Application No. 11/157 entitled “Content Control System Using Certificate Revocation Lists” filed on November 6, 2006 by Holtzman et al. No. 557,026 (Patent Document 4) and “Content Control Method Using Versatile Control Structure” of Holtzman et al. Filed on Nov. 6, 2006. National Patent Application No. 11 / 557,049 (Patent Document 15) and US Patent Application No. 11 / 557,056 entitled “Content Control System Using Versatile Control Structure” filed Nov. 6, 2006 by Holtzman et al. (Patent Document 16), US Patent Application No. 11 / 557,052 (Patent Document 17) called “Method for Controlling Information Supplied From Memory Device” by Holtzman et al. Filed on Nov. 6, 2006, 2006 US Patent Application No. 11 / 557,051 entitled “System for Controlling Information Supplied From Memory Device” by Holtzman et al. Filed on Nov. 6 and Holtzman filed on Nov. 6, 2006. US Patent Application No. 11 / 557,041 (Patent Document 19) entitled “Control Method Using Identity Objects” and Holtzman filed on Nov. 6, 2006. And US Patent Application No. 11 / 557,039 (Patent Document 20) called “Control System Using Identity Objects”.

  Each of these patent applications is incorporated herein by reference in its entirety as if it were written in the present application.

  Storage devices such as flash memory cards are favorably used as storage media for storing digital content such as photographs. Flash memory cards may be used to distribute different types of media content. With the diversification of host devices such as computers, digital cameras, mobile phones, personal digital assistants (PDAs), media players such as MP3 players, media content stored in flash memory cards can be played back. ing. For this reason, there is a high possibility that flash memory cards and other portable storage devices are widely used as means for distributing digital contents.

  Since the amount of confidential / public information stored in the storage device is increasing, it is desirable to be able to determine the type of information that can be used according to the state of the entity that queries it. Therefore, it is desired to provide an improved system for providing confidential / public information to an entity according to the state of the entity.

US Provisional Patent Application No. 60 / 819,507 US patent application Ser. No. 11 / 313,870 US Provisional Patent Application No. 60 / 638,804 US patent application Ser. No. 11 / 314,411 US patent application Ser. No. 11 / 314,410 US patent application Ser. No. 11 / 313,536 US patent application Ser. No. 11 / 313,538 US patent application Ser. No. 11 / 314,055 US patent application Ser. No. 11 / 314,052 US patent application Ser. No. 11 / 314,053 US patent application Ser. No. 11 / 557,028 US patent application Ser. No. 11 / 557,010 US patent application Ser. No. 11 / 557,006 US patent application Ser. No. 11 / 557,026 US patent application Ser. No. 11 / 557,049 US patent application Ser. No. 11 / 557,056 US patent application Ser. No. 11 / 557,052 US patent application Ser. No. 11 / 557,051 US patent application Ser. No. 11 / 557,041 US patent application Ser. No. 11 / 557,039

  Since the amount of confidential / public information stored in the storage device is increasing, it is desirable to be able to determine the type of information that can be used according to the state of the entity that queries it. Therefore, in one embodiment of the present invention, the memory device is detachably connected to the host device. The memory device supplies public information in response to a general information query transmitted by the entity from the host device. Access to sensitive information stored in the memory device is controlled by a control data structure. In response to a private information query sent by the authenticated entity from the host device, the memory device supplies only the portion of the confidential information that is permitted by the control data structure for access by such authenticated entity. . Entities are only allowed access to the parts of the confidential information that are permitted by the control data structure, even if authenticated. With such a flexible access control method, each business entity can access only the authorized portion of the confidential information, and is not allowed to access other confidential information portions.

  All patents, patent applications, articles, books, specifications, standards, other publications, documents and things referred to herein are hereby incorporated by reference in their entirety for all purposes. If there is a discrepancy or discrepancy in the definition or use of a term between any of the incorporated publications, documents, or things and the text of this specification, the definition or use of the term in this specification shall prevail.

1 is a block diagram of a memory system in communication with a host device that is useful for illustrating the present invention. FIG. Useful for illustrating various embodiments of the present invention, various partitions of memory that control access to specific partitions and encrypted files by access policies and authentication procedures and non-stored in various partitions. It is the schematic with an encryption and an encryption file. FIG. 4 is a schematic diagram of a memory showing various partitions in the memory. FIG. 4 is a schematic diagram of a file location table for various partitions of the memory shown in FIG. 3 in which several files in the partition are encrypted, useful for illustrating various embodiments of the present invention. FIG. 3 is a schematic diagram of access control records and corresponding key references in an access control record group that are useful for illustrating various embodiments of the invention. FIG. 3 is a schematic diagram of a tree structure formed by access control record groups and access control records that are useful in illustrating various embodiments of the present invention. FIG. 3 is a schematic diagram of a tree showing three hierarchical trees of access control record groups to illustrate the tree formation process. 6 is a flowchart illustrating a process executed by a host device and a memory device such as a memory card when creating and using a system access control record. 6 is a flowchart illustrating a process executed by a host device and a memory device such as a memory card when creating and using a system access control record. 6 is a flowchart illustrating a process for creating an access control record group using system access control records that is useful for illustrating various embodiments. 6 is a flowchart illustrating a process for creating an access control record. FIG. 2 is a schematic diagram of two access control record groups that are useful to illustrate one application of a hierarchical tree. FIG. 6 is a flowchart illustrating a process for delegating specific rights. FIG. 13 is a schematic diagram of an access control record group and an access control record for illustrating the delegation process of FIG. 12. FIG. 5 is a flow chart illustrating a process for creating a key for encryption and / or decryption purposes. FIG. 6 is a flowchart illustrating a process for deleting access rights and / or data access rights according to an access control record. FIG. 6 is a flowchart illustrating a process for requesting access when an access right and / or access right is deleted or expires. FIG. 6 is a schematic diagram illustrating the structure of an authentication rule structure and an encryption key access authorization policy that are useful for illustrating various embodiments of the present invention. FIG. 6 is a schematic diagram illustrating the structure of an authentication rule structure and an encryption key access authorization policy that are useful for illustrating various embodiments of the present invention. FIG. 6 is a block diagram of a database structure showing an alternative method for controlling access to protected information according to a policy. It is a flowchart which shows the authentication process using a password. It is a figure which shows many host certificate chains. It is a figure which shows many device certificate chains. FIG. 4 is a protocol diagram illustrating a process for one-way and mutual authentication schemes. FIG. 4 is a protocol diagram illustrating a process for one-way and mutual authentication schemes. FIG. 3 is a certificate chain diagram that is useful to illustrate one embodiment of the present invention. FIG. 7 is a table showing information in a control sector preceding a certificate buffer sent by a host when sending a final certificate to a memory device to illustrate another embodiment of the present invention, the certificate Indicates an indication that is the last certificate in the certificate chain. It is a flowchart which shows each process of a card | curd and a host by the authentication system with which a memory card authenticates a host apparatus. It is a flowchart which shows each process of a card | curd and a host by the authentication system with which a memory card authenticates a host apparatus. It is a flowchart which each shows the process of a card | curd and a host by the authentication system with which a host apparatus authenticates a memory card. It is a flowchart which each shows the process of a card | curd and a host by the authentication system with which a host apparatus authenticates a memory card. 6 is a flowchart illustrating processes executed by a host device and a memory device, respectively, when a certificate revocation list stored in the memory device is retrieved by the host device to exemplify another embodiment of the present invention. 6 is a flowchart illustrating processes executed by a host device and a memory device, respectively, when a certificate revocation list stored in the memory device is retrieved by the host device to exemplify another embodiment of the present invention. FIG. 6 is a certificate revocation list diagram showing fields in a certificate revocation list to illustrate yet another embodiment of the present invention. FIG. 6 is a flowchart illustrating a card and host process for verifying a certificate using a certificate revocation list. FIG. FIG. 6 is a flowchart illustrating a card and host process for verifying a certificate using a certificate revocation list. FIG. 6 is a flowchart illustrating a card process in which a card signs data to be transmitted to a host and decrypts data from the host. It is a flowchart which shows a host process in case a card signs the data transmitted to a host. It is a flowchart which shows a host process in case a host transmits encryption data to a memory card. It is a flowchart which shows the process of a general information and a nonpublic information query, respectively. It is a flowchart which shows the process of a general information and a nonpublic information query, respectively. 1 is a functional block diagram of a system architecture in a memory device (such as a flash memory card) connected to a host device for illustrating an embodiment of the present invention. FIG. 40B is a functional block diagram of an internal software module of the SSM core of FIG. 40A. It is a block diagram of the system which produces | generates a disposable password. It is a functional block diagram which shows a disposable password (OTP) seed provision and OTP production | generation. FIG. 6 is a protocol diagram illustrating a seed provision stage. It is a protocol figure which shows a disposable password production | generation step. It is a functional block diagram which shows a DRM system. FIG. 10 is a protocol diagram illustrating a process of providing a license and downloading a content when a key is provided in a license object. It is a protocol figure which shows the process of reproduction | regeneration operation. FIG. 11 is a protocol diagram showing a process of providing a license and downloading a content when no key is provided in the license object.

  The drawings illustrate features of various embodiments of aspects of the invention. For simplicity, the same components are labeled with the same numbers in this application.

  The block diagram of FIG. 1 illustrates an exemplary memory system that can implement various aspects of the present invention. As shown in FIG. 1, the memory system 10 includes a central processing unit (CPU) 12, a buffer management unit (BMU) 14, a host interface module (HIM) 16, a flash interface module (FIM) 18, and a flash. A memory 20 and a peripheral access module (PAM) 22 are included. The memory system 10 communicates with the host device 24 through the host interface bus 26 and the port 26a. The flash memory 20 may be of a NAND type and provides a data storage area for the host device 24. The host device 24 is a digital camera, personal computer, personal digital assistant (PDA), MP3 player, etc. It may be a digital media player, a mobile phone, a set top box, other digital devices or household appliances. The software code of the CPU 12 can also be stored in the flash memory 20. The FIM 18 connects to the flash memory 20 through the flash interface bus 28 and the port 28a. The HIM 16 is suitable for connection to a host device. The peripheral device access module 22 selects an appropriate controller module such as FIM, HIM, and BMU in communication with the CPU 12. In one embodiment, all components of the system 10 within the dotted frame may be enclosed in a single device, such as a memory card or stick 10 ', and preferably enclosed therein. Since the memory system 10 is detachably connected to the host device 24, the contents of the system 10 can be accessed from many different host devices.

  In the following description, the memory system 10 may be referred to as a memory device 10, or simply referred to as a memory device or device. Although the present invention is illustrated here with reference to a flash memory, the present invention can also be applied to different types of memories such as magnetic disks and optical CDs and other rewritable nonvolatile memory systems.

  The buffer management unit 14 includes a host direct memory access (HDMA) 32, a flash direct memory access (FDMA) 34, an arbiter 36, a buffer random access memory (BRAM) 38, and a crypto engine 40. Since the arbiter 36 is a shared bus arbiter, only one master or initiator (HDMA 32, FDMA 34, or CPU 12) always operates, and its slave or target is the BRAM 38. The arbiter is responsible for directing the appropriate initiator request to the BRAM 38. The HDMA 32 and the FDMA 34 are in charge of data transfer between the HIM 16, the FIM 18, and the BRAM 38 or the CPU random access memory (CPU RAM) 12a. The operation of the HDMA 32 and the operation of the FDMA 34 are conventional and need not be described in detail here. The BRAM 38 is used for storing data transferred between the host device 24 and the flash memory 20. The HDMA 32 and the FDMA 34 transfer data between the HIM 16 / FIM 18 and the BRAM 38 or the CPU RAM 12a, and further serve to instruct the end of the sector.

  The memory system 10 in one embodiment generates a key value for use in encryption and / or decryption, which is preferably inaccessible to external devices such as the host device 24. Alternatively, the key value may be generated outside the system 10, for example by a license server, and transmitted to the system 10. Regardless of the method of generating the key value, only the authenticated entity can access the key value once stored in the system 10. However, since the host device reads and writes data in the memory system 10 in the form of a file, encryption and decryption are normally performed in file units. The memory device 10 does not manage files, like many other storage devices of different types. The memory 20 stores a file allocation table (FAT) for identifying a logical address of a file, but normally the host device 24 and not the controller 12 access and manage this FAT. For this reason, when encrypting data of a specific file, the controller 12 needs to have the logical address of the data of this file in the memory 20 sent to the host device. And the data can be encrypted and / or decrypted using a key value that only the system 10 can use.

  In order to prepare a name for both the host device 24 and the memory system 10 to refer to the same key in the encryption processing of the file data, the host device generates each key generated by the system 10 or transmitted to the system 10. A reference is provided for each value, which may be a key ID. The host 24 assigns a key ID to each file encrypted by the system 10, and the system 10 assigns a key ID provided from the host to each key value used for data encryption processing. Thus, when the host requests data encryption processing, the request is transmitted to the system 10 together with the key ID and the logical address of the data taken out from the memory 20 or stored in the memory 20. The system 10 generates or receives a key value, assigns a key ID provided from the host 24 to the value, and executes cryptographic processing. There is no need to change the operation of the memory system 10, and the memory system 10 can completely control cryptographic processing using a key, such as exclusive access to a key value. In other words, once the key value is stored in the system 10 or generated by the system 10, the system manages the key value used for cryptographic processing while leaving the host 24 to manage the file under exclusive control of the FAT. Undertake. After the key value is stored in the memory system 10, the host device 24 is not involved in the management of the key value used for data encryption processing.

  The key ID provided from the host 24 and the key value transmitted to the memory system or generated by the memory system are, in one embodiment, two attributes, hereinafter referred to as “content encryption key” or CEK. Form. The host 24 may assign a key ID to one or more files and assign a key ID to data organized in some way, as well as unorganized data or data organized in a complete file. May be allocated.

  In order for a user or an application to access content or areas protected by the system 10, it is necessary to authenticate using a credential registered in advance in the system 10. A credential is associated with an access right that grants the access right to a particular user or application. Such pre-registration stores a record of the identity or credentials of the user or application in the system 10 and access is allocated according to such identity and credentials determined by the user or application and provided through the host 24. Is done. After pre-registration is complete, a user or application requesting data writing to the memory 20 stores its identity and credentials, a key ID for encrypting the data, and the encrypted data. The logical address needs to be provided through the host device. The system 10 generates or receives a key value, assigns a key ID provided by the host device to this value, and stores the key ID of the key value used for encrypting the write data in a record or table of this user or application. Then, the system 10 encrypts the data, stores the encrypted data at an address designated by the host, and stores the generated or received key value.

  A user or application requesting to read encrypted data from the memory 20 stores his / her identity and credentials, the key ID of the key used to encrypt the requested data, and the encrypted data. It is necessary to provide a logical address. The system 10 matches the user or application identity and credentials provided by the host with those stored in its own record. If they match, the system 10 retrieves the key value associated with the key ID provided by the user or application from its own memory and decrypts the data stored at the address specified by the host device using the key value. And send the decrypted data to the user or application.

  By separating the credentials for authentication from the management of keys used for cryptographic processing, it is possible to have a common data access right with different credentials. That is, even if one group of users or applications with different credentials can access the same key and access the same data, users other than this group cannot. Even if all users or applications in a group access the same data, the rights of those users or applications may still be different. Some have read-only access rights, some have only write access rights, others have both. In system 10, which maintains a record of user or application identity and credentials, accessible key IDs, and access rights associated with each key ID, the key ID is added under the control of a formally authenticated host device Or delete access, change the access rights associated with a specific user or application key ID, transfer access from one user or application to another, or record a user or application record or table It can also be deleted or added. In the stored record, a secure channel can be identified in accessing a particular key. Authentication can be accomplished using symmetric or asymmetric algorithms and passwords.

  Of particular importance, content protected within the memory system 10 can be moved. In embodiments where access to key values is controlled by a memory system, if the memory system or storage device incorporating this system is moved from one external system to another, the security of the content stored there Is kept. Whether the key is generated by the memory system or from outside the memory system, the external system cannot access the contents of the system 10 unless it is authenticated in a fully controlled manner by the memory system. Even after being authenticated as such, access is entirely controlled by the memory system, and the way of access by the external system is controlled in accordance with records preset in the memory system. Requests that do not comply with such records are rejected.

  In order to increase the flexibility of content protection, a specific area of memory, hereinafter referred to as a partition, is assumed, and this partition can be accessed only by authorized users or applications. By combining this with the above-described key-type data encryption function, the data protection capability of the system 10 is improved. As shown in FIG. 2, the storage capacity of the flash memory 20 can be divided into a number of partitions, namely a user area or partition and a custom partition. All users or applications can access the user area or partition P0 without authentication. All the bit values of the data stored in the user area can be read and written by any application or user, but if the read data is encrypted, the user or application that does not have the authority to decrypt can be read in the user area. The stored bit value representation information cannot be accessed. For example, the files 102 and 104 stored in the user area P0 correspond to this. Unencrypted files are also stored in the user area such as 106, which can be read and interpreted by all applications and users. Encrypted files such as files 102 and 104 are displayed with associated lock symbols.

  An unauthorized application or user cannot interpret the file encrypted in the user area P0, but even such an application or user can delete or destroy the file, which is preferable depending on the application. There may not be. For this reason, the memory 20 also includes protected custom partitions such as the partitions P1 and P2 that cannot be accessed without prior authentication. An authentication process that can be used for embodiments of this application will now be described.

  As also shown in FIG. 2, files in memory 20 are accessed by various users or applications. FIG. 2 shows users 1 and 2 and applications 1 to 4 (executed on the apparatus). These entities are granted access to the protected content in memory 20 after being authenticated by the authentication process described below. In this process, the entity that requires access needs to be identified on the host side for role-based access control. Thus, the entity requesting access first identifies itself by supplying information such as “I want to read file 1 as application 2”. The controller 12 matches its identity, authentication information, and request with a record stored in the memory 20 or the controller 12. If all requirements are met, such entities are granted access. As shown in FIG. 2, the user 1 can read and write the file 101 of the partition P1 and has unlimited read / write rights to the file 106 at P0, but the only other files that can be read are the files 102 and 104. It is. On the other hand, the user 2 is not permitted to access the files 101 and 104, but has read / write access rights to the file 102. As shown in FIG. 2, the login algorithms (AES) for users 1 and 2 are the same, but the login algorithms for applications 1 and 3 are different (eg, RSA and 000001), and are different from those for users 1 and 2.

The secure storage application (SSA) is a security application of the memory system 10 that exemplifies an embodiment of the present invention, and many of the functions described above can be executed using this. The SSA can be implemented as software or computer code, and a database stored in the memory 20 or a non-volatile memory (not shown) of the CPU 12 is read into the RAM 12a and executed by the CPU 12. The following table lists the acronyms used when referring to SSA.

Description of SSA System The main role of SSA is data protection, integrity and access control. Data is a file that may be stored at a glance in some mass storage devices. The SSA system sits on top of the storage system, adds a security layer for stored host files, and provides security functions through a security data structure described below.

  The main task of SSA is to manage various rights related to (protected) content stored in memory. Memory applications need to manage multiple users and content rights for multiple stored content. In addition to viewing the presented drive and partition from the host side, the host application also views a file allocation table (FAT) that manages and represents the location of the file stored in the storage device.

  The storage device in this case uses a NAND flash chip divided into partitions, but other portable storage devices can also be used and are within the scope of the present invention. These partitions are a series of logical addresses whose boundaries are delimited by a start address and an end address. Thus, if desired, restrictions can be placed on access to hidden partitions, which are associated by software (such as software stored in memory 20) with such restrictions on addresses within such boundaries. The SSA completely recognizes the partition by the boundary of the logical address managed by itself. SSA systems use partitions to physically protect data from unauthorized host applications. A partition for a host is a mechanism that defines a private space where data files are stored. When making these partitions public, anyone who has access to the storage device can choose to view and recognize the existence of these partitions on the device, and to make the partitions private or hidden. Only the host application that has access to these partitions can recognize their presence in the storage device.

  FIG. 3 is a schematic diagram of a memory showing memory partitions P0, P1, P2, and P3 (of course, more than five partitions may be used, or fewer than three partitions may be used), P0 is a public partition that any entity can access without authentication.

  Access to files in private partitions (such as P1, P2, or P3) is hidden. By preventing access to the partition by the host, the flash device (eg, flash card) achieves data file protection within the partition. However, this type of protection encloses all files in the hidden partition by limiting access to data stored at logical addresses in the hidden partition. In other words, a restriction is associated with a series of logical addresses. Any user / host that has access to the partition has unlimited access to all the files inside. In order to separate files (or file groups) from each other, the SSA system provides different levels of protection and integrity on a file (or file group) basis using keys and key references, or key IDs. The key reference or key ID of the key value used to encrypt data at various memory addresses can be compared to a container or area that contains the encrypted data. For this reason, in FIG. 4, key reference marks, that is, key IDs (for example, “key 1” and “key 2”) are shown as an area surrounding a file encrypted using the key value associated with the key ID. Yes.

  Referring to FIG. 4, for example, since file A is not surrounded by a key ID, any business entity can access file A without authentication. File B in the public partition can be read or overwritten by any entity, but the data in it is encrypted with the key with ID “Key 1”, so this key can be accessed. Unless it is such an entity, the information in file B cannot be accessed. The use of such key values and key references or key IDs provides only logical protection, unlike the partition protection described above. That is, any host that can access a partition (public or private) can read and write data including encrypted data in the partition. However, since the data is encrypted, an unauthorized user can only destroy the data. Unauthorized users are preferably unable to change this data without knowledge. By restricting access to the encryption and / or decryption key, only authorized entities can be allowed to use the data. In P0, the files B and C are also encrypted using a key having the key ID “key 2”.

  Data security and integrity can be provided by a symmetric encryption method using one content encryption key (CEK) per CEK. In the SSA embodiment, the CEK key value is generated or received by a flash device (eg, a flash card), used only internally, and kept secret to the outside. Data integrity can also be ensured by performing hash calculations on the data to be encrypted, or by chaining the ciphers.

  Not all data in a partition is encrypted with different keys and different key IDs are not allocated. A key or key reference may not be assigned to a logical address in a public or user file or operating system area (ie, FAT), in which case any entity that can access the partition itself You can access this.

  Entities that want to create keys and partitions, read and write data in partitions, and use keys must log into the SSA system through access control records (ACR). The privileges of ACR in the SSA system are called actions. Any ACR may have the authority to perform three types of actions: creating partitions and keys / key IDs, accessing partitions and keys, and creating / updating other ACRs.

  ACRs are organized into groups called ACR groups or AGPs. If the ACR authentication is successful, the SSA system releases the session, and the ACR action can be executed in this session. ACR and AGP are security data structures for controlling access to partitions and keys according to a policy.

The user partition SSA system manages one or more public partitions, also called user partitions. This partition exists on the storage device and can be accessed through standard read / write commands of the storage device. Information regarding the size of this partition and the presence of this partition on the device is preferably not hidden from the host.

  In an SSA system, this partition can be accessed through standard read / write commands or SSA commands. Access to this partition is preferably not restricted to a specific ACR. However, in the case of the SSA system, the host device can restrict access to the user partition. Read / write access can be individually enabled / disabled. All four combinations (for example, write only, read only (write protection), read and write, inaccessible) are possible.

  In an SSA system, a key ID is assigned to a file in a user partition using ACR, and an individual file can be encrypted using a key associated with such key ID. Access to the encrypted file in the user partition and setting of the access right to the partition are performed using the SSA command set. The functions described above also apply to data that is not organized in the form of files.

SSA partition This is a hidden (hidden for unauthenticated) partition that can only be accessed by SSA commands. The SSA system preferably does not allow access to the SSA partition by the host device unless access is made in a session (described below) established by logging into the ACR. Similarly, the SSA preferably does not provide information regarding the existence, size, and access rights of the SSA partition unless the request occurs within the established session.

  The access right to the partition is retrieved from the ACR authority. An ACR logged into the SSA system can share a partition with other ACRs (described later). When a partition is created, the host gives the partition a reference name or ID (eg, P0-P3 in FIGS. 3 and 4). This reference name is used in subsequent read / write commands for this partition.

Partitioning of storage devices Preferably, all of the device's available storage capacity is allocated to the user partition and the currently configured SSA partition. For this reason, repartitioning may involve reconfiguration of existing partitions. The net change in device capacity (total size of all partitions) is zero. The ID of the partition in the device memory space is set by the host system.

  The host system can subdivide any one of the existing partitions into two smaller partitions, or merge two existing partitions (which may or may not be adjacent) into one . Data in the divided and merged partitions can be erased at the discretion of the host or left as is.

  The SSA system imposes severe restrictions on repartitioning because data may be lost (due to erasure or movement in the logical address space of the storage device) due to repartitioning of the storage device. That is, only the ACR in the root AGP (described later) is allowed to issue a re-segmentation command, and the only partition that can be referred to is the partition owned by itself. Since the SSA system does not know how the data is organized in the partition (FAT or other file system structure), it is the host's responsibility to reconfigure the device in repartitioning.

  By repartitioning the user partition, the size and other attributes of this partition as seen from the host OS change.

  After repartitioning, the host system is responsible for ensuring that the ACR does not reference partitions that do not exist in the SSA system. If these ACRs are not properly deleted or updated, access attempts made on behalf of these ACRs to the absent partition will be detected and rejected by the system. Similar considerations are given to keys and key IDs to be deleted.

Keys, key IDs, logical protection Files written to certain hidden partitions are hidden from the public. However, once an entity (a hostile entity or otherwise) gains information and accesses this partition, the file becomes usable and self-explanatory. To further secure the file, the SSA can encrypt the file in a hidden partition, and the credentials for accessing the key used to decrypt the file are preferably different from those for accessing the partition. Make things. There is a problem with allocating CEK to a file because the file is totally controlled and managed by the host. To solve this, associate the file with something that the SSA understands, namely the key ID. That is, when a key is created by SSA, the host assigns a key ID to data to be encrypted using the key. If the key is sent to the SSA along with the key ID, it is easy to associate the key with the key ID.

  Key values and key IDs provide logical security. Any data that is assigned a specific key ID is encrypted with the same key value of the content encryption key (CEK) regardless of its location, and the host application provides a unique reference name or key ID. . An entity that accesses a hidden partition (via ACR authentication) and wants to read or write an encrypted file in that partition needs to access the key ID assigned to that file. When granting access to the key with this key ID, the SSA loads the key value into the CEK associated with this key ID and decrypts the data before transmitting it to the host, or encrypts the data and then flashes the memory. Write to 20. In one embodiment, the CEK key value associated with the key ID is randomly generated by the SSA system and maintained by the SSA system. No one knows or accesses the CEK key value outside the SSA system. Only reference marks, ie, key IDs, are provided externally and used externally, not CEK key values. The key value is fully controlled by the SSA, preferably only the SSA can access it. Alternatively, a key can be provided to the SSA system.

The SSA system protects the data associated with the key ID using one of the following cryptographic modes (set by the user) (the cryptographic algorithm used and the key value in CEK are under system control). Is not revealed to the outside).
Block mode: Data is divided into blocks and each block is encrypted individually. This mode is generally considered to be less secure and is susceptible to dictionary attacks, but the user can randomly access any one of the data blocks.
-Chain mode: Data is divided into blocks and connected in a chain during the encryption process. Any block is used as input to the encryption process for the next block. Although it is said that safety is high, since data reading and writing are sequentially performed from the beginning to the end, an overhead that is unacceptable to the user may occur.
-Hash mode: A chain mode plus a data digest used for data integrity verification.

The ACR and the access control SSA are designed to handle a large number of applications, and each application is represented as a tree of nodes in the system database. Achieve mutual exclusion between applications by eliminating crosstalk between branches of the tree.

  When accessing an SSA system, an entity needs to establish a connection through any one ACR of the system. When connecting, the SSA system operates a login procedure in accordance with the ACR rules selected by the user.

  ACR is an individual login point leading to the SSA system. The ACR holds login credentials and authentication methods. The login authority within the SSA system, including read and write privileges, is also in this record. In FIG. 5, which shows this, there are n ACRs in the same AGP. This means that at least various ACRs out of n ACRs share access to the same key. That is, ACR # 1 and ACR # n share the access right to the key having the key ID “key 3”, where ACR # 1 and ACR # n are ACR IDs, and “key 3” is the key It is a key ID, and data related to “key 3” is encrypted using this key. The same key can be used to encrypt and / or decrypt multiple files or multiple data groups.

  The SSA system supports several system logins, the authentication algorithms and user credentials may vary, and the privileges of the user who successfully logged in may also vary. FIG. 5 illustrates various password login algorithms and credentials. In ACR # 1, a password login algorithm and a password are designated as credentials, and in ACR # 2, a PKI (public key infrastructure) login algorithm and a public key are designated as credentials. Therefore, an entity must present a valid login algorithm and credentials in addition to presenting a valid ACR ID at login.

  The authority of the entity logged into the ACR of the SSA system, that is, the right to use the SSA command is set in the authority control record (PCR) associated with the ACR. As shown in the PCR of FIG. 5, ACR # 1 grants the read-only authority to the data associated with “Key 3”, and ACR # 2 reads and writes the data associated with “Key 5”. Grant permissions.

  Different ACRs such as keys used for reading and writing may have common interests and privileges in the system. For this reason, ACRs having a common part are grouped into AGPs, that is, ACR groups. Both ACR # 1 and ACR # n have an access right to the key having the key ID “key 3”.

  Since AGP and the ACRs within it are organized in a hierarchical tree, ACR can create secure keys that keep important data secure, and preferably other ACRs corresponding to its own key ID / partition. You can create items. These child ACRs have the same authority as that of the father, that is, the creator, or less, and may be granted the authority of the key created by the father ACR itself. Needless to say, the child ACR obtains access authority to an arbitrary key created by itself. This is illustrated in FIG. All of the ACRs in the AGP 120 are created by the ACR 122, and two of these ACRs inherit from the ACR 122 access authority to the data associated with “Key 3”.

AGP
When logging into the SSA system, specify the AGP and the ACR within the AGP.
Each AGP has a unique ID (reference name) and is used as an index to the corresponding item in the SSA database. The AGP name is provided to the SSA system when the AGP is created. SSA rejects the creation operation if the AGP name to be provided already exists in the system.

  As described in the following sections, restrictions related to access authority and delegation of management authority are managed and managed using AGP. Controlling management of access by completely independent entities, eg, two different applications or two different computer users, is one of the roles played by the two trees of FIG. What can be important here is that the two access processes are virtually independent of each other (ie, virtually eliminate crosstalk), even if they occur simultaneously. This means that the ACR and AGP authentication, authority, additional creation, etc. in each tree are irrelevant and independent of those in the other trees. For this reason, in the memory system 10 using the SSA system, a plurality of applications can be processed simultaneously. It also allows two applications to access two separate groups of data (eg, a set of photos and a set of songs) independently of each other. This is illustrated in FIG. At the top of FIG. 6, for an application or user accessing through a node (ACR) in the tree, the data associated with “Key 3”, “Key X”, and “Key Z” may be a photograph. . At the bottom of FIG. 6, for an application or user accessing through a tree node (ACR), the data associated with “key 5” and “key Y” may be a song. The ACR that created the AGP can delete the AGP only if the AGP has no ACR entry and is empty.

SSA entry for business entities: Access Control Records (ACR)
The ACR of the SSA system describes the way of system login by an entity. An entity that logs in to the SSA system needs to specify an ACR that corresponds to the authentication process starting from now. As shown in FIG. 5, the authority control record (PCR) in the ACR clarifies the permission actions that can be executed by the user who has completed the ACR authentication. The host entity provides all ACR data fields.

Entities that have successfully logged in to the ACR can query the ACR's partition / key access authority and ACAM authority (described below).
ACR ID
When an SSA system entity initiates the login process, it must specify the ACR ID that corresponds to the login method (provided by the host when the ACR is created), so SSA prepares the correct algorithm. When all the login conditions are satisfied, the correct PCR is selected. The ACR ID is provided to the SSA system when the ACR is created.

Login / authentication algorithm The login procedure used by the entity and the credentials required to prove the identity of the user depend on the authentication algorithm. From no procedure (no credentials) to password-based procedures, two-way authentication protocols based on symmetric or asymmetric cryptography, the SSA system supports several standard login algorithms.

The credentials of the credential entity correspond to a login algorithm and are used by the SSA to verify and authenticate the user. A password / PIN number for password authentication, an AES key for AES authentication, and the like may be examples of credentials. The credential type / format (PIN, symmetric key, etc.) is predetermined, retrieved from the authentication mode, and provided to the SSA system when the ACR is created. The SSA system is not involved in the setting, distribution, and management of these credentials, but with the exception of PKI authentication, a key pair such as RSA can be generated using a device (for example, a flash card), and it is made public for certificate generation. You can export the key.

Authority control record (PCR)
The PCR reveals the licensing terms for an entity after logging into the SSA system and passing the ACR authentication process. There are three types of authority: partition and key creation authority, partition and key access authority, and entity-ACR attribute management authority.

Access to Partitions This part of the PCR contains a list of partitions that can be accessed by entities that have successfully completed the ACR phase (using the partition ID provided to the SSA system). There are cases where the type of access is restricted to write-only or read-only for each partition, or complete write / read access rights may be specified. Although ACR # 1 in FIG. 5 can access partition # 2, it cannot access partition # 1. Restrictions specified in PCR apply to SSA partitions and public partitions.

  The public partition is accessed by normal read and write commands for a device (for example, a flash card) that hosts the SSA system, or by an SSA command. When a root ACR (described later) having the authority to restrict public partitions is created, this root ACR can pass that authority to its children. The ACR can only restrict access to the public partition, preferably with normal read and write commands. The ACR of an SSA system can preferably be limited only when it is created. After the ACR has read / write authority to the public partition, it preferably cannot be revoked.

This part of the key ID access PCR contains data associated with a list of key IDs (provided by the host to the SSA system) that can be accessed by the relevant entity if the ACR policy is met by the entity's login process. Enters. The specified key ID is assigned to the file in the partition described in the PCR. Since no key ID is assigned to the logical address of a device (eg, a flash card), if there are more than one partition for a particular ACR, there are files in any of those partitions. Each key ID specified in the PCR can have a different set of access rights. Access to data indicated by the key ID may be restricted to write-only or read-only, or a full write / read access right may be designated.

ACR attribute management (ACAM)
This section describes the case where the system attributes of ACR can be changed.
The ACAM actions that can be allowed in the SSA system are as follows.
1. 1. Create / delete / update AGP and ACR 2. Create / delete partitions and keys Delegating access to keys and partitions The father ACR preferably cannot edit ACAM rights. In this case, it is preferable to delete and recreate the ACR. Also, the access authority for the key ID created by the ACR cannot be revoked.

The ACR may have a capacity for creating other ACRs and AGPs. Creating an ACR may mean that some or all of the ACAM authority owned by the creator is delegated to the created ACR. Having the right to create an ACR means having the right to the next action.
1. Set and edit child credentials-The authentication method once set by the originator ACR is preferably not editable. The credentials may be changed within the range of an authentication algorithm set in advance for the child.
2. Delete the ACR.
3. Delegate creation rights to the child ACR (thus making grandchildren).

  An ACR that has the authority to create another ACR has the authority to delegate the unblocking authority to the ACR it creates (although there may be no authority to unblock the ACR). The father ACR places the release ACR reference mark in the child ACR.

The father ACR is the only ACR that has the authority to delete its child ACR. When the lower ACR created by the ACR is deleted, all ACRs born from the lower ACR are automatically deleted. When an ACR is deleted, all key IDs and partitions created by that ACR are deleted.
There are two exceptions where the ACR can update its own record.
1. Even passwords / PINs set by the creator ACR can only be updated by the ACR that contains them.
2. The root ACR can delete itself and the AGP to which it belongs.

The key / partition access right delegation ACR and its AGP are configured in a hierarchical tree, and the root AGP and its ACR are located at the top of the tree (for example, root AGPs 130 and 132 in FIG. 6). There may be several AGP trees in an SSA system, but they are completely independent of each other. An ACR in the AGP can delegate access to its key to all ACRs in the same AGP and all the ACRs created by them. The authority to create a key preferably includes the authority to delegate access authority to use the key.

There are three types of authority for keys.
1. Access: Set the access authority for the key, that is, read and write.
2. Ownership: Of course, the owner of the key is the ACR that created it. This ownership can be delegated from one ACR to another (ACR in the same AGP or in a child AGP). Key ownership provides the authority to delegate authority over a key in addition to the authority to delete a key.
3. Access right delegation: This right allows the ACR to delegate the rights it holds.
In addition to the partition created by itself, the ACR can delegate access authority to other partitions subject to access authority owned by the ACR.
To delegate authority, the partition name and key ID are added to the designated ACR PCR. In order to delegate access authority for a key, it is stated that the key ID may be used, or all created keys of the delegating ACR may be subject to access authority.

If the entity's ACR authentication process by the ACR block and release system fails, the ACR block counter may increase. When a certain maximum number of failed authentications (MAX) is reached, the ACR will be blocked by the SSA system.
A blocked ACR can be released by another ACR that references the blocked ACR. The reference to the released ACR is set by the ACR that is the creation source. The released ACR is preferably in the same AGP as the creator of the blocked ACR and has the “release” right.
Other ACRs in the system cannot release a blocked ACR. If there is no release ACR even if there is an ACR with a cutoff counter, it cannot be released when it is shut down.

Root AGP-Application Database Creation The SSA system is designed to process multiple applications and separate the data for each application. When identifying and separating application data, the tree structure of the AGP system is used as the main tool. The root AGP is located at the top of the application SSA database tree and conforms to somewhat different behavior rules. In the SSA system, several root AGPs can be configured. In FIG. 6, two root AGPs 130 and 132 are shown. Of course, fewer AGPs or more AGPs may be used and are within the scope of the present invention.
Registration of a device (for example, a flash card) for a new application and / or issuance of credentials for a new application of the device is performed in the process of adding a new AGP / ACR tree to the device.

The SSA system supports three modes when creating a root AGP (as well as all ACRs of the root AGP and their authority).
1. Open mode: A user / enterprise authenticated by any user or entity without authentication or through a system ACR (described below) can create a new root AGP. Route AGP creation in open mode is based on the case where all data transfer is performed through an open channel (within the issuing agency's secure environment) without security measures, and through system ACR authentication (Over The Air (OTA) and post-issue procedure). It may be done through a secure channel to be established.
If the system ACR is not configured (as an option) and the root AGP creation mode is set to open, the only option that can be selected is the open channel.
2. Control mode: Only entities authenticated through the system ACR can create a new root AGP. If the system ACR is not configured, the SSA system cannot be set to this mode.
3. Lock mode: Creation of root AGP is disabled and no further root AGP can be added to the system.

This function is controlled by two SSA commands (these commands can be used without authentication by any user / enterprise).
1. Method configuration command: Used to configure the SSA system to use any one of three route AGP creation modes. Only mode change from option to control and from control to lock is possible (ie, if the SSA system is currently configured in control mode, it can only be changed to lock mode).
2. Method configuration fix command: Used to override the method configuration command and permanently fix it in the currently selected method.

  The created root AGP enters a special initialization mode, allowing creation and configuration of ACR (using the same access restrictions applied to creating the root AGP). If an entity explicitly switches this to operational mode at the end of the root AGP configuration process, the existing ACR cannot be updated and no additional ACR can be created.

In order to delete the root AGP that has entered the standard mode, it is necessary to log in to the system through an ACR that is authorized to delete the root AGP. Besides the special initialization mode, this is also an exception for the root AGP. This is preferably the only AGP that may include an ACR that has the authority to delete its own AGP, rather than an AGP at the next tree level.
The third and final difference between the root ACR and the standard ACR is that it is the only ACR in the system that can have the authority to create and delete partitions.

SSA system ACR
The system ACR is used for the following two SSA operations:
1. Create ACR / AGP tree under secure channel protection in adverse situation.
2. Identify and authenticate the device that hosts the SSA system.
There may be only one system ACR in the SSA, and once set, the system ACR is preferably not changeable. System authentication is not required when creating a system ACR, only an SSA command is required. The system ACR creation function can be disabled (similar to the root AGP creation function). Since only one system ACR is allowed, the create system ACR command will not work after the creation of the system ACR.

  System ACR does not work in its creation process. When the creation is complete, it is necessary to issue a dedicated command telling that the system ACR is created and ready. Preferably, the system ACR cannot be updated or replaced at this point.

  The system ACR creates a root ACR / AGP with SSA. The system ACR has the authority to add / change the root level until the host is satisfied and blocked. When the route AGP is cut off, the connection with the system ACR is basically broken and tampering is impossible. At this point, no one can change / edit the root AGP and the ACR within it. This is accomplished with the SSA command. The effect of disabling root AGP creation is permanent and cannot be undone. FIG. 7 shows the above-described functions related to the system ACR. Three types of route AGP are created using the system ACR. As shown by the dotted line connecting the system ACR to the route AGP in FIG. 7, at a certain point after these route AGPs are created, an SSA command for intercepting the route AGP is sent from the system ACR, and the route AGP creation function is become invalid. As a result, the three root AGPs cannot be tampered with. Three separate trees are formed by using three root AGPs to create child AGPs before or after the root AGP is blocked.

  The functionality described above provides great flexibility when content owners use content to configure secure products. Secure products need to be “issued”. Issuing is a process in which a device identifies a host and the host issues an identification key for identifying the device. The host can determine if it can trust its secret by identifying the device (eg, flash card). On the other hand, by identifying the host, the device can implement the security policy only to the extent possible by the host (permit and execute a specific host command).

  Products designed to support multiple applications will have different identification keys. The product is “pre-issued” (stores the key during manufacturing prior to shipment) or “post-issue” (adds a new key after shipment). For later issuance, some parent key or device level key must be placed in a memory device (eg, a memory card) and this key can be used to identify the entity that is allowed to add applications to the device. Is called.

  The product can be configured to enable / disable post-issuance with the functions described above. In addition, post-issue configurations can be performed safely after shipment. The device is purchased as a retail product without a key in addition to the parent key or device level key described above and can be configured by a new owner to enable or disable further post-issue applications.

Thus, the system ACR function provides the ability to achieve the aforementioned objectives.
In the case of a memory device without a system ACR, applications can be freely added without limitation.
A memory device without a system ACR can be configured to disable the creation of the system ACR, which means that the addition of new applications cannot be controlled (unless the new root AGP creation function is also disabled).
In the case of a memory device with a system ACR, an application can be added via a secure channel established by an authentication procedure using system ACR credentials.
A memory device with a system ACR can be configured to disable the add application function before or after the application is added.

Key ID list The key ID is created according to a specific ACR request, but the memory system 10 uses this only in the SSA system. The data provided from the creation source ACR when the key ID is created or provided to the creation source ACR is as follows.
1. Key ID: This ID is provided from the business entity through the host, and is used to refer to the key and data encrypted or encrypted using the key in subsequent read access and write access.
2. Key encryption and data integrity modes (block, chain, and hash modes described above)

In addition to the attributes provided by the host, the SSA system manages the following data:
1. Key ID owner: ID of the ACR corresponding to the owner. The owner of the created key ID is the creator ACR. However, ownership of the key ID can be transferred to another ACR. Preferably, only the owner of the key ID can transfer the ownership of the key ID and transfer the key ID. It is the owner of the key ID or any other ACR with delegation authority that can delegate key access authority and revoke these rights. When any of these operations is attempted, the SSA system grants the operation only if the authority is given to the ACR that requests the operation.
2. CEK: The key value of this CEK is used for encrypting the content to which the key ID is assigned or the content indicated by the key ID. The key value may be a 128-bit AES random key generated by the SSA system.
3. MAC and IV values: Dynamic information (message authentication code and start vector) used in the chain block cipher (CBC) encoding algorithm.

  The various functions of the SSA are illustrated with reference to the flowcharts of FIGS. 8A to 16, where “H” on the left side of the steps in these figures means an operation performed by the host, and “C” means Means operations performed by the card. Although the SSA function is illustrated with reference to the memory card, it can be understood that these functions also apply to memory devices having different physical forms. To create the system ACR, the host issues a create system ACR command to the SSA of the memory device 10 (block 202). In response, device 10 checks whether a system ACR already exists (block 204, diamond 206). If it already exists, the device 10 returns a failure status and stops (oval 208). The memory 10 checks if creation of the system ACR is allowed if it does not already exist (diamond 210) and returns a failure status if not allowed (block 212). Therefore, for example, since a necessary security function is determined in advance, the device issuer may not permit the creation of the system ACR, for example, when the system ACR is not required. If so, the device 10 returns an OK status and waits for system ACR credentials from the host (block 214). The host checks the SSA status to see if the device 10 communicates that the creation of the system ACR is allowed (block 216 and diamond 218). If creation is not allowed or if a system ACR already exists, the host stops (oval 220). If the device 10 communicates that creation of the system ACR is permitted, the host issues an SSA command to set its login credentials and sends it to the device 10 (block 222). Device 10 updates the system ACR record with the received credentials and returns an OK status (block 224). In response to the status signal, the host issues an SSA command indicating that the system ACR is ready (block 226). In response, the device 10 locks the system ACR so that the system ACR cannot be updated or replaced (block 228). As a result, the function of the system ACR and the identity for identifying the device 10 to the host are fixed.

  The procedure for creating a new tree (new root AGP and ACR) depends on how those functions are configured on the device. FIG. 9 explains the procedure. Both the host 24 and the memory system 10 follow this procedure. If the addition of a new route AGP is completely disabled, a new route AGP cannot be added (diamond 246). If this is enabled, but a system ACR is required, the host authenticates through the system ACR prior to issuing the root AGP creation command (block 254) and establishes a secure channel (diamond 250, block 252). If the system ACR is not required (diamond 248), the host 24 can issue a create root AGP command without authentication and proceeds to block 254. The host may use the system ACR if it is present, even if it is not required (not shown in the flowchart). A device (eg, a flash card) rejects an attempt to create a new root AGP if the new root AGP creation function is disabled and creates a new root AGP without authentication if a system ACR is required Reject the attempt (diamonds 246 and 250). Since the AGP and ACR newly created in block 254 are switched to the operation mode, the ACR in the AGP cannot be updated or changed, and the ACR cannot be added to the AGP (block 256). Since the system is optionally locked here, no more root AGP can be created (block 258). A dotted frame 258 is a notation indicating that this step is an optional step. Any frame indicated by a dotted line in the flowchart of the figure of the present application is an optional step. In this way, the content owner can be prevented from using the device 10 for illegal purposes that pretend to be a real memory device containing legitimate content.

  To create an ACR (an ACR other than the ACR in the root AGP described above), one can start with an ACR that has the right to create an ACR, as shown in FIG. 10 (block 270). The entity attempting to enter through the host 24 provides an ACR identity that is the entrance and an ACR that includes all the attributes that it needs to create (block 272). The SSA checks the ACR identity match and further checks whether the ACR with that identity is authorized to create an ACR (diamond 274). If the request is verified, the SSA of device 10 creates an ACR (block 276).

  The two AGPs in FIG. 11 illustrate a tree useful in security applications using the method of FIG. Therefore, the ACR having the identity m1 in the marketing AGP has the authority to create an ACR. The ACR m1 also has the authority to read / write data associated with the key ID “marketing information” and data associated with the key ID “price list” using a key. Thus, a sales AGP including two ACRs s1 and s2 is created using the method of FIG. The ACRs s1 and s2 have only the authority to read the key for accessing the price data associated with the key ID “price list”, but are required when accessing the data associated with the key ID “marketing information”. There is no key authority. Thus, an entity having ACRs s1 and s2 cannot change the price data even if it is read, and cannot access the marketing data. On the other hand, ACR m2 has no authority to create an ACR, and has only the authority to read a key for accessing data associated with the key ID “price list” and the key ID “marketing information”.

  Accordingly, the access right can be delegated in the manner described above, and m1 delegates the right to read price data to s1 and s2. This is particularly useful when large scale marketing or sales organizations are involved. However, there may be no need to use the method of FIG. Instead, as shown in FIG. 12, access rights can be delegated from the ACR to an ACR located at or below the same AGP. To enter the AGP tree, the entity first specifies the ACR in the tree through the host as described above (block 280). Next, the host specifies the right to delegate with the ACR. The SSA checks this ACR in the tree and checks if this ACR is authorized to delegate rights to another designated ACR (diamond 282). If it is authorized, the right is delegated (block 284), otherwise it stops. FIG. 13 shows the result. In this case, since ACR m1 has the authority to delegate read authority to ACR s1, after delegation, s1 can access price data using a key. This can be done if m1 has the right to access price data or more and has the authority to delegate it. In one embodiment, m1 retains its access right after delegation. Preferably, access rights are delegated under certain conditions (not permanently), such as by limiting time or number of accesses.

  FIG. 14 shows the process of creating a key and key ID. The entity is authenticated through the ACR (block 302). The entity requests creation of a key with an ID specified by the host (block 304). The SSA checks whether the designated ACR has the authority (diamond 306). For example, if a key is used to access data in a particular partition, the SSA will check whether the ACR can access that partition. If the ACR has the authority, the memory device 10 creates a key value associated with the key ID provided by the host (block 308), stores the key ID in the ACR, and stores the key value in memory (controller-related memory or Rights and authorities are stored according to information provided by the entity (block 310), and the corresponding ACR PCR is modified with the granted rights and authorities (block 312). Thus, the key creator has all rights, such as read and write rights, the right to delegate and share to other ACRs or lower level ACRs in the same AGP, the right to transfer key ownership, etc.

  As shown in FIG. 15, the ACR can change the authority of another ACR in the SSA system (or the existence of the ACR itself). An entity may still enter the tree through the ACR. In this case, the entity is authenticated and the entity designates an ACR (blocks 330, 332). The entity requests deletion of the target ACR or deletion of authority of the target ACR (block 334). If the designated ACR or the currently active ACR has the right (diamond 336), the target ACR is deleted or the PCR of the target ACR is modified to remove such authority (block 338). If this is not authorized, the system stops.

After the process described above, the target can no longer access data that was accessible before the process. As shown in FIG. 16, since the ACR ID that once existed is no longer present in the SSA, the entity that attempts to enter the target ACR notices the failure of the authentication process, so the access right may be denied (diamond 352). ). Assuming that the ACR ID has not been deleted, the entity specifies the ACR (block 354), specifies the key ID and / or the data for the particular partition (block 356), and the SSA uses the PCR for such an ACR. To check whether the key ID or the partition access request is permitted (diamond 358). If the authority has been removed or has expired, the request is rejected again. If not, the request is granted (block 360).
The process described above determines whether access to protected data is performed by a device (eg, a flash card), whether the ACR and its PCR have been modified by another ACR or configured as such from the beginning. It explains how it is managed.

The session SSA system is designed to handle multiple users logging in simultaneously. When using this feature, the command received by the SSA is supported by a particular entity, and the command is executed only if the ACR used to authenticate this entity is authorized to perform the requested action. .

  Multiple entities are supported by the session concept. The session is established in the authentication process and a session id is assigned by the SSA system. The session id is internally associated with the ACR used to log in to the system, exported to the entity, and used in subsequent SSA commands.

  The SSA system supports two types of sessions: open sessions and secure sessions. The type of session associated with the authentication process is set in the ACR. The SSA system enforces session establishment in a manner similar to authentication enforcement. Since the entity's authority is set in ACR, the system designer can associate a secure tunnel with access to a specific key ID or execution of a specific ACR management operation (create new ACR, set credentials, etc.) .

Open Session An open session is a session identified by a session id. However, since bus encryption is not performed, both commands and data are delivered without being encrypted. This mode of operation is preferably used for a large number of users or a large number of business environments where the business entity does not fall under the threat model and does not intercept on the bus.

  In the open session mode, data transmission is not protected, and an efficient firewall is not implemented between applications on the host side, but access can be permitted only to information that the SSA system can access with an authenticated ACR.

  Open sessions can also be used when partitions or keys need to be protected. However, after a valid authentication process, access is granted to all entities on the host side. The host application can obtain the authority of the authenticated ACR as long as it has a session id. This is illustrated in FIG. 17A. Steps above line 400 are steps performed by host 24. The entity that has completed ACR1 authentication (block 402) requests access to the file associated with key ID X in memory device 10 (blocks 404, 406, and 408). If the ACR1 PCR grants this access, the device 10 grants the request (diamond 410). Otherwise, the system returns to block 402. After authentication is complete, the memory system 10 identifies the entity issuing the command by only the assigned session id (not the ACR credentials). Once ACR1 reaches the data associated with the PCR key ID in an open session, any other application or user can access the same data by specifying the correct session id shared by the various applications on the host 24 it can. This feature is advantageous for applications where it is convenient for the user to log in only once and have access to all data associated with the account used to log in for various applications. A user of a mobile phone can access the stored e-mail and listen to the music stored in the memory 20 without repeating login. On the other hand, data that does not correspond to ACR1 cannot be accessed. For this reason, content that can be valuable to users of the same mobile phone, such as games and photos, is accessed through another account ACR2. This is data that the mobile phone user does not want to make access to the person who borrows the phone, but for the mobile phone user, other data may be accessed if it can be accessed with the first account ACR1. By dividing access to data into two separate accounts and accessing ACR1 in an open session, not only is it easy to use, but valuable data can be protected.

  To further simplify the sharing of session ids between host applications, an ACR requesting an open session specifically requests that a “0 (zero)” id be assigned to the session. In this way, the application can be designed to use a predetermined session id. Of course, only one ACR requesting session 0 can be authenticated at a time. Attempts to authenticate another ACR requesting session 0 will be rejected.

In order to add a secure session security layer, the session id may be used as shown in FIG. 17B. In this case, the memory 10 also stores the session id of the active session. In FIG. 17B, to access a file associated with key ID X, for example, the entity must also provide a session id, eg, session id “A”, on which access to the file is allowed. (Blocks 404, 406, 412 and 414). Thus, the requesting entity cannot access the memory 10 without knowing the correct session id. Since the session id is deleted after the session is over and is different for each session, the entity can only access it if it can provide a session number.

The SSA system uses the session number to track whether the command is actually coming from the correct authenticated entity. The host application uses a secure session (secure channel) when there is a use or use in which an attacker may attempt to send malicious commands using the open channel.
When using a secure channel, the session id and the entire command are encrypted using a secure channel encryption (session) key, and its security level is as high as in the host-side embodiment.

End of session The session ends in one of the following scenarios, and the ACR is logged off.
1. The entity issues an explicit session termination command.
2. A communication timeout occurs. A particular entity did not issue a command for a period set as one of the ACR parameters.
3. All open sessions are terminated after a device (eg, flash card) reset and / or power cycle.

The data integrity service SSA system verifies that the SSA database (accommodating ACR, PCR, etc.) is kept intact. In addition, a data maintenance service for business entity data by a key ID mechanism is also provided.
When the key ID encryption algorithm is set to hash mode, the hash value is stored in the CEK record along with CEK and IV. During the write operation, the hash value is calculated and stored. The hash value is again calculated during the read operation and compared with the value stored during the previous write operation. Each time the entity accesses the key ID, the additional data is concatenated (encrypted) with the old data and the corresponding hash value (for reading or writing) is updated.

Since only the host knows the data file associated with or indicated by the key ID, each aspect of the data integrity function is explicitly managed by the host as follows.
1. A data file associated with or indicated by a key ID is written or read from beginning to end. Since the SSA system uses CBC cryptography and generates a hashed message digest of the entire data, the file will be confused by attempts to access a portion of the file.
2. Since the intermediate hash value is managed by the SSA system, there is no need to process the data in a continuous stream (this data stream can be interleaved with data streams with other key IDs and can be split across multiple sessions). However, the entity needs to explicitly instruct the system to reset the hash value when the data stream begins again.
3. When the read operation is complete, the host explicitly requests the SSA system to validate the read hash by comparing it with the hash value calculated during the write operation.
4). The SSA system also provides a “dummy read” operation. With this function, the data passes through the encryption engine but is not sent to the host. By using this function, it is possible to verify that the data is kept intact before the data is actually read from the device (for example, a flash card).

Random number generation external entities can use the internal random number generator of the SSA system, and random numbers can be used outside the SSA system. This service can be used on any host and does not require authentication.

RSA key pair generation External users can use the internal RSA key pair generation function of the SSA system, and the key pair can be used outside the SSA system. This service can be used on any host and does not require authentication.

Instead of using an alternative embodiment hierarchy approach, a similar result can be achieved using the database approach shown in FIG.
As shown in FIG. 18, the credential list, the authentication method, the maximum number of failures, the minimum number of credentials necessary for release of the block, etc., input to the database stored in the controller 12 or the memory 20 are stored in the memory 10. It is tied to the policy in the database (read / write access to keys / partitions, secure channel requirements) executed by the controller 12. Restrictions and restrictions on key / partition access are also stored in the database. Entities that may be whitelisted (eg, system administrators) have access to all keys and partitions. Information access attempts by entities that may be blacklisted are blocked. Restrictions may apply globally and may apply per key and / or partition. This means that only certain entities can access certain keys / partitions, and certain entities cannot. Regardless of the content partition and the key used to encrypt or decrypt the content, constraints can be imposed on the content itself. Thus, the number of times data is read, regardless of the entity that allows access to only the first five host devices that may access the data (eg, songs) or the data (eg, movies). Can be limited.
Authentication
Password protection and password protection mean that a password must be presented when accessing a protected area. Unless the password is limited to one, different rights such as read access and read / write access can be assigned to each password.
Password protection means that the device (eg, flash card) can verify the password provided by the host, that is, the device also stores the password in a memory area managed and protected by the device.
Problems, limitations and passwords can suffer replay attacks. Passwords that do not change with each presentation can be resent in the same state. In other words, if the data to be protected is valuable and easy access to the communication bus, the password should not be used as is.
• Access to stored data can be protected by passwords, but passwords should not be used to protect data (not keys).
-If the password is diversified using the parent key to raise the security level related to the password, the entire system will not be broken even if one password is hacked. A session key type secure communication channel can be used for password transmission.

  FIG. 19 is a flowchart showing authentication using a password. The business entity transmits the account id and password to the system 10 (for example, a flash memory card). The system checks whether the password matches the password in its memory. If they match, the authenticated status is returned. Otherwise, the account error counter is incremented and the entity is required to re-enter the account id and password. The system returns an access denied status when the counter is full.

The symmetric key symmetric key algorithm means that the same key is used for both encryption and decryption. This means that a key is determined in advance prior to communication. Each side executes the opposite algorithm of the other side. That is, one is an encryption algorithm and the other is a decryption algorithm. There is no need to run both algorithms on both sides when communicating.
Authentication / symmetric key authentication means that a device (for example, a flash card) and a host share the same key and have the same encryption algorithm (direct and reverse, for example, DES, DES-1).
-Symmetric key authentication means challenge response (replay attack countermeasure). The protected device generates a question for the other device and calculates the answer on both devices. The device on the authentication side sends back the answer, and the protected device checks the answer to check the authenticity. Then, a right is granted according to the authentication.
Authentication includes the following:
External authentication: A device (eg, a flash card) authenticates the outside. That is, the device checks the credentials of a particular host or application.
• Mutual authentication: generate questions on both sides.
Internal authentication: The host application authenticates the device (eg, flash card). That is, the host checks whether the device is authentic for the application.
To raise the security level of the entire system (so that if one is broken, not everything is broken)
・ Symmetric keys are usually combined with diversification using a parent key.
• Use questions from both sides with mutual authentication to confirm that the question is a genuine question.
Cryptographic symmetric key cryptography is a very efficient algorithm and does not require a powerful CPU for cryptographic processing, so it is also used for encryption.

When using the communication channel safely:
Both devices must know the session key used to secure the channel (ie, encrypt all outgoing data and decrypt all incoming data). This session key is usually set using a pre-shared secret symmetric key or using PKI.
• Both devices must know and execute the same cryptographic algorithm.
You can also sign data using a signature symmetric key. The signature in this case is a partial result of the encryption. Therefore, it is possible to sign as many times as necessary without exposing the key value.

The problem and bounding symmetric algorithms are very efficient and secure, but are based on pre-shared secrets. The problem is to share this secret dynamically and securely and make it random (like a session key). In other words, it is difficult to keep a shared secret secure for a long time, and it is almost impossible to share it with many people.
In order to facilitate this work, a public key algorithm that exchanges secrets without sharing them is devised.

Asymmetric Authentication Procedure In authentication based on an asymmetric key, a session key for secure channel communication is finally created while passing data using a series of commands. The basic protocol authenticates the user to the SSA system. Mutual authentication or two-factor authentication for verifying the ACR used by the user is also possible depending on the protocol variation.

  The SSA asymmetric authentication protocol preferably uses a public key infrastructure (PKI) algorithm and an RSA algorithm. By defining with these algorithms, each party in the authentication process can have its own RSA key pair. Each pair consists of a public key and a private key. These keys are secret keys and cannot provide proof of identity. In the PKI layer, a trusted third party signs the public key. This public authority public key is pre-shared between the parties authenticating each other and used to verify the public key of the parties. If trust is established (both parties determine that the public key provided by the other party can be trusted), protocol authentication (verifies the match of private keys owned by each party) and key exchange continues. This can be accomplished with the challenge-response mechanism of FIGS. 22 and 23 described below.

  A structure that accommodates a signed public key is called a certificate. The credit agency that signed the certificate is called a certification authority (CA). The side receiving the authentication has a certificate and RSA key pair that proves the authenticity of the public key. The certificate is signed by a certification authority trusted by the other party (the authenticating party). The authenticating side is required to own the public key of the trusted CA.

  SSA corresponds to a certificate chain. This means that the public key of the identified side is signed by a different CA, that is, a CA that is different from the CA that the identifying side trusts. In this case, the identified side provides the CA certificate that signed the public key in addition to its own certificate. If even this second level certificate is not trusted by the other party (not signed by a trusted CA), a third level certificate can be provided. In this certificate chain algorithm, each party has a complete list of certificates required for public key authentication. This is illustrated in FIGS. 23 and 24. The credentials required for mutual authentication by this type of ACR are RSA key pairs having a certain length.

The SSA certificate SSA is [X. 509] Adopt version 3 digital certificate. [X. 509] is a general-purpose standard, and the SSA certificate profile described here further specifies and restricts the contents of a predetermined field of the certificate. This certificate profile also defines the trust hierarchy used for certificate chain management, SSA certificate checking, and certificate revocation list (CRL) profiles.
Since the certificate is considered public information (as an internal public key), it is not encrypted. However, the certificate includes an RSA signature, and verifies that the public key and other information fields have not been tampered with by this RSA signature.
[X. 509] is ASN. The format of each field using one standard is defined, and ASN. One standard uses the DER format for data encoding.

Overview of SSA Certificate One embodiment of the SSA certificate management architecture shown in FIGS. 20 and 21 comprises an infinite hierarchical level of the host and three hierarchical levels of the device, but the hierarchical level used by the device is three levels. May be more or less than 3 levels.

The host certificate hierarchy device has two components: the root CA certificate stored in the device (stored as ACR credentials when creating the ACR) and the entity attempting to access the device (to that particular ACR). Authenticate the host based on the certificate / certificate chain provided by.

  The host certification authority acts as a root CA (certificate in ACR credentials) for each ACR. For example, a root CA for one ACR is a “host 1 CA (level 2) certificate”, and a root CA for another ACR is a “host root CA certificate”. For each ACR, all entities that hold a certificate signed by the root CA (or a certificate chain that connects the root CA to the end entity certificate) have a corresponding private key in the end entity certificate. You can log in to that ACR. As mentioned above, certificates are well known and are not kept secret.

  Anyone who owns a certificate issued by a root CA (as well as the corresponding private key) can log in to that ACR, because the certificate for a particular ACR is stored in the ACR's credentials. Means it depends on the person. In other words, the issuer of the root CA becomes a business entity that manages the ACR authentication method.

Host Root Certificate The root certificate is a trusted CA certificate used when SSA is used to initiate verification of the public key of the entity (host) attempting to log in. This certificate is provided as part of the ACR credentials when creating the ACR. Since this is the basis of trust in the PKI system, it is assumed that it is provided by a trusted entity (Father ACR, or manufacturing / configuration trust environment). The SSA that verifies the certificate verifies the certificate signature using the public key. The host root certificate is encrypted and stored in non-volatile memory (not shown in FIG. 1), and preferably only the CPU 12 of the system 10 of FIG. 1 has access to the device's private key. .

Host certificate chain These certificates are provided to the SSA during authentication. After the chain processing is completed, the host certificate chain is not collected again and stored in the apparatus.

FIG. 20 is a schematic diagram of the host certificate level hierarchy showing multiple host certificate chains. As shown in FIG. 20, the host certificate may have many certificate chains, and only three certificate chains are illustrated here.
A1. Host root CA certificate 502, host 1 CA (level 2) certificate 504,
Host certificate 506
B1. Host root CA certificate 502, host n CA (level 2) certificate 508,
Host 1 CA (level 3) certificate 510, host certificate 512
C1. Host root CA certificate 502, host n CA (level 2) certificate 508,
Host certificate 514

  The three certificate chains A1, B1, and C1 described above exemplify three types of host certificate chains that may be used to prove that the host's public key is authentic. Referring to FIG. 20 and the certificate chain A1 described above, the public key of the CA (level 2) certificate 504 of the host 1 is signed by the private key of the host root CA (ie, the digest of the public key is encrypted). The public key is in the host root CA certificate 502. Therefore, the business entity having the public key of the host root CA can verify the authenticity of the certificate chain A1 described above. As the first step, the entity decrypts the signed public key of the CA (level 2) certificate 504 of the host 1 transmitted from the host by using the public key of the host root CA owned by itself. The signed public key is compared with the digest of the unsigned public key of the CA (level 2) certificate 504 of the host 1 transmitted from the host. If the two match, the public key of host 1's CA (level 2) is authenticated, and the entity then locks host 1's CA (level 2) secret in the host certificate 506 sent from the host. The public key of the host signed by the key is decrypted using the CA (level 2) authenticated public key of the host 1. If the decrypted signed value matches the digest value of the public key in the host certificate 506 transmitted from the host, the host public key is also authenticated. Authentication using certificate chains B1 and C1 is similarly performed.

  As can be seen from the above-described process involving chain A1, the first public key sent from the host and verified by the entity is the host 1 CA (level 2) public key, not the host root CA certificate. Therefore, what the host needs to send to the entity is the host 1 CA (level 2) certificate 504 and the host certificate 506, and the host 1 CA (level 2) certificate is the first in the chain. Will need to be sent to. As described above, the certificate verification order is as follows. The verifying entity, ie the memory device 10 in this case, first verifies the authenticity of the public key of the first certificate in the chain, which in this case is the certificate of the CA located under the root CA. 504. After verifying that the public key of this certificate is authentic, the apparatus 10 proceeds to verify the next certificate, in this case the host certificate 506. Similarly, the verification sequence in the case where the certificate chain includes three or more certificates starts with the certificate located immediately below the root certificate and ends with the certificate of the entity to be authenticated.

The device certificate hierarchy host has two components: the device root CA stored on the host, and the certificate / certificate chain provided to the host from the device (provided to the device as credentials when creating the ACR). Authenticate the device based on. The device authentication process by the host is similar to the host authentication process by the device described above.

Device Certificate Chain These certificates are ACR key pair certificates. These certificates are provided to the card when the ACR is created. SSA stores these certificates individually and provides them to the host one at a time for authentication. SSA uses these certificates to authenticate the host. The device can process a chain of three certificates, but the number of certificates may be other than three. The number of certificates may vary depending on the ACR. This is determined when the ACR is created. Although the device can send a certificate chain to the host, it does not use certificate chain data, so there is no need to parse the certificate chain.

FIG. 21 is a schematic diagram of a device certificate level hierarchy showing 1 to n certificate chains in a device such as a storage device using SSA. The n certificate chains shown in FIG. 21 are as follows.
A2. Device root CA certificate 520, device 1 CA (manufacturer) certificate 522,
Device certificate 524
B2. Device root CA certificate 520, device n CA (manufacturer) certificate 526,
Device certificate 528

  SSA devices are manufactured by 1 to n manufacturers, each with its own device CA certificate. Thus, the public key of the device certificate for a particular device is signed by the different manufacturer's private key, and the manufacturer's public key is signed by the private key of the device root CA. The method for verifying the device public key is similar to the method for the host public key described above. As with the chain A1 verification described above for the host, there is no need to send the device root CA certificate, the first certificate to be sent in the chain is the device i CA (manufacturer) certificate, The device certificate follows, and i is an integer from 1 to n.

  In the embodiment shown in FIG. 21, the device sends two certificates: a device i CA (manufacturer) certificate, followed by its device certificate. A device i CA (manufacturer) certificate is a manufacturer's certificate that produces such a device and provides a private key for signing the device's public key. The host that has received the device i CA (manufacturer) certificate decrypts and verifies the device i CA (manufacturer) public key using the public key of the root CA owned by itself. If the host fails this verification, it interrupts the process and informs the device that the authentication has failed. If the host is successfully authenticated, it sends a request for the next certificate to the device. The device then sends its device certificate, and the host verifies it as well.

  22 and 23 show the verification process described above in more detail. The “SSM system” in FIG. 22 is a software module that executes the SSA system described in this specification and other functions described later. The SSM can be embodied as software or computer code, stores a database in the memory 20 or a non-volatile memory (not shown) of the CPU 12, is read into the RAM 12a, and is executed by the CPU 12.

  As shown in FIG. 22, the process by which the SSM system 542 of the device 10 authenticates the host system 540 has three stages. In the first public key verification stage, the host system 540 sends a host certificate chain to the SSM system 542 using an SSM command. The SSM system 542 verifies the authenticity of the host certificate 544 and the authenticity of the host public key 546 using the root certification authority public key in the host root certificate 548 of the ACR 550 (block 552). If there is an intermediate certification authority between the root certification authority and the host, the intermediate certificate 549 is also used for verification in block 552. Assuming that the verification or process (block 552) was successful, the SSM system 542 proceeds to the second stage.

  The SSM system 542 generates a random number 554 and transmits this as a question to the host system 540. The system 540 uses the host system's private key 547 to sign the random number 554 (block 556) and sends the signed random number as an answer to the question. The answer is decrypted using the host public key 546 (block 558) and compared with the random number 554 (block 560). Assuming the decrypted answer matches the random number 554, the challenge response is successful.

  In the third stage, the host public key 546 is used to encrypt the random number 562. This random number 562 becomes a session key. The host system 540 can obtain the session key by decrypting the encrypted number 562 from the SSM system 542 with the private key (block 564). With this session key, secure communication can be started between the host system 540 and the SSM system 542. In the one-way asymmetric authentication shown in FIG. 22, the host system 540 is authenticated by the SSM system 542 of the apparatus 10. FIG. 23 is a protocol diagram showing a two-way mutual authentication process similar to the one-way authentication protocol of FIG. 22, in which the SSM system 542 is also authenticated by the host system 540.

  FIG. 24 is a diagram of a certificate chain 590 that illustrates one embodiment of the present invention. As described above, the certificate chain that needs to be presented for verification may include a large number of certificates. The certificate chain in FIG. 24 includes a total of nine certificates, and when authenticating, it may be necessary to verify all of these certificates. As explained earlier in the background section, existing certificate verification systems do not provide a complete certificate chain, send entire credentials, or send certificates in a specific order. The receiver cannot parse the certificate until it has received and memorized the certificate. However, problems may arise because the number of certificates in the chain is not known in advance. It may be necessary to secure a large amount of storage capacity to store certificate chains of undefined length. This can be a problem for storage devices that perform verification.

  One embodiment of the present invention is based on the realization that this problem can be alleviated by a system in which the host device sends the certificate chain in the same order that the certificate chain is verified by the storage device. Therefore, as shown in FIG. 24, the certificate chain 590 starts with a certificate 590 (1) located immediately below the host root certificate and ends with a certificate 590 (9) corresponding to the host certificate. Therefore, the device 10 first verifies the public key with the certificate 590 (1), then verifies the public key with the certificate 590 (2), and finally verifies the public key with the certificate 590 (9). To do. This completes the verification process for the entire certificate chain 590. When the host device transmits the certificate chain 590 to the memory device 10 in the same order as the verification, the memory device 10 can start the verification every time the certificate arrives, and the nine certificates included in the chain 590 are one. There is no need to wait until it reaches the street.

  Thus, in one embodiment, the host device sends the certificates of chain 590 one at a time to memory device 10. The memory device 10 stores one certificate at a time. Except for the last certificate in the chain, the verified certificate can be overwritten with the next certificate sent by the host. For this reason, the memory device 10 may have a capacity for storing only one certificate at any time.

  The memory device needs to know that the chain 590 has arrived. For this reason, preferably, the last certificate 590 (9) is provided with a sign or indication that this is the last certificate in the chain. The table of FIG. 25 illustrating this shows information in the control sector preceding the certificate buffer transmitted from the host to the memory device 10. As shown in FIG. 25, the control sector of the certificate 590 (9) has an argument name “final” flag. The memory device 10 checks whether the “final” flag is set and determines whether the received certificate is the final certificate in the chain, whereby the certificate 590 (9) is included in the chain. You can verify that it is the last certificate.

  In alternative embodiments, the certificates in chain 590 may be sent in groups of one, two, or three certificates, rather than sent one by one. Of course, the number of certificates used in a group may be different or the same. Chain 590 has five consecutive certificate strings 591, 593, 595, 597, and 599. Each column contains at least one certificate. A certain certificate column includes a certificate adjacent to the preceding matrix of the corresponding column in the chain (first certificate) and a certificate adjacent to the subsequent column of the corresponding column in the chain ( Terminal certificate) and all certificates between the first certificate and the terminal certificate. For example, in column 593, there are a total of three certificates 590 (2), certificate 590 (3), and certificate 590 (4). The verification of the five certificate columns by the memory device 10 is performed in the order of 591, 593, 595, and 597, and ends with 599. Thus, if five columns are sent and received in the same order as verified by the memory device 10, it is not necessary to store the verified columns in the memory device, and all columns except the last column arrive from the host. You can overwrite it with the next column. As in the previous embodiment, the last certificate in the chain preferably contains an indicator, for example a flag set to a specific value that tells it is the last certificate in the chain. In the case of this embodiment, the memory device only needs to secure a sufficient capacity to store the certificate of the column having the largest number of certificates among the five columns. Therefore, if the memory device 10 is informed in advance of the largest column among the columns that the host intends to send, the memory device 10 need only reserve sufficient capacity for the largest column.

  Preferably, the length of each certificate in the chain sent by the host is no more than four times the length of the public key certified by that certificate. Similarly, the length of the certificate transmitted from the memory device 10 to the host device to prove the public key of the memory device is preferably not more than four times the length of the public key certified by the certificate. .

  The flowchart in FIG. 26 shows the above-described embodiment of certificate chain verification. Here, for the sake of brevity, it is assumed that the number of certificates in each group is 1. As shown in FIG. 26, the host sequentially sends the certificates in the chain toward the card. Beginning with the first certificate in the chain (usually a successor to the root certificate as described above), the card sequentially receives the certificate chain from the host to be authenticated (block 602). . The card then validates each received certificate and aborts the process if validation fails with any of the certificates. The card notifies the host if verification fails with any of the certificates (blocks 604, 606). The card then detects whether the last certificate has been received and verified (diamond 608). If the final certificate has not yet been received and verified, the card returns to block 602 to continue receiving and verifying the certificate from the host. If the final certificate is received and verified, the card proceeds to the next stage following certificate verification (610). The contents of FIG. 26 and the subsequent figures refer to a memory card as an example, but it can be understood that these contents also apply to a memory device whose physical form is not a memory card.

  FIG. 27 shows the process performed by the host when the card authenticates the host. As shown in FIG. 27, the host sends the next certificate in the chain to the card (block 620) (usually starting with the certificate following the root certificate. Determine if the card has arrived (diamond 622) If the abort notice has arrived, the host stops (block 624) If no abort notice has been received, the host will use the last certificate sent to Check if the final certificate of the chain has been sent by checking if the flag is set.If the final certificate has been sent, the host goes to the next stage following certificate verification Proceed (block 628), as shown in Figures 22 and 23, the next step is a challenge response, which may be followed by the creation of a session key. If the certificate has not been sent, the host returns to block 620 to send the next certificate in the chain.

  28 and 29 show the actions taken by the card and the host when the card is authenticated. As shown in FIG. 28, after the card starts, it waits for a request from the host for certificate transmission in the chain (block 630, diamond 632). If no request is received from the host, the card returns to diamond 632. If the request arrives from the host, the card will send the next certificate in the chain, starting with the first certificate to send (usually starting with the certificate following the root certificate) (block 634). The card determines whether a failure notification has been received from the host (diamond 636). If a failure notification is received, the card stops (block 637). If no failure notification is received, the card determines whether the final certificate has been sent (diamond 638). If the final certificate has not been sent, the card returns to diamond 632 and waits for the next request from the host to send the next certificate in the chain. If the final certificate has been sent, the card proceeds to the next stage (block 639).

  FIG. 29 shows the actions taken by the host when the card is authenticated. The host sends a request for the next certificate in the chain to the card, which begins with a request for the first certificate to be sent (block 640). The host verifies each certificate it receives and, if verification fails, stops the process and notifies the card (block 642). If the verification is successful, the host checks whether the final certificate has been received and verified successfully (diamond 644). If the final certificate has not yet been received and verified, the host returns to block 640 and sends a request for the next certificate in the chain. If the final certificate has been received and verification is successful, the host proceeds to the next stage following certificate verification (block 646).

Certificates that have been revoked are expected to be used throughout their validity period. However, the certificate may become invalid prior to expiration of the validity period due to various circumstances. This includes changes in names, changes in the relationship between the subject and the CA (for example, employee retirement), infringement of the corresponding private key, or suspicion of infringement. In such a case, the CA needs to invalidate the certificate.

  There are different methods for certificate revocation in SSA, and each ACR can be configured with a separate certificate revocation system. First, the ACR can be configured in a way that does not support the revocation system. The certificate in this case is considered valid until the expiration date. A certificate revocation list (CRL) can also be used. As yet another alternative, the revocation system may be limited to a specific application as described later, that is, may be application-specific. In ACR, it is specified which of three revocation systems is adopted by specifying a revocation value. An ACR created without a revocation system can adopt the revocation system of the ACR owner. The revocation of the memory device certificate is performed by the host, not the SSA security system. The revocation management of the host root certificate is handled by the ACR owner, which is accomplished by updating the ACR credentials.

Certificate revocation list (CRL)
To use the revocation scheme in an SSA system, each CA periodically issues a signed data structure called a certificate revocation list (CRL). The CRL is a time-stamped list that identifies a revoked certificate, is signed by a CA (the CA that issued the certificate), is open to the public, and can be used freely. Within the CRL, revoked certificates are identified by their respective certificate serial numbers. The size of the CRL is arbitrary, and depends on the number of certificates that expire before expiration. A device that uses a certificate (for example, to verify the identity of a host) not only checks the certificate's signature (as well as its validity) but also validates it against a list of serial numbers received through the CRL. . If the certificate's identification information, such as a serial number, is found in the CRL issued by the CA that is the certificate issuer, this means that the certificate has expired and is no longer valid.

  In order for the CRL to serve the purpose of checking the validity of the certificate, it is necessary to verify that the CRL is authentic. The CRL is signed using the CA's private key that is the issuer, and the CARL's public key is used to decrypt the signed CRL to verify that it is authentic. If the decrypted CRL matches the digest of the unsigned CRL, it means that the CRL is not falsified and is authentic. In order to obtain a CRL digest, a hash calculation is frequently performed using a hash algorithm, and the digest is encrypted with a CA private key. To verify whether the CRL is valid, the CA's public key is used to decrypt the signed CRL (ie, the hashed / encrypted CRL) to obtain the decrypted / hashed CRL (ie, the CRL digest). . This is then compared with the hashed CRL. For this reason, the verify process often involves a hash calculation step of the CRL for comparison with the decrypted / hashed CRL.

  As a feature of the CRL scheme, the validity of the certificate (using the CRL) can be verified separately from the acquisition of the CRL. The CRL is also signed by an appropriate certificate issuer, and is verified as described above using the CA's public key, which is the CRL issuer, in the same manner as certificate verification. The memory device verifies that the signature is that of the CRL, and further verifies the match between the CRL issuer and the certificate issuer. Another feature of the CRL scheme is that the CRL can be distributed in exactly the same way as the certificate itself, specifically through untrusted servers and untrusted communications. X. The 509 standard details the CRL and its features.

SSA infrastructure for CRL SSA provides an infrastructure for host revocation using the CRL scheme. When authenticating with an RSA ACR that employs a CRL revocation system, the host adds one CRL (an empty CRL if no certificate has been revoked by the issuing CA) as an additional field to the Set Certificate command . This field contains the CRL signed by the certificate issuer. If this field is present, the memory device 10 first verifies the certificate with the Set Certificate command. The host is entirely responsible for obtaining and accessing the CRL repository. A period during which the CRL remains valid (CRL validity period, that is, CET) is also issued together with the CRL. If it is found during validation that the current time is outside this period, the CRL is deemed incomplete and cannot be used for certificate validation. As a result, certificate authentication fails.

  Traditional certificate verification methods can be retrieved from a certification authority (CA) regardless of whether the authenticating or verifying entity has or does not have a certificate revocation list, The serial number of the certificate presented for the purpose is to be checked against the list to determine if the presented certificate has been revoked. If the authenticating or verifying entity is a memory device, the certificate revocation list is not retrieved from the CA if the memory device itself is not used. If the certificate revocation list stored in the device in advance becomes out of date, certificates revoked after the date of installation will not appear in the list. As a result, the user can access the storage device using the revoked certificate. This is undesirable.

  In one embodiment, the problem described above by a system in which an entity to be authenticated presents a certificate revocation list together with a certificate to be authenticated to an authenticating entity, for example, the memory device 10. Can be solved. The authenticating entity verifies the authenticity of the received certificate and the authenticity of the certificate revocation list. The authenticating entity checks whether the certificate is registered in the revocation list by checking the revocation list for the presence of identification information of the certificate, for example, the presence of the certificate serial number.

  Based on the above, an asymmetric authentication method can be used for mutual authentication between the host device and the memory device 10. A host device that intends to receive authentication of the memory device 10 needs to provide both a certificate chain and a corresponding CRL. On the other hand, since the host device is connected to the CA in advance and obtains the CRL, when the host device authenticates the memory device 10, the memory device presents the CRL together with the certificate or certificate chain to the host device. There is no need.

  In recent years, various portable devices such as various built-in or independent music players, MP3 players, mobile phones, personal digital assistants (PDAs), notebook computers and the like can be used for content reproduction. Although it is possible to connect such a device to the World Wide Web to access a certificate revocation list from a certification authority, many users typically do not connect to the web every day, for example one week every week Do this every time you get new content or renew your contract. For such users, obtaining certificate revocation lists more frequently from certification authorities can be cumbersome. For such users, a certificate revocation list and, if necessary, a host certificate to be presented to the storage device when accessing protected content are preferably stored in an unprotected area of the storage device itself. In many storage devices (eg, flash memory), the unprotected area of the storage device is not managed by the storage device itself but by the host device. This eliminates the need for the user to connect to the web (through the host device) to obtain a newer certificate revocation list. The host device can retrieve such information from the unprotected area of the storage device, present the certificate and list to the storage device or memory device, and access the protected content of the storage device. Certificates for accessing protected content and their corresponding certificate revocation lists are usually valid for a period of time, so as long as they are valid, the user will have the latest certificate or certificate revocation list. There is no need to obtain. Thus, users can easily obtain certificates and certificate revocation lists that are valid over a reasonably long period of time and do not need to connect to a certification authority to obtain the latest information.

  The processes described above are shown in the flowcharts of FIGS. As shown in FIG. 30, the host 24 reads the CRL associated with the certificate presented to the memory device for authentication from the unprotected public area of the memory device 10 (block 652). Since the CRL is stored in an unprotected area of memory, no authentication is required prior to the CRL being obtained by the host. Since the CRL is stored in the public area of the memory device, reading of the CRL is managed by the host device 24. Then, the host sends the CRL together with the certificate to be verified to the memory device (block 654), and proceeds to the next step if no failure notification is received from the memory device 10 (block 656). Referring to FIG. 31, the memory device receives the CRL and certificate from the host (block 658) and checks for the presence of a certificate serial number in the CRL and other points (eg, whether the CRL has expired) (see FIG. 31). Block 660). If the certificate serial number is found in the CRL or otherwise fails, the memory device sends a failure notification to the host (block 662). Since the same CRL can be used for authentication of different hosts in this way, each host obtains the CRL stored in the public area of the memory device. As described above, a certificate to be verified using the CRL is also preferably stored in the unprotected area of the memory device 10 together with the CRL for the convenience of the user. However, the host that can use the certificate when authenticating to the memory device is only the host that has issued the certificate.

  When the next update time is entered in the CRL field as shown in FIG. 32, the SSA of the device 10 checks the current time against this time to see if the current time has passed this time. If it has passed, authentication fails. That is, the SSA preferably checks not only the CET against the current time (or the time when the memory device 10 received the CRL), but also the time of the next update.

  As described above, when the list of revoked certificate identification information included in the CRL becomes long, it takes time to process the list (for example, hash calculation) and search for the serial number of the certificate presented by the host. However, it takes time especially when processing and retrieval are performed sequentially. Processing and retrieval are performed simultaneously to accelerate this process. The process also takes time when the CRL is not processed and searched until after the entire CRL is received. The inventors have realized that if a part of the CRL is processed and searched at the time of reception (each time), the process will be almost complete when the final part of the CRL is received, and the process will progress.

  33 and 34 show the characteristics of the revocation system described above. The authenticating entity (eg, a memory device such as a memory card) receives the certificate and CRL from the entity that is to be authenticated (block 702). A portion of the unencrypted CRL is processed (eg, hashed), and at the same time, the identification information (eg, serial number) of the presented certificate is retrieved in such portion. Full decryption formed by assembling the processed (eg hashed) CRL part into a fully hashed CRL and assembling the decrypted CRL part from the part received from the authenticating entity This is compared with the digitized / hashed CRL. If the comparison reveals no match, the authentication fails. The authenticating entity also checks both the CET and the next update time against the current time (blocks 706, 708). If the identification information of the presented certificate is found to be described in the CRL, or if the current time is not within the CET range, or if the next update time of the CRL has passed, Failure occurs (block 710). In execution, if the hashed CRL part and the decrypted / hashed CRL part are stored for assembly, a large amount of storage capacity may not be required.

The entity (eg, host) seeking authentication sends the certificate and CRL to the authenticating entity (block 722) and proceeds to the next stage (block 724). This is illustrated in FIG.
A process similar to that described above can also be performed when an entity presents a certificate chain for authentication. In this case, the process described above is repeated for each certificate in the chain and its corresponding CRL. As each certificate and its CRL is received, it can be processed each time, eliminating the need to wait for the remainder of the certificate chain and its corresponding CRL.

Identity object (IDO)
The identity object is a protected object for the memory device 10 such as a flash memory card to store an RSA key pair or other cryptographic ID. Any type of cryptographic ID used for identity signing and verification and data encryption and decryption can be included in the identity object. A CA certificate (or certificate chain of multiple CAs) certifying that the public key of the key pair is authentic is also placed in the identity object. Identity objects can be used to provide evidence of the identity of external entities or internal card entities (ie, the device itself, the internal application, etc., called the identity object owner). Thus, rather than using an RSA key pair or other type of cryptographic ID to authenticate the host with a challenge-response mechanism, the card signs a data stream that is presented to the card as evidence of identification information. In other words, the identity object contains the owner's cryptographic ID. To access the cryptographic ID in the identity object, the host must first be authenticated. As will be described later, this authentication process is managed by the ACR. If the host is successfully authenticated, the owner of the identity object can verify his identity to the other party using the cryptographic ID. For example, data presented from the other party through the host can be signed using a cryptographic ID (for example, a private key of a public-private key pair). The signed data and certificate of the identity object are presented to the other party on behalf of the identity object owner. Since the public key of the public-private key in the certificate is authentic by the CA (ie, the credit agency), the other party can trust that the public key is authentic. Therefore, the other party can decrypt the signed data using the public key of the certificate and compare the decrypted data with the data transmitted by the other party. If the decrypted data matches the data sent by the other party, it can be seen that the owner of the identity object is a self-described entity that has access to the authentic secret key.

  A second use of the identity object is to protect the data specified by the owner of the IDO using a cryptographic ID, such as the RSA key itself. This data is encrypted using the IDO public key. The memory device 10 such as a memory card decrypts the data using the secret key.

  An IDO is an object that can be created with any type of ACR. The ACR may have only one IDO object in one embodiment. Both data signing and protection are services provided by the SSA system to entities that are ACR certified. The protection level of IDO is as high as the ACR login authentication method. Any authentication algorithm can be chosen for the ACR that will have an IDO. It is the creator (host) that evaluates and determines algorithms that can better protect IDO operations. An ACR with IDO provides a certificate chain in response to an IDO public key acquisition command.

Even when IDO is used for data protection, the decrypted data output from the card may require further protection. In such cases, the use of a secure channel established by any authentication algorithm is recommended to the host.
When creating the IDO, the key length and the PKCS # 1 version are selected. In one embodiment, the PKCS # 1 version 2.1 defined (exponential, coefficient) representation is used for the public and private keys.
The data included during IDO creation is, in one embodiment, an RSA key pair having a selected length and a certificate chain that inductively proves the authenticity of the public key.

The ACR that owns the IDO permits the signing of user data. This is accomplished using two SSA commands.
Set user data: provides a free-format data buffer to be signed.
Get SSA signature: the card provides an RSA signature (using an ACR private key). The signature format and size are set according to PKCS # 1 version 1.5 or V2.1 depending on the object type.

  35 to 37 show operations using IDO, where the memory device 10 is a flash memory card, and this card is the owner of the IDO. FIG. 35 shows the process performed by the card when signing data sent to the host. Referring to FIG. 35, after the host is authenticated under the control of the ACR located at the node of the tree structure described above (block 802), the card waits for a host request for a certificate (diamond 804). The card that received the request sends a certificate, returns to diamond 804, and waits for the next host request (block 806). If a certificate chain needs to be sent to prove the IDO public key owned by the card, the above operations are repeated until all certificates in the chain are sent to the host. After each certificate is sent to the host, the card waits for another command from the host (diamond 808). If no command is received from the host within a predetermined period, the card returns to diamond 804. The card that has received the data and command from the host checks the command to see if it is for signing the data (diamond 810). If the command is to sign data, the card signs the data using the IDO private key, sends the signed data to the host (block 812), and returns to diamond 804. If the command from the host is not for signing data from the host, the card decrypts the received data using the IDO's private key (block 814) and returns to diamond 804.

  FIG. 36 shows the process performed by the host when the card signs data to be sent to the host. Referring to FIG. 36, the host sends authentication information to the card (block 822). If authentication succeeds under the control of the ACR located at the node of the tree structure described above, the host sends a request for a certificate chain to the card and receives the chain (block 824). When the verification of the card's public key is complete, the host sends the data to be signed to the card and receives the data signed with the card's private key (block 826).

  FIG. 37 shows the process performed by the host when the host encrypts the data using the card's public key and sends the encrypted data to the card. Referring to FIG. 37, the host sends authentication information to the card (block 862). If the authentication is successful under the management of the ACR, the host sends a certificate chain request, which is required to verify the public key of the card in the IDO, to the card (block 864), and further requests for data. Send to. After verifying the public key of the card in the IDO, the host encrypts the data received from the card using the verified public key of the card and sends it to the card (blocks 866, 868).

The query host and application need to have some information about the other memory device or card when performing system operations. For example, the host and the application need to know which of the applications stored in the memory card can be executed. The required information for the host may not be known, which means that there are those who have the right to own the information and those who are not. In order to distinguish between an authorized user and a non-authorized user, it is necessary to prepare two types of queries that can be used on the host.

General Information Query This query releases system public information indefinitely. The confidential information stored in the memory device consists of two parts: a shared part and a non-shared part. Part of the confidential information contains proprietary information for each entity, and each entity is allowed to access only its own proprietary information, and cannot access the proprietary information of other entities. This type of confidential information is not shared and forms a non-shared part or portion of the confidential information.

  Even what is normally considered public information, such as the name of the application on the card and its lifecycle state, may be considered confidential in some cases. As another example, even a root ACR name that is public information may be classified in some cases when SSA is used. In such a case, an option must be prepared in the system so that all information is used only by an authenticated user according to the general information query and not used by an unauthenticated user. Such information occupies a shared part of confidential information. A root ACR list, i.e. a list of all root ACRs currently present on the device, can be an example of a shared portion of sensitive information.

  When accessing public information through a general information query, the host / user need not log in to the ACR. Therefore, anyone who is familiar with the SSA standard can execute and receive information. According to the SSA rule, this query command is processed without a session number. However, an entity that desires access to a shared portion of sensitive information must first be authenticated through one of the control structures (eg, ACR) that controls access to data in the memory device. Entities that have been successfully authenticated will be able to access the shared portion of sensitive information using general information queries. As described above, an SSA session number or id for access is assigned as a result of the authentication process.

Private Information Query Private information about individual ACRs and their system access and assets is private and requires clear authentication. To obtain permission with this type of information query, ACR login and authentication (if authentication is specified in the ACR) is required in advance. This query requires an SSA session number.
Before elaborating on the two types of queries, it is useful to explain the concept of index groups as a practical solution for executing queries.

For an application executed on the index group potential SSA host, it is required from the system driver and the operating system (OS) on the host to specify the number of sectors to be read. This means that the host application needs to know the number of read sectors for each SSA read operation.
Since the information supplied by the query operation is generally unknown information to the requester, it is difficult for the host application to issue a query and to estimate the amount of sectors required for the operation. .

  To solve this problem, the SSA query output buffer consists of only one sector (512 bytes) for each query request. Objects that form part of the output information are organized into so-called index groups. The byte size of an object varies depending on the type of object, from which the number of objects that fit in one sector becomes clear. This determines the index group of the object. When the size of the object is 20 bytes, up to 25 objects can be stored in the index group of this object. If there are a total of 56 such objects, they are organized into three index groups, the first index group starts with object “0” (first object), and the second index group starts with The object is “25”, and the head of the third final index group is the object 50.

System query (general information query)
This query provides publicly available information about the SSA system that the device supports, the current system configured in a tree, and the applications that run on the device. Similar to the ACR query (private query) described below, the system query is configured to provide various query options.
General: Supported SSA versions SSA Applications: A list of all SSA applications that currently exist on the device, including application execution status.

  The information described above is public information. Similar to the ACR query, the host does not know the number of read sectors for the query output buffer, so the device can send back one sector and the host can continue to query additional index groups. If the number of root ACR objects in index group “0” exceeds the number of output buffer sizes, the host can send another query request in the subsequent index group (“1”).

ACR query (private information query)
The SSA ACR query command is used to supply information related to ACR system resources such as a key ID, an application ID, a partition, and a child ACR to an ACR user. The query information is only for the logged-in ACR, not for other ACRs on the system tree. In other words, the access is limited to a portion of the confidential information that can be accessed under the permission of the corresponding ACR.
There are three ACR objects that a user can query.
Partition: ID and access rights (owner, read, write).
Key ID and application ID: ID and access right (owner, read, write).
Child ACR: ACR and AGP name of the ACR that is the direct child.
IDO and secure data object (described later): ID and access right (owner, read, write).

  The number of objects associated with the ACR can vary widely, and the information can exceed 512 bytes, ie, one sector. Unless the number of objects is known in advance, the user cannot know the number of sectors that need to be read from the SSA system in the device to get the entire list. Therefore, as in the case of the system query described above, each object list provided by the SSA system is divided into index groups. The index group is the number of objects that can fit in the sector, for example, the number of objects that can be transmitted in one sector from the SSA system in the apparatus to the host. As a result, the SSA system in the apparatus can transmit the requested index group in one sector. The host / user will receive the buffer of the queried object and the number of objects in the buffer. If the buffer is full, the user can query the next object index group.

  FIG. 38 is a flowchart showing an operation involving a general information query. Referring to FIG. 38, the SSA system that received the general information query from the business entity (902) determines whether the business entity has been authenticated (diamond 904). If so, the system provides the public information and the shared portion of the confidential information to the entity (block 906). If not, the system provides only public information to the entity (block 908).

  FIG. 39 is a flowchart showing an operation involving a private information query. Referring to FIG. 39, the SSA system that received the private information query from the business entity (922) determines whether the business entity has been authenticated (diamond 924). If so, the system provides sensitive information to the entity (block 926). If not authenticated, the system denies the entity access to the confidential information (block (928)).

Feature set extension (FSE)
In many cases, it is very advantageous to be able to perform data processing activities (eg, DRM license object inspection) inside the SSA on the card. The result is a safer and more efficient system and less dependency on the host than alternative solutions that perform all of the data processing tasks on the host.

  The SSA security system comprises a series of authentication algorithms and authorization policies that control the access, use and collection of objects stored, managed and protected by the memory card. The host that has gained access processes the data stored in the memory device, and access to the memory device is controlled by the SSA. However, since the data varies substantially depending on the application, the data format or data processing is not determined in SSA that does not handle the data stored in the device.

  One embodiment of the present invention is based on the recognition that an SSA system can be enhanced in such a way that some of the functions normally performed by a host are performed on a memory card. Thus, some of the host's software functions may be divided into two parts: the part that is subsequently performed by the host and the part that is performed by the card. This improves the safety and efficiency of data processing for many applications. For this purpose, the ability of SSA may be increased by adding a mechanism called FSE. The FSE host application executed by the card in this way may be referred to as an internal application or an apparatus internal application herein.

  The enhanced SSA system provides a mechanism for extending the basic SSA commands that provide card authentication and access control with the introduction of card applications. The card application is to execute services other than SSA (eg, DRM scheme, e-commerce transaction). The SSA Feature Set Extension (FSE) is a mechanism that enhances the standard SSA security system with proprietary data processing software / hardware modules. With the service of the SSA FSE system, in addition to the information obtained by the above-described query, the host device can query applications available on the card, select a specific application, and communicate with it. The general and private queries described above can also be used for this purpose.

Two methods are used to expand the card function group in SSA FSE.
Service provision: This is realized by an authorized entity communicating directly with an internal application using a unique command channel called a communication pipe.
Extension of SSA standard access control policy: This is realized by associating an internal card application with an internal protected data object (CEK, a secure data object described later, ie, SDO). If a predetermined standard SSA policy is satisfied when accessing such an object, the association application is launched to impose at least one condition in addition to the standard SSA policy. This condition preferably does not conflict with the standard SSA policy. Access is granted only if this additional condition is also met. Before further elaborating on the capabilities of the FSE, the structural aspects of the FSE and the communication pipe and SDO will be addressed here.

Modules Associated with SSA Modules FIG. 40A is a functional block diagram of system architecture 1000 in memory device 10 (such as a flash memory card) connected to host device 24, illustrating one embodiment of the present invention. The main components of the software module in the memory device of the card 20 are as follows.

SSA transport layer 1002
The SSA transport layer relies on the card protocol. This processes the host side SSA request (command) in the protocol layer of the card 10 and sends the processed one to the SSM API. Host-card synchronization and SSA command identification are all done in this module. The transport layer is also responsible for all SSA data transfer between the host 24 and the card 10.

Secure service module core (SSM core) 1004
This module is an important part of the SSA embodiment. The SSM core implements the SSA architecture. More specifically, the SSM core executes the SSA tree, the ACR system, and all the rules that make up the system described above. The SSM core module uses the cryptographic library 1012 to support SSA security and cryptographic functions such as encryption, decryption, and hash calculation.

SSM core API1006
This is the layer where the host and internal applications perform SSA operations in contact with the SSM core. As shown in FIG. 40A, both the host 24 and the internal device application 1010 use the same API.

Secure Application Management Module (SAMM) 1008
SAMM is not part of the SSA system, but is an important card module that controls internal device applications while communicating with the SSA system.
Any internal device application to be executed is managed by SAMM.
1. 1. Application life cycle monitoring and control 2. Application initialization Application / Host / SSA interface

Device internal application 1010
This is an application that is allowed to be executed on the card side. It is managed by SAMM and may access the SSA system. The communication pipe between the host side application and the internal application is provided from the SSM core. The DRM application and the disposable password (OTP) application described in detail below are examples of an internal execution application.

Device management system (DMS) 1011
This is a module that contains processes and protocols for updating the card's system and application firmware, and adding / removing services in a post-shipment (commonly called post-issue) mode.

  FIG. 40B is a functional block diagram of the internal software module of the SSM core 1004. As shown in FIG. 40B, the core 1004 includes an SSA command processing unit 1022. The processing unit 1022 analyzes the SSA command issued from the host or device internal application 1010 and then delivers it to the SSA management unit 1024. All SSA security data structures, such as AGP and ACR, and all SSA rules and policies are stored in the SSA database 1026. The SSA management unit 1024 performs control using ACR, AGP, and other control structures stored in the database 1026. Other objects such as IDO and secure data objects are also stored in the SSA database 1026. The SSA manager 1024 controls the ACR, AGP, and other control structures stored in the database 1026. Non-secure operations that do not involve SSA are handled by SSA non-secure operation module 1028. Secure operations under the SSA architecture are handled by the SSA secure operation module 1030. The module 1032 is an interface for connecting the module 1030 to the cryptographic library 1012. Reference numeral 1034 denotes a layer for connecting the modules 1026 and 1028 to the flash memory 20 of FIG.

Communication (or Pass-Through) Pipe The pass-through pipe object allows communication between an authorized host-side entity and an internal application under the control of the SSM core and SAMM. Data transfer between the host and the internal application is performed by a SEND command and a RECEIVE command (described later). The actual command depends on the application. The entity that creates the pipe (ACR) will need to provide the pipe name and the ID of the application that is linked by opening the channel. Like other protected objects, this ACR becomes the owner of the pipe and can delegate usage and ownership to other ACRs according to standard delegation rules and restrictions.

  An authenticated business entity is permitted to create a pipe object when the CREATE_PIPE authority is set in the ACAM. Communication with the internal application is permitted only when pipe write authority or pipe read authority is set in the PCR. Ownership and delegation of access rights are allowed only if the entity is the owner of the pipe or if the delegation of access rights is set in the PCR. As with all other authorities, the original owner who delegates ownership to another ACR is preferably withdrawn from all authorities for this device application.

  Preferably, only one communication pipe is created for a particular application. Attempts to create the second pipe and connect it to the connected application are preferably rejected by the SSM system 1000. Therefore, there is preferably a one-to-one relationship between any one of the device internal applications 1010 and the communication pipe. However, multiple ACRs may communicate with a single device internal application (via the delegation mechanism). One ACR may communicate with several device applications (due to the delegation or ownership of multiple pipes connected to different applications). In order to eliminate crosstalk between communication pipes, the ACRs controlling different pipes are preferably located in completely separate tree nodes.

Data transfer between the host and a specific application is performed using the following command.
Write pass-through: Transfers an atypical data buffer from the host to the device internal application.
Read pass-through: The atypical data buffer is transferred from the host to the device internal application, and the atypical data buffer is returned to the host when the internal processing is completed.

In the write pass-through command and the read pass-through command, the ID of the other device internal application 1008 with which the host is to communicate is provided as a parameter. Data buffer if the entity's authority is verified and the authority to use the pipe leading to the requested application is on the requesting entity (ie, the ACR that manages the session used by this entity) And execute the command.
This communication method allows the host application to pass vendor specific / unique commands to the internal device application through the SSA ACR session channel.

Secure data object (SDO)
SDO is a convenient object that can be used in conjunction with FSE.
The SDO serves as a general-purpose container that securely stores confidential information. Like CEK objects, SDOs are owned by ACR, and access and ownership can be delegated between ACRs. The SDO contains data that is protected and used according to predetermined regulations, and optionally has a link to the device internal application 1008. Sensitive data is preferably used and interpreted by the owner and user of the object without being used or interpreted by the SSA system. In other words, the SSA system does not recognize information on the data handled. For this reason, the owner and user of the data in the object do not have to worry too much about the loss of sensitive information due to the association with the SSA system when data is passed between the host and the data object. . The SDO object is created by the host system (or internal application), and a character string ID is assigned as in the case of creating CEK. When creating the host, in addition to the name, it provides the application ID of the application linked to the SDO and the data block that is stored by SSA, integrity verified and retrieved.

  SDO, like CEK, is preferably created only during an SSA session. The ACR used to release this session becomes the owner of the SDO. In addition to having the right to delete the SDO and the right to read and write confidential data, the ownership of the SDO and the right to access it can be controlled by another ACR ( A child ACR or an ACR within the same AGP).

  Write and read operations are limited to the SDO owner. A write operation overwrites existing SDO object data with the presented data buffer. A read operation retrieves a set of SDO data records.

A SDO access operation is permitted to ACRs other than the owner who has a formal access authority. The following operations are defined.
SDO Set, Application ID designation: Data is processed by an internal SSA application with this application ID. The application is activated by association with the SDO. As an option, the application may write the SDO object.
SDO Set, absence of application ID: This option is invalid and prompts an illegal command error. The Set command requires an internal application to be executed on the card.
SDO Get, Application ID designation: The request is processed by the device internal application with this application ID. The application is activated by association with the SDO. The output is sent back to the requesting party even if not specified. As an option, the application may read the SDO object.
-SDO Get, absence of application ID: This option is invalid and prompts an illegal command error. The Get command requires an internal application to be executed on the card.
SDO-related authority: Some ACRs have SDO ownership and others have only access authority (Set, Get, or both). An ACR is allowed to transfer his access rights to SDOs he does not own to another ACR. An ACR having ACAM authority is explicitly allowed to create an SDO and delegate access rights.

Internal ACR
An internal ACR is similar to an ACR with a PCR, but no external entity for the device 10 can log in to this ACR. Alternatively, the SSA management unit 1024 of FIG. 40B automatically logs into the internal ACR when an object under its management or an application associated with this object is called. Since the entity attempting access is an entity internal to the card or memory device, no authentication is required. The SSA management unit 1024 passes a session key to the internal ACR to enable internal communication.

  Two examples of disposable password generation and digital rights management will be drawn to illustrate the capabilities of FSE. Before explaining the example of single-use password generation, let's take up the theme of two-factor authentication.

OTP embodiment
Two-factor authentication (DFA)
DFA adds authentication to standard user credentials (specifically usernames and passwords) by adding an additional secret, or “second factor”, to enhance security with private logins to web service servers, etc. Protocol. This second secret is usually stored in a physical and secure token owned by the user. The user needs to provide proof of ownership as part of login credentials during the login process. A disposable password (OTP) is often used for proof of possession, which is a password that is generated and output with a secure token and that can be used with only one login. Since it is cryptographically impossible to calculate an OTP without a token, this is considered sufficient evidence of token ownership if the user can provide the correct OTP. Since the OTP works only with one login and the old password obtained from the previous login does not work, the user must possess the token at the time of login.

  The products described in the following sections each use a separate password series (in order to log in to different websites) in flash memory, utilizing the SSA security data structure and the FSE design that calculates the next password with a series of OTPs. Use multiple) “virtual” secure tokens. FIG. 41 shows a block diagram of this system.

  The system suite 1050 includes an authentication server 1052, an Internet server 1054, and a user 1056 having a token 1058. In the first step, a shared secret is negotiated between the authentication server and the user (also called seed provisioning). User 1056 requests the issuance of a secret or seed and stores it in secure token 1058. The next step is to bind the issued secret or seed to a specific web service server. If this is achieved, authentication can be started. The user instructs the token to generate an OTP. The OTP is transmitted to the Internet server 1054 together with the user name and password. The Internet server 1054 transfers the OTP to the authentication server 1052 and requests verification of the user identity. The authentication server also generates an OTP, which is generated from the shared secret with the token, and therefore matches the OTP generated from the token. If a match is found, the user identity is verified and the user login process is complete when the authentication server returns an acknowledgment to the Internet server 1054.

OTP generation by FSE has the following characteristics.
The OTP seed is stored securely (encrypted) on the card.
• The password generation algorithm is executed inside the card.
The device 10 can emulate multiple virtual tokens, each virtual token stores a different seed and can use different password generation algorithms.
The secure protocol for transferring the seed from the authentication server to the device 10 is provided by the device 10.

  FIG. 42 shows an STP OTP seed providing function and an OTP generation function, where solid arrows indicate ownership or access rights, and broken arrows indicate associations or links. As shown in FIG. 42, in the SSA FSE system 1100, the software program code FSE 1102 can be accessed through one or more communication pipes 1104 respectively managed by N applications ACR 1106. The embodiments described below illustrate only one FSE software application, and there is only one communication pipe for each FSE application. However, it can be understood that multiple FSE applications can be used. Although only one communication pipe is illustrated in FIG. 42, it can be understood that a plurality of communication pipes can be used. Any such modification is possible. Referring to FIGS. 40A, 40B, and 42, the FSE 1102 is an application used for providing OTP, and may form part of the device internal application 1010 of FIG. 40A. The control data structure (ACR 1101, 1103, 1106, 1110) is a part of the SSA security data structure and is stored in the SSA database 1026. Data structures such as IDO 1120 and SDO object 1122 and communication pipe 1104 are also stored in SSA database 1026.

  Referring to FIGS. 40A and 40B, security-related operations involving ACR and data structure (for example, operations such as data transfer, encryption, decryption, and hash calculation during a session) are performed by module 1030 using interface 1032 and cryptographic library 1012. Process with the support of. Since the SSM core API 1006 does not distinguish between an operation related to an ACR (external ACR) transferred to and from the host and an operation related to an internal ACR not transferred to the host, there is no distinction between an operation related to the host and an operation related to the device internal application 1010. Access by the host-side entity and access by the device internal application 1010 are controlled by the same control mechanism. Therefore, data processing can be flexibly distinguished between the host-side application and the apparatus internal application 1010. The internal application 1010 (for example, the FSE 1102 in FIG. 42) is associated with the internal ACR (for example, the ACR 1103 in FIG. 42) and started under the management thereof.

  In addition, access to important information, for example access to SDO content or information retrieved from the SDO content, is preferably managed by security data structures such as ACR and AGP and SSA rules and policies, External or internal applications can access their content or information as long as they comply with SSA rules and policies. For example, when two users launch individual device internal applications 1010 to process data, access by the two users is controlled using internal ACRs located in separate hierarchical trees. There is no crosstalk. Both users can access a common internal device application 1010 when processing data, and the owner of the SDO content or information does not have to worry about loss of content or information control. For example, access by the device internal application 1010 to the SDO storing data can be controlled by ACRs located in separate trees, so there is no crosstalk between applications. This control method is similar to the method in which the SSA controls access to the data described above. This provides content owners and users with the security of the data stored in the data object.

  Referring to FIG. 42, it is possible to store a part of software application code necessary for an OTP-related host application in the memory device 10 as an application of FSE 1102 (stored in advance before issuing a memory card or loaded after issuing a memory card). is there. When executing such code, the host must first authenticate through any one of the N authentication ACRs 1106 and access the pipe 1104, where N is a positive integer. The host also needs to provide an application ID for identifying the OTP related application to be started. If authentication is successful, such code can be accessed and executed through a pipe 1104 associated with the OTP-related application. As described above, there is preferably a one-to-one relationship between the pipe 1104 and applications such as OTP-related internal applications. As shown in FIG. 42, a plurality of ACRs 1106 may control a common pipe 1104. There are cases where a plurality of pipes are controlled by one ACR.

  FIG. 42 shows secure data objects SDO1, SDO2, and SDO3, collectively referred to as objects 1114 that each contain data, eg, a seed for OTP generation, which seeds are valuable and preferably encrypted. The link or association 1108 between the three data objects and the FSE 1102 is an attribute of these objects, and when accessing any one of the objects, the application of the FSE 1102 whose application ID matches the SDO attribute is launched. The application is executed by the device CPU 12 and does not need to receive further host commands (FIG. 1).

  Referring to FIG. 42, the security data structure (ACRs 1101, 1103, 1106, and 1110) for controlling the OTP process and its PCR have been created before the user starts the OTP process. The user needs to obtain an access right for starting the OTP device internal application 1102 through any one of the authentication servers ACR 1106. The user also needs to gain access to the OTP through any one of the N user ACRs 1110. The SDO 1114 can be created in the OTP seed provision process. IDO 1116 is preferably created and controlled by internal ACR 1103. The internal ACR 1103 also controls the created SDO 1114. When accessing the SDO 1114, the SSA management unit 1024 in FIG. 40B automatically logs into the ACR 1103. The FSE 1102 is associated with the internal ACR 1103. As indicated by a broken line 1108, in the OTP seed provision process, the SDO 1114 is associated with the FSE. After the association is established, when the host accesses the SDO, the FSE 1102 is activated by the association 1108 even if there is no further request from the host. When accessing the communication pipe 1104 through any one of the N ACRs 1106, the SSA management unit 1024 in FIG. 40B automatically logs in to the ACR 1103. In any case (access to the SDO 1114 and the pipe 1104), the SSA management unit passes the session number to the FSE 1102, and the channel reaching the internal ACR 1103 is identified by this session number.

  The OTP operation involves two stages: a seed provision stage shown in FIG. 43 and an OTP generation stage shown in FIG. Reference is also made to FIGS. 40 to 42 to assist in this description. FIG. 43 is a protocol diagram showing the seed provision process. As shown in FIG. 43, a host such as the host 24 and the card perform various operations. The SSM system of FIGS. 40A and 40B including the SSM core 1004 is one entity that performs various operations on the card side. The FSE 1102 shown in FIG. 42 is also a business entity that performs various operations on the card side.

  In the two-factor authentication, the user requests to issue a seed, and the issued seed is stored in a secure token. The secure token in this example is a memory device or a card. In order to access the SSM system, the user is authenticated with one of the authentication ACRs 1106 of FIG. 42 (arrow 1122). Assuming successful authentication (arrow 1124), the user requests a seed (arrow 1126). The host selects an application 1102 to sign the seed request and sends a request to the card to sign the seed request. If the user does not know the application ID to be activated, this information can be obtained from the device 10 by, for example, a private query to the device. Then, the user inputs the application ID of the application to be activated, and thereby the communication pipe corresponding to this application is also selected. By the pass-through command, the user command is transferred from the user to the application specified by the application ID through the corresponding communication pipe (arrow 1128). The activated application requests a signature with a public key of a predetermined IDO such as IDO 1112 in FIG.

  The SSM system signs the seed request using the IDO public key, and notifies the application of the completion of the signature (arrow 1132). Next, the activation application requests an IDO certificate chain (arrow 1134). In response, the SSM system provides an IDO certificate chain under the control of ACR 1103. The launch application provides the signed seed request and IDO certificate chain to the SSM system through the communication pipe, and the SSM system forwards the same to the host (arrow 1138). Transmission of the signed seed request and the IDO certificate chain in the communication pipe is performed by a callback function established between the SAMM 1008 and the SSM core 1004 in FIG. 40A. This callback function will be described in detail later.

  The signed seed request and IDO certificate chain received by the host are transmitted to the authentication server 1052 shown in FIG. Since the origin of the signed seed request is proved by the certificate chain provided by the card, the authentication server 1052 is prepared to provide the secret seed to the card. Therefore, the authentication server 1052 transmits the seed encrypted with the IDO public key together with the user ACR information to the host. This user information makes it clear which of the N user ACRs is the user ACR for the user to access the OTP to be generated. The host launches the OTP application at FSE 1102 by providing the application ID, which also selects the communication pipe corresponding to this application, and the host forwards user ACR information to the SSM system (arrow 1140). The encrypted seed and user ACR information are transferred to the selected application through the communication pipe (arrow 1142). The activated application sends a request to the SSM system to decrypt the seed using the IDO private key (arrow 1144). The SSM system decrypts the seed and sends a notification to the application indicating the completion of the decryption (arrow 1146). The launch application creates a secure data object and requests to store a seed in the secure data object. In order to generate a one-time password, the activation application also requests that the SDO be assigned an ID of an OTP application (which may be the same application as the requesting application). The SSM system creates one of the SDOs 1114, stores the seed in that SDO, assigns the ID of the OTP application to the SDO, and sends a notification to the application when complete (arrow 1150). The application requests the SSM system to transfer the access right to access the SDO 1114 from the internal ACR to the corresponding user ACR based on the user information provided from the host (arrow 1152). When the delegation is completed, the SSM system notifies the application (arrow 1154). The application transmits the name of the SDO (slot ID) to the SSM system via the communication pipe by the callback function (arrow 1156). The SSM system transfers the same to the host (arrow 1158). The host binds the name of the SDO to the user ACR so that the user can access the SDO.

  Next, the OTP generation process will be described with reference to the protocol diagram of FIG. The user logs into a user ACR with access rights to obtain a disposable password (arrow 1172). Assuming that authentication was successful, the SSM system notifies the host, and the host sends a “get SDO” command to the SSM (arrows 1174, 1176). As described above, an application that generates an OTP is associated with the SDO that stores the seed. Therefore, instead of selecting the application via the communication pipe as before, the OTP generation application is activated by associating the SDO accessed by the command indicated by the arrow 1176 with the OTP generation application (arrow 1178). The OTP generation application requests the SSM system to read the content (ie seed) from the SDO. Preferably, the SSM does not recognize the information contained in the contents of the SDO and only processes the SDO data according to the FSE instructions. If the seed is encrypted, it may be necessary to decrypt the seed before reading according to the FSE instructions. The SSM system reads the seed from the SDO and provides the seed to the OTP generation application (arrow 1182). The OTP generation application generates an OTP and provides it to the SSM system (arrow 1184). The OTP is transferred to the host by the SSM (arrow 1186), and the OTP is transferred from the host to the authentication server 1052, completing the two-factor authentication process.

Callback Function A general callback function is established between the SSM core 1004 and the SAMM 1008 in FIG. 40A. Various device internal applications and communication pipes can be registered in such functions. By using this callback function, the activated application in the apparatus can pass the processed data to the SSM system using the same communication pipe used for passing the host command to the application.

DRM System Embodiment FIG. 45 is a functional block diagram showing a DRM system. In this system, a communication pipe 1104 ′, a CEK 1114 ′ having a link 1108 ′ leading to the FSE application 1102 ′, and a control for controlling the execution function of the DRM function. Structures 1101 ′, 1103 ′, 1106 ′ are used. As can be seen, the architecture of FIG. 45 includes the license server ACR 1106 ′ and playback ACR 1110 ′ instead of the authentication server ACR and user ACR as security data structures, and also includes CEK 1114 ′ instead of SDO. Very similar to 42. In addition, IDO is not relevant and is omitted in FIG. CEK 1114 ′ can be created during the license provision process. FIG. 46, which is a protocol diagram, shows the process of providing a license and downloading content, where a key is provided in the license object. As with the OTP embodiment, a user wishing to obtain a license must first obtain access under one of N ACRs 1106 ′ and one of N ACRs 1110 ′, and so on. As a result, the content can be reproduced by a media player such as a media player software application.

  As shown in FIG. 46, the host is authenticated by the license server ACR 1106 '(arrow 1202). Assuming successful authentication (arrow 1204), the license server provides the license file to the host along with CEK (key ID and key value). The host also selects the application to be launched by providing the application ID to the SSM system on the card. The host also sends player information (eg, media player software application information) (arrow 1206). This player information makes it clear which of the N playback ACRs 1110 'is the playback ACR to which the player has access rights. The SSM system transfers the license file and CEK to the DRM application through the communication pipe corresponding to the selected application (arrow 1208). The activated application requests the SSM system to write the license file to the non-display partition (arrow 1210). If the license file is written as such, the SSM system notifies the application (arrow 1212). The DRM application requests creation of the CEK object 1114 'and stores the key value in it from the license file. The DRM application also requests that the ID of the DRM application that checks the license associated with the provided key be allocated to the CEK object (arrow 1214). The SSM system completes these tasks and notifies the application to that effect (arrow 1216). Based on the player information transmitted from the host, the application requests to transfer the content read access right to CEK 1114 ′ to the playback ACR accessible by the player (arrow 1218). The SSM system performs delegation and notifies the application to that effect (arrow 1220). A message is sent from the application to the SSM system via the communication pipe indicating that the license has been stored, and the SSM system forwards it to the license server (arrows 1222 and 1224). A callback function is used for this operation via the communication pipe. Upon receiving this notification, the license server provides the card with the content file encrypted with the provided CEK key value. The encrypted content is stored in the public area of the card by the host. Since the security function is not involved in storing encrypted content files, the SSM system is not involved in storage.

  FIG. 47 shows the playback operation. The user is authenticated through the host by the corresponding reproduction ACR (that is, the reproduction ACR to which the read right is delegated by the arrows 1152 and 1154 described above) (arrow 1242). Assuming that the authentication is successful (arrow 1244), the user sends a request to read the content associated with the key ID (arrow 1246). Upon receiving the request, the SSM system notices that the ID of the DRM application being accessed is associated with the CEK object and launches the identified DRM application (arrow 1248). The DRM application requests the SSM system to read the data (ie, license) associated with the key ID (arrow 1250). An SSM that does not recognize the information of the data requested to be read only processes the request from the FSE and executes the data read process. The SSM system reads the data (ie, license) from the hidden partition and provides the data to the DRM application (arrow 1252). The DRM application interprets the data and checks the license information in the data to confirm whether the license is valid. If the license is still valid, the DRM application informs the SSM system that content decryption is allowed (arrow 1254). The SSM system decrypts the requested content using the key value of the CEK object and provides it to the host for playback of the decrypted content (arrow 1256). If the license is no longer valid, the content access request is denied.

  When the key is not provided by the license file from the license server, the license provision and the content download are somewhat different from those shown in FIG. The protocol diagram of FIG. 48 shows such another scheme. The same steps in FIGS. 46 and 48 are identified by the same numerals. For this reason, the host and the SSM system first work on authentication (arrows 1202, 1204). The license server provides the license file and key ID to the host but not the key value, and the host forwards them to the SSM system along with the application ID of the DRM application to be launched. The host also sends player information (arrow 1206 '). The SSM system transfers the license file and the key ID to the selected DRM application through the communication pipe corresponding to the selected application (arrow 1208). The DRM application requests writing of a license file to the non-display partition (arrow 1210). If the license file is written as such, the SSM system notifies the DRM application (arrow 1212). The DRM application requests the SSM system to generate a key value, create a CEK object, store the key value therein, and assign the DRM application ID to the CEK object (arrow 1214). '). The SSM system in response to the request sends a notification to the DRM application (arrow 1216). The DRM application requests the SSM system to delegate read access to the CEK object to the playback ACR based on player information from the host (arrow 1218). When this is complete, the SSM system notifies the DRM application to that effect (arrow 1220). The DRM application notifies the SSM system that the license has been stored, and this notification is sent via the communication pipe by the callback function (arrow 1222). The notification is forwarded to the license server by the SSM system (arrow 1224). The license server transmits the content file associated with the key ID to the SSM system (arrow 1226). The SSM system encrypts the content file with the key value identified by the key ID, but the application is not involved in this at all. The encrypted content stored on the card can be played back using the protocol of FIG.

  In the OTP embodiment and the DRM embodiment described above, the host device can select various OTP applications and DRM applications in the FSEs 1102 and 1102 '. The user can select and activate a desired application inside the device. However, since the overall relationship between the SSM module and the FSE is always the same, the user and the data provider can use a standard set of protocols when passing between the SSM module and starting the FSE. Users and providers need not be involved in the details of various device internal applications, including those developed independently.

  In addition, the provisioning protocol may be somewhat different, as is the case with FIGS. In the case of FIG. 46, the license object contains the key value, but in the case of FIG. 48, the license object does not contain the key value. Due to these differences, a slightly different protocol as described above is required. However, the reproduction in FIG. 47 is the same regardless of how the license is provided. Therefore, this difference is usually a problem only for content providers and distributors, and not for consumers who are usually involved only in the reproduction stage. This architecture remains easy to handle for consumers while providing great flexibility to content providers and distributors when customizing protocols. Of course, information retrieved from data provided by three or more provided protocol groups can also be accessed using the second protocol.

  Another advantage provided by the above-described embodiment is that the external entity such as the user and the device internal application both use data controlled by the security data structure, but what the user can access is stored by the device internal application. Only the results retrieved from the data. In the case of the OTP embodiment, only the OTP can be obtained by the user through the host device, and the seed value cannot be obtained. In the case of the DRM embodiment, only the reproduced content can be obtained by the user through the host device, and neither the license file nor the encryption key can be accessed. For this reason, the convenience of the consumer can be achieved without sacrificing security.

  In one embodiment of the DRM, neither the device internal application nor the host accesses the encryption key, only the security data structure accesses it. In another embodiment, entities other than the security data structure can also access the encryption key. In some cases, the key is generated by a device internal application and controlled by a security data structure.

Access to device internal applications and information (eg, OTP and playback content) is controlled by the same security data structure. This reduces the complexity and cost of the control system.
Features and functions described above by providing the ability to delegate access rights from an internal ACR that controls access to device internal applications to an ACR that controls host access to information obtained by launching device internal applications Is feasible.

The access control protocol of the application-specific revocation system security data structure can be modified when the device internal application is started. For example, the certificate revocation protocol may be either a standard protocol using CRL or a proprietary protocol. Therefore, by starting the FSE, the standard CRL revocation protocol can be replaced with the FSE original protocol.

  In addition to supporting the CRL revocation scheme, SSA can disable hosts from device internal applications through private communication channels between device internal applications and CA or other revocation agencies. The internal application specific revocation system is limited to the host-application relationship.

  If an application revocation scheme is configured, the SSA system will reject the CRL (if provided), otherwise certificates and proprietary application data (data provided through the application-specific communication pipe). Is used to determine whether the certificate has been revoked.

  As described above, in the ACR, by specifying the revocation value, one of three revocation systems (no revocation system, standard CRL system, and revocation system for each application) is specified. When an application-specific revocation system is selected, the internal application ID responsible for the revocation system is also designated by ACR, and the value of the CET / APP_ID field matches the internal application ID responsible for the revocation system. When authenticating a device, the SSA system complies with the internal application specific scheme.

  Instead of replacing one set of protocols with another, additional access conditions can be provided for access control already enforced by the SSA when launching device internal applications. For example, the access right for the key value of CEK can be examined more closely by FSE. The SSA system that has determined that the access right for the key value is in the ACR grants access after consulting with the FSE. This provides great flexibility to the content owner when controlling access to the content.

  Although the present invention has been described with reference to various embodiments so far, changes and modifications can be made without departing from the scope of the present invention, and the scope of the present invention is solely defined by the appended claims and their claims. It will be understood that it is determined by the equivalent.

Claims (13)

A method for supplying information on a security function of a memory device,
An answer to the query is generated by a memory device, the memory device having a public part and a private part, and encrypted data stored in either the public part or the private part of the memory device Storing a control structure that controls access to encrypted data by controlling access to a key that needs to be decrypted , referencing the key by a key ID, the control structure being accessed by an authenticated entity A publicly accessible component and a plurality of sensitive components that are restricted to only, the plurality of sensitive components include a key ID and access rights to the key, which are certified business to the control structure The body has access to a key for decrypting the encrypted data according to the access right ,
(A) If the query is for a publicly accessible component, obtain a publicly accessible component and include it in the answer;
(B) If the query is for any one of the plurality of confidential components, the entity that sent the query is authenticated to the memory device and can access this confidential component. presented, along with obtaining such sensitive components, including mETHODS to supply an answer to the so obtained confidential components included in the reply, and (c) query. The method of claim 1, wherein
A method that includes publicly accessible components in the answer, regardless of whether the entity that sent the query is authenticated. The method of claim 1, wherein
Each of the plurality of confidential components comprises a shared portion and a non-shared portion, wherein the shared portion is provided to all authenticated entities, and the non-shared portion is provided to only one authenticated entity. The method of claim 3, wherein
The memory device stores therein a software application having a life cycle state, and the shared portion of a plurality of confidential components includes an ID of the software application and a respective life cycle state. The method of claim 3, wherein
The method wherein the control structure comprises at least one sub-control structure and the query includes a list of the at least one sub-control structure. The method of claim 5, wherein
The method wherein the at least one secondary control structure comprises at least one root access control record and the shared portion includes a list of the at least one root access control record. The method of claim 1, wherein
The publicly accessible component includes a list of software applications on the memory device and their execution states. The method of claim 1, wherein
A publicly accessible component and a plurality of sensitive components are provided in at least one information object group, wherein one group of groups is transmitted in response to each query in a series of queries. A memory device,
Encryption by controlling access to keys that have a public part and a private part and that need to decrypt the encrypted data stored in either the public part or the private part of the memory device A non-volatile storage medium for storing a control structure for controlling access to the received data, wherein the key is referred to by a key ID, and the control structure is a public access limited to access by an authenticated entity look including possible components and a plurality of sensitive elements, said plurality of sensitive elements includes access to the key ID and key, it authenticated entity is encrypted in accordance with the access right to the control structure A non-volatile storage medium having access to a key for decrypting the stored data ;
A controller that communicates with the non-volatile storage medium and that is operated to generate an answer to a query, the generation comprising:
(A) If the query is for a publicly accessible component, obtain a publicly accessible component and include it in the answer;
(B) If the query is for any one of the plurality of confidential components, the entity that sent the query is authenticated to the memory device and can access this confidential component. Presenting such a confidential component and including in the answer the confidential component so obtained, and (c) providing an answer to the query;
A device comprising: The memory device according to claim 9, wherein
A memory device that includes publicly accessible components in the answer, regardless of whether the entity that sent the query has been authenticated. The memory device according to claim 9, wherein
Each of the plurality of confidential components includes a shared part and a non-shared part, the shared part being supplied to all authenticated entities, and the non-shared part being supplied to only one authenticated entity . The memory device according to claim 9, wherein
The publicly accessible component is a memory device that includes a list of software applications on the memory device and their respective execution states. The memory device according to claim 9, wherein
A publicly accessible component and a plurality of sensitive components are provided in at least one information object group, and one group of groups is transmitted in response to each query in a series of queries.

Images