TWI386947B - Memory device using time from a trusted host device and method for use therewith - Google Patents

Description

Memory device using time of trusted host device and method of using same

This application is related to US Patent Application Serial No. 11/811,284, "Method for Improving Accuracy of a Time Estimate"; U.S. Patent Application Serial No. 11/811,347 "Memory Device with Circuitry for Improving Accuracy of a Time Estimate"; U.S. Patent Application Serial No. 11/811,289, "for improvement" "Method for Improving Accuracy of a Time Estimate Used to Authenticate an Entity to a Memory Device"; US Patent Application Serial No. 11/811,344 "Memory Device with Circuitry for Improving Accuracy of a Time Estimate Used to Authenticate an Entity"; US Patent Application Serial No. 11/ 811, 354 "Method for Improving the Accuracy of Time Estimation Used in Digital Rights Management (DRM) Authorization Validation (Method for Improvin g Accuracy of a Time Estimate Used in Digital Rights Management (DRM) License Validation); US Patent Application Serial No. 11/811, 348 "has a time estimate for improving the use of digital rights management (DRM) authorization confirmation Memory Device with Circuitry for Improving Accuracy of a Time Estimate Used in Digital Rights Management (DRM) License Validation"; U.S. Patent Application Serial No. 11/811,346; US Patent Application Serial No. 11/811,345, "Memory Device Using Time from a Trust Host Device"; each of these applications is in connection with the present application The same is filed in the application and is hereby incorporated by reference.

Some memory devices, such as available from TrustedFlash SanDisk Corporation ^TM of the memory device needs to know to perform the operation based on the time period, such as a digital rights management (DRM) license confirmation. Due to the security issues involved in such operations, the memory device may not be able to trust the host device to provide the correct time. While the memory device may be able to obtain the correct time from trusted components in the network, the host device hosting the memory device may not be connected to the network when the memory device needs to know the time. The memory device can be designed to measure its effective time, but the time from the measured effective time is estimated to be in the case where the memory device is not continuously measured for effective time (eg, after the memory device is initially measured) In the case of a power outage) will not be a true measure of the actual time. Therefore, the time estimate resulting from the measured effective time actually only indicates that the actual time may be the lower limit, and this time estimate may not provide the desired accuracy in certain time-based operations. Although the memory device can be equipped with a battery powered clock to continuously track time even when the memory device is inactive, the clock may add the cost of the memory device.

The invention is defined by the scope of the patent application and should not be construed as limiting the scope of the application.

By way of introduction, the embodiments described below provide a memory device that uses the time of trusting the host device and methods of use thereof. In one embodiment, the application on the memory device receives a request from an entity authenticated by the memory device to perform a time based operation, wherein the entity is executing on the host device. The application selects the time of the host device instead of the time module on the memory device to perform time-based operations and uses the time of the host device to perform time-based operations. In another embodiment, a request is received to authenticate an entity executing on a host device. The entity is authenticated using the authentication method specified in the Access Control Record (ACR) and the time module on the memory device, wherein the ACR associates the entity with the application in the memory device. A request is received from the entity to perform a time-based operation on the application. The time of the host device is selected instead of the time module to perform time-based operations, and the time of the host device is used to perform time-based operations. In still another embodiment, the memory device compares the time received from the second host device with the stored time of the first host device, and determines whether to use the second host device or the stored time of the first host device based on the comparison. To perform time-based operations. In still another embodiment, the memory device uses a time-based authentication system to authenticate the host device, receives time from the host device, and uses the time received from the host device to perform time-based operations. Other embodiments are disclosed, and each of the embodiments can be used alone or in combination.

Embodiments will now be described with reference to the accompanying drawings.

Turning now to the drawings, Figure 1 is a diagram of a system 10 that will be used to illustrate such embodiments. instruction of. As shown in FIG. 1, system 10 includes a plurality of memory devices 20, 30, 40 that are removably coupled to respective plurality of host devices: a personal computer (PC) 50, digital media (eg, MP3) playback. The device 60 and the cellular phone 70. The host device is a device that can read data from a memory device and/or write data to a memory device. Data may include, but is not limited to, digital media content such as audio files or video files (with or without audio), images, games, books, maps, data files or software programs. The data can be downloaded, for example, from a server in the network to the memory device, preloaded by the manufacturer or another third party, or side-loaded from another device.

The host device can take any suitable form and is not limited to the example shown in FIG. For example, the host device can take the form of a notebook computer, a palmtop computer, a palm-sized email/text message device, a handheld game console, a video player (eg, a DVD player or a portable video player), Audio and/or video recorders, digital cameras, set-top boxes, display devices (eg, televisions), printers, car stereos, and navigation systems. Also, the host device may contain mixed functionality. For example, the host device can be a cellular phone that can also play digital media (eg, music and/or video) files in addition to being able to make and receive phone calls.

Host devices such as PC 50 and cellular telephone 70 may have the ability to be communicatively coupled to a network, such as Internet 80 or wireless network 90, although other types of networks may be used. A host device having this capability will be referred to herein as a "connected device." It should be appreciated that the "connected device" may not actually be connected to the network at all times, such as when the cellular telephone 70 is operating in the unconnected mode or when the PC 50 is not establishing an internet connection. Not own A host device (such as digital media player 60) that has the ability to communicate to the network in communication will be referred to herein as an "unconnected device." The unconnected device can be in communication with the network by connecting the unconnected device to the connected device (where the digital media player 60 is connected to the PC 50) as shown in FIG. Even if connected in this manner, the unconnected device may not be able to obtain information from the network if the unconnected device is not designed for the functionality (eg, a simple MP3 player). In this case, components in the network can push information to the device. It should be noted that although FIG. 1 shows that the digital media player 60 is connected to the PC 50 via a wired connection, a wireless connection can be used. Similarly, the terms "connected" and "coupled" do not necessarily denote a wired connection or a direct connection.

A network (eg, Internet 80 or wireless network 90) may allow access to external components via a connected device (or to an unconnected device connected to the connected device), such as, but not limited to, a time stampable time The server 100 and a digital rights management server (DRM) 110 that can provide DRM protected content and authorization to access the content. Both of these servers will be described in more detail below. Although the time server 100 and the DRM server 110 are shown as separate devices in FIG. 1, the two servers can be combined into a single device. In addition, these servers may contain other functionality. Further, components other than the time server 100 and the DRM server 110 can be accessed via the Internet 80 and the wireless network 90 as needed.

Turning to the drawings again, FIG. 2 is a block diagram of a memory device 200 of an embodiment, which may take the form of a memory card or a 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 circuit set 220. In this embodiment, non-volatile The memory array 210 takes the form of solid state memory (specifically, flash memory 210). It should be noted that other types of solid state memory can be used instead of flash memory. It should also be noted that memory other than solid state memory such as, but not limited to, a magnetic disk and an optical CD may be used. Also, for the sake of simplicity, the term "circuitry" will be used herein to refer to a hardware/software (or firmware) implementation of pure hardware implementation and/or combination. Thus, a "circuit" can take the form of one or more of the following: a special application integrated circuit (ASIC), a programmable logic controller, an embedded microcontroller, and a single board computer, as well as a processor and storage A computer readable medium readable by a processor, such as a software or firmware.

The circuit set 210 of FIG. 2 includes a plurality of components: a host interface module (HIM) 230, a flash interface module (FIM) 240, a buffer management unit (BMU) 250, a CPU 260, and a hardware timer block 270. . The HIM 230 provides interface functionality for the host device 300, and the FIM 240 provides interface functionality for the flash memory 210. The BMU 250 includes an encryption engine 252 for providing encryption/decryption functionality and a host direct memory access (DMA) component 254 and a flash DMA component 256 for communicating with the HIM 230 and the FIM 240, respectively. The CPU 260 executes the software and firmware stored in the CPU RAM 260 and/or the flash memory 210. The hardware timer block 270 will be described below in conjunction with the ability of the memory device to measure time.

