JP2011523481A - Access authentication for software development kit for peripheral devices - Google Patents

Abstract

  A code set for the peripheral device is installed on the host device. The code set is used to control access from the host device to the peripheral device. The code set also includes one or more code subsets used by software entities on the host device to access the peripheral device. Software entities on the host device must be successfully authenticated by a code set installed on the host device. If the software entity is successfully authenticated, it will have access to one or more code subsets dedicated to the software entity. A software entity can access peripheral devices using one or more code subsets.

Description

  The present invention relates to a technology of a secure peripheral device.

As technology advances, preventing unauthorized access to secure peripheral devices has become a major problem. The memory device is an example of a secure peripheral device. Memory devices that contain secure content must be protected from unauthorized access.
Semiconductor memories are widespread and are used in various electronic devices. For example, non-volatile semiconductor memories are used in cellular phones, digital cameras, mobile media players, personal digital assistants (PDAs), mobile computing devices, non-mobile computing devices, and the like.
The protection of the content stored in the nonvolatile semiconductor memory device is an important function, focusing on the protection of copyrighted materials. For example, a user can purchase content protected by copyright, such as music, through an electronic device. The owner of the content can usually limit the use of the content to the purchaser and request that the content be played by a legitimate application on the electronic device, such as the application used to purchase the content.

  Various protection methods such as encryption can be used to securely store information in order to prevent unauthorized use of secure content. An application on the device attempting to access the encrypted content cannot read the content unless the content is decrypted using the encryption key. An application permitted to access the encrypted content has an encryption key for decrypting the content. An unauthorized application can access the encrypted content, but cannot read the content without an appropriate encryption key. However, if the encryption key is obtained, the protected content can be read even by an unauthorized application. Therefore, there is a need for a simple, safe and improved method for preventing unauthorized applications on electronic devices from accessing protected content on secure peripheral devices.

  The techniques disclosed herein relate to authenticating applications, application launchers, and other software entities to prevent unauthorized access to secure peripheral devices. The software entity is authenticated by a code set on the host device and an authentication method. This code set is associated with the peripheral device and is installed on the host device to control access to the peripheral device. The code set also includes code used by software entities on the host device to perform tasks related to the peripheral device. If the software entity is successfully authenticated, code is available for the software entity to perform tasks related to the peripheral device.

  The process of an embodiment includes installing a code set associated with the secure peripheral device on the host device. This code set includes codes for operating peripheral devices on the host device such as device driver codes. The code set is used to authenticate the first software entity on the host device. The process further includes presenting a portion of the code set to the first software entity if the first software entity is successfully authenticated. This presenting also includes presenting code for the first software entity to communicate with the peripheral device.

  One embodiment of the authentication process includes receiving a first task request for a secure peripheral device from a user of a first software entity on a host device. Credentials are sent from the first software entity to the code set installed on the host device for the peripheral device. The process further includes accessing a portion of the code set if the credentials are valid. This accessing also includes accessing code associated with the first software entity so that the first software entity can perform the first task. The code set includes code for one or more software entities on the host device to perform tasks related to the peripheral device. The first software entity transmits information related to the first task using a portion of the code set.

  One embodiment of the authentication process includes sending one or more authentication options to the first software entity on the host device when the first software entity requests access to the peripheral device. One or more authentication options are transmitted from the code set installed on the host device for the peripheral device to the first software entity. The code set includes code relating to one or more software entities on the host device. The code set receives credentials from the first software entity. The credentials are associated with any one of one or more authentication options. The process further includes providing access to the first code associated with the first software entity if the credentials are valid. The first code is part of the code set and accesses the peripheral device.

  One embodiment includes a secure peripheral device and a host device in communication with the peripheral device. The host device includes one or more processors that control access to peripheral devices. The one or more processors also manage code sets by controlling access to code sets installed on the host device for peripheral devices. This code set allows communication between the peripheral device and one or more software entities on the host device. The one or more processors verify the credentials from the first software entity on the host device and, if the credentials are valid, present a subset of the code set code to the first software entity. This subset of code is associated with the first software entity.

  One embodiment includes a cryptographic engine and one or more processors on a host device in communication with the cryptographic engine. The cryptographic engine verifies credentials from the first software entity on the host device. One or more processors intercept access to the secure peripheral device. The one or more processors also receive credentials from the first software entity and, if the credentials are valid, present code related to the first software entity. When one or more processors execute this code, the first software entity can access the peripheral device.

  One embodiment includes one or more processor readable media having processor readable code that causes one or more processors to perform the method. The method includes sending one or more authentication options to the first software entity on the host device when the first software entity requests access to the peripheral device. This sending also includes sending one or more authentication options from a code set installed on the host device for the peripheral device to the first software entity, the code set being one of the ones on the host device. The code concerning the above software entity is included. The code set receives credentials from the first software. The credentials are associated with any one of one or more authentication options. The method further includes providing access to the first code associated with the first software entity if the credentials are valid. The first code is part of the code set and allows access to the peripheral device.

