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

Abstract

A memory device for using time from a trusted host device and a method for use therewith are disclosed. In one embodiment, an application on a memory device receives a request to perform a time-based operation from an entity authenticated by the memory device, wherein the entity is running on a host device. The application selects time from the host device instead of time from a time module on the memory device to perform the time-based operation and uses the time from the host device to perform the time-based operation. Other embodiments are disclosed, and each of the embodiments can be used alone or together in combination.

Description

MEMORY DEVICE USING THE TIME FROM A TRUSTED HOST DEVICE AND METHOD FOR USE THEREWITH

This application describes "Method for Improving Accuracy of a Time Estimate," U.S.patent application serial number 11 / 811,284; "Memory Device with Circuitry for Improving Accuracy of a Time Estimate," U.S.patent application serial number 11 / 811,347; "Method for Improving Accuracy of a Time Estimate Used to Authenticate an Entity to a Memory Device," U.S.patent application serial number 11 / 811,289; "Memory Device with Circuitry for Improving Accuracy of a Time Estimate Used to Authenticate an Entity," U.S.patent application serial number 11 / 811,344; "Method for Improving Accuracy of a Time Estimate used in Digital Rights Management (DRM) License Validation," U.S.patent application serial number 11 / 811,354; "Memory Device with Circuitry for Improving Accuracy of a Time Estimate Used in Digital Rights Management (DRM) License Validation," U.S.patent application serial number 11 / 811,348; "Method for Using Time from a Trusted Host Device," U.S.patent application serial number 11 / 811,346; and "Memory Device Using Time from a Trust Host Device," U.S.patent application serial number 11 / 811,345; Each of which is filed herein and incorporated herein by reference.

Some memory devices, such as TrustedFlash ^™ memory devices from SanDisk Corporation, need to know the time to perform time-based operations such as digital rights management (DRM) license validation. Due to the security issues involved in the above operations, the memory device cannot trust the host device to provide the correct time. While the memory device gets the correct time from a trusted component in the network, the host device hosting the memory device cannot connect to the network at the time the memory device needs to know the time. The memory device may be designed to measure the active time, but the time estimate generated from the measured active time may indicate that if the memory device continues to be unable to measure the active time (e.g., power goes down after the memory device measurement starts) Is not a reliable measure of real time. Thus, the time estimate generated from the measured active time indicates only a lower limit of what the actual time is, and the time estimate will not provide the desired accuracy in certain time-based operations. Although the memory device may be equipped with a battery-backed clock to keep a time track even when the memory device is inactive, the clock may add cost to the memory device.

The invention is defined by the claims, and nothing in this section should limit these claims.

By way of introduction, the embodiments described below provide a memory device for using time from a reliable host device and a method for use with the memory device. In one embodiment, the application on the memory device receives a request to perform a time based operation from an entity authenticated by the memory device, where the entity executes at the host device. The application selects the time from the host device instead of the time from the time module on the memory device to perform the time based operation and uses the time from the host device to perform the time based operation. In another embodiment, a request is received to authenticate an entity running on a host device. The entity is authenticated using the authentication method specified in the access control record (ACR) and the time from the time module on the memory device, where the ACR associates the entity with an application in the memory device. A request for an application is received from an entity to perform a time based operation. Time is selected from the time device instead of time from the time module to perform the time based operation, and time from the host device is used to perform the time based operation. In another embodiment, the memory device compares the time received from the second host device with the stored time from the first host device and uses the time from the first host device to perform a time based operation based on the comparison. Determine whether to use the stored time from the first host device. In another embodiment, the memory device uses a time-based authentication system to authenticate the host device, receive time from the host device, and use the time received from the host device to perform a time-based operation. 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.

The present invention has the effect of providing a memory device using time from a reliable host device and a method for use with the memory device.

1 is a diagram illustrating a system of the embodiment.
2 is a block diagram of a memory device of the embodiment;
3 illustrates various functional modules of the memory device of FIG.
4 is a protocol diagram of asymmetric authentication processing of the embodiment;
5 is a system diagram of an embodiment for obtaining a time stamp.
6 is a method flow diagram of an embodiment for obtaining a time stamp.
7 is a method flow diagram of an embodiment for checking a time stamp update policy.
8 is a memory device diagram of an embodiment using host time for an application running on the memory device.

Referring now to the drawings, FIG. 1 is a diagram of a system 10 that will be used to illustrate these embodiments. As shown in FIG. 1, system 10 includes a plurality of memory devices 20, 30, 40 that are removably connected with a plurality of host devices, respectively: a personal computer (PC) 50, Digital media (eg, MP3) player 60, and cell phone 70. The host device is a device capable of reading data from and / or writing data to the memory device. The data may include, but is not limited to, audio media or video files (with or without audio), images, games, books, maps, data files, or software programs. Data is downloaded, for example, from a server to a memory device in a network, preloaded by a manufacturer or another third party, or side-loaded from another device.

The host device may take any suitable form and is not limited to the examples shown in FIG. 1. For example, the host device may be a laptop computer, handheld computer, handheld email / text message device, handheld game console, video player (eg, DVD player or portable video player), audio and / or video recorder, digital It may take the form of a camera, set top box, display device (eg, television), printer, car stereo, and navigation system. In addition, the host device may include mixed functionality. For example, the host device may be a cell phone capable of playing digital media (eg, music and / or video) files in addition to making and receiving phone calls.

Host devices such as PC 50 and cell phone 70 may have the ability to communicatively connect to a network (although other forms of networks may be used, such as the Internet 80 or wireless network 90). Host devices with this capability are referred to herein as " connected devices. &Quot; It should be understood that the "connected device" may not actually always be connected to the network, such as when the cell phone 70 is operating in an unconnected mode or when the PC 50 does not establish an internet connection. A host device that does not itself have the ability to communicatively connect to a network (such as digital media player 60) is referred to herein as an "unconnected device." An unconnected device may be arranged in communication with the network by connecting a connected device and a non-connected device as shown in FIG. 1, where the digital media player 60 is connected to the PC 50. Although connected in this manner, an unconnected device cannot derive information from the network if the unconnected device is not designed for the function (eg a simple MP3 player). In such a situation, a component of the network can push information to the device. While FIG. 1 shows a digital media player 60 connected to a PC 50 via a wired connection, it should be noted that a wireless connection may be used. Similarly, the terms "connection" and "combination" do not necessarily denote a wired connection or a direct connection.

A network (e.g., Internet 80 or wireless network 90) includes a time server 100, to which connected devices (or unconnected devices connected to connected devices) can provide time stamps, and DRM-protected content and Enable access to external components such as, but not limited to, a digital rights management server (DRM) 110 that may provide a license to access the content. Both of these servers will be described in more detail below. Although time server 100 and DRM server 110 are shown as separate devices in FIG. 1, these two servers may be combined into a single device. In addition, these servers may include other functionality. In addition, the time server 100 and the DRM server 110 and other components can be accessed via the Internet 80 and wireless network 90 if desired.