To simplify the drawing, other components of the memory device 200 are not shown in FIG. 2, such as electrical connectors and physical connectors for removably connecting the memory device 200 to the host device 300. More information about the memory device 200 and its operation can be found in U.S. Patent Application Serial No. 11/314,411. Found in No. 11/557,028, which is incorporated herein by reference. Additional information can be found in U.S. Patent Application Serial No. 11/322,812, and U.S. Patent Application Serial No. 11/322,766, the disclosure of which is incorporated herein by reference. The components and functionality described in the literature should not be added to the scope of the following claims unless expressly stated.

In this embodiment, the memory device 200 stores a digital rights management (DRM) key and authorization to unlock protected content stored on the memory device 200. (It should be noted that these embodiments may also be used in conjunction with memory devices that do not store DRM keys and authorizations to unlock protected content stored on the memory device.) The DRM key and authorization may be generated by the memory device 200 or It is generated external to the memory device 200 (eg, by the DRM server 110) and sent to the memory device 200. Since the DRM key and authorization are moved with the memory device 200, the protected content is effectively associated with the memory device 200 rather than the host device 300, thereby making the protected content portable and identifiable to the memory device 200 It is accessed by any host device of the authorized device. The TrustedFlash ^(TM) memory device, available from SanDisk Corporation, is an example of a memory device that stores DRM keys and authorizations on the memory device such that the protected content can move with the memory device. In some embodiments, the memory device 200 also validates the DRM authorization by the DRM key stored on the memory device 200. In other embodiments, the memory device 200 provides the DRM key to the host device 300. It is used by the DRM key to make the DRM authorization effective.

In this embodiment, the CPU 260 of the memory device 200 executes a secure storage application (SSA) to ensure that only authenticated entities with appropriate authentication are available. Access DRM keys and authorizations. The computer readable code for the SSA can be stored in flash memory 210, CPU RAM 262, or another storage location in memory device 200. The SSA is described in more detail in the '028 patent application cited above. FIG. 3 is an illustration of various functional modules in the memory device 200 that will be used to illustrate the operation of the SSA. As shown in FIG. 3, the memory device 200 includes various access control records ("ACR"): a first asymmetric ACR 201, a second asymmetric ACR 202, and a symmetric ACR 203. The first asymmetric ACR 201 and the second asymmetric ACR 202 include a first time update policy and a second time update policy (TUP1 and TUP2, respectively), which will be described in more detail below. Although multiple ACRs are shown in FIG. 3, memory device 200 may only contain a single ACR.

Each ACR 201, 202, and 203 specifies the authentication method to be used and which authentication is required to provide proof of the identity of the entity. Each ACR 201, 202, and 203 also contains the permission to perform various actions (eg, accessing DRM keys and authorizations). Once the ACR successfully authenticates an entity, the SSA system initiates a session through which any of the ACR actions can be performed. As used herein, the term "entity" refers to any person or thing that attempts to access memory device 200. The entity can be, for example, an application executing on a host device, the host device itself, or a human user. In FIG. 3, three entities are attempting to access the memory device 200: a media (eg, audio and/or video) player 301, a storage application 302, and another application 303. These entities 301, 302, 303 can be on the same or different host devices. Each entity 301, 302, 303 is associated with a particular ACR (ACR 201, 202, and 203, respectively). Additional entities (not shown) can also be used with ACRs 201, 202 and 203 One or more are associated.

When the entity begins the login process, it sends a request for authentication, which includes the identifier of its associated ACR, which specifies the authentication method to be used and which authentication is required to provide proof of the identity of the entity. In FIG. 3, ACRs 201 and 202 specify an asymmetric authentication method, and ACR 203 specifies a symmetric authentication method. It should be noted that other authentication methods (such as password-based programs) may be used and the ACR may also stipulate that no authentication is required. In addition to specifying a particular authentication method, the ACR may also contain an admission control record (PCR) that describes the actions that the entity can perform once it has been authenticated.

Some authentication mechanisms (such as by using one-way and two-way asymmetric authentication for the X.509 credential chain for authentication) may require the memory device 200 to know the time to verify the authentication proposed by the entity based on time. (The symmetric authentication mechanism used by the symmetric ACR 203 does not require the memory device 200 to know the time. In symmetric authentication, the entity is identified using the key shared by the entity and its associated ACR.) In asymmetric authentication, it is possible It takes time to evaluate whether the authentication, such as RSA credentials and/or certificate revocation list (CRL), provided by the entity is valid. (When used herein, "voucher" may refer to a single credential or a plurality of credential (eg, credential chain), and "CRL" may refer to a single CRL or a plurality of CRLs.) may be used in steering memory device 200 Before the validation is performed to generate the time estimate, a brief discussion of the voucher and the CRL will be presented with respect to asymmetric authentication.

Asymmetric authentication uses a public key infrastructure (PKI) system in which a trusted authority called a certification authority (CA) issues RSA credentials for authenticating the identity of an entity. An entity wishing to establish an identity certificate to prove its identity Adequate evidence is registered with the CA. After proving the identity of the entity to the CA, the CA issues the credentials to the entity. The voucher typically includes the name of the CA that issued the voucher, the name of the entity to which the certificate was issued, the public key of the entity, and the public key of the entity signed by the CA's private key (usually by encrypting the digest of the public key) .

The voucher may contain a data field for the expiration date of the store. In this case, the entity holding the voucher can access the content protected by the ACR only for a limited amount of time (until the voucher expires). The voucher may also contain a data field for storing future valid time. In this case, the ACR will not authenticate the entity until the voucher becomes valid. If the memory device 200 determines that the current date is after the expiration date or before the expiration date (ie, if the memory device 200 determines that the voucher is invalid), the memory device 200 will not recognize the entity that presented the voucher.

Various circumstances, such as a change in name, a change in the association between an entity and a CA, and a compromise or suspected compromise of a private key, may cause the credential to become invalid before its expiration date. In these circumstances, the CA needs to revoke the voucher. In operation, the CA periodically issues a Document Revocation List (CRL), which is a signed data structure containing a list of stamped time stamps. Therefore, in order to authenticate the entity, the memory device 200 not only checks whether the voucher is timely, but also checks the CRL to see if the voucher is listed on the CRL. (The CRL may be provided by the entity along with the credentials, or the memory device 200 may obtain the CRL itself (eg, via the Internet 80 if the memory device 200 is a connected device).) If the credentials are listed on the CRL, then the credentials It is no longer valid (even if it has not expired) and the entity will not be authenticated. As with the voucher, the issued CRL has an expiration date, which indicates when it should be more New CRL. This ensures that the memory device 200 uses the most recent CRL. During the authentication period, if the memory device 200 finds that the current time exceeds the expiration date of the CRL (i.e., if the memory device 200 determines that the CRL is invalid), the CRL is considered to be defective and preferably not used for credential verification.

As discussed above, in this embodiment, the memory device 200 needs to know the time to verify the authentication (here the credentials and CRL). There are several options for allowing the memory device to know the time. One option is to cause the memory device to request a timestamp from the trusted time server via the host device each time the memory device needs to know the time. This solution is suitable for connected devices; however, since the memory device can be used in both connected and unconnected devices (eg, home PCs that are not connected to the Internet, MP3 players, cellular phones outside the network ( For example, on an airplane)), therefore, the memory device cannot rely on the available connectivity when it needs to know the time for the authentication process. Another option is to equip the memory device with a battery powered clock. However, this may be undesirable as it adds cost to the memory device. Yet another option is to rely on the host device to provide time to the memory device (either from its own internal clock or from an external source). However, in many cases, the memory device cannot trust the host device to provide precise time. If the user is allowed to "back date" the clock on the host device (ie, set the clock on the host device to be earlier than the current time), the user will be able to circumvent the memory device. Specific time limits to be enforced. On the other hand, if the memory device (the application executing in the memory device) can trust the host device, the memory device (or the application executing in the memory device) will be able to rely on the host device to obtain time. Below Ask for more information on when you can use host time.