It is a block diagram of the host device before the SDK of the secure peripheral device is installed. It is a flowchart explaining 1 process which comprises SDK of a secure peripheral device. An example of a secure peripheral device SDK is shown. 6 is a flowchart illustrating one process for loading a secure peripheral device into a host device. FIG. 3 is a block diagram illustrating an embodiment of a host device after a secure peripheral device SDK is installed. FIG. 2 is a block diagram illustrating one embodiment of components of a host device before secure memory device code is installed. FIG. 3 is a block diagram illustrating one embodiment of components of a host device and a secure memory device. 2 is a block diagram of an embodiment of a memory device SDK. FIG. 1 is a block diagram illustrating one embodiment of a secure memory device. 2 is a block diagram illustrating an embodiment of a firmware module for a secure memory device. FIG. 2 shows an example of a partition in a secure memory device. It is an example of application API contained in SDK for memory devices. 6 is a flowchart illustrating one process for accessing a secure peripheral device. It is a flowchart explaining an example of the process of registering a software entity on a host device. It is a flowchart of the authentication system which can be performed by SDK. It is a flowchart of the authentication system which can be performed by SDK. It is a flowchart of the authentication system which can be performed by SDK. An example of the registration process is shown. Fig. 4 illustrates an example of a software entity successfully registered on a host device. 5 is a flowchart illustrating an embodiment of a process for storing protected content in a memory device. 6 is a flowchart illustrating an embodiment of a process for accessing protected content in a memory device. 6 is a flowchart illustrating one embodiment of a process for deregistering a software entity.

  The disclosed technique of the present application provides secure peripheral device access by performing security functions on the host device. The peripheral device can be any device operated via a host device such as a memory device, a printer, a keyboard or the like. In order to operate a peripheral device on the host device, software for the peripheral device must be installed in the host device. This software is installed in the host device as a code set of a software development kit (SDK) such as a dynamic link library (DLL) or a static library (LIB). The host device operates the peripheral device through one or more software entities or applications. In many cases, access to a peripheral device requires a different API for each application on the host device according to the type of application, the function of the application, the authority of the application, and the like. If the user sends a task request to the host device through the application and the task request includes access to the peripheral device, the SDK of the peripheral device authenticates the application and the application is authorized to access the peripheral device Confirm. If this authentication is successful, the SDK presents only a dedicated API to the application. APIs that are not permitted to be accessed by the application are not presented. The application can send and execute a task request using the presented API. This improves the security of the peripheral device and prevents unauthorized API access by other applications.

  FIG. 1 shows an example of the host device 255 before the peripheral device SDK code set is installed. The host device 255 includes an application 105, a memory 260, and a host CPU 165. The host device 255 can be an electronic device such as a mobile phone, a PC, a digital camera, a mobile media player, a personal digital assistant (PDA), a mobile computing device, and a non-mobile computing device. The application 105 is any software entity used on a host device such as a calendar, a document viewer, or a media player. The application 105 may be a software entity used for starting an application. The memory 260 is some memory required for the host device 255. The host CPU 165 is any processor used for operating the host device 255.

  When SDK software is created by a software developer to operate a peripheral device through a host device, such as the host device 255 depicted in FIG. 1, the SDK software is a software entity or application on the host device that accesses the peripheral device. Can be configured for each. Software entities on the host device can often be owned or created by customers with different needs and preferences. The SDK can be configured based on each software entity / application or based on customer needs and preferences such as authentication preferences and customer application functionality. FIG. 2 is a flowchart of one process for constructing an SDK code set based on various applications and / or customer needs and preferences. In step 190, the SDK software developer develops SDK software for each application and / or customer based on the application and / or customer requirements. For example, an SDK code set that accesses a peripheral device through a customer application usually requires an API that acts as an intermediary between the application and the peripheral device. The SDK software for accessing the application API can be configured in detail according to customer preferences. For example, the SDK is configured to require application authentication prior to access by a peripheral device. The SDK is configured so that an API to be accessed is determined for each application. In step 195, the SDK software for operating the peripheral device is configured based on the required API of the specific SDK software for each application / customer executed in step 190. For example, SDK software modifications for security functions required for each application / customer are included. Once the SDK software is configured to operate the peripheral device, the SDK will install all of the software configured for each application and / or customer in step 190 (security software required for authentication, etc.) and the software customized in step 195. Other software for operating peripheral devices on the containing host device will also work properly.

  FIG. 3 shows an example of a peripheral device SDK 330 code set constructed according to the process of FIG. The peripheral device SDK 330 code includes a subset of the security layer 125, application APIs 1 to 3, device driver 140, and the like. This SDK code set can be a dynamic link library (DLL) or a static library (LIB). Security layer 125 includes software for authenticating different applications attempting to access the peripheral device. The security layer 125 can be part of the SDK software configured in step 195 of FIG. For example, the security layer 125 can be configured such that an additional authentication function is required for the application 1 API 262. The security layer 125 will be described in detail later. Each application must use the APIs for applications 1 to 3 to communicate with the peripheral device. As described in step 190 of FIG. 2, these APIs can be configured based on customer preferences for the application. For example, the application 1 API 262 can be an API customized for the application 105 in the host device 255 of FIG. The device driver 140 is software for operating peripheral devices normally on the host device.

  FIG. 4 is a flowchart illustrating one process for installing the SDK found in FIG. 3 in the host device. In step 170 of FIG. 4, the secure peripheral device is connected to the host device. When the secure peripheral device is connected to the host device, the SDK for operating the secure peripheral device is read into the host device and installed (step 175). This SDK can be stored in the secure peripheral device memory. The SDK includes software for operating the secure peripheral device to program the host CPU on the host device and prevent unauthorized access. Once the SDK code set is successfully read and installed in the host device, the host device can be operated with the secure peripheral device (step 180).

  It should be noted that in some embodiments, step 175 is performed only when a particular secure peripheral device is first connected to the host device. If the SDK is installed on the host device when the secure peripheral device is first connected, there is no need to install the SDK every time the secure peripheral device is reconnected to the host device. In another embodiment, the SDK is loaded and installed each time a secure peripheral device is connected to the host device.

  In one embodiment, an SDK for operating a secure peripheral device is read into the host device and preinstalled before the operating system is installed on the host device. In this case, the SDK can be activated or selected through the operating system. Thus, step 175 need not be performed as part of the process of FIG. In another embodiment, the SDK for operating the secure peripheral device is read and preinstalled after the operating system of the host device is installed. Again, step 175 need not be performed as part of the process of FIG.

FIG. 5 illustrates one embodiment of the host device 255 and secure peripheral device 145 after the SDK 330 code set of FIG. 3 is installed. In addition to the initial components (application 105, memory 260, and host CPU 165) seen in FIG. 1, the host device 255 includes components of the SDK 330 (security layer 125, APIs for applications 1 to 3 and device driver 140) seen in FIG. including. When the user of the host device 255 requests a task including the secure peripheral device 145 through the application 105, the security layer 125 causes the host CPU 165 to authenticate the application 105. If the application 105 is successfully authenticated by the security layer 125, the security layer presents an API subgroup dedicated to the application 105. For example, if the application 105 is the application 1, the application 1 API 262 is presented. Application 105 can then use the subset of the SDK code set to send a task request to secure peripheral device 145 via device driver 140. Application 105 can also send task requests for users using these APIs.
In order to more specifically describe the process of safely accessing a peripheral device through the peripheral device SDK, a secure memory device is used as an example of the peripheral device. However, it should be noted that the peripheral device may be any peripheral device and is not limited to the example memory device described below.

FIG. 6 shows an embodiment of components of the host device 100 before the SDK for secure memory device is installed. A user of the host device 100 usually accesses content stored in the host device 100 through a software entity such as the application 105. Examples of applications on the host device 100 include media players, calendars, address books, and the like stored in the host device 100. An application can also be executable code on the host device that is used to launch an application (media player, calendar, address book, etc.) stored at a location different from the executable code on the host device 100. For example, an application can be used to launch a media player application stored in a host device in a different part of the memory of the host device 100 or in a peripheral device connected to the host device 100. Content accessed or stored using the application 105 can include, for example, application, media, scheduling information, contact information, and the like.
The application 105 uses the host storage management unit 110 on the operating system for the host device 100, and accesses and stores content in peripheral devices such as the host device 100 and a removable memory device. The host storage management unit 110 is a software component on the operating system that controls the access function and the storage function, and includes access and storage within the host device 100 and between peripheral devices. Details will be described below.

  FIG. 6 also shows the host storage management unit 110 and the host file system 130. The host file system 130 is one component managed by the host storage management unit 110. The host storage management unit 110 accesses the host file system 130 using the host CPU 165. The host file system 130 is stored in the memory of the host device 100, and is used for searching for content stored in the host device 100 and peripheral devices and storing the content. When a user requests content from the host device 100, the host storage management unit 110 searches for the content using the host file system 130. When the user requests storage of content, the host storage management unit 110 uses the host file system 130 to store the content in an appropriate location.

  The content stored in the host device 100 can be encrypted for protection. The host device can include a host cryptographic engine 185, which includes a random number generator, a symmetric cryptographic method (AES, DES, 3DES, etc.), a cryptographic hash function (SHA-1, etc.), and a non-target cryptographic method (PKI, key pair). Generation) or any other cryptographic method.

  FIG. 7 shows an example of the host device 100 that works with the secure memory device 145 after the code set of the peripheral device SDK 330 is normally read and installed in the host device 100. The secure peripheral device is a removable storage device in one embodiment. The content is stored in a secure partition of the secure memory device or in a public partition of the secure memory device. The secure memory device can be any memory device such as a mass storage device or a non-volatile flash memory device. Content stored in the secure partition of the secure memory device is protected from unauthorized access. If the content is protected, the content stored in the public partition of the secure memory device is also protected from unauthorized access. If the content is encrypted, the content is protected in a secure memory device. If the content is not encrypted and stored in the public partition, it is not protected in the secure memory device. The host device can access the content on the secure memory device and store the content when the host device has an appropriate authority related to the content such as an authority to encrypt and decrypt the content.

  In FIG. 7, the host device 100 is physically connected to the secure memory device 145 by the physical interface 142. The application 105, the host CPU 165, the host device cryptographic engine 185, the host storage management unit 110, and the host file system 130 are software components on the host device 100 shown in FIG. The peripheral device SDK 330 is a code set that is installed in the host device 100 and used to operate the secure peripheral device 145 by the host device 100. The peripheral device SDK 330 handles secure peripheral device API 120, peripheral device SDK security layer 125, host file system 130, registration table 285, and SDK encryption when processing access and storage of the contents of the secure memory device 145. A library 168 and a secure file system 135 are used. As described in step 175 of FIG. 4, the secure peripheral device API 120, the peripheral device SDK security layer 125, the registration table 285, the SDK cryptographic library 168, the secure file system 135, and the device driver 140 Software components that are read from the SDK code set for the secure memory device 145 and installed on the host device. The open channel 150 and the secure channel 155 are data buses used for transferring content between the host device 100 and the secure memory device 145.

  The secure memory device 145 uses the software installed in the host device 100 for the secure memory device 145 to control content access and storage. The software includes a library preinstalled in the host apparatus in addition to the library described in step 175 of FIG. The SDK library loaded and installed on the host device can be a dynamic link library (DLL) or a static library (LIB) and can be integrated into the operating system on the host device. The SDK code set provides a hook to the host storage management unit 110 for secure operation of the secure memory device 145. For example, a subset of the peripheral device SDK code can be inserted into a call chain for calling the host file system 130, and the host CPU 165 can control the content access method and storage method. The peripheral device SDK security layer 125, secure peripheral device API 120, secure file system 135, registration table 285, SDK cryptographic library 168, and device driver 140 are hosted through the secure peripheral device SDK code set of FIG. A subset of the code provided to the device. These subsets are provided using device drivers 140 installed on the host device 100.