Referring again to the figures, FIG. 2 is a block diagram of an embodiment memory device 200 that may take the form of a memory card or stick. As shown in FIG. 2, memory device 200 includes a nonvolatile memory array (such as flash memory) 210 and a collection of circuits 220. In this embodiment, the nonvolatile memory array 210 is in the form of a solid memory, in particular a flash memory 210. It should be noted that instead of flash, other types of solid state memories can be used. It should also be noted that solid memories such as magnetic disks and optical CDs and other memories may be used. Further, for the sake of simplicity, the term “circuit” will be used to refer to a pure hardware implementation and / or a combined hardware / software (or firmware) implementation. Thus, a "circuit" refers to an application specific integrated circuit (ASIC), a programmable logic controller, an embedded microcontroller, and a single-substrate computer, as well as a processor and computer-readable program code executable by the processor (e.g., , Software or firmware) may be in the form of one or more of the computer-readable media having stored thereon.

The collector of the circuit 210 of FIG. 2 includes a number of components: the components include a host interface module (HIM) 230, a flash interface module (FIM) 240, a buffer management unit (BMU) 250, CPU 260 and hardware timer block 270. HIM 230 provides an interface function for host device 300, and FIM 240 provides an interface function for flash memory 210. The BMU 250 is a crypto-engine 252 and host direct memory access (DMA) component 254 to provide encryption / decryption functionality and a flash DMA to communicate with the HIM 230 and the FIM 240, respectively. Includes a component 256. The CPU 260 executes software and firmware stored in the CPU RAMS 260 and / or the flash memory 210. Hardware timer block 270 will be described below with respect to the memory device's ability to measure time.

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. 2 to simplify the drawing. More information regarding the operation of the memory device 200 and the apparatus can be found in U.S. Pat. Patent application serial numbers 11 / 314,411 and 11 / 557,028, both of which are incorporated herein by reference. Additional information may be found in U.S. Patent Application Serial Nos. 11 / 322,812 and U.S. Patent application serial number 11 / 322,766, both of which are incorporated herein by reference. The components and functionality described in these documents are not to be read in the following claims unless explicitly listed here.

In this embodiment, the memory device 200 stores digital rights management (DRM) keys and licenses for unlocking the protected content stored in the memory device 200. (It should be noted that these embodiments may be used for memory devices that do not store a DRM key and license to unlock protected content stored on the memory device). The DRM keys and licenses may be generated by the memory device 200 or may be generated outside of the memory device 200 (eg, by the DRM server 110) and transmitted to the memory device 200. Since moving with the memory device 200, the protected content is effectively coupled to the memory device 200 instead of the host device 300, so that the protected content can prove to the memory device 200 that the protected content is an authorized device. Can be carried and accessed by a host device of TrustedFlash ^™ memory devices from SanDisk Corporation are examples of memory devices that store DRM keys and licenses on a memory device, so protected content can be moved with the memory device. In some embodiments, memory device 200 may also be a memory device. Since the DRM license is ratified with the DRM keys stored in the case 200, in other embodiments the memory device 200 provides the DRM keys to the host device 300 to ratify the DRM license with the DRM keys.

In this embodiment, the CPU 260 of the memory device 200 executes a secure storage application (SSA) to ensure that only authorized entities with appropriate credentials can access the DRM key and licenses. The computer-readable code for the SSA may be stored in flash memory 210, CPU RAMs 262, or other storage location within memory device 200. SSA is described in more detail in the '028 patent application above. 3 shows various functional modules in the memory device 200 to be used to illustrate the operation of the SSA. As shown in FIG. 3, memory device 200 includes various access control records (“ACR”); First Asymmetric ACR 201, Second Asymmetric ACR 202, and Symmetric ACR 203. The first and second asymmetric ACRs 201, 202 include first and second time update policies TUP1 and TUP2, respectively, which will be described in more detail below. Although multiple ACRs are shown in FIG. 3, the memory device 200 includes only a single ACR.

Each ACR 201, 202, and 203 specifies the authentication method to be used and what kinds of certificates are needed to provide proof of the identity of the entity. Each ACR 201, 202, and 203 includes permissions for performing various actions, such as accessing a DRM key and licenses. Once the ACR has successfully authenticated the entity, the SSA system opens a session in which any ACR's actions are executed. As used herein, the term “entity” refers to any person or entity that attempts to access the memory device 200. An entity can be, for example, an application running 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 (ACRs 201, 202, and 203, respectively). Additional entities (not shown) may also be associated with one or more ACRs 201, 202, and 203.

When an entity starts a login process, it sends a request for authentication that includes the identifier of the associated ACR, which specifies the authentication method to be used and what kinds of credentials are needed to provide proof of the entity's identity. 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 procedures) may be used and may also specify that ACR does not require authentication. In addition to specifying a particular authentication method, the ACR may also include an authorization control record (PCR) that describes the actions that an entity can perform once authenticated.

