JP2010532024A - Memory device using time from trusted host device and method for use in the device - Google Patents

Abstract

  A memory device that uses time from a trusted host device and a method for use in the device are disclosed. In one embodiment, an application on the memory device receives a request to perform a time-oriented operation from an entity that executes on the host device and is authenticated by the memory device. The application selects the time from the host device instead of the time from the time module on the memory device when executing the time-oriented operation, and uses the time from the host device when executing the time-oriented operation. Other embodiments are also disclosed, but each of these embodiments can be used alone or in combination.

Description

  The present application relates to a memory device that uses time from a trusted host device and a method for use in the device.

CROSS-REFERENCE TO RELATED APPLICATIONS This application is filed with the present application, which is incorporated by reference herein, "Method for Improving Accuracy of a Time Estimate from a Memory Device " of U.S. Patent Application No. 11 / 811,284 (Patent Reference 1), US Patent Application No. 11 / 811,347 (Patent Reference 2), “Memory Device with Circuitry for Improving Accuracy of a Time Estimate”, “Method for Improving Accuracy of a Time Estimate Used to Authenticate an Entity to a” US Patent Application No. 11 / 811,289 entitled “Memory Device” (Patent Document 3), US Patent Application No. 11 / 811,344 entitled “Memory Device with Circuitry for Improving Accuracy of a Time Estimate Used to Authenticate an Entity” Patent Document 4), US Patent Application No. 11 / “Method for Improving Accuracy of a Time Estimate Used in Digital Rights Management (DRM) License Validation” No. 811,354 (Patent Document 5), US Patent Application No. 11 / 811,348 (Patent Document 6) “Memory Device with Circuitry for Improving Accuracy of a Time Estimate Used in Digital Rights Management (DRM) License Validation”, US Patent Application No. 11 / 811,346 entitled “Method for Using Time from a Trusted Host Device” and US Patent Application No. 11 / 811,345 called “Memory Device Using Time from a Trusted Host Device” No. (Patent Document 8).

  In order to perform time-oriented operations such as digital rights management (DRM) license verification in a memory device such as SanDisk Corporation's TrustedFlash (registered trademark), it is necessary to know the time. Due to security issues associated with such operations, the memory device may not trust the host device in providing the correct time. Although the memory device can obtain accurate time from trusted network components, the host device that hosts the memory device may not be connected to the network when the memory device needs to know the time. Generated from the measured operating time if the memory device can be designed to measure the operating time of the memory device, but the memory device does not constantly measure the operating time (such as when the memory device is powered off after the measurement is started) The estimated time is not a true real time measurement. The time estimate generated from the measured operating time is actually just a lower limit of the operating time, and such time estimation may not provide the accuracy required for certain time-oriented operations. To keep track of time even when the memory device is not operating, the memory device can be equipped with a battery-powered clock, but such a clock can add to the cost of the memory device. .

US patent application Ser. No. 11 / 811,284 US patent application Ser. No. 11 / 811,347 US patent application Ser. No. 11 / 811,289 US patent application Ser. No. 11 / 811,344 US patent application Ser. No. 11 / 811,354 US patent application Ser. No. 11 / 811,348 US patent application Ser. No. 11 / 811,346 US patent application Ser. No. 11 / 811,345 US patent application Ser. No. 11 / 314,411 US patent application Ser. No. 11 / 557,028 US patent application Ser. No. 11 / 322,812 US patent application Ser. No. 11 / 322,766

The present invention is defined by the following claims, and nothing in this section should be construed as limiting the scope of the claims.
The embodiments described below for introduction provide a memory device that uses time from a trusted host device and a method for use in that device. In one embodiment, an application on the memory device receives a request to perform a time-oriented operation from an entity that executes on the host device and is authenticated by the memory device. The application selects the time from the host device instead of the time from the time module on the memory device when executing the time-oriented operation, and uses the time from the host device when executing the time-oriented operation. In another embodiment, an authentication request for an entity executing on the host device is received. When authenticating an entity, an authentication method specified by an access management record (ACR) that associates the entity with an application in the memory device and a time from a time module on the memory device are used. A request for executing a time-oriented operation on an application is received from an entity. When executing the time-oriented operation, the time from the host device is selected instead of the time from the time module, and when executing the time-oriented operation, the time from the host device is used. In yet another embodiment, the memory device compares the time received from the second host device with the accumulation time from the first host device, and executes the time-oriented operation based on the comparison. Decide whether to use the time from the device or the accumulation time from the first host device. In another embodiment, the memory device authenticates the host device using a non-time based authentication system, receives time from the host device, and uses the time received from the host device to perform the time based operation. Other embodiments are also disclosed, but each of these embodiments can be used alone or in combination.