As shown in FIG. 7, the user can access content stored in the secure memory device 145 through a software entity such as an application 105 on the host device. For protected content stored in the secure peripheral device 145, the application 105 needs to be authenticated prior to accessing the content, as will be described in detail later.
The application 105 accesses the content in the secure memory device 145 using the host storage management unit 110 on the host device operating system, and stores the content. The host storage management unit 110 controls the access function and the storage function. This includes access and storage within the host device and access and storage within the secure memory device 145.

  As shown in FIG. 6, the host storage management unit 110 normally controls the access function and storage function of the host device and peripheral devices using the host file system 130 on the host device operating system. The host file system 130 can be a normal file system such as FAT12, FAT16, FAT32, or NTFS. However, in the case of the secure memory device 145, the peripheral device SDK 330 of the secure memory device 145 uses the peripheral device SDK security layer 125 to control the access function and the storage function on the host device. A secure file system 135 for 145 is used. Access to the secure file system 135 is controlled by authenticating the application 105. If the authentication is successful, access is permitted only to the API dedicated to the application 105. These APIs are the correct interface for the secure file system 135. The secure file system 135 is a file system for content installed in the host device 100 for the secure memory device 145 and stored in the secure memory device 145. The secure file system 135 can be a normal file system such as FAT12, FAT16, FAT32, NTFS or the like.

  The software for the peripheral device SDK security layer 125 is read and installed as part of the SDK that is read and installed in step 175 of FIG. The peripheral device SDK security layer 125 causes the host CPU 165 to authenticate the application 105. If the application 105 is successfully authenticated, the application 105 is registered in the registration table 285. The peripheral device SDK security layer 125 also provides an application handler to the application 105. This application handler indicates which API the application 105 can access. Details of the authentication and registration process executed by the peripheral device SDK security layer 125 will be described later.

  When the user requests access to the content through the application 105, the peripheral device SDK security layer 125 provides an API necessary for accessing the content of the secure peripheral device 145, for example, the secure peripheral device API 120 after successful authentication. To do. The application 105 can receive the content stored in the secure peripheral device 145 by using this API and accessing the permission of the content. When the content is protected, a header is stored together with the content. This header contains information related to the content, such as domain information related to the content encryption key (CEK) for encrypting and decrypting the content and content metadata indicating the type of the stored content.

  A secure peripheral device API (application program interface) 120 in the peripheral device SDK 330 links the secure peripheral device 145 to the application 105 when accessing or storing content. This secure peripheral device API 120 is installed as part of the SDK, and is called by the application 105 if the application 105 is successfully authenticated. The secure peripheral device API 120 serves as a bridge between the peripheral device SDK security layer 125 and the secure file system 135.

  Once the content location is determined using the secure file system 135, the device driver 140 on the host device can be used to access or store the content at the appropriate location on the secure memory device 145. This is done through a physical interface 142 that physically connects the host device 100 to the secure memory device 145. Content can be accessed and stored using secure channel 155 or open channel 150. Whether to use the secure channel 155 or the open channel 150 when transferring content between the secure peripheral device 145 and the host device is determined by the peripheral device SDK 330.

When the user requests storage of content that is not to be protected through the application 105, the peripheral device SDK 330 stores the content using the host file system 130. When the user requests storage of content to be protected in the secure peripheral device 145, the peripheral device SDK 330 stores the content using the secure file system 135.
A secure peripheral device API (application program interface) 120 in the peripheral device SDK 330 links the secure peripheral device 145 to the application 105 when the protected content is accessed or stored. This secure peripheral device API 120 is installed as part of the SDK, and is called by the application 105 if the application 105 is successfully authenticated. The secure peripheral device API 120 serves as a bridge between the peripheral device SDK security layer 125 and the secure file system 135.

Once the content location is located and filed using either the host file system 130 or the secure file system 135, the device driver 140 on the host device is used to place the content on the secure memory device 145 at the appropriate location. Content can be accessed and stored. This is done through a physical interface 142 that physically connects the host device 100 to the secure memory device 145. The secure channel 155 or the open channel 150 can be used to access and store content. The peripheral device SDK security layer 125 determines whether to use the secure channel 155 or the open channel 150 when transferring content between the secure peripheral device 145 and the host device.
A session key is an encryption key used to encrypt content before the content is transferred between the host device and the secure memory device. If there is no need to transfer the content using the secure channel, it can be indicated that there is no session key assigned to the content, or that no encryption is required with the session key assigned to the content.

When a session key is assigned to the content and content transfer using the secure channel 155 is instructed, the content is encrypted using the session key prior to transfer using the secure channel 155. When the encrypted content is transferred, the content is decrypted using the same session key. In the host device 100, the SDK encryption library 168 is used to encrypt or decrypt content. The SDK encryption library 168 includes a random number generator and a symmetric encryption method (AES, DES, 3DES, etc.), a cryptographic hash function (SHA-1, etc.), a non-target encryption method (PKI, key pair generation, etc.) or any other The encryption function corresponding to this encryption method is also included. The secure peripheral device 145 has a unique encryption engine for performing encryption in the secure memory device 145 before and after content transfer, as will be described in detail in FIG. When the session key instructs content transfer using the open channel 150, the content is transferred without being encrypted.
A host device in which the peripheral device SDK is not installed can access the content stored in the public partition. Even if the host device can access the content, if the content is protected, the encrypted content cannot be read normally. The host device cannot access the content stored in the secure partition.

  FIG. 8 shows an example of the software of the peripheral device SDK 330 installed in the host device 100 when the peripheral device is a secure memory device, as shown in FIG. As described above, the peripheral device is not limited to the example of the memory device. The peripheral device SDK 330 is a library installed in the host device 100. The peripheral device API 260, the peripheral device SDK security layer 125, the device driver 140, the secure file system 135, the SDK cryptographic library 168, the registration table 285, etc. Software for operating the secure memory device 145 on the device 100 is included. However, the peripheral device SDK 330 is not limited to this software.

  The application API 260 is an API used by an application such as the application 105 in FIG. In addition to the API for authentication, these APIs allow the application to the secure file system 135 to access content on the secure memory device 145 after the application such as the secure peripheral device API 120 of FIG. Includes APIs to be linked. The application API 260 can include an API dedicated to a specific application. For example, an API used by one application may not be used by another application. Applications successfully authenticated by the peripheral device SDK security layer 125 can access the protected content in the secure memory device 145 through the secure peripheral device API 120. The secure peripheral device API 120 will be described in detail later with reference to FIG.