Some authentication mechanisms (such as one-way and two-way asymmetric authentication using X.509 certificate chains for authentication, for example) are time-based and allow memory device 200 to verify a certificate presented by an entity. It requires you to know the 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 key shared by the entity and its associated ACR is used to authenticate the entity). In asymmetric authentication, time may be needed to evaluate whether certificates, such as RSA certificates and / or Certificate Revocation Lists (CRLs) supplied by an entity, are valid. (As used herein, a "certificate" may be referred to as a single certificate or multiple certificates (eg, a certificate chain) and "CRL" may be referred to as a single CRL or multiple CRLs. Before looking at the mechanisms that the memory device 200 can use to generate a time estimate for performing the validation, a short discussion of certificates and CRLs will be presented in connection with asymmetric authentication.

Asymmetric authentication uses a public key infrastructure (PKI) system, where a trusted certificate authority, known as a certificate authority (CA), issues an RSA certificate to prove the identity of the entities. Entities that wish to establish proof of an identity register register with the CA appropriate evidence to prove their identity. After the identity of the entity is proved to the CA, the CA issues a certificate to the entity. The certificate is the public name of the entity (usually by encrypting the digest of the public key) signed by the name of the CA that issued the certificate, the name of the entity for the person who issued the certificate, the public key of the entity, and the private key of the CA. Contains the key.

The certificate may include a data field that holds the expiration date. In this situation, the entity holding the certificate can only access content protected by the ACR for a limited amount of time (until the certificate expires). The certificate can also include a data field that holds the future valid time. In this situation, the ACR will not authenticate the entity until the certificate is validated. When the memory device 200 determines that the current date is after the expiration date or before the validation date (ie, when the memory device 200 determines that the certificate is invalid), the memory device 200 is an entity presenting the certificate. Will not authenticate.

Various situations (such as name changes, changes in associations between entities and CAs, and compromises or suspected compromises of private keys) can cause certificates to expire prior to the expiration date. Under these circumstances, the CA needs to revoke the certificate. In operation, the CA periodically issues a Certificate Revocation List (CRL), which is a signed data structure containing a time stamped list of revoked certificates. Thus, to authenticate an entity, the memory device 200 checks the CRL to see if the certificate is listed on the CRL as well as checking that the certificate is appropriate. (The CRL may be provided by the entity with a certificate or the memory device 200 may include the CRL itself (eg via the Internet 80 if the memory device 200 is a connected device). If the certificate is listed on a CRL, the certificate is no longer valid (although it has not expired) and the entity will not be authenticated. Like a certificate, a CRL is issued with an expiration date indicating when the CRL is updated. This ensures that memory device 200 uses the most recent CRL. During authentication, if the memory device 200 finds that the current time has passed the expiration date of the CRL (ie, if the memory device 200 determines that the CRL is invalid), the CRL is considered defective and preferably Not used for verification.

As discussed above, in this embodiment, the memory device 200 needs to know the time to verify the certificates (here, the certificate and the CRL). There are several options for letting the memory device know what time it is. One option is to have a time stamp from the trusted time server every time the memory device needs to know the time, ie a memory device request through the host device. This solution is suitable for connected devices; However, not only devices to which a memory device is connected, but also devices that are not connected (eg, home PCs not connected to the Internet, MP3 players, cell phones with network off (eg when on an airplane) Memory devices cannot rely on the available connections when they need to know the time for the authentication procedure Another option is to mount a memory device with a battery-backup clock. This may be undesirable because it adds cost to the memory device Another option is to rely on the host device (from its own internal clock or from an external source) to provide time to the memory device. The device cannot trust the host device to provide accurate time. If allowed to "back date" the clock on the test device (ie, set the clock on the host device to a time earlier than the current time), the user can bypass the actual time restrictions that the memory device needs to enforce. On the other hand, if the memory device (application running on the memory device) trusts the host device, the memory device (or application running on the memory device) may depend on the host device during that time. More information than is presented below.

Another option used in this embodiment is to use the limited time tracking capabilities of the memory device; In particular, the ability of the memory device 200 to measure active time. Active time refers to the time that memory device 200 is connected to the host device and actually used (ie, active on the bus between memory device 200 and host device 300 as compared to being in idle or sleep mode). Optionally, the active time may refer to the total amount of time that the memory device 200 is connected to the host device 300 and receives power from the host device. The terms "active time" and "use time" will be used herein interchangeably. As described below, in this embodiment, the memory device 200 is active when the hardware timer block 270 can generate clock ticks as interrupts to the CPU 260 and the CPU 260. May increment the active time counter.

In operation, hardware timer block 270 (eg, an ASIC controller) includes an oscillator that generates periodic clock ticks and provides the ticks to the CPU 260 as interrupts. (Preferably, the oscillator runs at very low frequencies and runs while the CPU 260 is sleeping). Thus, hardware timer block 270 interrupts CPU 260 periodically (eg, every millisecond or microsecond). When the CPU 260 is interrupted, a specific clock interrupt service routine (eg, in firmware executed by the CPU 260) is called and an active time counter stored in the CPU RAMs 262 and the nonvolatile flash memory 210. By adding in one period / unit, the counter value is not lost if power is lost. To prevent excessive drain on memory 210, instead of responding to every clock tick, the active time counter in memory 210 is periodically (e.g., every minute or the like as long as power is applied to memory device 200). It is desirable to update. Although this may cause additional inaccuracies in the measured time if power loss occurs before the active time counter is updated, this sacrifice is considered acceptable in terms of benefits for memory duration. (To further protect the memory duration, the value stored in the active time count may include a field indicating how many times the counter has been written. If the write value exceeds a certain amount, the counter is placed in a different location in memory. The bits in the counter can be shifted if the help persists). It is also desirable that writing to the active time counter does not affect the performance of memory device 200 (except power consumption to perform writing) and regular activity. (In other words, writing to the time counter is preferably part of the process of serving a host command). For example, writing to the active time counter can be handled as a background task and performed prior to the host device command service. At the end of the host device command, the firmware of the memory device 200 can verify that the programming of the active time counter succeeds by reading the data in the memory and comparing it to the desired value.

In addition, the value of the active time counter can be securely stored in memory 210 (e.g., signed through crypto-engine 252 using a key-hashing message authentication code (HMAC)), so that It is desirable that it cannot be tampered with. In the case of signature mismatching, the data can be treated as uninitiated, as in the case of an attacker tampering. In addition, it should be noted that other mechanisms for measuring active time may be used.

To convert the value stored in the active time counter to real time, the CPU 260 multiplies the value stored by the frequency at which the hardware timer block 270 generates clock ticks. For example, if the value 500 is stored in an active time counter and the hardware timer block 270 generates a clock tick every 5 milliseconds, the CPU 260 may generate an active time of 2,500 milliseconds (500 times 5). Calculate To generate a time estimate, the converted active time is added to the final time stamp received by the memory device 200 from a trusted source. In other words, the time stamp acts as a "start line" and the measured active time of the memory device is added to the time stamp. The time stamp can have any form and can represent time with any desired precision (eg, year, month, day, hour, minute, second, etc.). Preferably, the memory device 200 is provided with a time stamp from an entity that the memory device 200 trusts to provide the entity with the correct time (eg, the time server 100 or a trusted host device). The time stamp may have any form and may be included in other information or transmitted by itself. The memory device preferably stores very few time stamps via the crypto-engine 252 and therefore cannot be easily tampered with. When a new time stamp is received by the memory device 200, the new time stamp is stored in the memory device 200 and the active time counter is reset. Thus, the active time will be measured relative to the new time stamp instead of the old time stamp. Instead of resetting the counter (and therefore "rolling back"), the active time counter value present at the time of the new time stamp is recorded and subtracted from the current time to measure the active time.

The time-tracking capabilities of the memory device have now been discussed and an example of an authentication procedure will be described. Referring again to the drawings, FIG. 4 is a protocol diagram of an asymmetric authentication process of one embodiment. In the following example, layer 301 attempts to log in to memory device 200 via ACR 201. As described in more detail below, the player 301 includes certificates (eg, an RSA key pair, a certificate, and a certificate revocation list (CRL)), and the ACR 201 authenticates the player 301. It is responsible for validating and granting rights to the objects (in this case, establishing a secure channel between the player 301 and the DRM module 207). As shown in FIG. 4, the first step is to have the host device 300 send a request for authentication of 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).

The following series of acts describe the process of providing a time stamp to the memory device 200 and FIGS. 5 and 6, which are system diagrams and flowcharts, respectively, illustrating one specific way in which the memory device 200 can obtain a time stamp. Will be described in relation. It should be understood that the memory device 200 may obtain the time stamp in different ways and that the time stamp may have other forms. It should also be understood that a single memory device interfacing with multiple servers or hosts can handle multiple forms simultaneously. Accordingly, the specification of this example should not be construed as a claim unless explicitly recited herein.

As shown in FIG. 5, the memory device 200 communicates with the host device 300 via a memory device-host device communication channel 305, and the host device 300 is a host device-time server communication channel 315. Communicate with the time server 100 through. Although the time server 100 may comprise 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 an inter-server communication channel 325. As also noted above, instead of using the time server 100 for time stamps, the time stamps from the host device 300 may preferably be used only if they are reliable host devices.

In this embodiment, the procedure for requesting a time stamp is initiated by the host device 300 sending a nonce acquisition command to the memory device 200 (act 405) (see FIGS. 4, 5 and 6). . In this embodiment, the nonce is a 160-bit random number used by the memory device 200 to later verify the authenticity of the time stamp generated by the time server 100. Memory device 200 generates a random number (nons) (act 410) and stores it in CPU RAMS (ie, volatile memory) 262 (or, optionally, memory 210) for later verification steps. Memory device 200 transmits the nonce to host device 300 (act 415). Memory device 200 also begins to measure time (as described below) to later determine if a time-out has occurred.

When the host device 300 receives the nonce, it sends an acquisition time stamp request including the nonce to the time server 100 (act 420). The time server 100 signals the time (eg, world time in UTC Zulu format) and the nonce as a private key. The time server 100 then sends a time stamp response to the host device 300 that includes a nonce, a time stamp, a certificate chain, and a CRL chain in this embodiment (act 425). (This certificate and CRL are sent from the time server 100 for authentication and not the same as the certificate and CRL sent for authenticating the player 301). The host device 300 then sends a time update command with this response to the memory device 200 (act 430). In response to this command, memory device 200 attempts to verify the credentials and CRLs (act 435). (Again, the certificate and CRL are different from those sent to authenticate the player 301). As discussed below, it is desirable to assume that the validity period for the 100 certificate and the CRL of the time server is valid, instead of checking the validity for the time estimate generated by the memory device 200. If verification fails, memory device 200 resets volatile memory 262 and returns to an idle process (act 440). If the verification of the certificate and CRL passes (act 445), memory device 200 compares the nonce in volatile memory 262 with the nonce in response (act 450). If the comparison fails, the memory device resets volatile memory 262 and returns to 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 protect tampering.

It should be noted that after memory device 200 generates nonce 410 and waits for a response (act 460), host device 300 may send another acquire nonce command to memory device 200 (act 465). do. As mentioned above, the memory device 200 begins to measure time after the nonce has been generated. If a new nonce command 465 is received before the measured time reaches a specific time-out limit, the memory device 200 preferably ignores the new nonce command 465. However, if a new nonce command 465 is received after the time-out limit, the memory device 200 will reset the volatile memory 262 and generate a new nonce (act 470). Thus, the nonce is only valid for a limited time, and the time-out limit (“travel time error”) is the maximum time that the memory device 200 considers to be legitimate to wait for a time stamp from the time server 100.

Since the time stamp stored in the memory device 200 includes the time at which the time server 100 signals the data string, the time indicated in the time stamp is the time stamp precision (e.g., year, month, day, hour, minute). , Seconds, etc.) and the delays involved in sending the request and receiving the response, are not the actual real time the host device 300 requested the time stamp or the actual real world in which the memory device 200 stored the time stamp. It may not be time. The nonce time-end period described above may be set to that time to ensure that the time stamp has the precision required by the memory device 200. Thus, memory device 200 has control over the maximum allowable delay in requesting a time stamp. Further, in other embodiments, the time stamp generated by the time server 100 may be an estimated time at which the host device 300 requested a time stamp, an expected time for the time stamp to be stored in the memory device 200, or some It can refer to some other time, such as another time.

The protocol allows memory device 200 to communicate with time server 100 over an unsecured connection system (eg, the Internet, WiFi network, GSM network, etc.). The connection system is not secure in the sense that the memory device 200 cannot assume that the time stamp sent by the time server 100 is not tampered during transmission. Since the network cannot rely on protecting the time stamp, the protection mechanism (or some other protection mechanism) can be used between the server 100 and the memory device 200. The encryption protocol allows the memory device 200 to detect when the time stamp is tampered with. In other words, because the access system is not secure, the system itself cannot prevent people from changing the bits of the time stamp; However, memory device 200 may detect tampering and reject the time stamp. In another embodiment, a secure communication system is used (ie, data communication lines are protected), and the time stamp can be transmitted as plain text because it cannot tamper with the time stamp.

Referring to FIG. 4, a new time stamp is stored in the memory device 200 so that the memory device 200 sends a “time update success” message back to the host device 300 (act 452) and the host device 300 Sends back a request for authentication to the memory device 200 (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 the time stamp, time estimate biasing in the old time stamp can lead to inaccurate time estimates. Thus, the TUP is used to determine when an existing time stamp on the memory device 200 is considered outdated and requires playback (ie, a new time stamp). As shown in FIG. 3 and discussed in more detail below, other ACRs may have other TUPs that may be generated when an ACR is generated (ie, other ACRs may have different time tolerance levels).

In this embodiment, the TUP is represented by four values: (1) threshold number of power cycles, (2) threshold of active time, (3) threshold of "extended" active time, and (4) A bit indicating whether or not an OR relationship exists between the parameters (ie, whether a time update is required only if a single parameter fails, or whether 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 may be considered in addition to or instead of these).

7 is a flow chart illustrating test TUP acts in more detail (act 500). First, a check is made to determine whether the memory device 200 has begun examining the TUP by looking for configuration data stored in the memory 210 (act 505). If the memory device 200 does not begin to check the TUP, the memory device 200 uses the last time stamp received by the memory device 200 to generate a time estimate (act 510) and performs a time estimate. An attempt is made to authenticate the entity. When the memory device 200 starts to check the TUP, the memory device 200 starts to check it.

First, memory device 200 determines whether the TUP after the last time stamp includes checking the number of power cycles of memory device 200 (act 515). In this embodiment, this is done by checking the "power cycles" value described above. If the value of "power cycles" is zero, the number of power cycles is not checked. If the "power cycles" value is non-zero, the number of power cycles is checked using that value as the threshold. The number of power cycles is a count of how much power the memory device 200 has powered up, and a count that indicates how much power has been powered down by the memory device 200 since the last time stamp (ie, during every power up, power down Should be). The number of power cycles can be measured by the CPU 260. Each time the memory device 200 proceeds through a power cycle, the CPU 260 may call a device reset routine in firmware. As in the situation where the CPU 260 adds one unit to the active time counter, due to the device reset routine, the CPU 260 adds one unit to the power cycle counter of the CPU RAMS 262 and / or the memory 210. Add. Due to the active time counter, the power cycle counter can be updated periodically to reduce memory consumption.

When the memory device 200 is powered down, there is at least some actual time that is not provided by the measured active time (since the active time cannot be measured if the memory device 200 is not "active"). Since the memory device 200 does not know how many passes between power cycles, the number of power cycles does not indicate how inaccurate the measured active time is. However, a aspect of whether the memory device 100 is used outside of the expected usage pattern provides, and the expected usage pattern can roughly indicate how inaccurate the measured active time is. For example, a time estimate is made when memory device 200 has 10 power cycles, because the last time stamp is a time estimate made when memory device 200 has only one power cycle after the last time stamp. Because it can be less accurate.

If the TUP includes checking the number of power cycles, the memory device 200 powers up the memory device 200 after the last time stamp to see if the number of power cycles exceeds a threshold amount set at the "power cycles" value. Check the number of cycles (act 520). The threshold number can be configured per ACR to reflect the target time tolerance. For example, if authentication is very sensitive and needs to be guaranteed that the expiration date of the certificate or CRL has not passed, the threshold number may be set to one. Thus, once memory device 200 is shut down (and therefore there is at least some amount of time that cannot be accounted for by the measured active time), the TUP check of this parameter fails. On the other hand, if authentication is not sensitive, the number of power cycles is set to a higher number (or not considered at all) so that the TUP check can be performed even if some number of power cycles are present (and thus, by the measured active time). Some amount of time that cannot be accountable for) passes.

If the check of the number of power cycles fails and it is determined that there is an OR relationship between the TUP parameters (act 525), the TUP check fails (act 530). The memory device 200 sends a message indicating the failure to the host device 300 and the above described procedure is used to obtain a new time stamp. If a check of the number of power cycles passes or fails and it is determined that there is no OR relationship between the TUP parameters (act 525), the process continues by determining if the TUP includes a check of active time since the last time stamp (act 535).

Similar to the power cycle procedure described above, if the "active time" value is zero, the active time is not checked. However, if the "active time" value is different from zero, the active time is checked using the value as the threshold number of seconds (or some other unit of time). Due to the number of power cycles, the threshold active time amount can be configured per ACR to reflect the desired time tolerance. In general, the longer the memory device 200 is active, the more inaccurate the measured active time. Thus, if authentication is very sensitive and needs to be guaranteed that the expiration date of the certificate or CRL has not passed, the threshold amount of measured active time can be set very low. Conversely, if authentication is not sensitive, the threshold of measured active time can be set higher (or even not considered at all).

If the check of active time fails and it is determined that there is an OR relationship between the TPU parameters (act 545), the TUP check fails (act 550). The memory device 200 sends a message indicating the failure to the host device 300 and the above procedure is used to obtain a new time stamp. If the check of active time passes or fails and it is determined that there is no OR relationship between the TUP parameters (act 545), the process continues by determining whether the TUP includes a check of the "extended" active time (act 555).

As noted above, the measured active time may not be a true measure of the actual active time for which the memory device 200 does not continuously measure the active time. That is, if memory device 200 is "inactive" (eg, when memory device 200 is idle or in sleep mode, or memory device 200 is powered down or memory device 200 is removed from host device 300). When-in this embodiment, the hardware timer block 270 stops generating clock ticks and / or whatever event the CPU 260 stops responding to the ticks), when the measured active time is inactive It would be less than the actual time passed since the measurement started because there is nothing in the memory device 200 to say that time passes. For example, assume that a time stamp was received on January 1 and the memory device 200 measured an active time of two days. (For simplicity, time is measured in day units in this example. However, as noted above, any desired time unit may be used). Thus, the time estimate generated by the memory device 200 at this point indicates that the day is January 3 (ie, by adding two days of active time to the final time stamp of January 1). If the memory device 200 continuously measures active time, this time estimate accurately represents the actual time (assuming hardware timer block 270 and CPU 260 function correctly). However, if memory device 200 does not continuously measure active time (ie, if it is inactive at any point after memory device 200 begins measuring active time), the time estimate does not accurately represent the actual time. Best of all, the time estimate indicates that the actual time is at least January 3rd. The actual time may be January 4 or some later day (June 29, November 2, December 5, next year, etc.). Thus, checking the active time in act 540 may not provide accurate results.