Another option for use in this embodiment is the limited time tracking capability of using a memory device; in particular, the ability of the memory device 200 to measure its effective time. The effective time may refer to the memory device 200 being connected to the host device and actually being used (ie, when there is activity on the bus bar between the memory device 200 and the host device 300 compared to when idle or in the sleep mode) Time. Alternatively, the effective time may refer to the entire amount of time that the memory device 200 is connected to the host device 300 and receives power from the host device 300. The terms "effective time" and "time of use" will be used interchangeably herein. As described below, in this embodiment, the memory device 200 is active when the hardware timer block 270 can generate a clock timing unit as an interrupt to the CPU 260, and the CPU 260 can increment the valid time counter.

In operation, hardware timer block 270 (e.g., an ASIC controller) contains oscillators that generate periodic clock timing units and provide such timing units to CPU 260 as interrupts. (Preferably, the oscillator operates at a very low frequency and operates while the CPU 260 is asleep.) Thus, the hardware timer block 270 interrupts the CPU 260 on a periodic basis (e.g., every millisecond or microsecond). When the CPU 260 is interrupted, the special clock interrupt service routine (e.g., in the firmware executed by the CPU 260) is called and a cycle/unit is added to the valid time counter, and the valid time counter is stored in the CPU RAM 262 and In the volatile flash memory 210, therefore, the counter value will not be lost in the event of a power outage. In order to avoid excessive wear of the memory 210, it is preferred to update the memory 210 in a periodic manner (e.g., approximately every minute as long as the memory device 200 is powered) rather than in response to each clock timing unit. Effect time counter. While this may result in additional inaccuracies in the measured time in the event that a power outage occurs prior to updating the effective time counter, this sacrifice may be considered acceptable in view of the benefits to memory durability. (To further protect memory durability, the value stored to the valid time counter may include a field indicating how many times the counter has been written. If the written value exceeds a certain number, the counter may be stored in another location in the memory. The bits in the counter can also be shifted in the case of contributing to durability.) The write valid time counter does not affect the performance of the memory device 200 (except for the power consumption of writing) and the regular activity. It is also preferred. (In other words, preferably, the write time counter is part of the process that serves the host command.) For example, the write valid time counter can be processed as a background task and executed prior to servicing the host device command. At the end of the host device command, the firmware in the memory device 200 can verify the stylized success of the valid time counter by reading the data from the memory and comparing it to the desired value.

Also, preferably, the value of the valid time counter is securely stored in the memory 210 (e.g., via the encryption engine 252 by using a key-Hatch Message Authentication Code (HMAC)), so it cannot be easily Make tampering. In the case of a mismatch, the data can be treated as uninitialized, as the attacker tampers with it. Additionally, it should be noted that other mechanisms for measuring the effective time can be used.

In order to convert the value stored in the valid time counter to the real time, the CPU 260 multiplies the stored value by the hardware timer block 270 to generate the frequency of the clock timing unit. For example, if the value 500 is stored in the valid time counter The medium hardware timer block 270 generates a clock timing unit every 5 milliseconds, and the CPU 260 will calculate a valid time of 2,500 milliseconds (500 times 5). To generate a time estimate, the translated valid time is added to the memory device 200 to receive a time stamp from the trusted source. In other words, the time stamp acts as a "start line" to which the effective time of the measurement of the memory device is added. The time stamp can take any form and indicate the time with any desired accuracy (eg, year, month, day, hour, minute, second, etc.). Preferably, the memory device 200 trusts an entity (eg, the time server 100 or a trusted host device) that can give its precise time a time stamp to the memory device 200. The timestamp can take any form and be sent separately or included in other information. The memory device preferably securely stores the timestamp via the encryption engine 252 and therefore cannot be easily tampered with. When the memory device 200 receives the new time stamp, the new time stamp is stored in the memory device 200, and the valid time counter is reset. Therefore, the effective time will be measured later with respect to the new time stamp instead of the old time stamp. Instead of resetting (and therefore, "recalculating") the counter, the valid time counter value present at the time of the new timestamp can be recorded and subtracted from the current time to measure the effective time.

Now, since the time tracking capability of the memory device has been discussed, an example of the authentication procedure will be described. Turning again to the drawings, Figure 4 is an agreement diagram of the asymmetric authentication process of an embodiment. In the following example, the player 301 attempts to log into the memory device 200 via the ACR 201. As described in more detail below, the player 301 contains an authentication (eg, an RSA key pair, a voucher, and a voucher revocation list (CRL)), and the ACR 201 is responsible for confirming the authenticity of the player 301 and granting rights to the object (here In case, the player 301 and the DRM module are established. Secure channel between 207). As shown in FIG. 4, the first step is that the host device 300 transmits a request for authentication to the player 301 to the memory device 200 (act 402). If the timestamp has not been installed in the memory device 200, the memory device 200 responds to the authentication request with a login failure message (act 404).

The following series of actions describe the process of providing time stamps to the memory device 200 and will be described in conjunction with FIGS. 5 and 6, which are system diagrams illustrating a particular manner in which the memory device 200 can obtain time stamps, respectively. flow chart. It should be appreciated that the memory device 200 can obtain time stamps in different ways, and the time stamp can take different forms. It should also be appreciated that a single memory device connected to multiple server or host interfaces can handle multiple formats simultaneously. Therefore, the details of this example should not be included in the scope of the patent application unless explicitly stated therein.

As shown in FIG. 5, the memory device 200 communicates with the host device 300 via the memory device-host device communication channel 305, and the host device 300 communicates with the time server 100 via the host device-time server communication channel 315. Although the time server 100 can include a single server, in this embodiment, the time server 100 includes a plurality of servers 102, 104, 106 that are synchronized with each other via the inter-server communication channel 325. Again, as noted above, instead of using time server 100 to obtain a timestamp, a timestamp from host device 300 (preferably only if it is a trusted host device) may be used.

In this embodiment, the host device 300 starts a program for requesting a time stamp, and sends a get nonce command to the memory device 200 (ACT 405) (see FIG. 4, FIG. 5, and FIG. 6). In this embodiment, the temporary random number is used by the memory device 200 to verify the time at a later time. A 160-bit random number of the authenticity of the timestamp generated by server 100. The memory device 200 generates a random number (temporary random number) (act 410) and stores it in the CPU RAM (i.e., volatile memory) 262 (or alternatively, the memory 210) for later verification steps. The memory device 200 then transmits a temporary random number to the host device 300 (ACT 415). The memory device 200 also begins measuring time (as described below) to determine later if a timeout has occurred.

When the host device 300 receives the temporary random number, it transmits a time stamp request containing the temporary random number to the time server 100 (act 420). The time server 100 signs with its private key versus time (eg, world time in UTC Zulu format) and temporary random numbers. Time server 100 then transmits to the host device 300 a timestamp response containing the temporary random number, timestamp, credential chain, and CRL chain in this embodiment (act 425). (It should be noted that this credential and CRL are sent from the time server 100 to authenticate it and are different from the credentials and CRL sent to authenticate the player 301.) The host device 300 then responds to the memory device 200 with this response. A time update command is sent (act 430). In response to the command, the memory device 200 attempts to verify the credential and CRL (act 435). (again, the credential and CRL are different from the credential and CRL sent to authenticate the player 301.) As discussed below, it may be preferable to assume that the validity period of the credential and CRL of the time server 100 is valid, and The validity is checked against the time estimate produced by the memory device 200. If the verification fails, the memory device 200 resets the volatile memory 262 and returns to the idle process (act 440). If the verification of the credential and the CRL is passed (ACT 445), the memory device 200 compares the temporary random number in the response with the temporary random number in the volatile memory 262 (act 450). If the comparison fails, then remember 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 preferably stores the new time stamp in the memory 210 in a secure manner to prevent tampering.