The peripheral device SDK security layer 125 shown in FIG. 7 is installed in the host device, provides a hook to the host storage management unit 110, and controls the host CPU 165 to access and store content in the secure memory device 145. The peripheral device SDK security layer 125 code “takes over” the host file operation on the host device 100, so that the application can be authenticated prior to content access on the secure peripheral device 145.
The software of the device driver 140 shown in FIG. 7 can be read and installed in the host device after the secure memory device 145 is connected to the host device 100 (step 175 in FIG. 4), or an operating system is installed in the host device. It can be preinstalled on the operating system of the host device 100 before or after.
The secure file system 135 is a file system including filing data for accessing and storing content in the secure memory device 145 shown in FIG. The SDK encryption library 168 is a library including an encryption method for encrypting and decrypting content for the secure channel 155. Encryption methods such as AES, DES, 3DES, SHA-1, PKI, and key pair generation are known methods. The SDK encryption library 168 encrypts and decrypts content based on content permissions such as a session key.

The registration table 285 is a table used by the peripheral device SDK security layer 125 to manage and maintain application authentication status and related information. This table contains information such as the authentication algorithm, application ID, registration time, expiration time, and registration status. Details of the registration table 285 will be described later.
Continuing with the example secure memory device, one embodiment of the secure peripheral device 145 shown in FIG. 7 is shown in FIG. The secure peripheral device or memory device 145 includes a firmware module 210, a CPU 220, a peripheral device cryptographic engine 160, and a system partition 400. The system partition 400 includes a public partition 240 and a secure partition 250. The firmware module 210 uses the CPU 220 to access and store content in the public partition 240 or the secure partition 250 of the system partition 400. The memory device encryption engine 160 is used to encrypt and decrypt protected content accessed or stored in the secure memory device 145.

The firmware module 210 includes hardware and software that controls access and storage of content in the secure partition 250 and the public partition 240 of the secure memory device 145. The firmware module programs the CPU 260 to perform the access function and the storage function. For example, it is determined in which part of the memory the content is accessed or stored, or whether the content is protected. Details of the firmware module 210 will be described in the description of FIG.
The public partition 240 is a memory partition of the secure memory device 145 that is visible to the user and can be detected by the host device 100. The secure memory device 145 has one or more public partitions. The public partition 240 may include public content that is open to users and the host device 100. The public partition 240 can also include protected content that is encrypted using a content encryption key (CEK). CEK can be generated using domain information stored in a content header including information related to content. Public content can also be stored without encryption.

  The secure partition 250 is a hidden memory partition of the secure memory device 145 that is not visible to the user and is not detected by the host device. The secure memory device 145 can have one or more secure partitions. The secure partition 250 can include protected content that is not open to the user or the host device 100. The content to be protected can be encrypted using CEK. The content stored in the secure partition 250 can be accessed by an authenticated application that has appropriate permissions to access the content. Information relating to CEK and permissions related to content are stored in a content header in which content-related information is entered. In one embodiment, the public partition 240 and the secure partition 250 of the system partition 400 are stored in a flash memory device that includes one controller and one or more flash memory arrays.

Since the secure partition 250 is a hidden partition that is not detected by the user or the host device, the secure partition 250 can include software for operating the secure memory device 145 in the host device 100 together with an authority object, application credentials, and the like. .
The peripheral device encryption engine 160 is used in the secure memory device 145 to encrypt and decrypt content using CEK and a session key. The memory device cryptographic engine 160 has a random number generator and a symmetric cryptographic method (AES, DES, 3DES, etc.), a cryptographic hash function (SHA-1, etc.), a non-target cryptographic method (PKI, key pair generation, etc.) or any other method. And a cryptographic processing unit capable of supporting various cryptographic methods.

  FIG. 10 shows details of one embodiment of the firmware module 210. The firmware module 210 includes a peripheral device interface module 144, a flash memory management unit 310, a protected content access management unit 320, a cryptographic engine library 235, and a DRM (digital copyright management) module 315. The peripheral device interface module 144 includes hardware and software for linking the secure memory device 145 to the host device 100 via the physical interface 142 of the host device. The hardware components of the peripheral device interface module 144 may include components for any interface, such as a universal serial bus (USB), secure digital (SD) interface, compact flash (CF) interface, and the like. The flash memory management unit 310 includes software for the CPU 220 to access and store unprotected content in the public partition 240, and to access and store content based on permissions using the DRM module 315. . The protection target content access management unit 320 uses software for the CPU 220 to access and store the protection target content using the permission, and to access and store the content based on the permission using the DRM module 315. Including. The protected content access management unit 320 can also use a cryptographic engine library 235 that contains information necessary for encrypting content using a session key or CEK. Both the flash memory management unit 310 and the protected content access management unit 320 access and store content through the device driver 140 on the host device.

  When protection is not necessary, the flash memory management unit 310 uses the CPU 220 to control access and storage of unprotected content in the secure memory device 145. When the request to save the unprotected content is received from the host device 100 through the device driver 140, the flash memory management unit 310 saves the content in a corresponding position according to the host file system 130. When a request for accessing unprotected content is received from the host device file system 130 through the device driver 140, the flash memory management unit 310 accesses the content from the corresponding position using the host file system 130. The flash memory management unit 310 also provides access to the protected content access management unit 320 when the application 105 attempts to access protected content in the secure memory device 145.

  When protection is required, the protection target content access management unit 320 uses the CPU 220 to control access and storage of the protection target content in the secure memory device 145. The protected content access management unit 320 stores the permission related to the protected content in the DRM module 315 or acquires the permission related to the protected content from the DRM module 315. The protected content access manager 320 uses the secure file system 135 shown in FIG. 7 when accessing or storing the protected content. For example, when a request to save protected content is received from the host device through the device driver 140 and the content is transmitted through the secure channel 155, the peripheral device SDK security layer 125 uses the SDK encryption library 168 to protect the protected content. Is encrypted. This encryption uses a session key assigned to the content. Then, the encrypted content is transmitted to the secure memory device 145 through the secure channel 155, and the secure memory device 145 decrypts the content using the session key and an appropriate encryption method in the encryption engine library 235. The decrypted content is then encrypted by the peripheral device cryptographic engine 160 using the content CEK. Content encrypted using CEK is stored in an appropriate location according to the secure file system 135.

Even when the content to be protected is transmitted through the open channel, the same content transfer method is implemented, but there is no encryption of the session key for the secure channel 155. When a request to access protected content is received from the host device 100 through the device driver 140, the protected content access management unit 320 accesses the content from a corresponding position using the secure file system 135, and the host through the open channel 150. The contents are provided to the host storage management unit 110 on the apparatus 100. When an appropriate permission is confirmed by the protection target content access management unit 320, the protection target content access management unit 320 accesses and stores content through the flash memory management unit 310.
The protected content access management unit 320 uses the DRM module 315 to provide access to the content based on the permission related to the content such as copyright permission. The DRM module 315 can support any DRM technology such as OMA, DRM, MS DRM.

  The encryption engine library 235 contains an encryption method for encrypting content in the secure memory device 145 using CEK or a session key. When content is encrypted or decrypted in the secure memory device 145, the protected content access management unit 320 accesses an appropriate encryption method in the encryption engine library 235. The encryption method can be any known method, such as AES, DES, 3DES, SHA-1, PKI, and key pair generation.

  FIG. 11 shows an example of the system partition 400 of the secure memory device 145. This system partition 400 includes all memory partitions in the secure memory device 145. That is, the system partition 400 is created by the public partition 240 and the secure partition 250 shown in FIG. The secure memory device 145 has several public partitions or secure partitions. As already mentioned, the public partition can be detected and opened to be accessible to users and host devices. Unprotected content stored in public partitions can be accessed without authentication. However, protected content stored in the public partition can only be accessed after successful authentication. The secure partition is a hidden partition that cannot be detected by the user or the host device. Applications that attempt to open content in a secure partition must be authenticated in advance.

  When the protection target content is stored in the secure memory device 145, the protection target content access management unit 320 organizes the content according to the permission of the content. Next, the flash memory management unit 310 stores the content. Public partitions and secure partitions have domains or logical groups that contain protected content with the same CEK. Each domain or logical group has one CEK for decrypting the content and encrypting the content. An application having permission to open content in one domain or group can open other content stored in the same domain or group.

  The public partition P0 410 in FIG. 11 has two logical groups, domain 1 and domain 2. One CEK is used for encryption and decryption of all contents stored in the domain 1. A separate CEK is used to encrypt and decrypt all content stored in domain 2. Software entities attempting to access these groups require authentication prior to reading the content. Since public partition P0 is open and not hidden, protected content in the group can be seen and accessed, but cannot be read unless properly decrypted using the appropriate CEK . That is, the content in the group may be destroyed by an unauthorized user, but the content cannot be read.