1 is an illustration of a system of one embodiment. 1 is a block diagram of a memory device according to an embodiment. 3 is an illustration of various functional modules of the memory device of FIG. FIG. 3 is a protocol diagram of an asymmetric authentication process of an embodiment. FIG. 3 is a system diagram of an embodiment for obtaining a time stamp. 6 is a flowchart of an embodiment method for obtaining a time stamp. 6 is a flowchart of a method of an embodiment for checking a time stamp update policy. FIG. 4 is an illustration of an embodiment of a memory device that uses host time for applications executing on the memory device.

  Returning to the drawings, FIG. 1 is an illustration of a system 10 used to illustrate these embodiments. As shown in FIG. 1, the system 10 includes a plurality of memory devices 20, 30, 40 that are detachably connected to a plurality of host devices, a personal computer (PC) 50, and a digital media (MP3 etc.) player 60. And a mobile phone 70. The host device is a device that can read data from the memory device and / or a device that can write data to the memory device. Data includes, but is not limited to, digital media content such as audio files and video files (with or without audio), images, games, books, maps, data files, or software programs. Data may be downloaded from a network server to a memory device, preloaded by a manufacturer or third party, or side loaded from another device, for example.

  The host device can take any suitable form and is not limited to the example seen in FIG. For example, the host device may be a notebook computer, a handheld computer, a handheld email / text message device, a handheld game console, a video player (DVD player, portable video player, etc.), a recording and / or recording device, a digital camera, It can take the form of a set-top box, a display device (such as a television), a printer, a car stereo, and a navigation system. Further, the host device can incorporate a composite function. For example, the host device is a mobile phone that can make and receive calls and can play back digital media (music and / or video) files.

  A host device such as the PC 50 or the mobile phone 70 can have the ability to connect to and communicate with a network (such as the Internet 80 or the wireless network 90, but other types of networks can also be used). In the present specification, a host device having such a capability is referred to as a “connection device”. It should be understood that the “connection device” is not always actually connected to the network, such as when the mobile phone 70 is operating in the disconnected mode or when the PC 50 has not established an Internet connection. It is. In the present specification, a host device (such as the digital media player 60) that does not have the ability to communicate by connecting to a network is referred to as a “non-connection device”. By connecting the unconnected device to the connected device, the unconnected device can be placed in communication with the network, and the digital media player 60 is connected to the PC 50 as seen in FIG. Even when connected in such a manner, information cannot be extracted from the network unless a function for extracting information from the network is provided in the unconnected device (such as a simple MP3 player). Even in such a situation, the network component can push information to the device. Although FIG. 1 shows a digital media player 60 connected to the PC 50 via a wired connection, it should be noted that a wireless connection can also be used. Similarly, the terms “connected” and “coupled” do not necessarily mean a wired connection or a direct connection.

  A connection device (or a non-connection device connected to the connection device) can access an external component through a network (Internet 80, wireless network 90, etc.). , Including, but not limited to, a digital rights management server (DRM) 110 that can provide DRM protected content and a license for accessing such content. These servers will be described in detail below. In FIG. 1, the time server 100 and the DRM server 110 are shown as separate devices, but two servers can be combined into one device. Furthermore, other functions can be incorporated into these servers. If necessary, components other than the time server 100 and the DRM server 110 can be accessed via the Internet 80 or the wireless network 90.

  Returning to the drawing, FIG. 2 is a block diagram of a memory device 200 according to one embodiment, which may take the form of a memory card or memory stick. As shown in FIG. 2, the memory device 200 includes a non-volatile memory array (such as a flash memory) 210 and a group of circuits 220. The non-volatile memory array 210 of this embodiment takes the form of a solid state memory, specifically a flash memory 210. It should be noted that different types of solid state memory can be used instead of flash memory. It should also be noted that memories other than solid state memory can be used, including but not limited to magnetic disks and optical CDs. Also, for the sake of brevity, the term “circuit” as used herein refers to a pure hardware implementation and / or a combined hardware / software (or firmware) implementation. That is, the “circuit” may take the form of an application specific integrated circuit (ASIC), a programmable logic controller, an embedded microcontroller, a single board computer, etc., as well as a processor and computer readable program code executable by the processor. It may take the form of a computer readable medium for storing (software, firmware, etc.).

  The group of circuits 210 of FIG. 2 includes a plurality of components: a host interface module (HIM) 230, a flash interface module (FIM) 240, a buffer manager (BMU) 250, a CPU 260, and a hardware timer block 270. With. The HIM 230 provides an interface function for the host device 300, and the FIM 240 provides an interface function for the flash memory 210. The BMU 250 includes a crypto engine 252 that provides encryption / decryption functions, a host direct memory access (DMA) component 254 that communicates with the HIM 230, and a flash DMA component 256 that communicates with the FIM 240. The CPU 260 executes software and firmware stored in the CPU RAMS 260 and / or the flash memory 210. The hardware timer block 270 will be described below in relation to the time measurement capability of the memory device.

  To simplify the drawing, other components of the memory device 200 such as electrical and physical connectors for removably connecting the memory device 200 to the host device 300 are not shown in FIG. The memory device 200 and its operation are described in US patent application Ser. No. 11 / 314,411 (patent document 9) and US patent application Ser. No. 11 / 557,028, which are incorporated herein by reference. You can check the details at. Additional information can be found in US patent application Ser. No. 11 / 322,812 (Patent Document 11) and US Patent Application No. 11 / 322,766 (Patent Document 12), which are hereby incorporated by reference. However, the components and functions described in these patent applications should not be construed within the scope of the appended claims, unless explicitly stated in the appended claims.

  In this embodiment, the memory device 200 stores a digital rights management (DRM) key and a license to unlock the protected content stored in the memory device 200. (It should be noted that these embodiments are also useful for memory devices that do not store DRM keys and licenses to unlock protected content stored in the memory device.) DRM keys and DRM licenses are memory In addition to being generated by the device 200, it can be generated by other than the memory device 200 (DRM server 110 or the like) and transmitted to the memory device 200. Since the DRM key and DRM license move with the memory device 200, the protected content is effectively tied to the memory device 200, not the host device 300, and the protected content is portable and authorized. Any host device that can prove to the memory device 200 can access the protected content. SanDisk Corporation's memory device TrustedFlash (registered trademark) is an example of a memory device in which a DRM key and a DRM license are stored in the memory device, and protected content can be moved together with the memory device. In some embodiments, the memory device 200 verifies the DRM license using the DRM key stored in the memory device 200. In another embodiment, a DRM key is provided from the memory device 200 to the host device 300, and DRM license verification using the DRM key is left to the host device.

  In this embodiment, CPU 260 executes a secure storage application (SSA) to limit access to DRM keys and DRM licenses to authorized entities with appropriate credentials. The SSA computer readable code can be stored in the flash memory 210 and the CPU RAMS 262 and can be stored in another storage location of the memory device 200. SSA is described in more detail in previously referenced US patent application Ser. No. 11 / 557,028. FIG. 3 is an illustration of various functional modules of the memory device 200 used to illustrate SSA operation. As can be seen in FIG. 3, the memory device 200 comprises various access management records (“ACR”). That is, the first asymmetric ACR 201, the second asymmetric ACR 202, and the symmetric ACR 203 are provided. The first and second asymmetric ACRs 201 and 202 have first and second time update policies (TUP1 and TUP2), which will be described in detail later. Although a number of ACRs are seen in FIG. 3, the memory device 200 may accommodate only one ACR.

  ACRs 201, 202, and 203 specify the authentication method to be used and what kind of credentials are required to verify the identity of the entity. Authority for executing various actions such as access to the DRM key and license is also recorded in the ACRs 201, 202, and 203. If the entity is successfully authenticated by the ACR, the SSA system releases the session and can execute the ACR action. As used herein, the term “entity” refers to a person or object attempting to access the memory device 200. For example, the entity may be an application executed on the host device, the host device itself, or a human user. In FIG. 3, three entities, a media (audio and / or video) player 301, a storage application 302, and another application 303 attempt to access the memory device 200. These entities 301, 302, and 303 may be located on the same host device, or may be located on different host devices. Each entity 301, 302, 303 is associated with a specific ACR (ACR 201, 202, 203). Another entity (not shown) can be associated with any of ACRs 201, 202, and 203.

  When the entity initiates the login process, it sends an authentication request including the appropriate ACR identifier. The ACR specifies the authentication method to be used and what kind of credentials are required to establish the identity of the entity. ACRs 201 and 202 in FIG. 3 specify an asymmetric authentication method, and ACR 203 specifies a symmetric authentication method. Note that another authentication method (password method procedure or the like) can be used, and the ACR can specify that authentication is not required. In addition to specifying a particular authentication method, a privilege management record (PCR) can be placed in the ACR that describes the actions that can be performed on the authenticated entity.

  Some authentication mechanisms (eg, one-way and two-way asymmetric authentication used for X.509 certificate chain authentication, etc.) are time based, and the memory device 200 knows the time for checking the credentials presented by the entity. There is a need. (In the case of the symmetric authentication mechanism of the symmetric ACR 203, it is not necessary to know the time in the memory device 200. In the symmetric authentication, the entity is authenticated using a key shared between the entity and the corresponding ACR.) It may take time to evaluate credentials such as RSA certificates and / or certificate revocation lists (CRLs) provided by entities with asymmetric authentication. (As used herein, “certificate” may refer to a single certificate or multiple certificates (such as a series of certificates), and “CRL” may refer to a single CRL or multiple CRLs. Before explaining the mechanism for generating the time estimate in the memory device 200 when performing verification, a certificate and CRL for asymmetric authentication will be briefly described.

  In a public key infrastructure (PKI) system used for asymmetric authentication, a trusted authority called a certificate authority (CA) issues an RSA certificate that proves the identity of an entity. An entity that wants to prove its identity prepares enough evidence to register this and registers it with the CA. Once the identity of the entity is verified at the CA, a certificate is issued from the CA to the entity. The certificate is usually the name of the CA that is the certificate issuer, the name of the entity that is the certificate issuer, the public key of the entity, and the public key of the entity signed by the CA private key (usually the public key). Encryption).

  A data field for holding an expiration date can be provided in the certificate. In this case, the time that the entity that owns the certificate can access the content is limited (until the certificate expires). A data field that holds the future effective date can be provided in the certificate. In this case, entity authentication by ACR is not performed until the certificate becomes valid. When the memory device 200 determines that the current date has passed the expiration date or has not reached the effective date (that is, if the memory device 200 determines that the certificate is not valid), the entity presenting the certificate Is not authenticated.

  Certificates can be revoked before their expiration date in various ways (eg, name changes, entity and CA relationship changes, private key infringement or alleged infringement, etc.). In such a case, the CA needs to revoke the certificate. Specifically, the CA periodically issues a certificate revocation list (CRL). A CRL is a signed data structure that contains a time-stamped list of revoked certificates. Accordingly, the memory device 200 not only checks whether the certificate is timely for entity authentication, but also checks the CRL to check whether the certificate is registered in the CRL. (The CRL may be provided from the entity together with the certificate, or the memory device 200 may acquire the CRL itself (for example, if the memory device 200 is a connection device, it is acquired through the Internet 80).) The certificate registered in is no longer valid (even if it has not expired) and the entity is not authenticated. Like certificates, CRLs also have an expiration date. This expiration date indicates the CRL update time, and thus the latest CRL is thoroughly used in the memory device 200. If the memory device 200 finds that the current time has passed the validity period of the CRL during authentication (when the memory device 200 determines that the CRL is invalid), the CRL is considered to have a problem and the certificate We do not use for inspection of as much as possible.

  As described above, the memory device 200 of this embodiment needs to know the time for checking the credential (certificate and CRL in this specification). There are several options for making the memory device know the time. As one option, whenever it is necessary to know the time in the memory device, a time stamp is requested from the memory device to a trusted time server through the host device. Although this is a method suitable for a connected device, the memory device may be used by a disconnected device in addition to the connected device (for example, disconnected from a home PC, MP3 player, or network that is not connected to the Internet). If you need to know the time in the authentication procedure of the mobile device (such as when you are on a plane)) or memory device, it is not reliable. Another option is to equip the memory device with a battery-powered clock. However, this adds cost to the memory device, which is undesirable in some cases. Another option relies on the host device to provide time to the memory device (provided by the host device's own internal clock or an external source). However, in many cases, the memory device cannot rely on the host device to provide accurate time. If the user can “delay” the host device clock (ie, the host device clock can be set to a time earlier than the current time), the user must bypass the time limit that needs to be enforced on the memory device. Can do. On the other hand, if the host device can be trusted by the memory device (or application executing on the memory device), the memory device (or application executing on the memory device) can rely on the host device time. Details on when host time is available will be provided later.

  Another option employed in this embodiment utilizes the limited time tracking capability of the memory device, specifically the ability to measure the operating time of the memory device 200. The operation time may refer to a time when the memory device 200 is connected to the host device and is actually used (that is, between the memory device 200 and the host device 300 as opposed to an idle state or a sleep mode). Time when there was activity on the bus). Alternatively, the operation time may indicate the total time that the memory device 200 is connected to the host device 300 and receives power from the host device 300. In the present specification, the terms “operation time” and “use time” are used interchangeably. As will be described later, in this embodiment, the hardware timer block 270 can generate a clock tick as an interrupt to the CPU 260, and it is assumed that the memory device 200 is operating when the CPU 260 can increase the operating time counter.

  During operation, an oscillator built in the hardware timer block 270 (such as an ASIC controller) generates a periodic clock tick and provides the tick to the CPU 260 as an interrupt. (This oscillator preferably operates at a very low frequency when the CPU 260 is in a sleep state.) That is, the hardware timer block 270 interrupts the CPU 260 periodically (every millisecond, every microsecond, etc.). When CPU 260 receives an interrupt, a dedicated clock interrupt service routine is called (eg, executed in firmware by CPU 260), which adds one period / unit to the operating time counter. Since the counter value is stored not only in the CPU RAMS 262 but also in the nonvolatile flash memory 210, it is not lost even if a power failure occurs. To avoid excessive consumption of memory 210, the memory 210 uptime counter is not updated every clock tick, but periodically (eg, every minute while the memory device is powered on). It is preferable to update. In this case, if a power failure occurs before the operating time counter is updated, the measurement time accuracy may be further reduced. However, if the merit for memory durability is taken into consideration, it can be regarded as an acceptable price. (To further protect the endurance of the memory, it is possible to provide a field for transmitting the number of writes to the counter in the value accumulated in the operating time counter. If this write value exceeds a certain amount, the memory The counter can be stored at the position of .If the bit in the counter contributes to durability, the bit can also be shifted.) (In addition to the power consumption for writing) It is preferable that the writing does not hinder the performance of the memory device 200 and normal activities. (In other words, writing to the time counter is preferably part of the host command processing process.) For example, writing to the operating time counter is a background task that is executed before processing the host device command. You can also When the host device command ends, the firmware of the memory device 200 reads data from the memory and compares it with a desired value, thereby confirming that the operation time counter has been successfully programmed.

  Further, the value of the operating time counter is preferably stored securely in the memory 210 so as not to be easily tampered (for example, the key engine is signed by the crypto engine 252 using a key hash message authentication code (HMAC)). If the signatures do not match, the data has been altered by an attacker and can be treated as uninitialized data. In addition, it should be noted that other uptime measurement mechanisms can be used.

  In order to convert the value accumulated in the operating time counter into the actual time, the CPU 260 multiplies the accumulated value by the frequency with which the hardware timer block 270 generates clock ticks. For example, if the value 500 is accumulated in the operating time counter and the hardware timer block 270 generates a clock tick every 5 milliseconds, the CPU 260 calculates an operating time of 2,500 milliseconds (500 × 5). In generating the time estimate, the converted operation time is added to the latest time stamp that has arrived at the memory device 200 from a reliable supplier. In other words, the time stamp serves as a “start line”, and the measured operating time of the memory device is added to this time stamp. The time stamp can be of any format and can display the time with any precision (year, month, day, hour, minute, second, etc.). The time stamp is preferably provided from an entity (time server 100, trusted host device, etc.) that the memory device 200 trusts in providing precise time. The timestamp can be in any format and can be sent alone or included in other information. In order to prevent time stamps from being easily tampered with, the memory device preferably stores the time stamps securely via the crypto engine 252. When a new time stamp arrives at the memory device 200, the new time stamp is stored in the memory device 200, and the operating time counter is reset. Therefore, after that, the operation time is measured based on the new time stamp instead of the old time stamp. Instead of resetting the counter ("undo") to measure uptime, the uptime counter value present at the time of the new timestamp can be recorded and subtracted from the current time.

  Now that the time tracking capability of the memory device has been described, an example of an authentication procedure will now be described. Returning to the drawing, FIG. 4 is a protocol diagram of an asymmetric authentication process of one embodiment. In the following example, the player 301 tries to log in to the memory device 200 through the ACR 201. As will be described in detail later, the player 301 holds credentials (RSA key pair, certificate, certificate revocation list (CRL), etc.), and the ACR 201 verifies the authenticity of the player 301 and grants rights to the object. (In this case, a secure channel is established between the player 301 and the DRM module 207). As seen in FIG. 4, in the first step, the host device 300 transmits an authentication request for the player 301 to the memory device 200 (act 402). If the time stamp is not yet installed in the memory device 200, the memory device 200 responds to the authentication request with a login failure message (act 404).

  In a series of subsequent acts, the process of providing a time stamp to the memory device 200 will be described in relation to FIGS. These figures are a system diagram and a flowchart illustrating one method by which the memory device 200 can obtain a time stamp. It should be understood that the memory device 200 can obtain the time stamp in other ways, and that the time stamp can take other forms. It should also be understood that a single memory device can process multiple formats simultaneously in conjunction with multiple servers or hosts. Accordingly, the specific details of this example should not be construed in the appended claims unless explicitly set forth in the appended claims.

  As shown in FIG. 5, the memory device 200 communicates with the host device 300 through the memory device-host device communication channel 305, and the host device 300 communicates with the time server 100 through the host device-time server communication channel 315. Although the time server 100 may be a single server, the time server 100 of this embodiment includes a plurality of servers 102, 104, and 106 that are synchronized with each other via the inter-server communication channel 325. Also, as pointed out earlier, instead of using the time server 100 for time stamping, the time stamp of the host device 300 can also be used, which is preferably the host device 300 is trusted host Only if it is a device.

  In this embodiment, the time stamp request procedure starts when the host device 300 transmits a nonce acquisition command to the memory device 200 (act 405) (see FIGS. 4, 5 and 6). The nonce in this embodiment is a 16-bit random number used when the memory device 200 verifies the authenticity of the time stamp generated by the time server 100 later. The memory device 200 generates a random number (nonce) (act 410) and stores it in the CPU RAMS (volatile memory) 262 (or memory 210) for subsequent verification steps. Next, the memory device 200 transmits a nonce to the host device 300 (act 415). The memory device 200 also starts measuring time (to be described later) in order to confirm the presence or absence of a timeout later.

  Receiving the nonce, the host device 300 transmits a time stamp acquisition request including the nonce to the time server 100 (act 420). The time server 100 signs the time (universal time in UTC Coordinated Universal Time format) and nonce with the secret key. Next, the time server 100 transmits a time stamp response (act 425). (Note that this certificate and CRL transmitted from the time server 100 are for authenticating the time server 100, and are different from the certificate and CRL transmitted for authenticating the player 301. The time stamp response in this embodiment includes a nonce, a time stamp, a certificate chain, and a certificate revocation list (“CRL”) chain. The host device 300 transmits the time update command and this response to the memory device 200 (act 430). In response to this command, the memory device 200 attempts to verify the certificate and the CRL (act 435). (To be repeated, this certificate and the CRL are different from those transmitted for authentication of the player 301.) As will be described later, the certificate of the time server 100 in light of the time estimation generated by the memory device 200. It may be preferable to assume that the certificate of the time server 100 and the validity period of the CRL have not expired, rather than checking the validity of the certificate and the CRL. If this verification fails, the memory device 200 resets the volatile memory 262 and returns to the idle process (act 440). If the certificate and CRL verification is successful (act 445), the memory device 200 compares the nonce in the response with the nonce in the volatile memory 262 (act 450). If this comparison fails, the memory device resets the volatile memory 262 and returns to the idle process (act 455). If the comparison is successful, the memory device 200 stores the new time stamp in the memory 210, preferably in a secure manner to prevent tampering.

  When the memory device 200 generates a nonce (410) and is waiting for a response (act 460), another nonce acquisition command can be sent from the host device 300 to the memory device 200 (act 465). It should be noted. As described above, the memory device 200 starts time measurement after generating the nonce. If the memory device 200 receives a new nonce command (465) before its measurement time reaches a specific timeout limit, the memory device 200 preferably ignores the new nonce command (465). However, if the memory device 200 receives a new nonce command (465) after the timeout limit, the memory device 200 resets the volatile memory 262 and generates a new nonce (act 470). Accordingly, the nonce is valid within a limited time, and the timeout limit (“travel time error”) corresponds to the maximum time that the memory device 200 waits for a time stamp to arrive from the time server 100.

  Since the time stamp accumulated in the memory device 200 is the time when the time server 100 signs the data character string, it depends on the accuracy of the time stamp (year, month, day, hour, minute, second). The time stamp time may not be the actual time when the host device 300 requests the time stamp. Alternatively, the memory device 200 may not be the actual time when the time stamp is accumulated. The nonce timeout period described above can be set so that the accuracy of the time stamp meets the requirements of the memory device 200. Accordingly, the maximum allowable delay of the time stamp request is controlled by the memory device 200. In an alternative embodiment, another time can be displayed with a time stamp generated by the time server 100, for example, an estimated time when the host device 300 requests a time stamp, or an estimated time for time stamp accumulation in the memory device 200. Can be displayed.

  In the case of the protocol described above, the memory device 200 communicates with the time server 100 via a connection system (Internet, WiFi network, GSM network, etc.) whose safety is not guaranteed. A connection system whose security is not guaranteed means that the memory device 200 cannot determine that there is no tampering during the transmission of the time stamp transmitted by the time server 100. Since the network cannot rely on protecting the time stamp, the above-described protection mechanism (or some other protection mechanism) can be used between the time server 100 and the memory device 200. If the encryption protocol is used, the memory device 200 can detect tampering when the time stamp is tampered. In other words, if the connection system is not secure, the connection system itself cannot prevent the time stamp bits from being changed by someone, but the memory device 200 may detect tampering and reject the time stamp. it can. An alternative embodiment uses a secure communication system (ie, the data communication line is protected). In this case, since no one can falsify the time stamp, the time stamp can be transmitted in plain text.

  Returning to FIG. 4, a new time stamp is stored in the current memory device 200, the memory device 200 returns a “time update success” message to the host device 300 (act 452), and the host device 300 once again stores the authentication request in the memory. It transmits to the apparatus 200 (act 454). Since the memory device 200 has a time stamp, the memory device 200 checks the time stamp update policy (TUP) of the ACR 201 (act 500). Since time estimation is based on time stamps, putting time estimations on old time stamps can lead to inaccurate time estimations. Therefore, it is determined from the TUP whether the time stamp in the memory device 200 is old and needs to be updated (new time stamp). As will be described in detail later, the TUP may vary depending on the ACR as shown in FIG. 3 (the time tolerance varies depending on the ACR), and can be set when the ACR is created.

  In this embodiment, there are four values: (1) power cycle number, (2) operating time threshold, (3) “extension” operating time threshold, and (4) parameters are OR related. A TUP is represented by a bit indicating whether or not there is a parameter (requiring time update when even one parameter is disqualified for checking, or requesting time updating only when all parameters are disqualified for checking). These parameters will be described in detail later. (It should be noted that other parameters may be considered in addition to or instead of these parameters.)

  FIG. 7 is a flowchart showing further details of the TUP check act (act 500). First, it is determined whether or not the memory device 200 has been initialized for the TUP check (act 505). For example, the setting data stored in the memory 210 is checked. If the memory device 200 has not been initialized for the TUP check, the memory device 200 generates a time estimate using the last received timestamp (act 510) and attempts to authenticate the entity using the time estimate. . If the memory device 200 is initialized for the TUP check, the memory device 200 starts the TUP check.

  First, the memory device 200 determines whether or not the TUP includes a check of the number of power cycles of the memory device 200 after the last time stamp (act 515). In this embodiment, this is accomplished by checking the “power cycle” value described above. If the “power cycle” value is 0, the power cycle count is not checked. If the “power cycle” value is other than 0, the value is used as a threshold value to check the number of power cycles. The power cycle number is a count of the number of times the memory device 200 is turned on. From this number, the number of times the memory device 200 is turned off after the final time stamp is known (that is, every time the power is turned on, Each time you turn off the power). The power cycle number can be measured by the CPU 260. Each time the memory device 200 passes a power cycle, the CPU 260 can invoke a device reset routine in firmware. Similar to the case where the CPU 260 adds one unit to the operating time counter, this device reset routine causes the CPU 260 to add one unit to the CPU RAMS 262 and / or the power cycle counter of the memory 210. In order to suppress memory consumption, the power cycle counter can be updated periodically as well as the operation time counter.

  When the memory device 200 is turned off, at least some real time is not reflected in the operating time (because the operating time cannot be measured when the memory device 200 is not “operating”). Since the memory device 200 does not know how much time has passed between power cycles, it cannot grasp how much the measurement operation time is incorrect from the number of power cycles. However, whether or not the usage of the memory device 200 deviates from the assumed usage pattern can be grasped to some extent from the number of power supply cycles. Furthermore, it can be roughly understood how much the measurement operation time is incorrect. For example, the time estimate when the memory device 200 has 10 power cycles from the last time stamp may not be more accurate than the time estimate when the memory device 200 has only one power cycle from the last time stamp. There is.

  When the power cycle count check is included in the TUP, the memory device 200 checks the power cycle count of the memory device 200 after the last time stamp, and the threshold value is set to the “power cycle” value. It is confirmed whether or not the value is exceeded (act 520). This threshold can be set for each ACR depending on the desired time tolerance. For example, this threshold can be set to 1 if it is necessary to reliably verify that a certificate or CRL has not expired with very sensitive authentication. In this case, if the power supply of the memory device 200 has been turned off even once (accordingly, at least a certain amount of time cannot be counted in the measurement operation time), the TUP check of this parameter ends in failure. On the other hand, if the authentication is not so sensitive, the number of power cycles can be set to a high value (or this is not considered at all). In this case, the TUP check passes even if there are some power cycles (even if there is some time not counted in the measurement operation time).

  If the power cycle count check ends in failure and the OR relationship is determined by the TUP parameter (act 525), the TUP check ends in failure (act 530). The memory device 200 transmits a message indicating failure to the host device 300, and acquires a new time stamp by the above-described procedure. If the power cycle count check is passed, or if it is determined that the TUP parameter is not OR-related even if it is disqualified (Act 525), the process continues and the operation time check after the last time stamp is included in the TUP. It is determined whether or not (ACT 535).

  Similar to the power cycle procedure described above, if the “operating time” value is 0, the operating time is not checked. However, if the “operation time” value is other than 0, the value is used as a threshold value in seconds (or some other time unit) to check the operation time. Similar to the number of power cycles, the operating time threshold can be set for each ACR depending on the desired time tolerance. In general, the longer the operation of the memory device 200, the higher the likelihood that the measurement operation time will be inaccurate. Therefore, if it is necessary to reliably verify that the certificate or CRL has not expired with very delicate authentication, the threshold for the measurement operating time can be set very low. Conversely, if the authentication is not sensitive, the measurement uptime threshold can be set higher (or not considered at all).

  If the operating time check ends in failure and the OR relationship is determined by the TUP parameter (act 545), the TUP check ends in failure (act 550). The memory device 200 transmits a message indicating failure to the host device 300, and acquires a new time stamp by the above-described procedure. If the uptime check is passed, or if it is found that the TUP parameter is not OR-related even after disqualification (act 545), the process continues and whether or not the “extension” uptime check is included in the TUP. Is determined (act 555).

  As pointed out earlier, if the memory device 200 does not constantly measure the operating time, the measured operating time may not be a true actual operating time. That is, if the memory device 200 is “not operating” (for example, if the memory device 200 is in an idle state or a sleep mode, or if the memory device 200 is not powered on, the memory device 200 is removed from the host device 300). In any case, in this embodiment, the generation of clock ticks by the hardware timer block 270 is stopped and / or the CPU 260 stops responding to ticks), the time elapses when not running Since there is no way to know that the memory device 200 is doing, the measured operation time is less than the actual time that has elapsed since the start of measurement. For example, it is assumed that a time stamp is received on January 1 and the memory device 200 measures the operating time for two days. (For simplicity, this example measures time in days. However, as described above, any desired time unit can be used.) At this time, the date of the time estimate generated by the memory device 200 is 1. It will be the 3rd of the month (the working time of 2nd is added to the latest time stamp of 1st January). If the memory device 200 was constantly measuring uptime, this time estimate would accurately represent real time (assuming the hardware timer block 270 and the CPU 260 are functioning correctly). However, if the memory device 200 has not continuously measured the operation time (if the memory device 200 has not been operated after the start of the measurement of the operation time), the time estimation accurately represents the real time. Must not. The actual time reported by the time estimate is at least around January 3rd. Real time may be January 4th or later (June 29, November 2, December 5, next year, etc.). Therefore, the operating time check in Act 540 may not give an accurate result.

  To address this issue, a check for “extension” uptime can be included in the TUP (acts 555 and 560). “Extended” operating time is obtained by adjusting the measured operating time based on the calculation accuracy of the old measured operating time. If the memory device 200 measures the operating time for 3 days and knows that the value when the operating time was last measured was 50% of the real time, the memory device 200 measured the operating time for 3 days. Can be adjusted (or “stretched”) by a factor of 2 (because the measurement run time was 50% of real time) to calculate 6 days. For “extension” of operating time, US patent application Ser. No. 11 / 811,284 (“Method for Improving Accuracy of a Time Estimate from a Memory Device”) filed with the present application and incorporated herein by reference. Details are described in US Pat. No. 11 / 811,347 (Patent Document 2) entitled “Memory Device with Circuitry for Improving Accuracy of a Time Estimate”.

  Instead of using “stretched” working time, “stretched” non-working time can also be used. The non-operating time indicates a time during which the memory device 200 has not been operating between time stamps. Since there is no way to measure how long the memory device 200 has not been operating, the non-operating time is a calculated value. Specifically, non-operation time = actual time between time stamps−operation time. “Extended” non-working time is non-working time calculation adjusted based on the calculation accuracy of the old measured working time (or non-working time based on the measured working time). Hereinafter, examples of modifications of the non-operating time that can be considered will be shown. Here, “DownTime” indicates “extension” non-working time (average of non-working time between known time stamps, etc.).