To address this problem, the TUP includes an "extended" active time check (acts 555 and 560). The "extended" active time is the result of adjusting the measured active time based on the determined accuracy of the previously measured active time. Thus, if the memory device 200 measures 3 days of active time and knows that the last time (s) measured is the active time, a value of 50% of the actual time is formed, and the memory device 200 is 6 days The measured active time of 3 days can be doubled (or "extended") to form (since the measured active time was 50% of the actual time). Additional information regarding "extended" active time can be found in "Method for Improving Accuracy of a Time Estimate from a Memory Device" in U.S. Patent Application Serial No. 11 / 811,284 and "Memory Device with Circuitry for Improving" in U.S. Patent No. 11 / 811,347. Accuracy of a Time Estimate, which is filed with and incorporated herein by reference.

Instead of an "extended" active time, a "strecthed down" time can be used. The down time refers to the amount of time that the memory device 200 is inactive between time stamps. Since there is no way to measure how long memory device 200 is not active, the down time is a calculated number; Specifically, down time = actual time between time stamps-active time. The "stretch" down time calculation is adjusted based on the determined accuracy of the previously measured active time (or down time based on the measured active time). The following is a list of examples of other down-time changes that may be considered. "DownTime" in this list is referred to as "extended" down time (eg, the average of down time between time stamps of previous knowledge).