Since the file A440 of the public partition P0 410 is not included in the group, it does not have an allocated CEK. Thus, file A 440 can be accessed and read by any user.
Secure partition P1 420 includes file E and file F. File E and file F can be files that need to be protected in a secure partition. For example, the file E and the file F are used for storing secure information such as a content license and internal management data by the SDK. However, the contents of the secure partition P1 420 are not limited to such files. The secure partition P1 420 can store any secure file.
There are both file G and file H in domain 3 490 of secure partition P2 430. Domain 3 is assigned a CEK for encrypting and decrypting the content. For example, when an application attempts to access file G in domain 3, the application must be authenticated in advance. Upon authentication, the application can access the file G using the CEK of the domain 3 and the file H of the domain 3.
The secure partition P3 450 is an empty partition and can be used to store protected content.

  FIG. 12 shows an example of the application API 260 of the peripheral device SDK 330. The application API 260 includes a standard and secure storage API 340, an authentication API 350, a configuration API 360, a DRM API 370, and a custom API 380 necessary for the user to operate the secure memory device 145 on the host device 100. Each of the various APIs can be dedicated to software entities such as applications and application launchers. In one embodiment, the API of each application is stored as a logical group such as a domain. For example, the API 262 for APP1 is stored in a group different from other application APIs. In one embodiment, each group contains one type of API for one application. For example, the storage API for APP1 can be regarded as one group.

  An API 262 for APP1 indicates an API subgroup dedicated to application 1 in the API group. The SDK is configured to be able to access the APP1 API 262 when the application 1 is successfully authenticated (see step 190 in FIG. 2). The API 262 for APP1 is, in one embodiment, a subset that is called by one or more applications of the SDK code set. In another embodiment, only application 1 calls the API 262 for APP1. The API 262 for APP1 includes a secure storage API, a configuration API, a DRM API, and a custom API. However, the API 262 for APP1 is not limited to these APIs.

  The standard and secure storage API 340 is used when the application or the application launcher 105 acquires and stores content in the secure memory device 145, establishes a secure session, or involves accessing or storing content in the secure memory device 145. In executing other operations, a necessary API is included. For example, the standard / secure storage API 340 can be an API for the application 105 to send the path position of the content requested to be accessed to the host file system 130 or the secure file system 135. The application 105 can call the standard and secure API 340 group standard APIs when accessing public content. After the application 1 is authenticated by the peripheral device SDK security layer 125, it is possible to call a secure API of the API1 API 262 group such as the secure peripheral device API 120 shown in FIG.

  The authentication API 350 is an API for authenticating the application 105, and is open to all applications without requiring an authentication process for accessing the authentication API 350. The authentication API 350 is called by the application 105. When the authentication API 350 is called by the application 105, the application 105 can send the credentials to the peripheral device SDK security layer 125 using the authentication API 350. The peripheral device SDK security layer 125 verifies whether the credentials transmitted by the application 105 using the authentication API 350 are valid. This credential can be any type of credential used to authenticate software entities such as responses to challenge / response authentication algorithms, PKI certificates, PINs, keys, passwords, and the like. In the case of a challenge / response authentication algorithm, the challenge can be sent to the application 105 using the authentication API 350. A response to the challenge to the peripheral device SDK security layer 125 can then be sent using the same authentication API 350 from the application 105.

The configuration API 360 is an API for the application 105 to configure the secure memory device 145 or to obtain configuration information of the secure memory device 145. This can be done only if the application 105 has the appropriate authority to do that. For example, when obtaining information about used and free memory space in the secure memory device 145 or creating a new secure partition after the application 105 is successfully authenticated, the application 105 API 360 can be called.
In order to access the permission and digital copyright related to the content, the application 105 can call the DRM API 370 and access the content if the authority is valid. Authority verification is performed by the DRM module 315 in the firmware module 210 of the secure memory device 145. As seen in the API 262 subgroup for APP1, the DRM API 370 may be a DRM API dedicated to a particular application 105 in one embodiment.
The custom API 380 may be an additional API that is required when the user operates the secure memory device 145 on the host device 100. As seen in the API1 API 262 subgroup, the custom API 380 can be a custom API dedicated to a particular application 105.

  The flowchart in FIG. 13 illustrates an example of operating the host device together with the secure peripheral device after the peripheral device SDK has been successfully installed in the host device (step 180 in FIG. 4). More specifically, FIG. 13 is a process that illustrates how a task request related to a secure peripheral device that a user sends through an application on a host device is executed. For example, a task request can be a request to access or store content on a secure peripheral device, access and store files (music, applications, etc.), or information related to secure peripheral devices (free memory capacity, etc.) , Change the configuration content of the secure memory device, or access DRM information (digital copyright object, etc.). A user can request a task through an application on the host device. In the following examples, a secure memory device is used as the secure peripheral device. However, it should be noted that the use and configuration of the secure peripheral device is not limited to this example.

In step 505 of FIG. 13, the user sends a task request to the application 105 on the host device 100. This task request is received from the application 105 by the peripheral device SDK security layer 125 (step 505).
In step 515, the peripheral device SDK security layer 125 executes the registration process of the application 105. The registration process is a process of authenticating the application 105 and registering the application 105 in the internal registration table 285 (shown in FIG. 7) when the authentication is successful. If the registration is successful, the peripheral device SDK sends an indicator to the application 105. This indicator conveys that a dedicated API of the registered application 105 is presented. The peripheral device SDK security layer 125 also sends an application handler to the application 105. This application handler serves as an additional security measure. Each time the application 105 communicates with the peripheral device 145 using the presented API, it must send an application handler to the peripheral device through the API. Details of the registration process will be described with reference to FIG.

If the registration process of step 515 is successful, the application 105 sends a task request to the peripheral device SDK 330 through one or more APIs presented during the registration process (step 520). The task request must be transmitted together with the application handler given to the application 105 during the registration process.
In step 525, the task request is executed using the application 105 dedicated API subgroup to which the peripheral device SDK 330 is presented. FIG. 18 illustrates an example of the steps executed when the protection target content is stored in the secure memory device. FIG. 19 illustrates an example of the steps executed when accessing the content to be protected stored in the secure memory device.
When the task request is completed in step 525, the peripheral device SDK security layer 125 deregisters the application 105 from the internal registration table 285 in step 530. How this step is performed will be described in detail in connection with FIG.

The flowchart in FIG. 14 shows an example of a registration process (step 515 in FIG. 13) executed by the task related to the protection target content. After the user sends a task request to the application 105, in step 700, the application 105 selects an authentication method from the list of authentication method options. This list of authentication method options is provided from the peripheral device SDK security layer 125 to the application 105 through the authentication API. An API that provides such a list can be defined, for example, as follows.
void ListAuthenMethod (char * AppID,
char * AuthList)

  The ListAuthenMethod API provides the application ID (char * AppID) of the application 105 to the peripheral device SDK security layer 125. The application ID is a unique identifier assigned to the application 105. The peripheral device SDK security layer 125 returns a list (char * AuthList) of authentication methods supported by the peripheral device SDK security layer 125. The application 105 selects an authentication method to be used in the list provided from the peripheral device SDK security layer 125. The application is programmed with the authentication method to be used.