It should be noted that after the memory device 200 generates the temporary random number 410 and waits for a response (act 460), the host device 300 may send another acquisition temporary random number command to the memory device 200 (act 465). As mentioned above, the memory device 200 begins measuring time after the temporary random number is generated. If a new temporary random number command is received (465) before the measured time reaches a particular timeout limit, the memory device 200 preferably ignores the new temporary random number command (465). However, if a new temporary random number command is received (465) after the timeout limit, the memory device 200 will reset the volatile memory 262 and generate a new temporary random number (act 470). Thus, the temporary random number is only valid for a limited time, and the timeout limit ("travel time error") is the maximum time that the memory device 200 considers to be reasonably used to wait for the timestamp from the time server 100.

Because the timestamp stored in the memory device 200 contains the time when the time server 100 signs the data string, the time indicated in the time stamp may not be the actual real time of the host device 300 requesting the time stamp or the memory device 200 stores the time stamp. The actual real time depends on the accuracy of the timestamp (eg, year, month, day, hour, minute, second, etc.) and the delay involved in sending the request and receiving the response. The temporary random number overdue period discussed above can be set to a time to ensure that the time stamp will have the accuracy required by the memory device 200. Thus, the memory device 200 can control the maximum acceptable delay in the timestamp request. Also, in an alternate embodiment, the timestamp generated by the time server 100 may indicate some other time, such as the host device 300 requesting a timestamp. The estimated time, time stamp will be stored in the memory device 200 at an expected time or some other time.

The above agreement allows the memory device 200 to communicate with the time server 100 via an insecure connection system (eg, internet, WiFi network, GSM network, etc.). The connection system is unsafe in the sense that the memory device 200 cannot assume that the timestamp sent by the time server 100 will not be tampered during transmission. Since the time stamp cannot be protected by the network, the above protection mechanism (or some other protection mechanism) can be used between the time server 100 and the memory device 200. The encryption protocol allows the memory device 200 to detect this tampering in the event that the timestamp is tampered with. In other words, because the connection system is not secure, the system itself cannot prevent others from changing the bits in the timestamp; however, the memory device 200 can detect tampering and reject the timestamp. In an alternate embodiment, a secure communication system is used (i.e., the data communication line is protected) and the timestamp can simply be sent as plaintext because no one can tamper with the timestamp.

Returning to FIG. 4, in the case where the new time stamp is now stored in the memory device 200, the memory device 200 sends back a "time update successful" message to the host device 300 (act 452), and the host device 300 once again memorizes The body device 200 sends an authentication request (act 454). Since the memory device 200 has a time stamp, the memory device 200 will check the time stamp update policy (TUP) of the ACR 201 (act 500). Since the time estimate is based on a time stamp, making the time estimate based on an outdated time stamp may result in an inaccurate time estimate. Therefore, the TUP is used to determine when an existing timestamp on the memory device 200 is considered obsolete and needs to be updated (ie, a new timestamp). As shown in Figure 3 and described in more detail below Different ACRs may have different TUPs (i.e., different ACRs may have different time tolerance levels), which may be established when an ACR is generated.

In this embodiment, TUP is represented by four values: (1) the number of thresholds of the power cycle, (2) the threshold of the effective time, (3) the threshold of the "extended" effective time, and (4) Indicates whether there is a logical OR (OR) relationship between the parameters (ie, whether a time update is required if only a single parameter fails, or if a time update is required only if all parameters fail). Each of these parameters will be described in detail below. (It should be noted that other parameters besides or in place of these parameters may be considered.)

7 is a flow chart showing more details of checking a TUP action (act 500). First, a check is made to determine if the memory device 200 has been initialized to check the TUP (eg, by observing configuration data stored in the memory 210) (act 505). If the memory device 200 has not been initialized to check the TUP, the memory device 200 uses the time stamp received by the memory device 200 to generate a time estimate (act 510) and attempts to authenticate the entity using the time estimate. If the memory device 200 has been initialized to check the TUP, the memory device 200 begins the check.

First, the memory device 200 determines whether the TUP includes a check of the number of power cycles of the memory device 200 from the last time stamp (act 515). In this embodiment, this is done by examining the "power cycle" values mentioned above. If the "power cycle" value is zero, the number of power cycles is not checked. If the "power cycle" value is not zero, the number of power cycles is checked by using the value as a threshold. The number of power cycles is activated for the memory device 200 The count of the number of times indicates how many times the memory device 200 is powered off since the last time stamp (i.e., there must have been a power outage for each power-on). The number of power cycles can be measured by the CPU 260. Each time the memory device 200 passes a power cycle, the CPU 260 can call the device reset routine in the firmware. In the case where the CPU 260 adds a unit to the active time counter, the CPU 260 will add a unit to the CPU cycle 262 and/or the power cycle counter in the memory 210 by the device reset routine. Like the effective time counter, the power cycle counter can be periodically updated to reduce memory wear.

When the memory device 200 is powered down, there is at least some actual time that is not represented by the measured effective time (because the memory device 200 cannot measure its effective time when it is not "active"). Since the memory device 200 does not know how long it takes between power cycles, the number of power cycles does not indicate how inaccurate the measured time is. However, it does provide a preliminary impression of whether or not the memory device 100 is being used outside of the intended mode of use, which can roughly indicate how inaccurate the measured time may be. For example, the time estimate performed by the memory device 200 with ten power cycles from the last time may be less accurate than when the memory device 200 has only a single power cycle since the last time stamp. Estimate.

If the TUP includes an inspection of the number of power cycles, the memory device 200 checks the number of power cycles of the memory device 200 from the last timestamp to see if the number exceeds the threshold amount set in the "power cycle" value (action) 520). The threshold number is configurable for each ACR to reflect the desired time tolerance. For example, if the identification is very sensitive and you need to make sure that the credentials are not exceeded or The expiration date of the CRL can be set to one. Thus, if the memory device 200 is turned off (even in one case) (and therefore, there is at least some amount of time that cannot be accounted for by the measured effective time), the TUP check for this parameter will not pass. On the other hand, if the authentication is not so sensitive, the number of power cycles can be set to a larger number (or even not at all) to allow the TUP to pass, even if there is a certain number of power cycles (and therefore, In the case of a certain amount of time not indicated by the measured effective time).

If the check for the number of power cycles fails and it is determined that there is an OR relationship between the TUP parameters (act 525), then the TUP check fails (act 530). The memory device 200 sends a message to the host device 300 to indicate the failure, and uses the procedure described above to obtain a new timestamp. If the check of the number of power cycles passes or if it fails and it is determined that there is no OR relationship between the TUP parameters (ACT 525), then the process determines whether the TUP includes a check for the effective time since the last timestamp. And continue (act 535).

Similar to the power cycle procedure described above, if the "valid time" value is zero, the valid time is not checked. However, if the "valid time" value is not zero, the effective time is checked by using the value as the threshold second (or some other time unit). As with the number of power cycles, the threshold effective amount of time is configurable for each ACR to reflect the desired time tolerance. In general, the longer the memory device 200 is effective, the greater the inaccuracy of the measured effective time. Therefore, if the authentication is very sensitive and you need to ensure that the expiration date of the voucher or CRL is not exceeded, the threshold for the measured effective time can be set to be very low. Conversely, if the identification is not so sensitive, the measurement can be The threshold for the effective time is set to be higher (or even not considered at all).