Total Down Time Estimation (teDownTime): teDownTime = (timestamp _i -timestamp _{i -1} -ActiveTime _i ), where index i proceeds from the second time stamp to the last time stamp configured in memory device 200.

Current downtime since last time stamp for a particular moment. This is the number of power cycles (pc) since the last timestamp update (cDowntime = PC * (teDownTime / PC) since the last timestamp) or active time after the last timestamp update {cDowntime = ActiveTime * (teDownTime / ActiveTime after the last timestamp) )}.

If the DownTime parameter is configured not to be used, the down time value is set to zero.

If the downtime parameter is configured to be used, the downtime is set to one. Memory device 200 uses the down time feature to evaluate when a time stamp update is needed in the following manner: Service Time (e.g., validity of certificate or validity of CRL)-time evaluation <down time, Timestamp update is required).

Referring to FIG. 7, if the check of the "extended" active time fails (act 560), the check of the TUP fails (act 565), and the memory device 200 sends a message to the host device 300. . The above procedure is used to obtain a new time stamp. If the check of the "extended" active time passes (or the memory device 200 does not start to check for TUP), the memory device 200 sends a "TUP pass' message 510,570 back to the host device 300. (See Fig. 4) The host device 300 sends the entity's certificate 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 time stamp and the measured active time to validate the certificate (act 585) and to validate the CRL (act 590). After evaluation, the memory device 200 sends an OK message back to the host device 300, and if so, other steps of the authentication method can be performed. Approves entity rights for the objects (where by establishing a secure channel between player 301 and DRM module 207), otherwise, if the certificate and / or CRL expire, the memory device 200 fails the authentication attempt. Send a message to the host device 300. The host device 300 may in turn start a time stamp update as described above.

As noted above, the time estimate for the authentication attempt is generated by adding the measured active time to the final time stamp. Since the measured active time may be inaccurate, the “time extension” techniques described above may be used to improve time estimation accuracy. However, it is possible that the "extended" active time can actually be greater than the actual time. When checking the TUP, the "over-extended" active time results in a new time stamp. However, when verifying a certificate or CRL, the "over-extended" active time can prevent the proper entity from authenticating. Thus, it may not be desirable to use a "time extension" when generating a time estimate for authentication.

In summary, in the method, memory device 200 receives a request to authenticate an entity and prior to an attempt to authenticate the entity, memory device 200 determines if a new time stamp is needed. If a new time stamp is needed, the memory device 200 attempts to authenticate the entity by obtaining a new time stamp by generating a time estimate based on the new time stamp and comparing the time estimate against the certificate and / or CRL validity period. . If a new time stamp is not needed, the memory device attempts to authenticate the entity by generating a time estimate based on the final time stamp and comparing the time estimates for the certificate and / or CRL validity periods.

