Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
  • G06F21/78—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data
  • G06F21/79—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data in semiconductor storage media, e.g. directly-addressable memories
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/60—Protecting data
  • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
  • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
  • G06F21/6281—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database at program execution time, where the protection is within the operating system

Definitions

• the present invention relates to technology for secure peripheral devices.
• a secure peripheral device may be memory devices, as memory devices containing secure content must be protected from unauthorized use.
• Non-volatile semiconductor memory has become more popular for use in various electronic devices.
• non-volatile semiconductor memory is used in cellular telephones, digital cameras, mobile media players, personal digital assistants, mobile computing devices, non-mobile computing devices and other devices.
• Protecting content stored on non-volatile semiconductor memory devices has become an important feature, especially concerning protection for copyrighted material.
• a user may purchase copyrighted content, such as music, through an electronic device.
• Content owners typically intend for only the purchaser to use the content and may require that the purchased content be played only by authorized applications on an electronic device, such as the application used to purchase the content.
• Securely storing information to protect against unauthorized use of secure content can be performed using a variety of protection techniques, such as encryption.
• An application on a device that tries to access encrypted content must decrypt the content using an encryption key before that content can be read.
• An application authorized to access the encrypted content will have the appropriate encryption key for decrypting the content.
• Unauthorized applications may still be able to access the encrypted content, but without the appropriate encryption key, the unauthorized application may not be able to read the content. However, if an application obtains the encryption key, the unauthorized application will be able to read the protected content.
• the technology described herein pertains to authentication of an application, application launcher, or other software entity on a host device to prevent unauthorized access to a secure peripheral device.
• the software entity is authenticated with set of code on the host device using any authentication mechanism.
• the set of code is associated with the peripheral device and is installed on the host device to control access to the peripheral device.
• the set of code also contains code that software entities on the host device can use for performing tasks associated with the peripheral device. Once the software entity is successfully authenticated, the set of code will make code that the software entity can use for performing tasks associated with the peripheral device available to the software entity.
• One embodiment includes a process that involves installing a set of code associated with a secure peripheral device on a host device, where the set of code includes code for operating the peripheral device on the host device, such as code for a device driver.
• the set of code is used to authenticate a first software entity on the host device.
• the process further includes exposing a portion of the set of code to the first software entity if the first software entity is successfully authenticated including exposing code that allows the first software entity to communicate with the peripheral device.
• One embodiment of an authentication process includes receiving a first task request associated with a secure peripheral device from a user at a first software entity on a host device.
• a credential is sent from the first software entity to a set of code installed on the host device for the peripheral device.
• the process further includes accessing a portion of the set of code if the credential is valid including accessing code associated with the first software entity that allows the first software entity to perform the first task.
• the set of code includes code that allows one or more software entities on the host device to perform tasks associated with the peripheral device.
• the first software entity sends information associated with the first task using the portion of the set of code.
• One embodiment of an authentication process includes sending one or more authentication options to a first software entity on a host device when the first software entity requests access to a peripheral device.
• the one or more authentication options are sent to the first software entity from a set of code installed on the host device for the peripheral device.
• the set of code includes code associated with one or more software entities on the host device.
• the set of code receives a credential from the first software entity.
• the credential is associated with one of the one or more authentication options.
• the process further includes providing access to first code associated with the first software entity if the credential is valid.
• the first code access to the peripheral device and is part of the set of code.
• 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 the peripheral device.
• the one or more processors also manage a set of code installed on the host device for the peripheral device by controlling access to the set of code, where the set of code allows communication between the peripheral device and one or more software entities on the host device.
• the one or more processors verify a credential from a first software entity on the host device and expose a subset of code from the set of code to the first software entity if the credential is valid, where the 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 that are in communication with the cryptographic engine.
• the cryptographic engine verifies a credential from a first software entity on the host device.
• the one or more processors intercept access to a secure peripheral device.
• the one or more processors also receive the credential from the first software entity and expose code associated with the first software entity if the credential is valid. When the one or more processors execute the code, the one or more processors allow the first software entity to access the peripheral device.
• One embodiment includes one or more processor readable media having processor readable code respectively, where the processor readable code causes the one or more processors to perform a method.
• the method includes sending one or more authentication options to a first software entity on a host device when the first software entity requests access to a peripheral device including sending one or more authentication options to the first software entity from a set of code installed on the host device for the peripheral device, where the set of code includes code associated with one or more software entities on the host device.
• the set of code receives a credential from the first software.
• the credential is associated with one of the one or more authentication options.
• the method further includes providing access to first code associated with the first software entity if the credential is valid.
• the first code allows access to the peripheral device and is part of the set of code.
• Figure 1 is a block diagram of a host device before a SDK for a secure peripheral device is installed.
• Figure 2 is a flow chart describing one process for configuring a SDK associated with a secure peripheral device.
• Figure 3 depicts one example of a secure peripheral device SDK.
• Figure 4 is a flow chart describing one process for loading a secure peripheral device into a host device.
• Figure 5 is a block diagram depicting one embodiment of a host device after a SDK for a secure peripheral device is installed.
• Figure 6 is a block diagram depicting one embodiment of host device components before installing code for a secure memory device.
• Figure 7 is a block diagram depicting one embodiment of components of a host device and a secure memory device.
• Figure 8 is a block diagram of one embodiment for a memory device SDK.
• Figure 9 is a block diagram depicting one embodiment of a secure memory device.
• Figure 10 is a block diagram depicting one embodiment of a firmware module for a secure memory device.
• Figure 11 depicts one example of partitions within a secure memory device.
• Figure 12 is one example of application APIs contained in a SDK for a memory device.
• Figure 13 is a flow chart describing one process for accessing a secure peripheral device.
• Figure 14 is a flow chart describing one embodiment of a process for registering a software entity on a host device.
• FIGS 15A-C are flow charts for different authentication methods that the SDK can perform.
• Figure 16 depicts one example of the registration process.
• Figure 17 depicts one example of software entities successfully registered on a host device.
• Figure 18 is a flow chart describing one embodiment of a process for storing protected content on a memory device.
• Figure 19 is a flow chart describing one embodiment of a process for accessing protected content on a memory device.
• Figure 20 is a flow chart describing one embodiment of a process for unregistering a software entity.
• a peripheral device can be any device operated via a host device, such as a memory device, a printer, a keyboard, etc.
• Software for the peripheral device must be installed on the host device in order to operate the peripheral device on the host device.
• This software is a set of code for a software development kit (SDK), such as a dynamic link library (DLL) or a static library (LIB), installed on the host device for operating the peripheral device via one or more software entities or applications on the host device.
• SDK software development kit
• DLL dynamic link library
• LIB static library
• the SDK for the peripheral device When a user sends a task request to the host device via an application and the task request involves access to the peripheral device, the SDK for the peripheral device will authenticate the application and verify that the application is authorized to access the peripheral device. If the authentication is successful, the SDK will expose only those APIs for that specific application. The SDK will not expose APIs the application is not authorized to access. The application can send and perform the task request using the exposed APIs specific to that application. This increases the security of the peripheral device and prevents unauthorized access to APIs for other applications.
• FIG. 1 depicts one example of a host device 255 before the set of code for an SDK for a peripheral device is installed.
• the host device 255 has an application 105, memory 260, and a host CPU 165.
• the host device 100 can be any electronic device, such as a cellular telephone, a PC, a digital camera, mobile media players, personal digital assistant, mobile computing device, non-mobile computing device and other devices.
• the application 105 can be any software entity used on a host device, such as a calendar, document viewer, media player, etc.
• the application 105 can also be any software entity used to launch an application.
• the memory 260 can be any type of memory that a host device 255 may require.
• the host CPU 165 can be any type of processor used for operating the host device 255.
• a SDK When a SDK is created by a software developer for a peripheral device that will be operated through a host device, such as the host device 255 depicted in Figure 1, the SDK software may be configured for each software entity or application on the host device that will require access to the peripheral device. Many times, the software entity on the host device may be owned or created by a particular customer with various needs and preferences. The SDK may be configured based on each software entity/application or customer's needs and preferences, such as authorization preferences or functions of the customer's application.
• Figure 2 is a flow chart for one process of configuring a set of code for a SDK based on different application and/or customer needs and preferences.
• the SDK software specific to each application and/or customer will be configured by the SDK software developer based on the specific requirements of the application and/or customer.
• the set of code for the SDK for accessing a peripheral device through a customer application typically requires an API for interfacing the application with the peripheral device.
• the SDK software for access to these APIs for the application can be specifically configured based on customer preferences, such as configuring the SDK to require application authentication before the peripheral device is accessed, for example.
• the SDK is configured to determine which APIs each application will need to access.
• the SDK software for operating the peripheral device will be configured based on the required APIs of the SDK software specific to each application/customer performed in step 190.
• step 190 e.g. security software required for authentication
• step 195 any other software needed to operate the peripheral device on the host device, including the software customized in step 195.
• Figure 3 depicts one example of a set of code for a peripheral device SDK 330 that has been configured according to the process described in Figure 2.
• the peripheral device SDK 330 includes subsets of code such as the security layer 125, APIs for applications 1-3, and a device driver 140.
• the sets of code for the SDK can be a dynamic link library (DLL) or a static library (LIB).
• the security layer 125 includes the software for authenticating different applications that attempt to access the peripheral device.
• the security layer 125 may be part of the SDK software that is configured as described in step 195 of Figure 2.
• the security layer 125 can be configured if the APIs for Application 1 262 require extra authentication features.
• the security layer 125 will be later discussed in more detail.
• the APIs for applications 1-3 are the APIs that each application must use to communicate with the peripheral device. These APIs may be configured based on customer preferences for each application, as described in step 190 of Figure 2. For example, APIs for Application 1 262 may be the APIs customized for application 105 in the host device 255 of Figure 1.
• the device driver 140 is the software that allows the peripheral device to properly operate on the host device.
• FIG 4 is a flow chart describing one process for installing the SDK shown in Figure 3 on a host device.
• the secure peripheral device is connected to the host device.
• the SDK for operating the secure peripheral device is loaded and installed onto the host device (step 175).
• This SDK may be stored in memory for the secure peripheral device.
• the SDK contains software used to program the host CPU on the host device in order to operate the secure peripheral device so that unauthorized access is prevented.
• the host device can be operated with the secure peripheral device (step 180).
• step 175 is performed for a particular secure peripheral device only during the first time that the particular secure peripheral device is connected to the host device.
• the SDK for this particular peripheral device need not be installed again each time it is re-connected to the host device.
• the SDK is loaded and installed every time the secure peripheral device is connected to the host device.
• the SDK for operating the secure peripheral device is loaded and pre-installed on the host device before the operating system is installed on the host device.
• the SDK can be used by activating or selecting it through the operating system. Therefore, step 175 need not be performed as part of the process of Figure 4.
• the SDK for operating the secure peripheral device is loaded and pre-installed on the host device after the operating system for the host device has been installed. Again, in this case, step 175 need not be performed as part of the process of Figure 4.
• Figure 5 shows one embodiment of the host device 255 with the secure peripheral device 145 after the set of code for the SDK 330 of Figure 3 has been installed.
• the host device 255 includes the original components shown in Figure 1 (application 105, memory 260, and host CPU 165) as well as the components of the SDK 330 shown in Figure 3 (security layer 125, APIs for applications 1-3, and device driver 140).
• security layer 125 will cause the host CPU 165 to authenticate the application 105.
• the security layer 125 will expose the subgroup of APIs specific to the application 105, such as APIs for Application 1 262, if application 105 was Application 1.
• the application 105 can then use that subset of the set of SDK code to send the task request to the secure peripheral device 145 via the device driver 140.
• the application 105 can also use those APIs to perform the task request for the user.
• a secure memory device will be used as an example of a peripheral device.
• the peripheral device can be any peripheral device and is not limited to the example of a memory device described below.
• Figure 6 shows one embodiment of the components in a host device 100 before a SDK for a secure memory device is installed.
• a user of a host device 100 assesses content stored on the host device 100 through a software entity such as an application 105.
• applications on the host device 100 include media players, calendars, address books, etc. that are saved on the host device 100.
• An application can also be executable code on the host device used to launch an application (i.e. media players, calendars, address books, etc.) stored in a different location from the executable code on the host device 100.
• an application may be used to launch a media player application that is saved within the host device in a different part of memory for the host device 100 or on a peripheral device connected to the host device 100.
• Content accessed or saved using an application 105 can include content such as applications, media, scheduling information, or contact information, etc.
• the application 105 uses a host storage manager 110 on the operating system for the host device 100 to access or store content on the host device 100 or any other peripheral devices, such as a removable memory device.
• the host storage manager 110 is a software component on the operating system that controls access and storage functions for the host device 100, including access and storage within the host device 100 and between any peripheral devices, as will be explained in more detail below.
• Figure 6 also shows the host storage manager 110 and the host file system 130, which is a component that the host storage manager 110 manages.
• the host storage manager 110 uses the host CPU 165 to access the host file system 130.
• the host file system 130 is stored in memory on the host device 100 and is used to locate and store content stored on the host device 100 and in any peripheral devices. When a user requests content from the host device 100, the host storage manager 110 will use the host file system 130 to locate the content. When a user requests that content be stored, the host storage manager 110 will use the host file system 130 to store the content in the proper location.
• the host device may contain a host cryptographic engine 185, which may have a random number generator and a cryptographic processor that may support encryption methods such as symmetric encryption (i.e. AES, DES, 3DES, etc.), cryptographic hash functions (i.e. SHA-I, etc.), asymmetric encryption (PKI, key pair generation, etc.), or any other cryptography methods.
• symmetric encryption i.e. AES, DES, 3DES, etc.
• cryptographic hash functions i.e. SHA-I, etc.
• PKI key pair generation, etc.
• Figure 7 shows one example of the host device 100 that operates with a secure memory device 145 after the set of code for the peripheral device SDK 330 has been properly loaded and installed on the host device 100.
• the secure peripheral device is a removable storage device for storing content that either may be stored in a secure partition of the secure memory device or may be stored in a public partition of the secure memory device.
• the secure memory device can be any type of memory device, such as a mass storage device, a non- volatile flash memory device, etc.
• the secure memory device protects against unauthorized access of content stored in the secure partition of the secure memory device.
• the secure memory device may also protect against unauthorized access of content stored in the public partition of the secure memory device if the content is protected.
• Content is protected in the secure memory device if the content is encrypted.
• Content is unprotected in the secure memory device if the content is unencrypted and is stored in a public partition.
• a host device may access and store content on the secure memory device if the host device has the proper authorizations associated with the content, such as authorizations that allow the content to be encrypted or decrypted.
• the host device 100 is physically connected to the secure memory device 145 through the physical interface 142.
• the application 105, the host CPU 165, the host device crypto engine 185, the host storage manager 110, and the host file system 130 are software components on the host device 100 as shown in Figure 6.
• the peripheral device SDK 330 is the set of code installed on the host device 100 and is used to operate the secure peripheral device 145 with the host device 100.
• the peripheral device SDK 330 uses the secure peripheral device API 120, the peripheral device SDK security layer 125, the host file system 130, the registration table 285, the SDK crypto library 168, and the secure file system 135 to manage content access and storage for the secure memory device 145.
• the secure peripheral device API 120, the peripheral device SDK security layer 125, the registration table 285, the SDK crypto library 168, the secure file system 135, and the device driver 140 are software components loaded and installed on the host device from the set of code for SDK for the secure memory device 145 as described in step 175 of Figure 4.
• the open channel 150 and the secure channel 155 are the data buses used to transfer content between the host device 100 and the secure memory device 145.
• the secure memory device 145 controls access to and storage of content using software installed on the host device 100 for the secure memory device 145.
• the software includes the libraries described in step 175 of Figure 2 or they can be libraries pre-installed on the host device.
• the SDK libraries loaded and installed on the host device can be either dynamic link libraries (DLL) or static libraries (LIB) that can be integrated into the operating system on the host device.
• the set of code for the SDK provide hooks into the host storage manager 110 for secure operation of the secure memory device 145. For example, subsets of code from the set of code for the peripheral device SDK can be inserted in the call chain for calling the host file system 130 so that the code causes the host CPU 165 to control how content is accessed and stored.
• peripheral device SDK security layer 125, the secure peripheral device API 120, the secure file system 135, the registration table 285, the SDK crypto library 168, and the device driver 140 are the subsets of code that are provided to the host device through the set of code for the secure peripheral device SDK using a device driver 140 installed on the host device 100.
• a user may access content stored in the secure memory device 145 through a software entity, such as an application 105 on a host device, as shown in Figure 7.
• a software entity such as an application 105 on a host device, as shown in Figure 7.
• the application 105 first needs to be authenticated before the content can be accessed, as described in more detail below.
• the application 105 uses the host storage manager 110 on the operating system for the host device to access or store content in the secure memory device 145.
• the host storage manager 110 controls access and storage functions for the host device, including access and storage within the host device and the secure memory device 145.
• the host storage manager 110 controls access and storage functions for the host device or any peripheral devices using a host file system 130 on the operating system for the host device, as discussed in Figure 6.
• the host file system 130 can be any standard file system, such as FAT12, FAT16, FAT32, NTFS, etc.
• the peripheral device SDK 330 for the secure memory device 145 uses a peripheral device SDK security layer 125 to control access and storage functions on the host device by using a secure file system 135 for the secure memory device 145. Access to the secure file system 135 is controlled by authenticating the application 105 and allowing access to only APIs specific to the application 105 upon successful authentication. These APIs allow the proper interface for the secure file system 135.
• the secure file system 135 is installed on the host device 100 for the secure memory device 145 and is the file system for the content stored in the secure memory device 145.
• the secure file system 135 can be any standard file system, such as FAT 12, FAT 16, FAT32, NTFS, etc.
• the peripheral device SDK security layer 125 causes the host CPU 165 to authenticate the application 105. After the application 105 is successfully authenticated, the application 105 will be registered in the registration table 285.
• the peripheral device SDK security layer 125 also provides an application handler to the application 105. The application handler indicates which APIs the application 105 is allowed to access. More detail regarding the authentication and registration process performed by the peripheral device SDK security layer 125 will be described below.
• the peripheral device SDK security layer 125 will provide the appropriate API, such as secure peripheral device API 120, needed to access the content from the secure peripheral device 145 after successful authentication.
• the application 105 can receive the content stored in the secure peripheral device 145 by accessing the permissions associated with the content.
• the header is stored with the content and contains information associated with the content, such as domain information related to content encryption keys (CEK) for encrypting and decrypting the content, and content metadata, which may indicate what type of content is stored.
• CEK content encryption keys
• the secure peripheral device API 120 in the peripheral device SDK 330 is used to interface the secure peripheral device 145 with the application 105 when content is accessed or stored.
• the secure peripheral device API 120 is part of the SDK that is installed and may be called by the application 105 when the application 105 is successfully authenticated.
• the secure peripheral device API 120 is the interface bridge between the peripheral device SDK security layer 125 and the secure file system 135.
• the content can be accessed or stored on the secure memory device 145 in the appropriate location using the device driver 140 on the host device. This is performed through the physical interface 142 that physically connects the host device 100 and the secure memory device 145.
• the content may be accessed or stored using a secure channel 155 or an open channel 150.
• the peripheral device SDK 330 determines whether the content should be transferred between the secure peripheral device 145 and the host device using a secure channel 155 or an open channel 150.
• the peripheral device SDK 330 When a user, through the application 105, requests storage of content that should be unprotected, the peripheral device SDK 330 will use the host file system 130 to store the content. If the user requests storage of content that should be protected in the secure peripheral device 145, the peripheral device SDK 330 will use the secure file system 135 to store the content.
• the secure peripheral device API 120 in the peripheral device SDK 330 is used to interface the secure peripheral device 145 with the application 105 when protected content is accessed or stored.
• the secure peripheral device API 120 is part of the SDK that is installed and may be called by the application 105 when the application 105 is successfully authenticated.
• the secure peripheral device API 120 is the interface bridge between the peripheral device SDK security layer 125 and the secure file system 135.
• the content can be accessed or stored on the secure peripheral device 145 in the appropriate location using the device driver 140 on the host device. This is performed through the physical interface 142 that physically connects the host device 100 and the secure memory device 145.
• the content may be accessed or stored using a secure channel 155 or an open channel 150.
• the peripheral device SDK security layer 125 determines whether the content should be transferred between the secure peripheral device 145 and the host device using a secure channel 155 or an open channel 150.
• a session key is an encryption key used to encrypt content before it is transferred between the host device and the secure memory device. If content does not need to be transferred through a secure channel, there may be no session key associated with the content, or the session key associated with that content may indicate that no encryption is needed.
• the content is associated with a session key indicating that the content should be transferred using a secure channel 155, the content will be encrypted using the session key before it is transferred through the secure channel 155. Once the encrypted content is transferred, the content will be decrypted using the same session key.
• the content is encrypted or decrypted on the host device 100 using the SDK crypto library 168.
• the SDK crypto library 168 contains a random number generator and cryptographic functions for encryption, such as symmetric encryption (i.e. AES, DES, 3DES, etc.), cryptographic hash functions (i.e. SHA-I, etc.), asymmetric encryption (PKI, key pair generation, etc.), or any other cryptography methods.
• the secure peripheral device 145 has its own crypto engine for encryption on the secure memory device 145 before or after transferring content, as will be explain in more detail for Figure 11. If the session key indicates that the content should be transferred using an open channel 150, the content is transferred without encrypting the content.
• the host device may be able to access content stored in a public partition. If the content is protected, although the device may be able to access the content, the device will not be able to read the content correctly if it is encrypted. If the content is stored in a secure partition, the device cannot access the content.
• Figure 8 shows an example of software contained in the peripheral device SDK 330 that is installed on the host device 100 when the peripheral device is a secure memory device, as shown in Figure 7.
• the peripheral device is not limited to the example for a memory device.
• the peripheral device SDK 330 is the library that is installed on the host device 100 and contains software for operating the secure memory device 145 on the host device 100, such as peripheral device APIs 260, the peripheral device SDK security layer 125, the device driver 140, the secure file system 135, the SDK crypto library 168, and the registration table 285.
• the peripheral device SDK 330 is not limited to only this software.
• the application APIs 260 are the APIs used by any application, such as the application 105 in Figure 7. These APIs include APIs used for authentication, and they also include APIs used to interface an application with the secure file system 135 for access to content on the secure memory device 145 once the application has been successfully authenticated, such as the secure peripheral device API 120 in Figure 7.
• the application APIs 260 may contain APIs specific to that particular application. For example, an API used by one application may not be used by another application. An application that is successfully authenticated through the peripheral device SDK security layer 125 may access protected content in the secure memory device 145 through a secure peripheral device API 120.
• the secure peripheral device APIs 120 are discussed in more detail below for Figure 12.
• the peripheral device SDK security layer 125 is installed on the host device to provide hooks into the host storage manager 110 and cause the host CPU 165 to control how content on the secure memory device 145 is accessed and stored.
• the code for the peripheral device SDK security layer 125 ' hijacks' the host file operations on the host device 100 so that an application can be authenticated before accessing content on the secure peripheral device 145.
• the software of the device driver 140 can be loaded and installed on the host device after the secure memory device 145 is connected to the host device 100 (step 175 of Figure 4) or pre-installed on the operating system for the host device 100 either before or after the operating system is installed on the host device.
• the secure file system 135 is the file system containing filing data for accessing and storing content in the secure memory device 145, as illustrated in Figure 7.
• the SDK crypto library 168 is the library containing the cryptographic schemes that may be used for encrypting or decrypting content for a secure channel 155.
• the cryptographic schemes can be any known schemes, such as AES, DES, 3DES, SHA-I, PKI, key pair generation, etc.
• the SDK crypto library 168 will encrypt or decrypt content based on permissions associated with the content, such as a session key.
• the registration table 285 is the table used by the peripheral device SDK security layer 125 to manage and maintain the application authentication status and related information.
• the table may contain information such as authentication algorithms, application ID, registration time, expiration time, registration status, etc. More detail regarding the registration table 285 will be discussed below.
• Figure 9 depicts one embodiment of the secure peripheral device 145 shown in Figure 7.
• the secure peripheral or memory device 145 contains a firmware module 210, a CPU 220, a peripheral device crypto engine 160, and a system partition 400.
• the system partition 400 contains public partitions 240 and secure partitions 250.
• the firmware module 210 accesses and stores content in either the public partitions 240 or the secure partitions 250 of the system partition 400 using the CPU 220.
• the memory device crypto engine 160 is used to encrypt or decrypt the accessed or stored protected content within the secure memory device 145.
• the firmware module 210 contains the hardware and software for controlling the access and storage of content on the secure memory device 145 for the secure partitions 250 and the public partitions 240.
• the firmware module programs the CPU 220 to perform the access and storage functions, such as determining from which portion of memory content should be accessed or stored and whether the content is protected. More details regarding the firmware module 210 will be discussed below in the description for Figure 10.
• the public partitions 240 are memory partitions of the secure memory device 145 that are viewable by a user and detectable by the host device 100.
• the secure memory device 145 may have one or more public partitions.
• the public partitions 240 may contain public content that is openly accessible to a user or the host device 100.
• the public partitions 240 may also store protected content that is encrypted using a content encryption key (CEK).
• CEK can be generated using the domain information stored in the content header containing information associated with the content.
• Public content may also be stored without encrypting the content.
• the secure partitions 250 are hidden memory partitions of the secure memory device 145 that are not viewable by a user and are not detectable by the host device.
• the secure memory device 145 may have one or more secure partitions.
• the secure partitions 250 may contain protected content that is not openly accessible to the user or the host device 100.
• the protected content may be encrypted using a CEK.
• Content stored in the secure partitions 250 is accessible to authenticated applications having the appropriate permissions for accessing the content.
• the information associated with the CEK and the permissions associated with the content are stored in the content header containing information associated with the content.
• public partitions 240 and secure partitions 250 of the system partition 400 are stored in a flash memory device that includes a controller and one or more flash memory arrays.
• the secure partitions 250 are hidden partitions undetectable by a user or the host device, the secure partitions 250 may contain the software for operating the secure memory device 145 on the host device 100, including rights objects, application credentials, etc.
• the peripheral device crypto engine 160 is used to encrypt or decrypt the content using the CEK or the session key within the secure memory device 145.
• the memory device crypto engine 160 contains a random number generator and a cryptographic processor that may support encryption methods such as symmetric encryption (i.e. AES, DES, 3DES, etc.), cryptographic hash functions (i.e. SHA-I, etc.), asymmetric encryption (PKI, key pair generation, etc.), or any other cryptography methods.
• FIG. 10 depicts the details of one embodiment for the firmware module 210.
• the firmware module 210 contains a peripheral device interface module 144, a flash memory manager 310, a protected content access manager 320, a crypto engine library 235, and a DRM (digital rights management) module 315.
• the peripheral device interface module 144 contains the hardware and software for interfacing the secure memory device 145 with the host device 100 via the host device physical interface 142.
• the hardware components for the peripheral device interface module 144 can include components for any type of interface, such as a Universal Serial Bus (USB), Secure Digital (SD), or Compact Flash (CF) interface.
• USB Universal Serial Bus
• SD Secure Digital
• CF Compact Flash
• the flash memory manager 310 contains the software that causes the CPU 220 to access or store unprotected content in the public partitions 240 and may cause the CPU 220 to access or store the content based on permissions using the DRM module 315.
• the protected content access manager 320 contains the software that causes the CPU 220 to access or store protected content using permissions for the protected content and may cause the CPU 220 to access or store the protected content based on the permissions using the DRM module 315.
• the protected content access manager 320 may also use the crypto engine library 235, which stores the information needed to encrypt content using a session key or a CEK. Both the flash memory manager 310 and the protected content access manager 320 access and store content for the host device through the device driver 140 on the host device.
• the flash memory manager 310 controls access and storage of unprotected content in the secure memory device 145 using the CPU 220.
• the flash memory manager 310 When a request to save unprotected content is received from the host device 100 through the device driver 140, the flash memory manager 310 will save the content in the appropriate location according to the host file system 130.
• the flash memory manager 310 When a request to access unprotected content is received through the host device file system 130 via the device driver 140, the flash memory manager 310 will access the content from the appropriate location using the host file system 130.
• the flash memory manager 310 also provides access to the protected content access manager 320 when the application 105 tries to access protected content in the secure memory device 145.
• the protected content access manager 320 controls access and storage of protected content in the secure memory device 145 using the CPU 220.
• the protected content access manager 320 stores or retrieves the permissions associated with the protected content to or from the DRM module 315.
• the protected content access manager 320 uses the secure file system 135 shown in Figure 7 to access or store protected. For example, when a request to save protected content is received from the host device through the device driver 140, the peripheral device SDK security layer 125 will use the SDK crypto library 168 to encrypt the protected content using a session key associated with the content if the content should be sent through a secure channel 155.
• the encrypted content is then sent to the secure memory device 145 through the secure channel 155 and decrypted at the secure memory device 145 using the session key and the appropriate cryptographic scheme from the crypto engine library 235.
• the decrypted content is then encrypted by the peripheral device crypto engine 160 using a CEK for the content.
• the content encrypted using the CEK is then saved in the appropriate location according to the secure file system 135.
• the protected content access manager 320 For protected content sent through an open channel, a similar method for transferring the content is performed but without the session key encryption for the secure channel 155.
• the protected content access manager 320 When a request to access protected content is received from the host device 100 through the device driver 140, the protected content access manager 320 will access the content from the appropriate location using the secure file system 135 and provide the content to the host storage manager 110 on the host device 100 through an open channel 150.
• the protected content access manager 320 will access and store content through the flash memory manager 310 once the appropriate permissions are determined by the protected content access manager 320.
• the protected content access manager 320 may also use the DRM module 315 to provide access to content based on permissions associated with the content, such as copyright permissions for example.
• the DRM module 315 can support any particular DRM technology, such as OMA DRM, MS DRM, etc.
• the crypto engine library 235 contains the cryptographic schemes that may be used for encrypting the content with a CEK or a session key within the secure memory device 145.
• the protected content access manager 320 will access the appropriate cryptographic scheme from the crypto engine library 235.
• the cryptographic schemes can be any of the known schemes, such as AES, DES, 3DES, SHA-I, PKI, key pair generation, etc.
• FIG 11 depicts an example of a system partition 400 for the secure memory device 145.
• the system partition 400 includes all of the memory partitions in the secure memory device 145. That is, the system partition 400 is made up of the public partitions 240 and the secure partitions 250 shown in Figure 9.
• the secure memory device 145 may have any number of public or secure partitions.
• a public partition is detectible and openly accessible to a user or a host device. Unprotected content stored in a public partition can be accessed without authentication. However, protected content stored in a public partition must be accessed only after successful authentication.
• a secure partition is a hidden partition that is undetectable to a user or a host device. Any application attempting to open content in a secure partition must first be authenticated.
• the protected content access manager 320 organizes the content according to the permissions associated with the content and the content is then stored by the flash memory manager 310.
• Public and secure partitions may have domains or logic groups that contain groups of protected content having the same CEK. Each domain or logic group is associated with one CEK for decrypting content from or encrypting content to that domain or group. Any application having the appropriate permissions for opening content within a domain or group may also be able to open other content stored in the same domain or group.
• Public partition PO 410 in Figure 1 1 contains two logic groups, Domain 1 and Domain 2. AU content stored in Domain 1 will use one CEK for encrypting and decrypting content. All content stored in Domain 2 will use another CEK for encrypting and decrypting the content. A software entity attempting to access either of these groups will require authentication before the content can be read. Because the public partition PO is not hidden and is openly accessible, protected content contained within a group may be seen and possibly accessed but the content may not be read unless the content is properly decrypted using the appropriate CEK. Therefore, it is possible that content in a group may be corrupted by an unauthorized user but the content may not be read. [0084] File A 440 in public partition PO 410 is not contained within a group so it does not have a CEK associated with it. Therefore, any user may access and read File A 440.
• Secure partition Pl 420 contains File E and File F.
• File E and File F can be any file requiring protection in a secure partition.
• File E or File F can be used by the SDK to store secure information, such as content licenses or any internal management data.
• secure partition Pl 420 is not limited to storing only these types of files. Secure partition Pl 420 can store any secure files.
• Secure partition P2 430 contains File G and File H, both within Domain 3 490.
• Domain 3 is associated with a CEK for encrypting and decrypting the content. For example, if an application attempts to access File G in Domain 3, the application must first be authenticated. Once authenticated, the application may access File G using the CEK for Domain 3 and may also access File H within Domain 3.
• Secure partition P3 450 shows an empty partition that may be used to store any protected content.
• FIG 12 shows an example of the application APIs 260 contained in the peripheral device SDK 330.
• the application APIs 260 include standard and secure storage APIs 340, authentication APIs 350, configuration APIs 360, DRM APIs 370, and any other customized APIs 380 that a user may need for operating the secure memory device 145 on the host device 100.
• Each of the different types of APIs may be specific to a software entity, such as an application or an application launcher 105.
• the APIs for each application are stored as a logic group, such as a domain.
• the APIs for APP 1 262 are stored in a group separate from the APIs for other applications.
• each group contains only one type of API for one application.
• the secure storage APIs for APP 1 262 are may be considered as one group.
• the APIs for APP 1 262 show the subgroup of APIs from the entire group of APIs that are specific to Application 1.
• the SDK was configured to allow the APIs for APPl 262 to be accessed by Application 1 upon successful authentication (see Figure 2, step 190).
• the APIs for APP 1 262 is the subset of code from the set of code for the SDK that may be called by one or more different applications.
• the APIs for APP 1 262 may only be called by Application 1 software entity.
• the APIs for APP 1 262 include secure storage APIs, configuration APIs, DRM APIs, and customized APIs. However, the APIs for APP 1 262 are not limited to only those APIs.
• the standard and secure storage APIs 340 contain the APIs needed for an application or an application launcher 105 to retrieve and store content on the secure memory device 145, to establish a secure session, or to perform any other type operations involving access and storage of content on the secure memory device 145.
• a standard or secure storage API 340 may be an API that allows an application 105 to send a path location for content requested for access to the host file system 130 or the secure file system 135.
• the application 105 may call a standard API from the group of standard and secure APIs 340 when accessing public content and may call a secure API from the group of APIs for APP 1 262 after Application 1 is authenticated with the peripheral device SDK security layer 125, such as secure peripheral device API 120 shown in Figure 7.
• the authentication APIs 350 are APIs used to authenticate an application 105, and it is open to all applications without requiring an authentication process for access to authentication APIs 350.
• the authentication APIs 340 are called by the application 105.
• the application 105 can send a credential to the peripheral device SDK security layer 125 using the authentication API 340.
• the peripheral device SDK security layer 125 will then verify if the credential sent by the application 105 through the authentication API 340 is valid.
• the credential can be any type of credential used to authenticate a software entity, such as a response to a challenge/response authentication algorithm, a PKI certificate, a PIN, a key, a password, etc.
• the authentication API 350 may be used to send a challenge to the application 105.
• the response to the challenge may then be sent from the application 105 to the peripheral device SDK security layer 125 using the same authentication API 340.
• the configuration APIs 360 are the APIs used to allow the application 105 to configure the secure memory device 145 or to retrieve information about the configuration of the secure memory device 145. This may only occur if the application 105 has the appropriate authority to do so.
• the configuration APIs 360 may be called by a specific application 105 to obtain information about the used and free memory space on the secure memory device 145 or to create a new secure partition after the application 105 is successfully authenticated.
• the DRM APIs 370 may be called by the application 105 to access the permissions or digital rights associated with content and provide access to that content if the rights are valid. The validation of these rights would occur in the DRM module 315 in the firmware module 210 in the secure memory device 145. In one embodiment, the DRM APIs 370 may be specific to a particular application 105, such as shown in the subgroup of APIs for APP 1 262.
• the customized APIs 380 may be any additional APIs a user may require for operation of the secure memory device 145 in the host device 100.
• the customized APIs 380 may be specific to a particular application 105, such as shown in the subgroup ofAPIs for APP 1 262.
• Figure 13 is a flow chart describing an example of how a host device can be operated with the secure peripheral device after the peripheral device SDK is properly installed on the host device (step 180 of Figure 4). More specifically, Figure 13 is a process describing how a task request associated with the secure peripheral device and sent by a user through an application on the host device is performed.
• a task request can be a request to access or store content on the secure peripheral device, including accessing and storing files (e.g. music, applications, etc.), accessing information associated with the secure peripheral device (e.g. the amount of free memory space), changing content for configuration of the secure memory device, or accessing DRM information (e.g. digital rights objects).
• the user may request this task via an application on the host device.
• a secure memory device will be used as the secure peripheral device.
• the secure peripheral device is not limited in its use or configuration as provided such this example.
• a user may send a task request to an application 105 on the host device 100.
• the task request is received from the application 105 at the peripheral device SDK security layer 125 (step 505).
• the peripheral device SDK security layer 125 will perform a registration process for the application 105.
• the registration process is the process for authenticating the application 105 and registering the application 105 in the internal registration table 285 (shown in Figure 7) if the authentication is successful.
• the peripheral device SDK will send an indication to the application 105.
• the indication indicates that the APIs specific to the registered application 105 are exposed.
• the peripheral device SDK security layer 125 also sends an application handler to the application 105.
• the application handler is used as an added security measure. Each time the application 105 communicates with the peripheral device 145 using an exposed API, the application 105 must also send the application handler to the peripheral device via the API.
• step 515 the application 105 will send the task request to the peripheral device SDK 330 through one or more of the APIs exposed during the registration process (step 520).
• the task request must be sent with the application handler given to the application 105 during the registration process.
• step 525 the peripheral device SDK 330 will perform the task request using the exposed subgroup of APIs specific to the application 105.
• Figure 18 describes an example of how this step is performed for storage of protected content in a secure memory device.
• Figure 19 describes an example of how this step is performed for access of protected content stored in a secure memory device.
• the peripheral device SDK security layer 125 will unregister the application 105 from the internal registration table 285 in step 530.
• Figure 20 describes how this step is performed in more detail.
• FIG 14 is a flow chart illustrating one example of how the registration process is performed for a task associated with protected content (step 515 of Figure 13).
• step 700 after a user sends a task request to the application 105, the application 105 will choose an authentication method from a list of authentication method options.
• the list of authentication method options is provided to the application 105 by peripheral device SDK security layer 125 through an authentication API.
• the API for providing such a list can be defined, for example, as:
• the ListAuthenMethod API may provide the peripheral device SDK security layer 125 with the application ID (char*AppID) for the application 105.
• the application ID is the unique identifier associated with the application 105.
• the peripheral device SDK security layer 125 will return a list of authentication methods (char*AuthList) supported by the peripheral device SDK 125.
• the application 105 will then choose which authentication method to use from the list provided by the peripheral device SDK security layer 125 based on the authentication method the application 105 is programmed to use.
• the application 105 will perform the chosen authentication method by acquiring the appropriate credential for the chosen authentication method. For example, if the chosen authentication method is PKI-based, the application 105 will perform the authentication method by retrieving its PKI certificate as its credential. If the chosen authentication method is a challenge/response authentication method, the application 105 will perform the authentication method by calling the challenge/response API stored with the authentication APIs 350 in the memory device SDK 330. The application 105 will receive the challenge from the peripheral device SDK security layer 125 using the challenge/response API. The challenge can be a random number generated by the host device crypto engine 185 or the memory device crypto engine 160. The application 105 will then calculate the appropriate response to the challenge as its credential. More detail about how different authentication methods are performed is discussed in the description for Figures 15A-C.
• step 710 the application 105 will send the registration information to the peripheral device SDK security layer 125 by calling a registration API.
• the API for registering the application can be defined, for example, as:
• the RegisterApplication API may allow the application 105 to send its application ID (char*AppID), the chosen authentication method (char*AuthMethod), the credential (uchar*credential), and the length of the credential (uchar credentialLen) retrieved in step 705 to the peripheral device SDK security layer 125 using the RegisterApplication API.
• the credential length should be provided to support different credential lengths that different authentication methods may require.
• the peripheral device SDK security layer 125 will check to see if the credential is valid. If the credential is not valid, the peripheral device SDK security layer 125 will return an error to the application 105 (step 720).
• the peripheral device SDK security layer 125 will generate an application handler for the application 105.
• the application handler is a unique random number that is generated using any predefined cryptographic algorithm, such as HASH, for example.
• the application handler will be generated by inputting particular values into the predefined cryptographic algorithm. These particular values can be any values associated with the application 105 and/or the registration information for the application 105, such as the application ID, the time that the application 105 is registered, the amount of time that the application 105 can be registered, or the registration status, for example.
• All peripheral device SDK APIs contain an input parameter for an application handler. In one embodiment, a default application handler can be generated and used for APIs that are open to all applications. However, as previously described, the authentication APIs 350 are open to all applications and no application handler is required for accessing these APIs for authentication.
• the peripheral device SDK security layer 125 will register the application 105 in an internal registration table 285 managed by the peripheral device SDK security layer 125 (step 725).
• the internal registration table 285 contains information for authenticated applications and application launchers.
• the peripheral device SDK security layer 125 will record information in the internal registration table 285, such as the application handler, a time out period for the application 105 indicating an amount of time that the authenticated application can remain registered in the internal registration table 285 (e.g. the registration time + the amount of time the application can be registered), the APIs the application 105 can access, or any other information.
• the internal registration table 285 is used to keep track of authenticated applications and application launchers so that those authenticated applications and application launchers do not have to re-authenticate each time a task request is received while the authenticated applications and application launchers are registered in the authentication table.
• the peripheral device SDK security layer 125 checks if the application 105 is 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 will return an error to the application 105 (step 735).
• the peripheral device SDK security layer 125 will return the application handler generated in step 722 to the application 105 (step 738) via the authentication API.
• the peripheral device SDK security layer 125 will also return an indication to the application 105 indicating that the registration was successful, such as status_ok (step 740).
• the status_ok indication lets the application 105 know that the subgroup of APIs specific to the application 105 and needed to perform the task will be exposed for use by the application 105.
• the peripheral device SDK security layer 125 will then expose the subgroup of APIs from the peripheral device SDK 330 to the application 105, such as the subgroup 262 shown in Figure 12.
• This subgroup of APIs will allow the application 105 to communicate with the secure peripheral device 145. However, access to this portion of code is only allowed if the application 105 provides a valid application handler after authentication.
• This subgroup of APIs allows the application 105 to perform the task request by creating the proper link between the application 105 and the secure peripheral device 145.
• Figures 15A-C show examples of process for performing different types of authentication methods supported by the peripheral device SDK security layer 125 (steps 710 and 715 of Figure 14).
• Figure 15A is a flow chart of one example of a process of performing a password-based authentication.
• the application 105 is programmed with a password that can be used for authentication.
• the application 105 accesses the password that the application 105 was programmed to use.
• the application 105 will send the password to the peripheral device SDK security layer 125 via an authentication API.
• the peripheral device SDK security layer 125 will then continue with the process of Figure 14 by checking to see if the password is valid (step 715 of Figure 14).
• FIG. 15B is a flow chart of one example of a process of performing a challenge-response based authentication.
• the application 105 receives a challenge from the peripheral device SDK security layer 125 via an authentication API.
• the form of the API can be void GetChallenge(char*AppID, uchar*challenge, uchar*challengeLen).
• the API GetChallenge may allow the application 105 to provide the peripheral device SDK security layer 125 with its application ID (char*AppID).
• the peripheral device SDK security layer 125 may then return the challenge (uchar* challenge) as well as the length of the challenge (uchar* challenge) to the application 105.
• step 500 the application 105 will calculate a response by inputting the received challenge into a cryptographic function that the application 105 was programmed to use.
• step 555 the application 105 will send the calculated response to the peripheral device SDK security layer 125.
• the peripheral device SDK security layer 125 will also calculate a response using the same challenge in the same cryptographic function (step 560) and compare that calculated response with the response received from the application 105 (step 565).
• This comparison step is how the peripheral device SDK security layer 125 checks if the credential (e.g. the response from the application 105) is valid (step 715 of Figure 14). The registration process of Figure 14 can continue based on this credential.
• FIG 15C is a flow chart of one example of a process for performing a PKI-based authentication of the application 105.
• the application 105 sends a certificate to the peripheral device SDK security layer 125.
• the certificate is part of the credential that is stored with the application 105.
• the application 105 is programmed to provide this certificate through an authentication API.
• step 575 the peripheral device SDK security layer 125 will verify the certificate.
• step 580 if the certificate is valid, the peripheral device SDK security layer 125 will encrypt a randomly generated number with a public key retrieved from the certificate sent by the application (step 570). The random number could be generated and encrypted using the SDK crypto library 168. The encrypted random number is then sent from the peripheral device SDK security layer 125 to the application 105 (step 585).
• step 590 the application 105 will decrypt the encrypted random number received from the peripheral device SDK security layer 125 using a private key associated with the public key used by the peripheral device SDK security layer 125. Authorized applications are able to decrypt the encrypted random number because they have the correct private key.
• step 590 the application 105 will send the decrypted random number to the peripheral device SDK security layer 125 for verification (step 715 of Figure 14). At that point, the process of Figure 14 can be continued.
• Figure 16 depicts a block diagram of an example of the registration process of Figure 12.
• Application 1 107 will first perform an authentication method (step 705 of Figure 12) using the chosen authentication method from the list provided by the peripheral device SDK security layer 125 in step 700 of Figure 14 and send the registration information to the peripheral device SDK security layer 125 within the peripheral device SDK 330 (step 710). If the peripheral device SDK security layer 125 determines that the credential is valid (step 715), the peripheral device SDK security layer 125 will generate an application handler for Application 1 (step722), register Application 1 107 in the internal registration table 285 (step 725), and expose the subgroup of APIs for APP 1 262 to Application 1 107 (step 745).
• Figure 17 depicts an example of software layers for several authenticated applications requesting access to a secure memory device 145.
• Different APIs are accessible based on how the SDK was configured for each application, as described in step 190 of Figure 2.
• Application 1 107 After Application 1 107 has been successfully authenticated with the peripheral device SDK security layer 125 and registered in the internal registration table 285, Application 1 107 will have access to the subgroup of APIs for Application 1 262.
• Application 1 107 may call those APIs to securely store and access protected content on a secure memory device 145, configure the secure memory device 145, etc.
• the APIs for APPl 262 will provide the appropriate interface so Application 1 can perform the requested tasks for protected content through the secure file system 135 and the device driver 140.
• the SDK was configured to provide a full set of functions for access to each of the APIs for APP 1 (see step 190 of Figure 2).
• Application 2 and Application 3 are examples of other applications that have been successfully authenticated with the file system filter 125 and registered in the internal registration table 285.
• Application 2 may access and store protected content through the secure file system 135 and the device driver 140 using the subgroup of APIs for APP 2, such as the secure storage APIs and the DRM APIs, and may also configure the secure memory device 145 using the configure APIs in the SDK.
• Application 2 may not have access to any custom APIs within the SDK.
• the APIs that Application 2 is allowed to access are based on the SDK configuration as described in step 190 of Figure 2.
• Application 3 may access and store protected content through the secure file system 135 and the device driver 140 using the subgroup of APIs for APP 3.
• Application 3 does not have access to the configuration, DRM, and custom APIs within the SDK, as the SDK was not configured to allow Application 3 to access these APIs in step 190 of Figure 2.
• Figure 18 is a flow chart describing one example of how the peripheral device SDK 330 performs the task of storing protected content in the secure memory device 145 (step 525 of Figure 13).
• the peripheral device SDK 330 will direct the secure file system 135 for the secure memory device 145 to locate a place to store the protected content in the secure memory device 145.
• the application 105 may call one of the APIs from the subgroup of APIs that was exposed in step 745 of Figure 14 to provide the desired storage location for the secure file system 135.
• step 905 the peripheral device SDK 330 will access the permissions associated with the storage location where the protected content is to be stored, such as a session key for creating a secure channel 155.
• step 910 the peripheral device SDK 330 will determine whether a secure channel should be used to transfer the protected content based on the permissions accessed in step 905.
• the peripheral device SDK 330 determines that a secure channel should not be used, the protected content will be transferred from the host storage manager 110 on the host device 100 to the secure memory device 145 through an open channel 150 (step 915).
• the application 105 may transfer this content by calling one of the APIs from the subgroup of APIs exposed in step 745 of Figure 14.
• the protected content access manager 320 will access the CEK for the storage location and direct the peripheral device crypto engine 160 to encrypt the content using the CEK and the crypto engine library 235 (step 920).
• the protected content access manager 320 will then store the encrypted protected content in the appropriate storage location (step 925).
• the peripheral device SDK 330 determines that a secure channel 155 should be used, the peripheral device SDK 330 will receive the content from the application 105 through one of the APIs in the subgroup of exposed APIs and direct the SDK crypto engine 168 to encrypt the protected content within the host device 100 using the session key and the appropriate cryptographic scheme (step 930).
• the encrypted content will be transferred from the host storage manager 110 on the host device 100 to the secure memory device 145 through a secure channel 155.
• the peripheral device crypto engine 160 will then decrypt the transferred protected content in the secure memory device 145 and the crypto engine library 235 (step 940).
• the protected content access manager 320 will access the CEK for the storage location where the protected content is to be stored and direct the peripheral device crypto engine 160 to encrypt the content using the CEK and the crypto engine library 235.
• the protected content access manager 320 will then store the encrypted protected content in the appropriate storage location (step 925).
• Figure 19 is a flow chart describing one example of how the peripheral device SDK security layer 125 performs the task of accessing protected content stored in the secure memory device 145 (step 525 of Figure 13).
• the peripheral device SDK security layer 125 will direct the secure file system 135 to locate the requested protected content in the appropriate location of the secure memory device 145.
• the application 105 may call one of the APIs from the subgroup of APIs that was exposed in step 745 of Figure 14 to provide the desired storage location for the secure file system 135.
• the protected content access manager 320 accesses the permissions associated with the location of the protected content, including the CEK and the session key (step 805).
• the secure content access manager 320 then accesses the protected content from the location in the secure memory device 145 (step 810) and directs the peripheral device crypto engine 160 to decrypt the content using the CEK and the crypto engine library 235 (step 815).
• step 820 the protected content access manager 320 then determines whether the protected content should be transferred to the host storage manager 110 on the host device 100 using a secure channel. If the session key accessed in step 805 indicates that the protected content should be transferred using an open channel 150, the protected content access manager 320 will transfer the content to the host storage manager 110 on the host device 100 through the open channel 150 (step 825).
• the protected content access manager 320 determines that the protected content should be transferred to the host storage manager 110 on the host device 100 using a secure channel 155
• the protected content access manager 320 will direct the peripheral device crypto engine 160 to encrypt the protected content within the secure memory device 145 using the session key (step 830).
• the protected content access manager 320 will then transfer the encrypted protected content to the host storage manager 110 on the host device 100 through the secure channel 155 (step 835).
• the SDK crypt library 168 will be used to decrypt the protected content using the same session key (step 840).
• FIG. 20 is a flow chart describing one example of how the application 105 is unregistered from the internal registration table 285 in the peripheral device SDK security layer 125 (step 530 of Figure 13). In step 945, the peripheral device SDK security layer 125 will check to see if the task has been completed.
• the peripheral device SDK security layer 125 will clean the registration table 285 of any information associated with the application 105 (step 970). The peripheral device SDK security layer 125 will then unregister the application 105 from the internal registration table 285 (step 975).
• the step of unregistering the application 105 can be performed by calling the appropriate API, such as uchar UnRegisterApplication(char*AppID), for example. This API will unregister the application 105 by removing the corresponding application ID from the internal registration table 285. The process of performing the requested task is then ended (step 980).
• the peripheral device SDK security layer 125 checks to see if the application 105 has been registered for the amount of time indicated in the internal registration table 285 for the time out period (step 950). If the time out period has passed, the peripheral device SDK security layer 125 will clean the registration table 285 of any information associated with the application 105 (step 955). The peripheral device SDK security layer 125 will then request re-authentication of the application 105 (step 960). An authentication process similar to Figure 14 can be used for re-authentication of application 105. The peripheral device SDK security layer 125 will determine if the re- authentication was successful (step 965).
• the peripheral device SDK security layer 125 will unregister the application 105 from the internal registration table 285 by calling the appropriate API, such as uchar UnRegisterApplication(char*AppID) (step 975). This API will unregister the application 105 by removing the corresponding application ID from the internal registration table 285. The process of performing the task will then end (step 980).
• the appropriate API such as uchar UnRegisterApplication(char*AppID)
• step 950 the peripheral device SDK security layer 125 determines that the time out period in the internal registration table 285 has not passed, the peripheral device SDK security layer 125 will continue performing the task request in step 525.

Landscapes

• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• Computer Hardware Design (AREA)
• General Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• Physics & Mathematics (AREA)
• Software Systems (AREA)
• Databases & Information Systems (AREA)
• Health & Medical Sciences (AREA)
• Bioethics (AREA)
• General Health & Medical Sciences (AREA)
• Storage Device Security (AREA)

Priority Applications (3)

Applications Claiming Priority (4)

Publications (1)

Family

ID=40844807

Family Applications (1)

Country Status (6)

Cited By (4)

Families Citing this family (4)

Citations (5)

Family Cites Families (5)

• 2009
  • 2009-04-30 KR KR1020107026110A patent/KR20110033112A/ko not_active Application Discontinuation
  • 2009-04-30 JP JP2011510489A patent/JP2011523481A/ja active Pending
  • 2009-04-30 EP EP09750920A patent/EP2294528A1/de not_active Withdrawn
  • 2009-04-30 CN CN200980127311.1A patent/CN102089765A/zh active Pending
  • 2009-04-30 WO PCT/US2009/002637 patent/WO2009142689A1/en active Application Filing
  • 2009-05-19 TW TW98116598A patent/TW201003457A/zh unknown

Patent Citations (5)

Also Published As

Similar Documents

Legal Events