The application 105 obtains the credential corresponding to the authentication method selected in Step 705 and executes the selected authentication method. For example, if the selected authentication method is based on PKI, the application 105 acquires a PKI certificate as its own credential and executes the authentication method. If the selected authentication method is a challenge / response authentication method, the application 105 executes the authentication method by calling the challenge / response API stored in the memory device SDK 330 together with the authentication API 350. The application 105 receives the challenge from the peripheral device SDK security layer 125 using the challenge / response API. This challenge is a random number generated by the host device cryptographic engine 185 or the memory device cryptographic engine 160. The application 105 calculates the response to the challenge as its own credentials. Details of the various authentication schemes are described in connection with FIGS.
In step 710, the application 105 calls the registration API and transmits registration information to the peripheral device SDK security layer 125. An API for registering an application can be defined as follows, for example.
uchar RegisterApplication (char * AppID,
char * AuthMethod, uchar * credential,
uchar credentialLen)

This RegisterApplication API includes the application 105's own application ID (char * AppID), the selected authentication method (char * AuthMethod), the credential (uchar * credential), and the length of the credential acquired in step 705. (Uchar credentialLen) may be transmitted to the SDK security layer 125 for peripheral devices. To accommodate differences in credential length depending on the authentication scheme, a credential length must be provided.
The peripheral device SDK security layer 125 checks in step 715 whether the credentials are valid. If the credentials are not valid, the peripheral device SDK security layer 125 returns an error to the application 105 (step 720).

  If the credentials are valid, the peripheral SDK security layer 125 generates an application handler for the application 105 at step 722. This application handler is a unique random number generated using a predetermined encryption algorithm such as HASH. The application handler is generated by inputting a specific value to a predetermined encryption algorithm. These specific values are values related to the registration information of the application 105 and / or the application 105 such as the application ID, the time when the application 105 is registered, the period during which the application 105 can be registered, and the registration status. The peripheral device SDK API has input parameters for application handlers. In one embodiment, a default application handler is created and used for the API that is open to all applications. However, as already mentioned, the authentication API 350 is open to all applications, and no application handler is required to access these APIs for authentication.

  When the application handler is generated, the peripheral device SDK security layer 125 registers the application 105 in the internal registration table 285 (step 725). The internal registration table 285 is managed by the peripheral device SDK security layer 125. The internal registration table 285 includes information on authenticated applications and application launchers. The peripheral device SDK security layer 125 includes an application handler, a timeout period indicating a period during which the authenticated application 105 continues to be registered in the internal registration table 285 (registration time + a period during which an application can be registered), an API accessible from the application 105, and the like. The information of the application and the application launcher successfully authenticated is recorded in the internal registration table 285. The internal registration table 285 is useful for tracking authenticated applications and application launchers. For this reason, the authenticated application and the application launcher do not have to repeat authentication every time a task request is received while being registered in the authentication table.

The peripheral device SDK security layer 125 checks in step 730 whether the application 105 has been successfully registered in the internal registration table 285. If the application 105 is not successfully registered in the internal registration table 285, the peripheral device SDK security layer 125 returns an error to the application 105 (step 735).
When the application 105 is successfully registered in the internal registration table 285, the peripheral device SDK security layer 125 returns the application handler generated in step 722 to the application 105 through the authentication API (step 738). The peripheral device SDK security layer 125 also returns to the application 105 a sign indicating that the registration of status_OK or the like was successful (step 740). The status_OK indicator notifies the application 105 that the API sub-group dedicated to the application 105 necessary for executing the task is presented and can be used.

  The peripheral device SDK security layer 125 presents to the application 105 the API subgroup of the peripheral device SDK 330, such as the subgroup 262 seen in FIG. This API subgroup allows the application 105 to communicate with the secure peripheral device 145. However, access to this code portion is allowed only if the application 105 provides a valid application handler after authentication. This API subgroup allows application 105 to establish an appropriate link between application 105 and secure peripheral device 145 and execute a task request.

  15A to 15C show examples of processes for executing various authentication methods supported by the peripheral device SDK security layer 125 (steps 710 and 715 in FIG. 14). The flowchart of FIG. 15A is an example of a process for executing password-based authentication. The application 105 is programmed with a password used for authentication. In step 535 of FIG. 15A, the application 105 accesses the programmed password. The application 105 transmits the password to the peripheral device SDK security layer 125 through the authentication API. The peripheral device SDK security layer 125 checks whether the password is valid (step 715 in FIG. 14) and continues the process in FIG.

  The flowchart in FIG. 15B is an example of executing challenge / response authentication. In step 545, the application 105 receives a challenge from the peripheral device SDK security layer 125 through the authentication API. For example, this API can take the form of void GetChallenge (char * AppID, uchar * charge, uchar * chargeLen). With the GetChallenge API, the application 105 provides its own application ID (char * AppID) to the peripheral device SDK security layer 125. The peripheral device SDK security layer 125 returns the challenge (uchar * charge) and the challenge length (uchar * chargeLen) to the application 105.

  In step 550, the response is calculated by inputting the challenge received by the application 105 into the cryptographic function. The application 105 is programmed with a cryptographic function to be used. In step 555, the response calculated by the application 105 is transmitted to the peripheral device SDK security layer 125. The peripheral device SDK security layer 125 also calculates a response using the same challenge for the same cryptographic function (step 560), and compares the calculated response with the response received from the application 105 (step 565). In this comparison step, the peripheral device SDK security layer 125 checks whether or not the credential (response from the application 105) is valid (step 715 in FIG. 14). Based on this credential, the registration process of FIG. 14 can continue.

  The flowchart in FIG. 15C is an example of executing PKI authentication of the application 105. In step 570, the application 105 transmits a certificate to the peripheral device SDK security layer 125. This proof is stored with the application 105 as part of the credential. Application 105 is programmed to provide this proof through an authentication API.

  In step 575, the peripheral device SDK security layer 125 verifies the certificate. If the certificate is valid in step 580, the peripheral device SDK security layer 125 extracts the public key from the certificate sent by the application (step 570) and uses it to encrypt the randomly generated number. This random number can be generated and encrypted using the SDK cryptographic library 168. Next, the encrypted random number is transmitted from the peripheral device SDK security layer 125 to the application 105 (step 585).

  In step 590, the application 105 decrypts the encrypted random number received from the peripheral device SDK security layer 125. For this decryption, a secret key corresponding to the public key used in the peripheral device SDK security layer 125 is used. Since legitimate applications have the appropriate secret key, they can decrypt the encrypted random number. In step 595, the random number decrypted by the application 105 is transmitted to the peripheral device SDK security layer 125 for verification (step 715 in FIG. 14). The process of FIG. 14 can now be continued.

  The block diagram of FIG. 16 is an example of the registration process of FIG. First, the application 1 107 executes the authentication method selected in the list provided from the peripheral device SDK security layer 125 in step 700 of FIG. 14 (step 705 of FIG. 14), and the peripheral device in the peripheral device SDK 330 is executed. The registration information is transmitted to the SDK security layer 125 (step 710). If the peripheral device SDK security layer 125 determines that the credential is valid (step 715), it generates an application handler for the application 1 (step 722) and registers the application 1 107 in the internal registration table 285 (step 722). 725), the API subgroup 262 for APP1 is presented (step 745).

  FIG. 17 depicts an example of the software layer when several authenticated applications request access to the secure memory device 145. As described in step 190 of FIG. 2, the accessible APIs differ depending on how the SDK is configured for each application. For example, after the application 1 107 is successfully authenticated by the peripheral device SDK security layer 125 and registered in the internal registration table 285, the application 1 107 accesses the application 1 API subgroup 262. For example, the application 1 107 can call the API, and the secure memory device 145 can safely store and access the protected content, and can configure the secure memory device 145. The API 1 for APP1 serves as an interface for the application 1 to execute a task requested for the content to be protected through the secure file system 135 and the device driver 140. In the case of the application 1 107, the SDK is configured to be able to access all APIs for APP1.

  Application 2 and application 3 are examples of other applications that have been successfully authenticated by the peripheral device SDK security layer 125 and registered in the internal registration table 285. Application 2 uses APP2 API subgroups such as secure storage API and DRM API, and can access and store protected content through secure file system 135 and device driver 140, and secure using SDK configuration API The memory device 145 can also be configured. However, the application 2 cannot access the custom API in the SDK. As described in step 190 of FIG. 2, the API that can be accessed by the application 2 depends on the configuration of the SDK. Similarly, the application 3 can access and store protected content through the secure file system 135 and the device driver 140 using the API subgroup for APP3. However, since the SDK is not configured to allow the application 3 to access the configuration API, the DRM API, and the custom API in step 190 of FIG. 2, the application 3 cannot access these APIs.

  Continuing with the example of using a secure memory device as a peripheral device, the flowchart of FIG. 18 illustrates an example in which the peripheral device SDK 330 executes a task of storing protected content in the secure memory device 145 (FIG. 13). Step 525). When the registration process of FIG. 13 is completed and a task request is sent using one or more of the presented APIs, the peripheral device SDK 330 identifies where to store the protected content in the secure memory device 145 in step 900. The secure file system 135 is instructed to do so. To provide the desired storage location of the secure file system 135, the application 105 can call one of the API subgroup APIs presented in step 745 of FIG.