In this embodiment, it should be noted that the TUP is checked and, if necessary, a new time stamp is obtained before authenticating the entity. In other words, checking a TUP and getting a new time stamp does not require the entity to be authenticated before checking the TUP or before a new time stamp is obtained. This is in contrast to systems that use a single server to provide both time stamps and DRM licenses. The server requires memory device authentication before providing a time stamp (or other information) to the memory device. This provides a "catch 22" situation for authenticating the server and requires a new time, but a new time stamp can only be obtained after the server is authenticated. To avoid this situation, some older systems do not use time in the authentication process. While avoiding the " catch 22 " situation, the ignore time can lead to authenticating an entity that should not be authenticated (eg because the certificate and / or CRL has expired).

By dividing the time server 100 from the entity attempting to authenticate with the memory device 200, the memory device 200 creates an "empty channel" between the player 301 and the time module 204 of the memory device. The player 301 then forwards the time stamp update from the time server 100 (see FIG. 3). This time stamp is used to generate a time estimate during which the entity's credentials can be validated for authentication. An "empty channel" refers to a communication pipeline established without first authenticating an entity. In contrast, a "secure channel" refers to a communication pipeline that is established only after an entity has been authenticated.

Although the player 301 does not need to be authenticated to be used as a conduit for supplying the time stamp from the time server 100 to the memory device 200, the time server 100 preferably generates a time stamp from a trusted source. It should be noted that certification is done to ensure that it is done. This is shown in act 435 of FIGS. 4 and 6, where the 100 certificate and CRL of the time server are verified before allowing the time stamp. However, to avoid the "catch 22" situation described above, it is assumed that the memory device 200 is valid for the 100 certificate of the time server and the CRL is valid and therefore does not verify the validity periods for the generated time estimate.

When an entity is authenticated to the memory device 200, it may perform various actions shown in the admission control record (PCR) of the ACR. For example, referring again to FIG. 3, the player 301 may communicate with the DRM module 207 via a secure channel to access the protected content 205 of the memory device 200. (As another example, the ACR for the storage application 302 causes the application 302 to store the protected content 205 in the memory device 200). Although the player 301 is authenticated, because the content is protected, the DRM module 207 attempts to validate the DRM license 206 for the protected content 205 before unlocking the protected content (eg For example, by determining whether a license is still valid or has expired). To this end, the DRM module 207 requests time evaluation from the time module 204 of the memory device 204. (The time module 204 includes the software described above used to store and generate various components used to generate time estimates (e.g., time stamps, active times, number of power cycles, "extended" elements, etc.); / Or hardware). The DRM module 207 compares the generated time estimate with the expiration date and / or expiration date of the license 206 to determine whether the license is valid. DRM module 207 may perform additional checks to validate a license, such as, but not limited to, determining whether protected content 205 has been played more than a certain number of times.

As noted above, the more recent the time stamp is, the more accurate the time estimate will be. In this embodiment, the TUP of the ACR determines if a time stamp update is needed. Thus, the TUP effectively determines how accurate the generated time estimate is for DRM license validation. When determining the parameters of the TUP, you will find a balance between the need of service providers to provide services in consideration of expiration and the need of end users, which may be inconvenient when it is necessary to connect host devices to the network to obtain a new time stamp. There is a need. If time tolerances are too sparse, service providers can lose income. On the other hand, if the time tolerance is too strict, the end user may decide to leave the service if frequent connections to the network are too burdened to obtain the required time stamp update.

When memory device 200 has a single ACR with a single TUP (or all multiple ACRs sharing the same TUP), a single "one size fits all" TUP finds the right balance for all service providers. You may not be able to. Thus, in this embodiment, memory device 200 has multiple ACRs 201 and 202 with different TUPs (TUP1, TP2), each of which can be configured by an associated service provider. As discussed above, through the use of other ACRs, memory device 200 may be configured to authenticate using other authentication schemes (symmetric, asymmetric authentication, etc.). The use of other ACRs allows for configurable time tolerances. That is, through the use of configurable TUPs of ACRs, service providers can use one or more of the time-validating parameters (eg, active time, number of power cycles, “extended” active time / down time) of a memory device. The anomaly is considered outdated and you can define your own time tolerance by specifying when the time stamp update should be triggered. By forming configurable TUPs, the service provider can configure time tolerances according to the specific needs and relationships of the end users instead of relying on a single “one size fits all” TUP.

For example, some service providers generate certificates for a very short time (eg 10 minutes). By having the end user get a new certificate every hour he wants to use the service on the desired memory device 200, the service provider can closely monitor the end user's behavior and evaluate the hourly cost that the end user requires the certificate. . Thus, for this business model, service providers need strict tolerances for currency definition. As another example, if the service provider has a highly flexible installation base of end users, the service provider may want to frequently invoke the certificate as a major part of the business model. In this situation, the service provider wants a tight time tolerance to ensure that the most recent CRL is used for authentication. On the other hand, if a service provider provides a monthly subscription service where users regularly access the service provider's website in order to obtain new content and receive compulsory time stamp updates, the service provider may not be able to access the network for end users to obtain new content. Connections do not require time tolerances strictly.

Instead of or in addition to using configurable TUPs on ACRs, a configurable TUP may be placed on DRM licenses for separate pieces of content. In this way, instead of an authenticated entity that handles all the pieces of content equally, the entity may get a new time stamp for some content while using an existing time stamp for other content. (Unlike TUP on ACR, which is only checked during authentication, a TUP under license can be checked every hour that DRM module 207 attempts to validate a license).

For example, consider a situation where a user downloads a two hour movie to his memory device according to a license that states that the movie can only be watched for 24 hours. The service provider may not want the user to watch the movie after the 24 hour period, but he does not want to inconvenience the normal user by connecting to the network to get a new time stamp. Thus, the service provider may decide to place a TUP on a license that requires a new time stamp if the active time is 4 hours or more (the amount of active time required to watch a 2 hour movie twice). If the active time is greater than 4 hours when the DRM module 207 attempts to validate the license, the user will not be able to watch the movie-not necessarily because the license expires, but because a new time stamp is required. (Instead of or in addition to the active time, the number of power cycles may be used for the TUP. For example, based on the average usage pattern, 10 or more power cycles may indicate that the memory device has been used for more than 24 hours.) . If the time estimate generated with the new time stamp is valid and points to the license, the DRM module 207 will cause the movie to be played again.

By having a TUP per license configured, the TUP can be customized for its content. Thus, if the movie expires after one week, instead of expiring the movie after 24 hours, the time tolerance on the license may be set differently. For example, if the service provider evaluates that the memory device is used on average 10 hours a day, the service provider may be in license to trigger a time update after 70 hours of active time (i.e., 7 times 10 hours a day). TUP can be set. As another example, instead of a two-hour movie, if the content is a three-minute pay-per-view video that must be watched once, the TUP can be designed such that a new time stamp is required after three minutes of active time. have.