Total non-working time estimate (teDownTime): teDownTime = (time stamp _i −time stamp _i−1− ActiveTime _i ), where index i advances from the second time stamp to the last time stamp and is set in memory device 200 .
Current non-working time (cDowntime) after the last timestamp: This can be calculated based on the number of power cycles (PC) since the last timestamp update (cDowntime = PC after the last timestamp * (teDownTime / PC) ) And the operation time after the last time stamp update can be calculated as a reference (cDowntime = ActiveTime * (teDownTime / ActiveTime) after the last time stamp).
To set the DownTime parameter not to be used, set the DownTime value to 0.
To set to use the DownTime parameter, set DownTime to 1. The memory device 200 evaluates whether a time stamp update is necessary based on the DownTime property. ServiceTime (Certificate validity, CRL validity, etc.)-Time estimate <DownTime, timestamp update is required.

  Returning to FIG. 7, if the “stretch” operating time check fails (ACT 560), the TUP check fails (ACT 565), and the memory device 200 sends a message to the host device 300. Then, a new time stamp is acquired according to the procedure described above. If the “extension” operating time check is passed (or if the memory device 200 has not been initialized for the TUP check), the memory device 200 returns a “TUP passed” message 510, 570 to the host device 300 (FIG. 4). Then, the host device 300 transmits the entity certificate and the CRL to the memory device 200, and the memory device attempts to authenticate the entity (act 585). Specifically, the memory device 200 generates a time estimate based on the last received timestamp and the measured operating time, checks the certificate (act 585), and checks the CRL (act 590). If the expiration date of the certificate and the CRL is after the generated time estimate, the memory device 200 returns an OK message to the host device 300, and if there are other steps in the authentication method, these steps can be executed. If the entity is authenticated, rights to the object are granted to the entity from the ACR 201 (in this case, a secure channel is established between the player 301 and the DRM module 207). When the certificate and / or the CRL has expired, a message notifying that the authentication attempt has failed is transmitted from the memory device 200 to the host device 300. In response to this, the host device 300 can start the time stamp update described above.

  As described above, the time estimate used for the authentication attempt is generated by adding the measured operation time to the final time stamp. Since the measurement running time may not be accurate, the “time stretch” technique described above can be used to improve the accuracy of time estimation. However, the “stretched” operating time may actually exceed the real time. When checking the TUP, if there is such “overextension” of the operating time, a new time stamp is acquired. However, if the certificate or CRL is inspected and there is an “excessive extension” of the operation time, there is a possibility that a legitimate entity will not be authenticated. Thus, it may be desirable not to use “time stretch” when generating a time estimate for authentication.

  In summary, the memory device 200 receives an entity authentication request in the manner described above and determines whether a new time stamp is required before attempting to authenticate the entity. If a new time stamp is required, the memory device 200 obtains the new time stamp, generates a time estimate based on the new time stamp, and compares the time estimate to the validity period of the certificate and / or CRL. Attempt to authenticate. If a new timestamp is not needed, the memory device attempts to authenticate the entity by generating a time estimate based on the final timestamp and comparing the time estimate to the certificate and / or CRL validity period.

  Note that this embodiment checks the TUP prior to entity authentication and obtains a new timestamp if necessary. In other words, it is not necessary to authenticate the entity prior to checking the TUP or acquiring a new time stamp. This is in contrast to systems that use a single server to provide both timestamps and DRM licenses. In this case, it is necessary to authenticate the server to the memory device before providing the time stamp (or other information) to the memory device. This leads to a situation called “Catch 22”. That is, even if a new time is required for server authentication, a new time stamp can only be obtained after the server is authenticated. To avoid such situations, some prior systems do not use time for the authentication process. Even if the “catch 22” situation described above is avoided, entities that should not be authenticated if time is ignored (such as an entity whose certificate and / or CRL has expired) may be authenticated.

  By separating the time server 100 from the entity attempting to authenticate to the memory device 200, a “free channel” is created between the player 301 and the time module 204 of the memory device, and the player 301 receives a time stamp from the time server 100. Updates can be delivered (see FIG. 3). A time estimate is generated from this timestamp, and the authentication can verify the entity's credentials against the time estimate. “Free channel” refers to a communication route established without the initial entity authentication. In contrast, a “secure channel” refers to a communication route that can only be established after an entity has been authenticated.

  Even if the player 301 is not authenticated, the player 301 can be used as a conduit, and the time stamp can be supplied from the time server 100 to the memory device 200. However, the time stamp is from a trusted source. In order to guarantee, the time server 100 should be authenticated. 4 and FIG. 6 showing this, the certificate and CRL of the time server 100 are inspected before the time stamp of the time server 100 is received. However, in order to avoid the above-described “catch 22” situation, it is preferable to assume that the validity period of the certificate of the time server 100 and the CRL has not expired in the memory device 200. No inspection is performed.

  An entity authenticated to the memory device 200 can perform various actions described in the ACR's authority management record (PCR). For example, referring again to FIG. 3, the player 301 can communicate with the DRM module 207 through a secure channel and attempt to access the protected content 205 in the memory device 200. (As another example, the ACR of the storage application 302 allows the application 302 to store the protected content 205 in the memory device 200.) Since the content is protected even if the player 301 has been authenticated, the DRM The module 207 attempts to verify the DRM license 206 before unlocking the protected content 205 (eg, determine whether the license is still valid or has expired). To accomplish this, the DRM module 207 requests time estimation from the time module 204 of the memory device 200. (Time module 204 refers to the aforementioned software and / or hardware that accumulates and generates various elements (time stamp, uptime, number of power cycles, “stretch” factor, etc.) used to generate a time estimate.) Module 207 compares the generated time estimate to the expiration date and / or validity period in license 206 to determine whether the license is valid. The DRM module 207 can also execute another check for license verification, including, for example, a check for determining whether or not the number of times the protected content 205 has been reproduced exceeds a predetermined number, but is not limited thereto. .

  As described above, the newer the time stamp, the higher the likelihood that the time estimate will be accurate. In the above-described embodiment, whether or not the time stamp update is necessary is determined by the ACR TUP. Therefore, how accurate the time estimate generated for DRM license verification will depend on the TUP in effect. When determining TUP parameters, there is a balance between the needs of service providers who provide services while considering expiration and the needs of end users who have to connect the host device to the network even if it is troublesome to obtain a new time stamp. It is necessary to take If the time tolerance is extremely loose, the service provider's revenue may be impaired. On the other hand, if the time tolerance is extremely strict, frequent network connection for obtaining the time stamp is a burden, and the end user may give up the service.

  If there is only one ACR in the memory device 200 and only one TUP (or if the same TUP is shared by multiple ACRs), one “common” TUP is used for all service providers. You may not be able to get the right balance. Therefore, the memory device 200 of this embodiment has a plurality of ACRs 201 and 202 with different TUPs (TUP1, TUP2), and the TUP can be set by the corresponding service provider. As described above, by providing individual ACRs, the memory device 200 can be set to use different authentication methods (symmetric authentication, asymmetric authentication, etc.) for authentication. By providing individual ACRs, time tolerances can be set. If the ACR TUP is configurable, the service provider can set its own time tolerance. In other words, it is possible to determine that the memory device parameters (time of operation, number of power supply cycles, “extension” operating time / non-operating time, etc.) that convey the time are old and trigger the time stamp update. If the TUP is configurable, service providers can set time tolerances based on their needs and end user relationships instead of relying on a single “common” TUP.

  For example, depending on the service provider, the time for issuing a certificate is very short (such as 10 minutes). By forcing the end user to obtain a new certificate each time the end user wants to use the service in the memory device 200, the service provider closely monitors the end user's behavior and whenever the end user requests a certificate. You can assess the fee. In this business model, service providers require tight tolerances for money return. As another example, service providers may need to revoke certificates frequently as a key part of their business model when the end user's installed base is very fluid. Again, the service provider wants tight time tolerances to ensure that the latest CRL is used for authentication. On the other hand, if a service provider offers a monthly subscription service and the user regularly connects to the service provider's website to get new content and receives a mandatory timestamp update, the end user Since it is expected to connect to the network to obtain new content, the time tolerance may not be so strict.

  Instead of using a TUP that can be set by ACR, or in addition to using a TUP that can be set by ACR, a TUP that can be set for a DRM license of each content can be arranged. In this case, the authenticated entity does not handle all content in the same way, but can use the existing time stamp for some content and force the entity to obtain a new time stamp for other content. (Unlike the ACR TUP, which is checked only during authentication, the TUP placed in the license is checked each time the DRM module 207 attempts to verify the license.)

  For example, consider the situation where a user downloads a two hour movie to his memory device. A license is also downloaded to the user's memory device, telling them that the movie can be viewed for a limited time of 24 hours. The service provider does not want the user to watch the movie beyond 24 hours, but also does not want to take care of connecting to the network to get a normal user to get a new timestamp. Therefore, the service provider decides to place a TUP requesting a new time stamp in the license when the operation time exceeds 4 hours (operation time required to watch a two-hour movie × 2). If the DRM module 207 attempts to verify the license and the uptime exceeds 4 hours, the user will not be able to watch the movie (because the movie will not be watched because a new timestamp is required and the license has expired) Not necessarily). (Instead of or in addition to operating time, the number of power cycles can also be used for TUP. For example, based on an average usage pattern, the memory device usage time can be 24 times from 10 or more power cycles. It can be determined that the time has been exceeded.) If the time estimate generated from the new time stamp reveals that the license is valid, the DRM module 207 again allows the movie to be played.

  If the TUP can be set in units of licenses, the TUP can be adjusted according to the content. In other words, the license time tolerance setting can be changed for a movie that expires after one week rather than a movie that expires after 24 hours. For example, a service provider may estimate that memory devices will be used on average 10 hours per day and trigger a license TUP to trigger a time update after 70 hours (10 hours per day x 7 days) of uptime. Can be set. As another example, instead of a two-hour movie, if the content is a three-minute pay-per-view video and if it is only viewed once, request a new timestamp after three minutes of working time TUP can be designed.

  The service provider's business model can also be taken into account when designing the TUP. For example, monthly subscription services are now a common business model for distributing protected music rights. The music subscription service allows users to download as much music as they want from the service provider's website and play it as much as they want for one month. After that month, the user needs to renew his subscription to renew the license. Otherwise, the license expires and the user cannot play music stored in his memory device. A user who frequently visits the service provider's website to download another music receives a new time stamp each time he connects to the website, thus increasing the accuracy of the time estimate provided from the user's memory device. However, users who download a relatively large amount of music do not always reconnect to the service provider's website before their monthly license expires. Eventually, when the user reconnects to download another music, the service provider can charge the user for the time the music was played outside the license period. Due to this business model, the time tolerances required by service providers with monthly subscriptions differ greatly from those of pay-per-use content service providers. Pay-per-use content users may not return to the website that received the content. Strict time tolerances may not be desirable for monthly subscription service providers because users of monthly subscription services are more likely to return to the website to download other music than pay-per-use services . This is because if the time tolerance is tightened, even if it is not tightened, the returning customer will be requested to acquire a new time stamp, and the customer will be offended. Loose time tolerances allow customers who do not return to the service provider's website to play music longer than the one-month license period (eg, play over one month of operating time rather than one month of real time). However, service providers may allow such misuse at the expense of combining various circumstances and making inconveniences to return customers and avoiding offenses.

  As another example, consider a business model in which a service provider provides point advertisements to a mobile phone when the user is playing audio or video from a memory device using his / her mobile phone. If the point advertisement relates to a store near the mobile phone when the content is reproduced, the host device must be connected to the network when the content is reproduced. If you are not connected, you cannot send different point advertisements for each location. To ensure this, the content TUP can be set to a very low amount (such as one minute of uptime) so that the user can reliably connect to the network and obtain a new time stamp. When the user connects to the network, the network can know the location of the mobile phone and send appropriate advertising content to the mobile phone. On the other hand, if the service provider only needs to know the number of times the content has been played to make a profit, the time tolerance can be considerably relaxed.

  As can be seen from the above example, by using a configurable TUP in the license file, the content service provider does not impair the customer's mood by forcing the customer to connect the host device to the network for the time stamp update. In this way, an appropriate time update can be set and balanced. Since the memory device of this embodiment is a multi-purpose / multi-purpose memory device having a large number of TUPs, even if one service is overdue after a certain period of time in the memory device, other services continue to be effective. That is, since the TUP is different for each content license, there are content that can be played back by the memory device and content that cannot be played back unless a new time stamp is acquired even if the player is authenticated.

  As previously described, the memory devices of these embodiments include two components. That is, it consists of a central security system and one or more applications independent of the central security system. (Because the application is independent of the central security system, the application may be referred to herein as an “extension” or “internal extension”.) In the embodiment seen in FIG. Have taken. However, other applications such as e-commerce function, banking function, credit card function, electronic money function, biometric function, access control function, personal data function, e-mail security function may be used. it can. In addition, although only one application is shown in the memory device 200 of FIG. 3, several kinds of applications can be prepared in the memory device (DRM module, e-commerce module, etc.).

  The central security system uses ACR to authenticate an entity attempting to access protected data stored in the memory device through an application (such as a DRM agent) in the memory device. When the entity is authenticated against the memory device, a secure session begins between the entity and the application specified by the ACR used to authenticate the entity. The entity can then send a command / request to the application to access the protected data. Thus, the central security system acts as a gatekeeper for the memory device. As detailed in previously referenced US patent application Ser. No. 11 / 557,028, the central security system can also separate various applications executing on the memory device 200, in which case One application cannot access data of another application.

  The central security system provides an access management mechanism that protects data in a manner that limits access to data stored in memory devices to authorized entities, but the central security system itself recognizes the data to be protected. However, it may not be processed. It is the application that runs on the memory device that recognizes and processes the protected data. For example, if the protected data is a DRM license, the DRM agent verifies the DRM license instead of the central security system. Thus, the central security system can be viewed as a configurable toolbox independent of the application. Specifically, when a service provider installs an application in a memory device and sets an ACR, a specific entity is associated with the application. From the perspective of the central security system, the central security system does not know how the application works (eg, whether the application performs DRM license verification or e-commerce functions), but the ACR Only entities that have been authenticated against know that they can communicate with the application specified in the ACR. Once the entity is authenticated by the central security system, the central security system opens a secure channel between the entity and the application.

  Sometimes it is necessary to know time in both the central security system and the application. For example, the central security system needs to know the time for time-based authentication (such as asymmetric authentication), and the application needs to know the time for time-based operations (such as DRM license verification). As described above, the central time module of the memory device can provide time to both the central security system and the applications executing on the memory device. For example, referring to FIG. 3, the time module 204 provides time to the asymmetric ACRs 201, 202 for authentication of various entities, as well as time to the DRM module 207 for license validation. As will be described later in connection with FIG. 8, the memory device application may choose to use host time in addition to or instead of time module time, as the case may be.

  FIG. 8 shows a memory device 600 that communicates with the host device 700. The host device 700 includes an entity (here, a player 710) and has some mechanism (such as a battery-powered clock) that provides time 720. The memory device 600 of this example includes a symmetric ACR 610 (which may be an asymmetric ACR), a time module 620, a DRM module 630, protected content 640, and a license 650 for the protected content 640. (The memory device application in FIG. 8 is the DRM module 630. Note that different types of applications can be used and more than one application can run on the memory device.) When the player 710 is authenticated with respect to the memory device 600, a secure channel 660 is established between the player 710 and the DRM module 630 according to the parameters set in the symmetric ACR 610. Although the DRM module 630 and the player 710 do not know each other, the DRM module 630 is associated with the player 710 by the symmetric ACR 610 set by the service provider. Accordingly, there is a certain degree of trust between the DRM module 630 and the player 710 that are counterparts in the same group. Based on this trust relationship, the DRM module 630 can be programmed to accept the host time 720 from the player 710 as the time source and perform DRM license verification. The DRM module 630 that performs DRM license verification has two time sources that supply time. That is, the host time 720 and the time from the central time module 620 of the memory device can be used. Each of these time sources has advantages and disadvantages. The time module 620 time is not as accurate as the host time 720 because the memory device time module 620 does not continuously track time. Host time 720 is often provided by a battery-powered continuous clock. On the other hand, for the security measures described above, the time of the time module 620 is safer than the host time 720, and the user of the host device 700 can change the host time 720 using a simple user interface. In particular, the time of the time module 620 is safer.

  Applications executing on memory device 600 (such as DRM module 630) can be programmed to use two time sources in a manner suitable for generating time estimates for use in time-based operations. (But preferably, the application cannot update the time module 620 using the host time 720.) For example, the application can be programmed to always use the host time 720 instead of the time of the time module 620, as well as the host time. It can be programmed to always use the time of the time module 620 instead of 720. As another example, an application can be programmed to use the later (or earlier) of the host time 720 and the time module 620 time. Both time sources may be used in some way (eg, averaging the time of host time 720 and time module 620) and the application programmed to generate a time estimate. As another example, the application can determine a time source to be used based on information about the host device 700. The application can know the type of the host device through the authentication process (for example, if using asymmetric authentication, the authentication algorithm can inform the application of the individual identifier and group identifier of the host device 700). This information can be important because some host devices are secure and some are not. For example, if the host device is a PC, the PC clock can be easily manipulated using a simple user interface of a software application. (In addition to not trusting the host time from a host device with relatively low trustworthiness, the application may not be able to trust the entity running on the host device that has the content key, license value or duration, license change right. In this case, DRM The agent need only flow content from the memory device to the host device (instead of providing the encryption key and content to the host device). However, if the host is a closed system, for example an MP3 player, the host clock It can be much more difficult to operate. Therefore, for the application executed on the host device 600, the host time 720 can be trusted when the host device 700 is an MP3 player than when the host device 700 is a PC.

  Player 710 recommends host time 720 to DRM module 630 in one embodiment when sending a request to play a song to DRM module 630. The DRM module 630 determines whether to use the host time 720 or the time module 620 time as described above. Host time 720 is preferably used only for relatively short login sessions and should not be used in subsequent sessions as an absolute current time. Alternatively, the host time 720 can be accumulated so that it can be used in an application earlier, and the above-described “time expansion” or other mechanism can be used to improve the accuracy of the time (optional). However, the host time should be used only for specific time-based operations of the application and should not be used to update the time of the time module 620 (the application is an “extension” and is the same as the central security system It does not form a credit camp). As described above, it is always preferable to update the time of the time module 620 using a trusted time server (a time server that forms the same trust camp as the central security system). When a plurality of applications are executed in the memory device 600, each application has two time sources. That is, the time of the time module 620 and the time from the host device of the entity communicating with the application can be used. However, the host time used in one application should be used only for that application and not for another application associated with a different host device.

  As described above, an application (such as the DRM module 630) executing on the memory device 600 compares the host time 720 to the time from the time module 620 and uses the later (or earlier) of the two times. Can be programmed. For example, the host time 720 may be earlier than the time of the time module 620 because the host 700 has not connected to the time server for a sufficiently long time, or because the host clock is hacked. There is. As described above, the host time 720 can be accumulated so that it can be used in an application first. These ideas can be combined to accumulate the host time 720 and later used for comparison with the time received from another host device (used alone or in conjunction with the time of the time module 620). Based on this comparison, the memory device can determine whether to use the current host device's time or the previous accumulated host device's time to perform the time-based operation. For example, the memory device takes the earlier of the two times if the time-based operation is “not possible before” operation, and takes the later of the two times if the time-based operation is “impossible after” operation. Can be programmed to In this way, a time stamp received from another trusted host device can be used as a reference value for a single multi-host anti-rollback mechanism based on a single time server.

  As described above, a non-time-based authentication system (such as symmetric authentication) can be used for authenticating the host device. In this case, the time base operation (DRM operation etc.) of the application can be separated from the authentication time server. In other words, if only the time of the host device or the DRM server is used, the time-based operation of the application does not depend on the time of the authentication time server or the time module of the memory device. Therefore, even if there is a problem with the authentication time server for some reason, or the time-based application chooses not to use the time based on the authentication time server, the time-based application continues to perform operations using the host time. it can.

  It should be noted that any of the embodiments described above can be used alone or in combination. Patent applications incorporated by reference describe other embodiments that can be used in conjunction with these embodiments. Further, although it is currently preferred to implement these embodiments on SanDisk Corporation's memory device TrustedFlash®, it should be understood that any type of memory device can be useful. . These embodiments can also be useful when faced with the general problem of needing to know or use time in fields other than memory devices and inaccurate clocks. In addition, instead of executing the above-described act entirely on the memory device, part or all of the act can be executed on the host device (or some other device).

  The above detailed description is not intended to define the present invention, but is intended to be understood as illustrating specific forms that the present invention can take. The scope of the present invention is defined solely by the appended claims and their equivalents. It should be noted that the actions recited in the claims can be performed in any order, not limited to the order described. Finally, it should be noted that any of the aspects of the preferred embodiments described herein can be used alone or in combination with each other.

Claims (19)

A method for performing a time-oriented operation by an application on a memory device,
Depending on the application on the memory device,
Receiving an execution request for a time-oriented operation from an entity executed on a host device and authenticated by the memory device;
Selecting the time from the host device instead of the time from the time module on the memory device in performing the time-oriented operation;
Using the time from the host device in performing the time-oriented operation;
Including methods. The method of claim 1, wherein
The method in which the time from the host device is selected instead of the time from the time module only if the time from the host device is later than the time from the time module. The method of claim 1, wherein
The method further comprises the step of determining the identity of the host device, wherein the time from the host device is selected instead of the time from the time module only if the host device is determined to be reliable. The method of claim 1, wherein
The time from the host device is relatively more accurate than the time from the time module, and the time from the time module is relatively safer than the time from the host device. The method of claim 1, wherein
The time from the host device cannot be used to update the time module. The method of claim 1, wherein
The method further comprising using the time from the time module in authenticating the entity. The method of claim 1, wherein
A method further comprising using time from the host device for a single session only. The method of claim 1, wherein
The time-oriented operation includes a digital rights management (DRM) license verification operation. The method of claim 1, wherein
The memory device stores a digital rights management (DRM) key and a license to unlock protected content stored in the memory device. The method of claim 1, wherein
The memory device compares the time received from the host device, the time received from the second host device, and the time received from the second host device with the time accumulated from the host device. And a method for determining the use of time from the host device instead of the second host device based on the comparison in performing the time-oriented operation. The method of claim 1, wherein
The method wherein the memory device serves to authenticate the host device using a non-time based authentication system. A memory device,
A memory array;
A circuit in communication with the memory array,
Receiving an entity authentication request to be executed on the host device;
Authenticating the entity using an authentication method specified in an access management record (ACR) that associates the entity with an application in the memory device and a time from a time module on the memory device;
Receiving a request for execution of a time-oriented operation for the application from the entity;
In performing the time-oriented operation, the function of selecting the time from the host device instead of the time from the time module;
A circuit that uses the time from the host device to perform the time-oriented operation;
A memory device. The memory device according to claim 12, wherein
The memory device is selected in place of the time from the time module only when the time from the host device is later than the time from the time module. The memory device according to claim 12, wherein
A memory device in which the time from the host device is selected instead of the time from the time module only if the host device is determined to be reliable. The memory device according to claim 12, wherein
The memory device wherein the time from the host device is relatively more accurate than the time from the time module, and the time from the time module is relatively safer than the time from the host device. The memory device according to claim 12, wherein
The memory device cannot use the time from the host device for updating the time module. The memory device according to claim 12, wherein
The memory device further serves to use time from the host device for a single session only. The memory device according to claim 12, wherein
The time-oriented operation is a memory device including a digital rights management (DRM) license verification operation. The memory device according to claim 12, wherein
The memory device stores a digital rights management (DRM) key and a license for unlocking protected content stored in the memory device.

Images