In step 905, the peripheral device SDK 330 accesses the permission related to the storage location of the content to be protected such as a session key for establishing the secure channel 155. In step 910, the peripheral device SDK 330 determines whether or not the secure channel should be used for the transfer of the protection target content based on the permission accessed in step 905.
When the peripheral device SDK 330 determines that the secure channel should not be used, the protection target content is transferred from the host storage management unit 110 on the host device 100 to the secure memory device 145 through the open channel 150 (step 915). Application 105 transfers this content by calling one of the API subgroup APIs presented in step 745 of FIG. The protected content access management unit 320 accesses the CEK at the storage location, and instructs the peripheral device cryptographic engine 160 to encrypt the content using the CEK and the cryptographic engine library 235. Next, the protected content access management unit 320 stores the encrypted protected content in the corresponding storage location (step 925).

If the peripheral device SDK 330 determines in step 910 that the secure channel 155 should be used, the peripheral device SDK 330 uses one of the API subgroups presented by the application 105.
The content is received through the API, and the host device encryption engine 185 is instructed to encrypt the content to be protected in the host device 100 using the session key and the corresponding encryption method (step 930). In step 935, the encrypted content is transferred from the host storage management unit 110 on the host device 100 to the secure memory device 145 through the secure channel 155. Next, the peripheral device cryptographic engine 160 uses the cryptographic engine library 235 to decrypt the protected content transferred by the secure memory device 145 (step 940).
In step 920, the protection target content access management unit 320 accesses the CEK at the storage location where the protection target content is stored, and uses the CEK and the encryption engine library 235 to encrypt the content to the peripheral device encryption engine 160. Instruct. Next, the protected content access management unit 320 stores the encrypted protected content in the corresponding storage location (step 925).

  The flowchart in FIG. 19 illustrates an example in which the peripheral device SDK security layer 125 executes a task of accessing the protected content stored in the secure memory device 145 (step 525 in FIG. 13). Once the registration process of FIG. 13 is complete and a task request is sent using the presented one or more APIs, the peripheral SDK security layer 125 is requested at the appropriate location in the secure memory device 145 at step 800. The secure file system 135 is instructed to find the protected content. To provide the desired storage location of the secure file system 135, the application 105 can call one of the API subgroup APIs presented in step 745 of FIG.

  The protection target content access management unit 320 accesses the permissions related to the position of the protection target content such as CEK and session key (step 805). Next, the protected content access management unit 320 accesses the protected content from the location of the secure memory device 145 (step 810), and decrypts the content using the CEK and the cryptographic engine library 235 so that the peripheral device cryptographic engine 160 is decrypted. (Step 815).

  Next, in step 820, the protected content access management unit 320 determines whether or not to use a secure channel for content transfer to the host storage management unit 110 on the host device 100. When the session key accessed in step 805 indicates transfer of the protection target content using the open channel 150, the protection target content access management unit 320 sends the content to the host storage management unit 110 on the host device 100 through the open channel 150. Transfer (step 825).

If it is determined in step 820 that the protected content access management unit 320 should use the secure channel 155 to transfer the protected content to the host storage management unit 110 on the host device 100, the secure memory device At 145, the peripheral device encryption engine 160 is instructed to encrypt the content to be protected using the session key (step 830). Next, the protected content access manager 320 transfers the encrypted protected content to the host storage manager 110 on the host device 100 through the secure channel 155 (step 835). The transferred protected content is decrypted by the SDK encryption library 168 using the same session key (step 840).
Once the protected content has been successfully transferred (steps 825, 835) and decrypted as necessary (step 840), the application 105 receives the requested protected content (step 850). The application 105 receives the requested protected content using one API of the API subgroup presented in step 745 of FIG.

  The flowchart in FIG. 20 illustrates an example of deregistering the application 105 from the internal registration table 285 in the peripheral device SDK security layer 125 (step 530 in FIG. 13). The peripheral device SDK security layer 125 checks in step 945 whether the task is complete. If the task is completed, the peripheral device SDK security layer 125 deletes information related to the application 105 from the registration table 285 (step 970). Next, the peripheral device SDK security layer 125 deregisters the application 105 from the internal registration table 285 (step 975). The step of deregistering the application 105 can be performed by calling an appropriate API, for example, by calling ucharUnRegisterApplication (char * AppID). This API cancels the registration of the application 105 by deleting the corresponding application ID from the internal registration table 285. This ends the process of executing the requested task (step 980).

If the task has not yet been completed, the task request is executed (step 525), while the peripheral device SDK security layer 125 checks whether the application 105 has been registered for the timeout period of the internal registration table 285. (Step 950). When the timeout period has passed, the peripheral device SDK security layer 125 deletes information related to the application 105 from the registration table 285 (step 955). Next, the peripheral device SDK security layer 125 requests re-authentication of the application 105 (step 960). For re-authentication of the application 105, an authentication process similar to that shown in FIG. 14 can be used. The peripheral device SDK security layer 125 determines whether the re-authentication is successful (step 965). If re-authentication is successful, task execution continues (step 525). If the re-authentication is not successful, the peripheral device SDK security layer 125 deregisters the application 105 from the internal registration table 285 by calling an appropriate API, for example, by calling ucharUnRegisterApplication (char * AppID). (Step 975). This API cancels the registration of the application 105 by deleting the corresponding application ID from the internal registration table 285. This ends the process of executing the task (step 980).
If the peripheral device SDK security layer 125 determines in step 950 that the timeout period of the internal registration table 285 has not passed, it continues to execute the task request in step 525.

  The above detailed description of various embodiments is not intended to be exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. The described embodiments are sufficient to fully explain the principles and practical applications of the present invention and to enable those skilled in the art to fully utilize the present invention with various modifications depending on the intended use in the various embodiments. It has been. Therefore, the above description is not intended to limit the scope of the invention as set forth in the appended claims.

Claims (43)