The business model of the service provider can be considered in specifying the TUP. For example, at present, the monthly subscription service is a popular business model for allocating rights to protected music. In a music subscription service, a user downloads a lot of the desired music from the service provider's website and lets him play the desired music several times during the month. After that month, the user will need to renew his subscription to renew the license; Otherwise, the license expires and the user will no longer be able to play the music stored on his memory device. Users who frequently visit the service provider's website for more songs will receive a new time stamp when connecting to the website; Thus, memory devices will provide a more accurate time estimate. However, users downloading a relatively large amount of music are not necessarily able to reconnect to the service provider's website before the license expires every month. When the user ultimately reconnects for more music, the service provider may charge the user for the time he plays music outside of the license terms. Because of this, as a business model, a service provider for a subscription on a monthly basis may want a different time tolerance than the service provider of pay-per-use content, where the user is responsible for the pay-per-use content You may not be able to proceed back to the website if you receive a. In this situation, because the user is more likely to go back for more music on the subscription service on a monthly basis than the pay-per-use service, the service provider may ask the customer by asking for a new time stamp even though he ultimately returns to the website. You may not want a tight time tolerance that can be embarrassing. Having a less stringent time tolerance allows customers who never return to the service provider's website to play music for longer than the license's one month period (eg, one month of active time instead of one month of actual time). You can do it. However, in consideration, the service provider may determine that the unauthorized use is an acceptable sacrifice in order to prevent customers return inconvenience and embarrassment.

As another embodiment, consider a business model where a user wants to provide a point for a service provider to advertise a cell phone when a user uses his cell phone to play audio or video content from a memory device. If the point ad includes advertisements related to repositories near the location of the cell phone at the time the content is played, then the host device needs to be connected to the network when the content is played; Otherwise, location-specific point advertisements may not be delivered. To ensure this occurrence, the TUP of the content may be set in a very small amount (eg, one minute of active time) to ensure that the user connects to the network to obtain a new time stamp. Once the user connects to the network, the network knows the location of the cell phone and can push the appropriate advertising content to the cell phone. On the other hand, if the service provider can make money by knowing how much content is played, the time tolerance may be less stringent.

As shown by the above examples, through the use of configurable TUPs on license files, the service provider of a particular content does not embarrass customers by requiring him to connect the host device to the network during a time stamp update. You can be notified whenever you balance the time updates you think are appropriate. Since the memory device in this embodiment is a multi-purpose, multi-application memory device with multiple TUPs, it should be noted that one service on the memory device can be shut down after a certain time and the other services on the memory device are still enabled. do. That is, although authenticated, the player may play certain content on the memory device but may not be able to play other content on the memory device unless a new time stamp is obtained due to different TUPs associated with licenses of other content. .

As shown above, in these embodiments, the memory device includes two independent configurations: a central security system and one or more applications separate from the central security system. (Since the application is isolated from the central security system, the application can sometimes be called "extended" or "internal extension" here). In the embodiment shown in FIG. 3, the application takes the form of a DRM module 207. However, other applications may be used, for example e-trade, banking, credit cards, electronic money, life measurement, access control, personal data, or secure email functions may be provided. 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, a DRM module and an e-trade module).

The central security system authenticates the entity attempting to access protected pieces of data stored on the memory device through applications in the memory device (eg, DRM agent) through the use of ACRs. Once an entity authenticates a memory device, a secured session is opened between the entity and the application specified by the ACR used to authenticate the entity. The entity can then send commands / requests to the associated application to access the protected data. In this way, the central security system acts as the main gatekeeper to the memory device. As described in detail in the 11 / 557,028 patent application described above, the central security system can separate various applications running on the memory device 200 such that one application cannot access data associated with another application.

While the central security system provides an access control mechanism and protects the data stored in the memory device so that the data is accessed only by appropriate authorized entities, the central security system itself cannot understand and process the very data it protects. There are applications running on memory devices that can understand and process protected data. For example, if the protected data is a DRM license, the DRM agent-not the central security system-can validate the license. Thus, a central security system can be considered an application-independent toolbox that can be configured. In operation, a service provider defines an ACR that places an application on a memory device and associates the application with a particular entity. At the point of view of the central security system, it is not known what application is being performed (e.g., the application is validating DRM licenses, e-trade functions, etc.) but merely allowing entities authenticated to a particular ACR to communicate with the applications defined in the ACR. Is allowed. Once an entity is authenticated by the central security system, the central security system opens a secure channel between the entity and the application.

In some situations, the central security system and application need to know the time. For example, the central security system does not need to know the time for time-based authentication (eg asymmetric authentication), and the application needs to know the time for time-based operation (eg DRM license validation). There can be. As noted above, the memory device has a central time module that can provide time to both the central security system and the applications running on the memory device. For example, referring to FIG. 3, module 204 not only provides time to asymmetric ACRs 201 and 202 to authenticate various entities, but also provides time to DRM module 207 to validate licenses. can do. As will be discussed below with respect to FIG. 8, in some situations, an application on a memory device may choose to use host time in addition to or instead of time from the memory device's time module.

8 illustrates a memory device 600 in communication with a host device 700. Host device 700 includes an entity (here player 710) and has some mechanism (eg, a battery backup clock) for providing time 720. In this embodiment, memory device 600 includes symmetric ACR 610 (although asymmetric ACR may be used), time module 620, DRM module 630, protected content 640, and protected content ( License 650 for 640. (In Figure 8, the application of the memory device is a DRM module 630. It is noted that other types of applications may be used, and one or more applications may be executed within the memory device). When the player 710 authenticates to the memory device 600 using the symmetric ACR 610, the secure channel 660 establishes the player 710 and the DRM module 630 according to the parameters set in the symmetric ACR 610. Is set between. The DRM module 630 and the player 710 are not known to each other because the service provider defines a symmetric ACR 610 to associate the DRM module 630 with the player 710. Thus, there are certain levels of reliability between the DRM module 630 and the player 710 because they are counterpart members of the same group. Based on this reliability, DRM module 630 may be programmed to allow host time 720 from player 710 as a source of time to perform DRM license validation. Thus, the DRM module 630 has two independent sources of time that can perform DRM license validation: 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. Because the time module 620 of the memory device does not continue to track the track of time, depending on the time module 620 may not be accurate at the host time 720 provided by the battery backup continuous clock. On the other hand, due to all the security precautions described above, over time module 620 may be able to change host time 720, particularly if a user of host device 700 can change host time 720 using a simple user interface. It can be safer.

An application running on memory device 600 (such as DRM module 630) may be programmed to use these two different time sources in a desired manner to generate a time estimate for time-based operation. (However, it is desirable for the application to not be able to update the time module 620 using host time 720). For example, an application may be programmed to always use host time 720 instead of time from time module 620 or always use time from time module 620 instead of host time 720. As another example, an application may be programmed to use the slow (or name) of host time 720 and the time from time module 620. The application can be programmed to generate a time estimate using both time sources (eg, taking the average of time from host time 720 and time module 620, etc.). As another example, an application may determine which time source to use for use based on information about the host device 700. The application may learn the type of the host device through an authentication process (eg, if asymmetric authentication is used, the authentication algorithm may inform the application of the individual and group identities associated with the host device 700). This information may be important because some host devices may be more secure than others. For example, if the host device is a PC, the clock can be easily manipulated through a simple user interface on a software application. (In addition to trusting host time from a relatively untrusted host device, an application cannot trust an entity running on the host device using, for example, content keys, license values or durations, or license change rights.) In a situation, the DRM agent may cause the content of the memory device to flow to the host device (instead of providing encryption keys and content to the host device), however, if the host is a closed system such as an MP3 player, the host's clock may It may be more difficult to steer, therefore, an application running on host device 600 may be more reliable at host time 720 than when host device 700 is an MP3 player than when host device 700 is a PC. .

In one embodiment, player 710 pushes host time 720 to DRM module 630 when sending a request to DRM module 630 to play a song. 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 be used only during a particular login session, which is a relatively short interval, instead of being used as an absolute current time measure during later sessions. Optionally, host time 720 may be stored for future use by the application, and the "time-extension" and other mechanisms discussed above are (optionally) used to improve the accuracy of that time. However, it is desirable that the host time is used only for a specific time-based operation of the application and not used to update the time of the time module 620 (because the application is "extended" and part of a reliable camp, such as a central security system). Is not). Preferably, the time in time module 620 is only updated using trusted time servers (which are part of the same trusted camp as the central security system) as described above. It should be noted that when some applications run on the memory device 600, each application may have two time sources: from the time module 620 and from the host device operating the entity communicating with the application. time. However, it may be desirable for a host time associated with one application to be used only for that application and not for other applications associated with other host devices.