If the check for the valid time has not passed and it is determined that there is an OR relationship between the TUP parameters (act 545), the TUP check fails (act 550). The memory device 200 sends a message to the host device 300 to indicate the failure, and uses the procedure described above to obtain a new timestamp. If the check of the valid time passes or if it fails and it is determined that there is no OR relationship between the TUP parameters (act 545), then the process continues by determining if the TUP includes a check for the "extended" effective time (act 555) ).

As noted above, the measured effective time may not be a true measure of the actual effective time if the memory device 200 does not continuously measure the effective time. That is, if the memory device 200 is "inactive" (eg, when the memory device 200 is idle or in a sleep mode, or when the memory device 200 is powered down or the memory device 200 is removed from the host device 300) - in this embodiment, to cause the hardware timer block 270 to stop generating the clock timing unit and/or cause the CPU 260 to stop any event that reacts to the timing unit, the measured effective time will be less than The actual time elapsed is measured as there is nothing in the memory device 200 to inform it of the elapsed time when it is inactive. For example, assume that a timestamp is received on January 1 and the memory device 200 measures the effective time of two days. (For simplicity, the time is measured in days in this example. However, as mentioned above, any desired time unit can be used.) Therefore, the time estimate produced by the memory device 200 at this point will indicate The date is January 3 (that is, the effective time of two days is added to the time stamp above January 1). If the memory device 200 continuously measures the effective time, then this time estimate will accurately represent the actual time. Time (assuming hardware timer block 270 and CPU 260 act accurately). However, if the memory device 200 does not continuously measure the effective time (i.e., if the memory device 200 is inactive at any point after it begins to measure the effective time), the time estimate will not accurately represent the actual time. In the best case, the time estimate will indicate that the actual time is at least January 3. The actual time can be January 4 or a later time (June 29, November 2, December 5, next year, etc.). Therefore, the check of the effective time in act 540 may not give an accurate result.

To address this issue, the TUP may include a check for "extended" valid time (acts 555 and 560). The "extension" effective time is a result of adjusting the measured effective time based on the determination accuracy of the effective time of the previous measurement. Therefore, if the memory device 200 measures the effective time of three days and knows that the measurement effective time last time or several times, which is a value of 50% of the actual time, the memory device 200 can adjust the factor two. (or "extend") three days of measurement of the effective time (because the measured effective time is 50% of the actual time) to produce six days. Additional information regarding the "extended" effective time is described in "Method for Improving Accuracy of a Time Estimate from a Memory Device" and "U.S. Patent Application Serial No. 11/811,347", "Memory Device with Circuitry for", US Patent Application No. 11/811,284 In the case of "According Accuracy of a Time Estimate", both of which are hereby incorporated by reference.

Instead of using the "extended" effective time, you can use "extended" downtime. The downtime refers to the amount of time that the memory device 200 is inactive between timestamps. Since there is no measure of the length of time that the memory device 200 is not effective Law, so the downtime is the calculated value; specifically, the downtime = the actual time between the timestamps - the effective time. The "extended" downtime is a downtime calculation that is adjusted based on the accuracy of the previous measurement's effective time (or based on the measured downtime of the measured effective time). The following is a list of examples of other downtime changes that can be considered. In this list, "DownTime" refers to "extended" downtime (eg, the average of downtime between previously known timestamps).

Total Downtime Estimate (teDownTime): teDownTime = (timestamP _i -timestamp _i-1 -ActiveTime _i ), where the index i is from the second timestamp configured in the memory device 200 to the last timestamp.

The current DownTime (cDowntime) from a previous time stamp for a particular moment. This can be calculated as the number of power cycles (PC) since the last timestamp update (cDowntime=PC*(teDownTime/PC) from the last timestamp) or calculated from the effective time since the last timestamp update ( cDowntime=ActiveTime *(teDownTime/ActiveTime)) since the last time.

If the DownTime parameter is configured and not used, set the DownTime value to 0.

Set DownTime to 1 if the DownTime parameter is configured for use. The memory device 200 will use the DownTime property to evaluate when a timestamp update is needed in the following manner: When the ServiceTime (eg, validity of the credential or validity of the CRL) - time estimate <DownTime, a timestamp update is required.

Return to Figure 7, if the check for the "extended" valid time does not pass (action 560), the check of the TUP is not passed (ACT 565), and the memory device 200 sends a message to the host device 300. The procedure described above is then used to obtain a new time stamp. If the check for the "extended" valid time passes (or if the memory device 200 is uninitialized to check the TUP), the memory device 200 sends a "TUP through" message 510, 570 (see FIG. 4) to the host device 300. The host device 300 then sends the entity's credentials and CRL to the memory device 200, and the memory device attempts to authenticate the entity (act 585). In particular, the memory device 200 will generate a time estimate based on the last received timestamp and the measured valid time to verify the credential (act 585) and verify the CRL (act 590). If the expiration time of the credential and the CRL is after the generated time estimate, the memory device 200 sends back an OK message to the host device 300, and other steps in the authentication method, if any, can be performed. If the entity is authenticated, the ACR 201 grants the entity rights to the object (here by establishing a secure channel between the player 301 and the DRM module 207). Otherwise, if the credentials and/or CRL have expired, the memory device 200 can send a message to the host device 300 stating that the authentication attempt has failed. Host device 300, in turn, can initiate a timestamp update as described above.

As mentioned above, the time estimate for the authentication attempt is generated by adding the measured effective time to the up time stamp. Since the measured effective time may be inaccurate, the "time extension" technique discussed above can be used to improve the accuracy of the time estimate. However, it is possible that the "extended" effective time may actually be greater than the actual time. In the case of checking the TUP, the "excessive extension" effective time will result in a new time stamp. However, in the case of a verification credential or CRL, the "excessive extension" effective time prevents the identification from being appropriate in other situations. entity. Therefore, it may be necessary to not use "time extension" when generating a time estimate for authentication.

In general, by the above method, the memory device 200 receives the request of the authentication entity, and before attempting to authenticate the entity, the memory device 200 determines whether a new time stamp is needed. If a new timestamp is needed, the memory device 200 obtains a new timestamp and then attempts to authenticate the entity by generating a time estimate based on the new timestamp and comparing the time estimate with the credential and/or CRL validity period. If a new timestamp is not required, the memory device 200 attempts to authenticate the entity by generating a time estimate based on the last timestamp and comparing the time estimate with the credential and/or CRL validity period.

It should be noted that in this embodiment, the TUP is checked and a new timestamp is obtained prior to authenticating the entity if needed. In other words, checking the TUP and obtaining a new timestamp does not require that the entity be authenticated before checking the TUP or before obtaining a new timestamp. This is in contrast to systems that use a single server to provide time stamping and DRM authorization. The server will need to authenticate to the memory device before providing a time stamp (or other information) to the memory device. This raises the "Catch 22" scenario - in order to authenticate the server, a new time may be required, but the new timestamp can only be obtained after the authentication server. To avoid this situation, some prior art systems simply do not use time during the authentication process. While the above "Article 22 Military Regulations" situation is avoided, ignoring time may result in an entity that is not identifiable (eg, because its credentials and/or CRL has expired).

By separating the time server 100 from the entity attempting to authenticate to the memory device 200, the memory device 200 is at the time of the player 301 and the memory device. A "free channel" is created between the modules 204, allowing the player 301 to pass time stamp updates from the time server 100 (see Figure 3). The time stamp will then be used to generate a time estimate, which can be verified against the time estimate for authentication. "Free channel" refers to a communication pipeline that is established without first authenticating the entity. In contrast, a "secure channel" refers to a communication line that is established only after the authentication entity.