A method for providing access to a secure device comprising:
Installing a code set associated with the peripheral device on the host device, the code set including a code set for operating the peripheral device on the host device;
Authenticating a first software entity on the host device using the code set;
If the first software entity is successfully authenticated, presenting a portion of the code set to the first software entity, the presenting step comprising: Presenting a code for communicating with the peripheral device;
Including methods. The method of claim 1, wherein
The code set includes device driver code, application programming interface code, and authentication code;
The method wherein the portion of the code set includes a portion of the code of the application programming interface code and the authentication code. The method of claim 1, wherein
Receiving a task request from the first software entity in the code set;
Performing the task request using a portion of the code set;
A method further comprising: The method of claim 1, wherein
The authenticating step comprises:
Receiving credentials from the first software entity;
Verifying the credentials performed by the code set;
Including methods. The method of claim 4, wherein
Providing one or more authentication options for the first software entity, wherein the providing step is performed by the code set;
Receiving from the first software entity a response indicating any one of the one or more authentication options;
The verifying includes verifying the credentials based on the response. The method of claim 1, wherein
A method further comprising returning an error to the first software entity if the first software entity is not successfully authenticated. The method of claim 1, wherein
A method further comprising generating a software entity handler using an identifier associated with the first software entity in a cryptographic function if the first software entity is successfully authenticated. The method of claim 7, wherein
Sending the software entity handler to the first software entity, the software entity handler providing access to the first code. The method of claim 7, wherein
If the first software entity is successfully authenticated, the method further comprises registering the first software entity using the code set, the registering step being included in the table of authenticated software entities. Registering the software entity handler. The method of claim 9, wherein
Further comprising transmitting an indication that a portion of the code set is to be presented, wherein the transmitting step is directed to the first software entity if the first software entity is successfully registered. Transmitting the indicator. The method of claim 10, wherein:
The method further includes allowing the first software entity to perform a task related to the peripheral device while the first software entity is registered, and the allowing step includes allowing the software entity handler to Allowing the first software entity to use with a portion of a code set to perform the task. The method of claim 9, wherein
The registering step includes registering a permission associated with the first software entity, wherein the permission indicates one or more portions of the code set that the first software entity can access. The method of claim 9, wherein
A method further comprising deregistering the first software entity if the first software entity has been registered in the table for a predetermined period indicated in the table. The method of claim 9, wherein
Receiving a task request from the first software entity;
Performing the task request using a portion of the code set;
Deregistering the first software entity from the table using the code set after the task request is executed;
A method further comprising: The method of claim 1, wherein
The method wherein the peripheral device is a flash memory device. The method of claim 1, wherein
Receiving a request to store content at a group of the peripheral devices, wherein the receiving step includes receiving the request in the codeset from the first software entity;
If the first software entity is successfully authenticated, accessing an encryption key associated with the group;
Encrypting the content using the encryption key;
Storing the content in the group using a portion of the code set;
A method further comprising: The method of claim 1, wherein
Receiving a request to access content at a group of the peripheral devices, the receiving step including receiving the request in the codeset from the first software entity;
If the first software entity is successfully authenticated, accessing an encryption key associated with the group;
Decrypting the content using the encryption key;
Accessing the content using a portion of the code set;
A method further comprising: A method for providing access to a device, comprising:
Receiving a first task request for a peripheral device from a user of a first software entity on a host device;
Sending credentials from the first software entity to a code set installed on the host device for the peripheral device;
If the credentials are valid, accessing a portion of the code set associated with the first software entity, wherein the accessing step includes the first task being performed by the first software entity. Accessing the code for executing the code, wherein the code set includes code for one or more software entities on the host device to perform tasks related to the peripheral device;
Transmitting information related to the first task using a portion of the code set, wherein transmitting the information is performed by the first software entity;
Including methods. The method of claim 18, wherein:
Further comprising the step of selecting one authentication method from authentication method options;
Sending the credential depends on the authentication scheme and the selecting is performed by the first software entity. The method of claim 18, wherein:
The method further comprising the steps of: transmitting no information related to a second task using the portion of the code set without transmitting a second credential, wherein the transmission is performed by the first software entity. A method for providing access to a secure device comprising:
Transmitting one or more authentication options to a first software entity on a host device in response to a request to access a memory device from the first software entity, the one or more authentication options comprising: Deriving from a code set installed on the host device for the memory device, the code set including code relating to one or more software entities on the host device;
Receiving credentials from the first software entity associated with the one or more authentication options;
If the credentials are valid, providing access to a first code associated with the first software entity, the first code enabling access to the memory device; And being a part of the code set;
Including methods. The method of claim 21, wherein
If the credentials are valid, computing a software entity handler using the identifier of the first software entity;
Sending the software entity handler to the first software entity, wherein the software entity handler is used by the first software entity to access the first code;
A method further comprising: The method of claim 22, wherein
If the credential is valid, registering the first software entity in a table of authorized software entities, wherein the registering step registers the software entity handler in the table. Including steps;
Allowing the first software entity to perform one or more tasks associated with the memory device while the first software entity is registered in the table, the allowing step Allowing the first software entity to perform the one or more tasks using the software entity handler with the first code;
A method further comprising: 24. The method of claim 23.
The method further comprising deregistering the first software entity from the table when the one or more tasks are completed. 24. The method of claim 23.
The method further comprising deregistering the first software entity from the table after the software entity is registered in the table for a predetermined period of time indicated in the table. A system for accessing a secure device,
Peripheral devices;
A host device in communication with the peripheral device, the host device including one or more processors adapted to control access to the peripheral device, the one or more processors for the peripheral device Adapted to process a code set installed on the host device, wherein the code set enables communication between the peripheral device and one or more software entities on the host device, wherein the one or more processors are A subset of code of the code set for the first software entity if adapted to verify credentials from the first software entity on the host device and the credentials are valid; And the subset of the code is adapted to present the first software. And a host device associated with the A entity,
A system comprising: The system of claim 26.
The one or more processors receive a task request from the first software entity;
The one or more processors perform the task when the code set is programmed in the one or more processors. The system of claim 26.
The one or more processors provide one or more authentication options to the first software entity;
The one or more processors receive a response from the first software entity indicating any one of the one or more authentication options;
The one or more processors verify the credential based on the response. The system of claim 26.
The one or more processors return an error to the first software entity if the credentials are not valid. The system of claim 26.
The one or more processors generate a software entity handler using an identifier associated with the first software entity in a cryptographic function if the credentials are valid. The system of claim 30, wherein
The one or more processors send the software entity handler to the first software entity. The system of claim 30, wherein
The one or more processors register the first software entity in a table of authorized software entities if the credentials are valid;
The system wherein the one or more processors register the software entity handler in the table if the credentials are valid. The system of claim 32.
The one or more processors send a sign to the first software entity if the software entity is successfully registered, the sign indicating that a subset of the code is presented. 34. The system of claim 33.
The one or more processors use the software entity handler while the first software entity is registered in the table when the subset of code is programmed into the one or more processors. A system that permits the first software entity to execute a task related to the peripheral device. The system of claim 32.
The one or more processors register permissions for the first software entity in the table, the permissions indicating one or more subsets of the code set that the first software entity can access. System. The system of claim 32.
The one or more processors, when the first software entity has been registered in the table for a predetermined period indicated in the table, deregisters the first software entity. The system of claim 32.
The one or more processors receive a task request from the first software entity;
The one or more processors execute the task request when the subset of code is programmed into the one or more processors;
The system wherein the one or more processors deregister the first software entity from the table after the task request is executed. The system of claim 26.
The system wherein the peripheral device is a flash memory device. The system of claim 26.
The one or more processors receive a request to store content in a group of the peripheral devices, the request received from the first software entity;
The one or more processors access an encryption key associated with the group if the credentials are valid;
The peripheral device includes one or more peripheral device processors that encrypt the content using the encryption key and store the content in the group. The system of claim 26.
The one or more processors receive a request to access content in a group of the peripheral devices, the request received from the first software entity;
The one or more processors access an encryption key associated with the group if the credentials are valid;
The peripheral device includes one or more peripheral device processors that decrypt the content using the encryption key;
The one or more processors access the content if the subset of code is programmed into the one or more processors. A system for accessing a secure device,
A crypto engine,
One or more processors on a host device in communication with the cryptographic engine, the cryptographic engine verifies credentials from a first software entity on the host device, and the one or more processors Intercept access to a memory device that communicates with a host device, receive the credentials from the first software entity, and if the credentials are valid, present code associated with the first software entity And, if the code is programmed into the one or more processors, one or more processors that allow the first software entity to access the memory device;
With system. 42. The system of claim 41, wherein
The one or more processors provide one or more authentication options to the first software entity;
The one or more processors receive a selection of the one or more authentication options from the first software entity;
The crypto engine verifies the credentials based on the selection. 42. The system of claim 41, wherein
The one or more processors register the first software entity in a table of authorized software entities if the credentials are valid;
The one or more processors allow communication between the first software entity and the memory device while the first software entity is registered in the table.

Images