As noted above, an application running on memory device 600 (such as DRM module 630) may be programmed to compare the time from time module 620 with host time 720 and use the slower (or name) of the two times. Can be. For example, the host time 720 may be from the time module 620 because the host 700 may not be able to contact the time server or the host clock has been hacked for a sufficiently long time that time asymmetry occurs at the host time 720. It can be earlier than time. As also noted above, host time 720 may be stored for future use by the application. Combining these ideas, host time 720 may be stored and later used (alone or with time from time module 620) to compare with the time received from another host device. Based on the comparison, the memory device may determine whether to use the time from the current host device or the time stored from the previous host device to perform the time based operation. For example, the memory device may be programmed to take the name of two times if the time based operation is "earlier" than the operation and take the slower of the two times if the time based operation times are "slower" than the operation. . In this way, time stamps received from other trusted host devices can be used as a reference for a single multi-host anti-rollback mechanism in relation to a single time server.

As noted above, a non-time based authentication system (such as symmetric authentication) can be used to authenticate the host device. This makes the time-based operation of the application (eg, DMR operation) independent of the authentication time server. That is, because only time from the host device or DRM server is used, the time-based operation of the application does not depend on time from the time module of the authentication time server or memory device. Thus, for any reason, if there is a problem with the authentication time server or if the time-based application does not choose to use time based on the authentication time server, the time-based application may use host time to perform its operation.

It should be noted that any of the above embodiments may be used alone or in combination. Other embodiments that can be used in these embodiments are described in patent applications incorporated by reference. In addition, while these embodiments are currently preferred to be implemented in a TrustedFlash ^™ memory device by SanDisk Corporation, it should be understood that these embodiments may be used with any type of memory device. In addition, these embodiments may be used for non-memory device fields when faced with the common problem of having an incorrect clock and needing to know or use time. Additionally, some or all of the above described acts may be performed exclusively at the host device (or some other apparatus) instead of the memory device.

It is intended that the above detailed description be understood and not as a definition of the invention and as illustrations of selected forms that the invention may take. The following claims are intended to cover all equivalents intended to define the scope of the invention. The acts listed in the claims may be performed in any order-not essential to the order in which they are listed. Finally, it should be noted that any aspect of any of the preferred embodiments described herein may be used alone or in combination with each other.

100; Time server 110; DRM server, 80; Internet, 270; Hardware timer block, 254; Host DMA, 252; Crypto-engines, 256; Flash DMA, 300; Host device 210; Flash memory, 303; Application, 301; Player, 302; Storage application, 203; Symmetric ACR, 201; Asymmetric ACR, 202; Asymmetric ACR, 204; Time module 205; Protected content, 207; DRM module, 206; License for Protected Content

Claims (19)

A method for performing a time-based operation with an application on a memory device,
In an application on a memory device,
Receiving a request to perform a time-based operation from an entity authenticated by the memory device, wherein the entity is executed at a host device;
Selecting a time from the host device instead of a time from a time module on the memory device to perform the time based operation;
Using the time from the host device to perform the time based operation
And a time based operation with an application on the memory device. 2. The time-based operation of an application on a memory device as recited in claim 1 wherein time from the host device is selected instead of time from the time module only if time from the host device is slower than time from the time module. How to do it. The method of claim 1, further comprising determining an authentication 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. A method for performing time-based operations with an application on a memory device. The time on application as recited in claim 1 wherein time from the host device is relatively more accurate than time from the time module, and time from the time module is relatively safer than time from the host device. Method for performing the background action. The method of claim 1, wherein time from the host device cannot be used to update the time module. 10. The method of claim 1, further comprising using time from the time module to authenticate the entity. 2. The method of claim 1, further comprising using the time from the host device only for a single session. 4. The method of claim 1, wherein the time based operation comprises a digital rights management (DRM) license validation operation. The method of claim 1, wherein the memory device stores a digital rights management (DRM) key and a license for unlocking protected content stored on the memory device. . The memory device of claim 1, wherein the memory device stores a time received from the host device, receives a time from a second host device, and compares a time stored from the host device with a time from the second host device. And determine to use the time from the host device instead of the second host device to perform a time based operation based on the comparison. 2. The method of claim 1, wherein the memory device is operative to authenticate the host device using a non-time based authentication system. As a memory device,
A memory array,
Communicate with the memory array,
Receive a request to authenticate an entity running on a host device,
Authenticate the entity using an authentication method specified in an access control record (ACR) and time from a time module on a memory device, where ACR associates the entity with an application in the memory device,
Receive a request from the entity for the application to perform a time based operation,
Select time from the host device instead of time from the time module to perform the time based operation,
To use time from the host device to perform the time based operation
Operating circuit
Including a memory device. The memory device of claim 12, wherein the time from the host device is selected instead of time from the time module only if time from the host device is slower than time from the time module. 13. The memory device of claim 12, 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. 13. The memory device of claim 12, wherein time from the host device is relatively more accurate than time from the time module, and time from the time module is relatively safer than time from the host device. 13. The memory device of claim 12 wherein time from the host device cannot be used to update the time module. The memory device of claim 12, wherein the circuitry is further operative to use time from the host device only for a single session. 13. The memory device of claim 12 wherein the time based operation comprises a digital rights management (DRM) license validation operation. The memory device of claim 12, wherein the memory device stores a digital rights management (DRM) key and a license to unlock protected content stored on the memory device.

Images