It should be noted that although it is not necessary to authenticate the player 301 to use it as a conduit to supply the memory device 200 with a timestamp from the time server 100, the time server 100 is preferably authenticated to ensure that the timestamp is from trusted source. This is illustrated in FIG. 4 and FIG. 6 in act 435 where the credentials and CRL are verified prior to accepting the timestamp of the time server 100. However, in order to avoid the "twenty-two military regulations" scenario discussed above, the memory device 200 preferably assumes that the validity period of the credentials and CRLs of the time server 100 is valid, and therefore does not coincide with the time of generation. Estimate the comparison to verify the validity period.

When an entity is authenticated to the memory device 200, the entity can perform various actions as stated in the ACR's admission control record (PCR). For example, referring again to FIG. 3, the player 301 can communicate with the DRM module 207 via a secure channel in an attempt to access 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.) Even if the player 301 has been authenticated, the DRM module 207 is also protected due to content protection. The DRM authorization 206 that is attempting to use the protected content 205 prior to unlocking the protected content is valid (eg, by determining if the authorization is still valid or has expired). In order to do this, the DRM module 207 will be a time module from the memory device 204. 204 requests a time estimate. (Time module 204 refers to the software described above for storing and generating various components for generating time estimates (eg, time stamps, effective time, number of power cycles, "extension" factors, etc.) and/or Or hardware.) The DRM module 207 compares the expiration date and/or expiration period in the generated time estimate and authorization 206 to determine if the authorization is valid. The DRM module 207 can perform additional checks to validate the authorization, such as, but not limited to, determining whether the protected content 205 has been played for more than a specified number of times.

As mentioned above, the newer the time stamp, the more accurate the time estimate will be. In the above embodiment, the TUP in the ACR determines whether a timestamp update is required. Therefore, the TUP effectively determines how accurate the time estimate will be for DRM authorization confirmation. In determining the parameters of the TUP, between the needs of the service provider providing the service with the expiration considerations and the needs of the end user who may be inconvenient to connect the host device to the network to obtain a new time stamp. Get balanced. If the time tolerance is too loose, the service provider may lose revenue. On the other hand, if the time tolerance is too tight, the end user may decide to abandon the service if they are frequently connected to the network to obtain the required time stamp update too much trouble.

When the memory device 200 has a single ACR with a single TUP (or multiple ACRs share the same TUP), a single "one size fits all" TUP may not achieve the correct balance for all service providers. Thus, in this embodiment, memory device 200 has a plurality of ACRs 201, 202, each having a different TUP (TUPI, TUP2) that can be configured by an associated service provider. As discussed above, via different ACRs, the memory device 200 can be configured to use different authentication mechanisms (symmetric Identification, asymmetric identification, etc.) for identification. The use of different ACRs allows for configurable time tolerances. That is, by using a configurable TUP in the ACR, the service provider can inform one of the parameters (eg, effective time, number of power cycles, "extended" valid time/downtime) by specifying the time of the memory device. When more than one is considered obsolete and should trigger a timestamp update to define its own time tolerance. By making the TUP configurable, the service provider can configure its time tolerance based on its specific needs and its relationship to the end user, rather than relying on a single "all-in-one" TUP.

For example, some service providers publish credentials for very short periods of time (eg, ten minutes). By forcing the end user to obtain new credentials each time he wishes to use the service on the memory device 200, the service provider can closely monitor the behavior of the end user and estimate the cost of each end user requesting the voucher. Therefore, for this business model, service providers need strict tolerance for monetization. As another example, if the service provider has a highly mobile end-user installation base, the service provider may wish to revoke the credentials frequently as an integral part of their business model. In this case, the service provider will also need strict time tolerance to ensure that the latest CRL is used for authentication. On the other hand, if the service provider provides a monthly subscription service (where the user regularly connects to the service provider's web site to obtain new content and receives mandatory timestamp updates), the service provider will not need such a strict time Tolerance, because end users will likely connect to the network to get new content.

Instead of using a configurable TUP on the ACR or in addition to using a configurable TUP on the ACR, the configurable TUP can be placed in the DRM license for the individual content portion. on. In this way, instead of the authenticated entity processing all portions of the content as such, the entity may be forced to obtain a new timestamp for some content while using an existing timestamp for other content. (Unlike the TUP on the ACR that is only checked during the authentication period, the authorized TUP can be checked each time the DRM module 207 attempts to make the authorization valid.)

Consider, for example, a situation where a user downloads a two-hour movie to their memory device along with an authorization indicating that the movie can only be viewed within 24 hours. While a service provider may not want a user to watch a movie after a 24-hour period, it may not wish to be inconvenient by having a normal user connect to the network to obtain a new timestamp. Therefore, the service provider may decide to set the TUP on the authorization, which requires a new timestamp if the effective time is greater than four hours (the amount of time required to watch the two-hour movie twice). If the effective time is greater than four hours when the DRM module 207 attempts to make the authorization valid, the user will not be able to watch the movie, not necessarily because the authorization expires, but because a new timestamp is needed. (Instead of or in addition to the effective time, the number of power cycles can be used in the TUP. For example, based on the average usage mode, ten or more power cycles can indicate that the memory device is used for more than 24 hours.) The time estimate indication generated by the new time stamp, if the authorization is valid, the DRM module 207 will allow the movie to be played again.

By allowing the TUP to be configurable for each grant, the TUP can be customized to fit the content. Therefore, if the movie expires after 24 hours and the movie is full at the end of the week, the time tolerance for authorization can be set in different ways. For example, if the service provider estimates that the average memory device is used for 10 hours per day, the service provider can set the TUP in the authorization to be valid for 70 hours. The time update is triggered after the time (ie, 10 hours per day by 7 days). As another example, if instead of a two-hour movie, the content is a three-minute pay-per-view video that should only be viewed once, the TUP can be designed such that a new time stamp will be required after a three-minute effective time.

The business model of the service provider can also be a consideration in designing the TUP. For example, currently, the monthly subscription service is a popular business model for distributing protected music rights. In the music reservation service, the user freely downloads the music he wants from the service provider's web site and is allowed to play his music any number of times in a month. After the month, the user will need to update their subscription to update the authorization; otherwise, the authorization will expire and the user will no longer be able to play the music stored in their memory device. Users who frequently access the service provider's web site to get more songs will receive a new timestamp when they connect to the web site; therefore, their memory device will be able to provide a more accurate time estimate. However, users who download relatively large amounts of music may not reconnect to the service provider's web site until the monthly license expires. When the user eventually reconnects for more music, the service provider can charge the user for the time they are allowed to play music outside of the authorization period. Due to this situation, as a business model, a monthly subscription service provider may wish to have a very different time tolerance from the service provider of the charge-based content. In the case of the charge-based content, the user may not return to receive it. A web site that counts the content of the charge. In this case, because the user is likely to return in the monthly subscription service to get more music than in the pay-per-view service, the service provider may not want strict time tolerance because strict time tolerance may By requiring consumers to obtain The new time stamp makes it dissatisfied (even if it would eventually return to the web site). Having a less stringent time margin can mean that consumers who never return to the service provider's web site will be able to play music for a month longer than the authorized one (eg, one month's effective time instead of one month's actual time) ). In general, however, the service provider may determine that the unauthorized use is an acceptable sacrifice to avoid making the returning consumer inconvenient and slow.

As another example, consider a business model in which a service provider desires to provide a point advertisement to a cellular phone when a user uses his cellular phone to play audio or video content from a memory device. If the point advertisement contains an advertisement for a store that is close to the location of the cellular phone when the content is played, the host device needs to connect to the network when the content is played; otherwise, the location-specific point advertisement cannot be delivered. To ensure this happens, the TUP of the content can be set to a very low amount (eg, one minute effective time) to ensure that the user will connect to the network to get a new timestamp. Once the user is connected to the network, the network will know the location of the cellular phone and will be able to push the appropriate advertising content to the cellular phone. On the other hand, if the service provider only makes money by knowing how many times the content is played, the time tolerance can be much less stringent.

As shown in the above example, by using the configurable TUP on the authorization profile, the service provider of the particular content can perform any balance it considers appropriate for the time update so that the consumer is not required to connect his host device to the network. The road gets the time stamp update and makes it unsatisfactory. It should be noted that since the memory device in this embodiment is a multi-purpose multi-application memory device having multiple TUPs, one of the services on the memory device can be turned off after a certain time, while other services on the memory device Still enabled. Player (Even if authenticated) may be able to play particular content on the memory device, but may be prevented from playing other content on the memory device unless a new timestamp is obtained due to a different TUP associated with the authorization of the different content.

As explained above, in these embodiments, the memory device includes two separate components: a central security system and one or more applications separate from the central security system. (Because the application is separate from the central security system, sometimes the application will be referred to as "extension" or "internal extension" in this article. In the embodiment shown in FIG. 3, the application takes the form of a DRM module 207. However, other applications may be used, such as applications that provide, for example, e-commerce, banking, credit card, electronic money, biometrics, access control, personal data, or secure email functionality. It should also be noted that although only a single application is shown in the memory device 200 in FIG. 3, the memory device may have several applications (eg, DRM modules and e-commerce modules).

The central security system authenticates an entity attempting to access a portion of the protected data stored in the memory device via an application (eg, a DRM agent) within the memory device via the ACR. Once the entity authenticates to the memory device, the security session is opened 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 associated application to access the protected material. In this way, the central security system acts as the primary gatekeeper for the memory device. As described in greater detail in the above-referenced 11/557,028 patent application, the central security system can also isolate various applications executing on the memory device 200 such that an application cannot access data associated with different applications.

While the central security system provides access control mechanisms and protects the data stored in the memory device such that the data is only accessed by appropriately authorized entities, the central security system itself may not be able to understand and process the particular data it protects. An application executing on a memory device can understand and process protected data. For example, if the protected material is DRM authorized, the DRM agent (rather than the central security system) will be able to validate the authorization. Therefore, the central security system can be considered as a configurable application-independent toolbox. In operation, the service provider places the application on the memory device and defines an ACR that associates the particular entity with the application. From the point of view of the central security system, it does not know what the application is doing (for example, whether the application provides DRM authorization confirmation, or provides e-commerce functionality, etc.), but does know that only entities that are authenticated according to their specific ACR are allowed. Application communication defined 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.

In some cases, central security systems and applications need to know the time. For example, the central security system may need to know the time for time-based authentication (eg, asymmetric authentication), and the application may need to know the time for time-based operations (eg, DRM authorization confirmation). As mentioned above, the memory device has a central time module that provides time to the central security system and applications executing on the memory device. For example, referring to FIG. 3, time module 204 can provide time to asymmetric ACRs 201, 202 to authenticate various entities and provide time to DRM module 207 to verify authorization validity. As will be described below and in conjunction with Figure 8, in some In this case, the application on the memory device can select the host time in addition to or instead of the time module from the memory device.

FIG. 8 shows a memory device 600 in communication with host device 700. Host device 700 includes an entity (here, player 710) and has a mechanism for providing time 720 (eg, a battery powered clock). In this example, memory device 600 has a symmetric ACR 610 (although asymmetric ACR can be used), a time module 620, a DRM module 630, protected content 640, and an authorization 650 for protected content 640. (In Figure 8, the application in the memory device is the DRM module 630. It should be noted that other types of applications can be used and more than one application can be executed in the memory device.) When the player 710 is used by When the memory device 600 is authenticated using the symmetric ACR 610, a secure channel 660 is established between the player 710 and the DRM module 630 based on the parameters established in the symmetric ACR 610. The DRM module 630 and the player 710 are not unfamiliar with each other because the service provider defines a symmetric ACR 610 to associate the DRM module 630 with the player 710. Therefore, there is a certain degree of trust between the DRM module 630 and the player 710 because it is a corresponding member of the same group. Based on this trust, DRM module 630 can be programmed to accept host time 720 from player 710 as a time source to perform DRM authorization confirmation. Thus, the DRM module 630 has two independent time sources that can perform DRM authorization confirmation by the time sources: host time 720 and time from the central time module 620 of the memory device. There are advantages and disadvantages associated with each of these time sources. Since the time module 620 of the memory device does not continuously maintain the tracking time, the time from the time module 620 may not be as good as the host time that may be supplied by the battery powered continuous clock. 720 is generally accurate. On the other hand, due to all of the security prevention discussed above, the time from the time module 620 may be more secure than the host time 720, especially where the user of the host device 700 can change the host by using a simple user interface. In the case of time 720.

An application (such as DRM module 630) executing on memory device 600 can be programmed to use these two different times in any manner required to generate a time estimate for the time-based operation of the application. source. (However, preferably, the application cannot use the host time 720 to update the time module 620.) For example, the application can be programmed to always use the host time 720 instead of the time module 620, or The time from the time module 620 is always used instead of the host time 720. As another example, the application can be programmed to use the host time 720 and the laggard (or preemptor) from the time module 620. The application can also be programmed to use two time sources to generate a time estimate in a manner (e.g., using host time 720 and the average of time from time module 620, etc.). As yet another example, the application can determine which time source to use based on information about the host device 700. The application can learn the type of host device via the authentication process (eg, if asymmetric authentication is used, the authentication algorithm can notify the application of the individual and group identities associated with the host device 700). This information can be important because some host devices may be more secure than other host devices. For example, if the host device is a PC, it is easy to manipulate its clock via a simple user interface on the software application. (In addition to not trusting host time from a relatively untrusted host device, the application may not trust execution with (for example) content confidentiality The entity on the host device, the key, the authorization value or the expiration date or the right to change the authorization. In this case, the DRM agent can only stream the content out of the memory device and reach the host device (rather than giving the encryption key and content to the host device). However, if the host is a closed system such as an MP3 player, the clock of the host may be more difficult to manipulate. Therefore, the application executing on the host device 600 can trust the host time 720 more when the host device 700 is an MP3 player than when the host device 700 is a PC.

In one embodiment, the player 710 pushes the host time 720 to the DRM module 630 as it sends a request to play the song to the DRM module 630. The DRM module 630 then determines whether to use the host time 720 or the time from the time module 620, as described above. Preferably, host time 720 will only be used for a particular login session (which will be a relatively short interval) rather than as an absolute current time measurement for a later session. Alternatively, host time 720 can be stored for future use of the application, with the "time extension" discussed above and other mechanisms (as appropriate) to improve the accuracy of the time. However, preferably the host time is only used for the particular time-based operation of the application and is not used to update the time in the time module 620 (because the application is "extended" and not the same trust group as the central security system) section). Preferably, as described above, the time in the time module 620 is updated using only the trusted time server, which is part of the same trust group as the central security system. It should also be noted that when a number of applications are executed on the memory device 600, each application may have two sources of time: the time from the time module 620 and the time from the host device operating the entity in communication with the application. However, preferably, when the host associated with an application is made It is only used with the application and does not work with other applications associated with different host devices.

As discussed above, an application executing on the memory device 600 (such as the DRM module 630) can be programmed to compare the host time 720 with the time from the time module 620 and use the laggard of the two times (or Preemptive). The host time 720 may be earlier than the time from the time module 620, for example because the host 700 failed to connect to its time server for a sufficient amount of time to cause a time offset in the host time 720 or because the host clock was compromised. As also discussed above, host time 720 can be stored for future use of the application. In combination with these ideas, host time 720 can be stored or later used (either alone or in conjunction with time from time module 620) to compare with times received from different host devices. Based on the comparison, the memory device can decide whether to perform the time-based operation using the time from the current host device or the stored time from the previous host device. For example, a memory device can be programmed to take the preemptive of two times in the case of a "no earlier than" operation based on a time-based operation, and "no later than" in a time-based operation time. In the case of operations, take the laggard of the two times. In this way, timestamps received from other trusted host devices can be used as a reference for a single multi-master anti-recalculation mechanism relative to a single time server.

As also discussed above, a non-time based authentication system, such as symmetric authentication, can be used to authenticate the host device. This allows the application's time-based operations (eg, DMR operations) to be independent of the authentication time server. That is, since only time from the host device or DRM server is used, the time-based operation of the application does not depend on the authentication time server or memory. The time of the time module of the body device. Therefore, for whatever reason, if there is a problem with the authentication time server or if the time-based application chooses not to use the time based on the authentication time server, the time-based application can still execute using the host time. Its operation.

It should be noted that any of the above embodiments may be used alone or in combination. Other embodiments for use with such embodiments are described in the patent application incorporated by reference. Additionally, while such embodiments are currently preferably implemented in SanDisk Corporation's TrustedFlash ^(TM) memory devices, it should be understood that such embodiments can be used in any type of memory device. Moreover, such embodiments can be used in the field of non-memory devices that encounter general problems with inaccurate clocks and the need to know or use time. Additionally, some or all of the actions described above may be performed on the host device (or some other device), and not only on the memory device.

The foregoing detailed description is to be understood as illustrative of the invention The scope of the invention is defined only by the scope of the invention, including the equivalents of the invention. It should be noted that the actions recited in the scope of the claims may be performed in any order, and not necessarily in the order in which they are stated. Finally, it should be noted that any aspect of any of the preferred embodiments described herein can be used alone or in combination with one another.

10‧‧‧System

20‧‧‧ memory device

30‧‧‧ memory device

40‧‧‧ memory device

50‧‧‧Personal Computer (PC)

60‧‧‧Digital media (eg MP3) player

70‧‧‧Hive Phone

80‧‧‧Internet

90‧‧‧Wireless network

100‧‧‧Time server

102‧‧‧Server

104‧‧‧Server

106‧‧‧Server

110‧‧‧Digital Rights Management Server (DRM)

200‧‧‧ memory device

201‧‧‧First asymmetric ACR

202‧‧‧Second Asymmetric ACR

203‧‧ symmetrical ACR

204‧‧‧Time module

205‧‧‧Protected content

206‧‧‧DRM authorization

207‧‧‧DRM module

210‧‧‧Non-volatile memory array/flash memory

220‧‧‧ Circuit Set

230‧‧‧Host Interface Module (HIM)

240‧‧‧Flash Interface Module (FIM)

250‧‧‧Buffer Management Unit (BMU)

252‧‧‧Cryptographic engine

254‧‧‧Host Direct Memory Access (DMA) component

256‧‧‧Flash DMA components

260‧‧‧CPU

262‧‧‧CPU RAM

270‧‧‧ hardware timer block

300‧‧‧Host device

301‧‧‧Media (eg, audio and/or video) player/entity

302‧‧‧Storage application/entity

303‧‧‧Applications/Entities

305‧‧‧Memory device-host device communication channel

315‧‧‧Host device-time server communication channel

325‧‧‧Inter-server communication channel

510‧‧‧"TUP Pass" message

570‧‧‧"TUP Pass" message

600‧‧‧ memory device

610‧‧ symmetrical ACR

620‧‧‧Time module

630‧‧‧DRM module

640‧‧‧Protected content

650‧‧‧Authorization

660‧‧‧Safe passage

700‧‧‧Host device

710‧‧‧ Player

720‧‧ hours

TUP‧‧‧ time stamp update strategy

TUP1‧‧‧ first time update strategy

TUP2‧‧‧ second time update strategy

Figure 1 is an illustration of a system of an embodiment.

2 is a block diagram of a memory device of an embodiment.

3 is an illustration of various functional modules in the memory device of FIG. 2.

4 is an agreement diagram of an asymmetric authentication process of an embodiment.

Figure 5 is a system diagram of an embodiment for obtaining a time stamp.

6 is a flow chart of a method for obtaining an embodiment of a time stamp.

7 is a flow chart of a method for examining an embodiment of a timestamp update policy.

8 is an illustration of a memory device that uses host time for an embodiment of an application executing in a memory device.

200‧‧‧ memory device

210‧‧‧Non-volatile memory array/flash memory

220‧‧‧ Circuit Set

230‧‧‧Host Interface Module (HIM)

240‧‧‧Flash Interface Module (FIM)

250‧‧‧Buffer Management Unit (BMU)

252‧‧‧Cryptographic engine

254‧‧‧Host Direct Memory Access (DMA) component

256‧‧‧Flash DMA components

260‧‧‧CPU

262‧‧‧CPU RAM

270‧‧‧ hardware timer block

300‧‧‧Host device

Claims (13)

A method for performing a time-based operation by an application on a memory device, the method comprising: by using an application on a memory device, wherein the memory device stores protected content and a digital rights management DRM key and authorization for unlocking the protected content: authenticating an entity executing on a host device, the host device communicating with the memory device; determining an identification of the host device; The entity receives a request to perform a time-based operation; and only when the host device is determined to be trustworthy based on the identification of the host device, selecting the time of the host device instead of the time module of the memory device Performing the time-based operation; and performing the time-based operation using the time of the host device, wherein the time-based operation includes confirming a DRM authorization stored in the one of the memory devices. The method of claim 1, wherein the time of the host device is selected instead of the time of the time module only if the time of the host device is later than the time of the time module. The method of claim 1, wherein the time of the host device is relatively more accurate than the time of the time module, and wherein the time of the time module is relatively safer than the time of the host device. The method of claim 1, wherein the time of the host device is not available to update the time module. The method of claim 1, further comprising identifying the entity using the time of the time module. The method of claim 1, further comprising the time of using the host device for only a single session. The method of claim 1, wherein the memory device is operative to: store a time received from the host device, receive a time from a second host device, compare the time of the second host device with the location of the host device The time is stored, and based on the comparison, the time of the use of the host device is determined instead of the time of the second host device to perform the time based operation. The method of claim 1, wherein the memory device is operative to authenticate the host device using a time-based authentication system. A memory device comprising: a memory array storing protected content and a digital rights management DRM key and authorization for unlocking the protected content; and circuitry for communicating with the memory array and operating to: Receiving a request to authenticate an entity executing on a host device; using an authentication method in an access control record ACR and a time module on a memory device to identify the entity, Wherein the ACR associates the entity with an application in the memory device; determining an identification of the host device; receiving, from the entity, a request to perform a time-based operation on the application; Only when the host device is determined to be trustworthy according to the identification of the host device, selecting the time of the host device instead of the time module to perform the time-based operation; and using the time of the host device to execute the time Time based operation, wherein the time based operation includes confirming a DRM authorization stored in the memory device. The memory device of claim 9, wherein the time of the host device is selected instead of the time of the time module only if the time of the host device is later than the time of the time module. The memory device of claim 9, wherein the time of the host device is relatively more accurate than the time of the time module, and wherein the time of the time module is relatively safer than the time of the host device. The memory device of claim 9, wherein the time of the host device is not available to update the time module. A memory device as claimed in claim 9, wherein the circuit is further operative to use the time of the host device for only a single session.