KR101465555B1 - Memory device with circuitry for improving accuracy of a time estimate used to authenticate an entity and method for use therewith - Google Patents

Abstract

A memory device having a circuit for improving the time estimation accuracy used to authenticate an entity and a method for use with the memory device are disclosed. In one embodiment, the memory device receives a request to authenticate the entity. Prior to attempting to authenticate the entity, the memory device determines whether a new timestamp is required. If a new timestamp is needed, the memory device receives the new timestamp and then attempts to authenticate the entity using a time estimate based on the new timestamp. In another embodiment, the memory device includes a number of different timestamp update policies (TUP) that specify when new timestamps are needed, and the determination of whether a new timestamp is needed is based on the TUP associated with the entity. Other embodiments are disclosed and each of the embodiments may be used alone or in combination.

Description

WHAT IS CLAIMED IS: 1. A memory device having circuitry for improving the accuracy of the time estimate used to authenticate an entity, and a method for using the memory device with the memory device FOR USE THEREWITH}

&Quot; 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 Trusted Host Device," U.S. patent application serial number 11 / 811,346; and "Memory Device Using Time from a Trust Host Device," which relates to U.S. patent application serial number 11 / 811,345; Each of which is hereby incorporated herein by reference.

Some memory devices, such as TrustedFlash ^TM 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 security issues associated with these operations, the memory device can not trust the host device to provide the correct time. While the memory device obtains the correct time from the trusted component in the network, the host device hosting the memory device can not be connected to the network at a time when 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 be used when the memory device can not continue to measure the active time (e.g., when the power is down ) Will not be a reliable measure of the actual time. Thus, the time estimate value generated from the measured active time only indicates the lower limit of what the actual time is, and the time estimate value will not provide the desired accuracy in certain time-based operations. Although the battery-backup clock may be equipped in the memory device to continue to maintain the time track even when the memory device is inactive, the clock may add cost to the memory device.

The present invention is defined by the claims, and none of these sections should restrict these claims.

By way of introduction, the embodiments described below provide a memory device with circuitry for improving the time estimation accuracy used to authenticate an entity and a method for use with the memory device. In one embodiment, the memory device receives a request to authenticate the entity. Prior to attempting to authenticate the entity, the memory device determines whether a new timestamp is required. If a new timestamp is required, the memory device receives a new timestamp and then attempts to authenticate the entity using a time estimate based on the new timestamp. In another embodiment, the memory device includes a number of different timestamp update policies (TUP) that specify when new timestamps are needed, and the determination of whether a new timestamp is needed is based on the TUP associated with the entity. Other embodiments are disclosed, and each of the embodiments may 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 with circuitry for improving the time estimation accuracy used to authenticate the entity and a method for use with the memory device.

BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 shows a system of an embodiment. Fig.
2 is a block diagram of a memory device of an embodiment;
Figure 3 illustrates various functional modules of the memory device of Figure 2;
4 is a protocol diagram of the 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 timestamp;
7 is a method flow diagram of an embodiment for checking a timestamp update policy;
8 is a memory device illustration of an embodiment using host time for an application executing in a memory device.

Referring now to the drawings, FIG. 1 is a diagram of a system 10 to be used to illustrate these embodiments. 1, the system 10 includes a plurality of memory devices 20, 30, and 40, respectively, removably connected to a plurality of host devices: a personal computer (PC) 50, A digital media (e.g., MP3) player 60, and a cell phone 70. A host device is a device capable of reading data from a memory device and / or writing data to the 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 may be downloaded, for example, from a server to a memory device in a network, pre-loaded by a manufacturer or other 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. For example, the host device may be a notebook computer, a handheld computer, a handheld email / text messaging device, a handheld game console, a video player (e.g. a DVD player or portable video player), an audio and / Cameras, set top boxes, display devices (e.g., televisions), printers, car stereos, and navigation systems. Also, the host device may include mixed functionality. For example, the host device may be a cell phone capable of playing digital media (e.g., music and / or video) files in addition to forming and receiving telephone calls.

A host device, such as PC 50 and cell phone 70, may have the ability to communicatively connect to a network (such as Internet 80 or wireless network 90, although other types of networks may be used). A host device with this capability is referred to herein as a "connected device. &Quot; It is to be understood that a "connected device" such as when the cell phone 70 operates in an unconnected mode or when the PC 50 does not establish an internet connection can not always be connected to the network at all times. A host device that does not have the capability to communicatively connect itself to a network (such as a digital media player 60) is referred to herein as an "unconnected device. &Quot; An unconnected device can be placed in communication with the network by connecting a connected device and an unconnected device, as shown in FIG. 1, wherein the digital media player 60 is connected to the PC 50. Even if connected in this manner, an unconnected device can not derive information from the network unless an unconnected device is designed for the function (e.g., a simple MP3 player). In this situation, a component of the network may push information to the device. It should be noted that, while FIG. 1 shows a digital media player 60 connected to a PC 50 via a wired connection, a wireless connection may be used. Similarly, the terms "connection" and "combination" do not necessarily represent a wired connection or direct connection.

A network (e. G., The Internet 80 or wireless network 90) includes a time server 100 in which connected devices (or disconnected devices connected to connected devices) can provide timestamps, and DRM- (Such as, but not limited to) a digital rights management server (DRM) 110 that can provide a license to access the content. Both of these servers will be described in more detail below. Although the 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 functions. In addition, the time server 100 and the DRM server 110 and other components can be accessed via the Internet 80 and the wireless network 90, if desired.

Referring again to the drawings, FIG. 2 is a block diagram of a memory device 200 of an embodiment that may have a memory card or stick form. As shown in FIG. 2, memory device 200 includes a collection of non-volatile memory arrays (such as flash memory) 210 and circuitry 220. In this embodiment, the non-volatile memory array 210 has the form of a solid state 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 (not limited thereto) can be used. Further, for 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" is intended to include both 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 , ≪ / RTI > software or firmware) stored in a computer readable medium.

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 an interface function for the host device 300 and the FIM 240 provides an interface function for the flash memory 210. [ The BMU 250 includes a crypto-engine 252 and a host direct memory access (DMA) component 254 for providing an encryption / decryption function and a flash DMA 258 for communicating with the HIM 230 and the FIM 240, respectively. Component 256. < / RTI > CPU 260 executes software and firmware stored in CPU RAMS 260 and / or flash memory 210. [ Hardware timer block 270 will be described below with respect to the ability of the memory device 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 about the memory device 200 and the operation of the device 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. Pat. Patent Application Serial No. 11 / 322,812 and U.S. Pat. Patent application Serial No. 11 / 322,766, both of which are incorporated herein by reference. The components and functions described in these documents are not read into the following claims unless explicitly recited herein.

In this embodiment, the memory device 200 stores digital rights management (DRM) keys and licenses to unlock 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 DRM keys and licenses to unlock the protected content stored on the memory device. The DRM key and licenses may be generated by the memory device 200 or generated outside the memory device 200 (e.g., by the DRM server 110) and transmitted to the memory device 200. The DRM key and licenses The protected content may be effectively coupled to the memory device 200 instead of the host device 300 to allow the memory device 200 to prove to the memory device 200 that the protected content is an authorized device, The TrustedFlash ^TM memory devices from SanDisk Corporation are examples of memory devices that store DRM keys and licenses on a memory device so that the protected content is moved with the memory device In some embodiments, the memory device 200 may also include a memory device The memory device 200 in other embodiments provides the DRM keys to the host device 300 to validate 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 the proper credentials can access the DRM keys and licenses. The computer-readable code for SSA may be stored in flash memory 210, CPU RAMs 262, or other storage locations in memory device 200. The SSA is described in more detail in the above'028 patent application. FIG. 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, the memory device 200 includes various access control records ("ACRs"); A first asymmetric ACR (201), a second asymmetric ACR (202), and a symmetric ACR (203). The first and second asymmetric ACRs 201,202 comprise first and second time update policies (TUP1 and TUP2, respectively) to 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 an authentication method to be used and what kind of certificates are needed to provide proof of the identity of the entity. Each ACR 201,202, and 203 includes permissions to perform various actions, such as accessing DRM keys and licenses. Once the ACR has successfully authenticated the entity, the SSA system opens a session in which actions of any ACR are executed. As used herein, the term "entity" refers to any person or matter that attempts to access memory device 200. The entity may be, for example, an application running on a host device, a host device itself, or a human user. In FIG. 3, three entities are attempting to access memory device 200: media (e.g., audio and / or video) player 301, storage application 302, . These entities 301, 302, and 303 may be on the same or different host devices. Each entity 301, 302, 303 is associated with a specific 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 initiates a login process, it sends a request for authentication containing an identifier of the associated ACR, which specifies what authentication method to be used and what kind of certificates 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) can be used and that the 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 the entity can perform once authenticated.

Some authentication mechanisms (e.g., unidirectional and bidirectional asymmetric authentication using an X.509 certificate chain for authentication) are time-based, and the memory device 200 may be used to verify a certificate presented by an entity I need to know the time. (The symmetric authentication mechanism used by symmetric ACR 203 does not require the memory device 200 to know the time. In symmetric authentication, the entity and the key shared by the ACR associated with it are used to authenticate the entity). In asymmetric authentication, the time may be needed to evaluate whether the certificates, such as the RSA certificate and / or the certificate revocation list (CRL) supplied by the entity, are validated. (As used herein, a "certificate" is a single certificate or multiple certificates (e.g., a certificate chain), and a "CRL" may be a single CRL or multiple CRLs. Before looking at the mechanisms that the memory device 200 may 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 for proving the identity of the entities. Entities wishing to establish a proof of identity register register appropriate evidence in the CA to prove their identity. After the identity of the entity is certified to the CA, the CA issues a certificate to the entity. A certificate is a public key of an entity signed (typically by encoding a digest of a public key) signed by the name of the CA that issued the certificate, the name of the entity to whom the certificate was issued, the entity's public key, Key.

The certificate may include a data field holding an expiration date. In this situation, the entity holding the certificate may only access content protected by the ACR for a limited amount of time (until the certificate expires). The certificate may also include a data field holding the future validity time. In this situation, the ACR will not authenticate the entity until the certificate is validated. If the memory device 200 determines that the current date is after the expiration date or before the validation date (i.e., if the memory device 200 determines that the certificate is not valid), the memory device 200 determines whether the entity presenting the certificate . ≪ / RTI >

Various situations (such as name changes, association changes between entities and CAs, and private key compromises or suspected compromises) may cause the pre-expiration certificate to become invalid. 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 timestamping list of revoked certificates. Thus, in order to authenticate the entity, the memory device 200 not only checks whether the certificate is appropriate, but also checks the CRL to see if the certificate is listed on the CRL. (A CRL may be provided by an entity with a certificate, or the memory device 200 may include the CRL itself (e.g., over the Internet 80 if the memory device 200 is a connected device). If the certificate is listed on the 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 that indicates 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 (i.e., the memory device 200 determines that the CRL is not valid), the CRL is considered defective and preferably, It is 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 the memory device time stamp from an hourly reliable time server that needs to know the time, i. E. A memory device request, via the host device. This solution is suitable for connected devices; However, if the memory device is connected to devices that are not connected, as well as unconnected devices (e.g., home PCs that are not connected to the Internet, MP3 players, cell phones when the network is off The memory device can not rely on a connection available when it needs to know the time for the authentication procedure. Another option is to mount a memory device with a battery-backup clock, May be undesirable because it adds cost to the memory device. Another option is to rely on the host device (from its internal clock or external source) to provide time for the memory device. However, in many situations, The device can not trust the host device to provide the correct time. (I.e., setting the clock on the host device at a time earlier than the current time), the user may bypass the actual time limits that the memory device needs to reinforce . On the other hand, if the memory device (the application running on the memory device) can trust the host device, the memory device (or the application executing on the memory device) may depend on the host device for that time. More information will be presented below.

Another option used in this embodiment is to use limited time tracking capabilities of the memory device; Specifically, the ability of the memory device 200 to measure the active time. The active time refers to the time when the memory device 200 is connected to the host device and is actually used (i.e., when operating on the bus between the memory device 200 and the host device 300 as compared to being in idle or sleep mode). Alternatively, 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 "usage time" will be used interchangeably herein. As described below, in this embodiment, the memory device 200 is active when the hardware timer block 270 is able to generate clock ticks as interrupts to the CPU 260, and the CPU 260 ) May increase the active time counter.

In operation, a hardware timer block 270 (e.g., an ASIC controller) includes an oscillator that generates periodic clock ticks and provides the ticks to the CPU 260 as interrupts. (Preferably, the oscillator operates at a very low frequency and runs while the CPU 260 is sleeping). Accordingly, the hardware timer block 270 interrupts the CPU 260 periodically (e.g., every millisecond or microsecond). When CPU 260 is interrupted, a particular clock interrupt service routine (e.g., in firmware executed by CPU 260) is invoked and stored in CPU RAMs 262 and non-volatile flash memory 210, Is added in one cycle / unit, so that the counter value is not lost when power is lost. To prevent excessive consumption of memory 210, an active time counter in memory 210 may be periodically (e.g., one minute as long as power is applied to memory device 200 or the like) in response to each clock tick, It is desirable to be updated. Although this may cause additional inaccuracies in the measured time when 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 bits in the counter may be moved if the help is persistent). It is also desirable that the write to the active time counter does not affect the performance of the memory device 200 (except power consumption to perform writing) and regular activity. (In other words, it is desirable that the write to the time counter is part of the process of servicing the host command). For example, writing to the active time counter can be handled as a background task and is performed prior to the host device instruction service. At the end of the host device command, the firmware of the memory device 200 can verify that programming of the active time counter is successful 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 the crypto-engine 252 using a key-hashed message authentication code (HMAC)), It is desirable that it can not be tampered. In the case of signature mismatching, the data can be treated as uninitiated, such as when the attacker tampered with it. In addition, it should be noted that other mechanisms for measuring active time can be used.

To switch the value stored in the active time counter to the actual time, the CPU 260 multiplies the value stored by the frequency at which the hardware timer block 270 generates the clock ticks. For example, if the value 500 is stored in the active time counter and the hardware timer block 270 generates a clock tick every 5 milliseconds, then the CPU 260 will generate an active time of 2,500 milliseconds (500 times 5) . To generate a time estimate, the converted active time is added to the final timestamp received by the memory device 200 from a trusted source. In other words, the timestamp acts as the "start line ", and the measured active time of the memory device is added to the timestamp. The timestamp can take any form and can represent time with any desired precision (e.g., year, month, day, hour, minute, second, etc.). Preferably, the memory device 200 is provided with a timestamp from an entity that the memory device 200 trusts to provide the entity with the correct time {e.g., the time server 100 or a trusted host device}. The timestamp can take any form and can be included in other information or transmitted by itself. The memory device preferably stores little time stamps through the crypto-engine 252, and can not be easily tampered with. When a new timestamp is received by the memory device 200, a new timestamp 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 timestamp instead of the old timestamp. Instead of resetting the counter (and therefore, "rolling back"), the active time counter value present at the time of the new timestamp is recorded and subtracted from the current time to measure the active time.

The time-tracking capabilities of memory devices are now discussed, and examples of authentication procedures will be described. Referring back to the drawings, FIG. 4 is a protocol diagram of an asymmetric authentication process of an embodiment. In the following example, layer 301 attempts to log in to memory device 200 via ACR 201. Player 301 includes certificates (e.g., an RSA key pair, a certificate, and a certificate revocation list (CRL)), and the ACR 201 includes an authentication (In this case, establishing a secure channel between the player 301 and the DRM module 207). 4, the first step is to cause the host device 300 to 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 the respective system diagrams and flow diagrams showing one particular way in which the memory device 200 can obtain a timestamp, ≪ / RTI > It should be appreciated that the memory device 200 may obtain a timestamp in another manner and the timestamp may have other forms. It should also be understood that a single memory device that interfaces with multiple servers or hosts can handle multiple types simultaneously. Accordingly, the specifics of such examples should not be construed as claiming unless explicitly recited herein.

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 host device-time server communication channel 315 To communicate with the time server 100 via the Internet. In this embodiment, the time server 100 includes a plurality of servers 102, 104, 106 that are synchronized with each other through the inter-server communication channel 325, although the time server 100 may include a single server. Also, as noted above, instead of using the time server 100 for the timestamp, the timestamp from the host device 300 can preferably be used only if it is a reliable host device.

In this embodiment, the procedure for requesting a timestamp is initiated by the host device 300 sending a nonce acquisition instruction to the memory device 200 (Act 405) (see Figures 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 authentication of the time stamp generated by the time server 100. The memory device 200 generates a random number (act 410) and stores it in a CPU RAMS (i.e., volatile memory) 262 (or, optionally, memory 210) for later verification. The memory device 200 sends the nonce to the host device 300 (Act 415). The 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 timestamp request containing the nonce to the time server 100 (Act 420). The time server 100 signals the time (for example, the world time in the UTC Zulu format) and the nonce with the private key. The time server 100 then sends a timestamp response to the host device 300 (Act 425), including a nonce, a timestamp, a certificate chain, and a CRL chain in this embodiment. (This certificate and CRL are not identical to the certificate and CRL sent from the time server 100 for authentication and sent to authenticate 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, the memory device 200 attempts to verify the certificates 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 of the time server 100 certificate and the CRL is valid, instead of checking the validity of the time evaluation generated 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 certificate and CRL passes (act 445), the memory device 200 compares the nonce in the volatile memory 262 with the non-response in the response (Act 450). If the comparison fails, the memory device resets volatile memory 262 and returns to the idle process (Act 455). If the comparison is successful, the memory device 200 preferably stores a new time stamp in the memory 210 in a secure manner to protect tampering.

It should be appreciated that the memory device 200 may generate the nonce 410 and wait for a response (act 460) after which the host device 300 may send another acquisition nonce command to the memory device 200 (act 465) do. As described above, the memory device 200 begins to measure time after the nonce is generated. If a new nonce instruction 465 is received before the measured time reaches a specific time-out limit, the memory device 200 preferably ignores the new nonce instruction 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 create a new nonce (Act 470). Thus, the nonce is only valid for a limited time, and the time-out limit ("movement time error") is the maximum time to consider that the memory device 200 is legitimate to wait for a timestamp from the time server 100.

Since the timestamp stored in the memory device 200 includes the time when the time server 100 signals the data string, the time indicated in the timestamp may be timestamp precision (e.g., year, month, day, hour, minute , The seconds, etc.) and the delays associated with sending the request and receiving the response, the host device 300 may determine that it is not the actual real-time time that requested the timestamp, It may not be time. The nonce time-out period described above may be set to the time to ensure that the timestamp has the precision required by the memory device 200. Thus, the memory device 200 has control over the maximum allowable delay in the timestamp request. Also, in other embodiments, the timestamps generated by the time server 100 may be stored in the memory device 200, such as the estimated time at which the host device 300 requested the timestamp, the estimated time at which the timestamp was stored in the memory device 200, You can point to some other time, such as another time.

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

4, a new timestamp is stored in the memory device 200 and the memory device 200 sends a "time update success" message back to the host device 300 (act 452) and the host device 300 Sends again a request for authentication to the memory device 200 (Act 454). Because the memory device 200 has a timestamp, the memory device 200 will check the timestamp update policy (TUP) of the ACR 201 (act 500). Because the time estimate is based on a timestamp, the time estimate biasing in the old timestamp can lead to an inaccurate time estimate. Thus, the TUP is used to determine when an existing time stamp on the memory device 200 is considered obsolete and requires reclamation (i.e., a new timestamp). 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 (i.e., other ACRs may have different time tolerance levels).

In this embodiment, the TUP is represented by four values: (1) the number of power cycles, (2) the threshold of the active time, (3) the threshold of the "extended" active time, A bit indicating whether an OR relationship exists between the parameters (i.e., 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).

FIG. 7 is a flow chart that illustrates the test TUP act in greater detail (Act 500). First, a check is made to determine if the memory device 200 has started to check the TUP by looking for configuration data stored in the memory 210 (Act 505). If the memory device 200 does not begin checking the TUP, the memory device 200 uses the final timestamp received by the memory device 200 to generate a time estimate (act 510) An attempt is made to authenticate the entity using. When the memory device 200 starts inspecting the TUP, the memory device 200 starts its checking.

First, the memory device 200 determines whether the TUP after the last timestamp includes a check of the number of power cycles of the memory device 200 (Act 515). In this embodiment, this is done by checking the above "power cycles" value. If the value of "power cycles" is zero, the number of power cycles is not checked. If the "power cycles" value is not zero, the number of power cycles is checked using this value as a threshold. The number of power cycles is a count of how much power the memory device 200 has been powered up to, a count indicating how much power the memory device 200 has been powered down since the last time stamp (i.e., during each power rise, . The number of power cycles may be measured by the CPU 260. Every time the memory device 200 proceeds through a power cycle, the CPU 260 may invoke a device reset routine in the firmware. Due to the device reset routine, as in the situation where the CPU 260 adds one unit to the active time counter, the CPU 260 may send one unit to the CPU RAMS 262 and / or the power cycle counter of the memory 210 . Due to the active time counter, the power cycle counter may be updated periodically to reduce memory consumption.

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

If the TUP includes a power cycle number check, the memory device 200 determines the power of the memory device 200 after the last time stamp to know whether the number of power cycles exceeds a threshold amount set in the "power cycles & The number of cycles is checked (act 520). The critical number can be configured per ACR to reflect the desired time tolerance. For example, if it is necessary to ensure that the certificate is very sensitive and that the expiration date of the certificate or CRL does not expire, the threshold number may be set to one. Thus, once the memory device 200 shuts down (and thus, if there is at least some amount of time that can not be accounted for by the measured active time), the TUP check of these parameters fails. On the other hand, if the authentication is not sensitive, the number of power cycles is set to a higher number (or not at all), so that the TUP check can be performed even if some number of power cycles are present Some amount of time that can not be accounted for).

If the number of power cycles check 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 failure to the host device 300 and the procedure described above is used to obtain a new timestamp. (Act 525), the process continues by determining whether the TUP after the last time stamp includes a check of the active time (Act < RTI ID = 0.0 > 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 critical number of seconds (or some other unit of time). Due to the number of power cycles, the amount of critical active time 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 a guarantee is required that the authentication is very sensitive and that the expiration date of the certificate or CRL has not elapsed, then the threshold amount of measured active time can be set very low. Conversely, if authentication is not sensitive, the threshold of the measured active time may be set higher (or even not considered at all).

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

As noted above, the measured active time can not be a true measure of the actual active time that the memory device 200 does not continuously measure the active time. That is, if the memory device 200 is "inactive" (e.g., when the memory device 200 is in idle or 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, the hardware timer block 270 stops generating clock ticks and / or whatever event the CPU 260 stops responding to the ticks), the measured active time is inactive It would be less than the actual time passed since the measurement started since there is nothing in the memory device 200 to say that the time passes. For example, assume that a timestamp was received on January 1, and memory device 200 measured two active 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 (i.e., by adding two days of active time to the last timestamp of January 1). When the memory device 200 continuously measures the active time, this time estimate accurately represents the actual time (assuming hardware timer block 270 and CPU 260 function correctly). However, if the memory device 200 does not continuously measure the active time (i.e., if the memory device 200 is inactive at any time after starting to measure the active time), the time estimate does not accurately represent the actual time. At best, the time estimate indicates that the actual time is at least January 3. The actual time may be January 4 or some later days (June 29, November 2, December 5, next year, etc.). Thus, checking of the active time in act 540 may not provide accurate results.

To handle 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 measured last time (s) is the active time, a value that is 50% of the actual time is formed, (Or "extend") the measured active time of 3 days to form the active time (since the measured active time was 50% of the actual time). Additional information regarding "extended" active time may be found in U.S. Patent Application Serial No. 11 / 811,284 entitled " Method for Improving Accuracy of a Time Estimate from a Memory Device ", and U.S. Patent Serial No. 11 / Quot; Accuracy of a Time Estimate ", which is filed herewith and incorporated herein by reference.

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

TotalDurationTime (teDownTime): teDownTime = (timestamp _i - timestamp _{i -1} - ActiveTime _i ), where index i goes from the second timestamp to the last timestamp configured in the memory device 200.

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

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

If the down time parameter is configured to be used, the down time is set to one. The memory device 200 uses the downtime property to evaluate when the timestamp update is needed in the following manner: ServiceTime (e. G., The validity of the certificate or the validity of the CRL) A timestamp update is required).

7, if the checking of the "extended" active time fails (act 560), the examination 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 timestamp. If the "extended" active time check passes (or the memory device 200 is not started to check the TUP), the memory device 200 sends back a "TUP pass" message 510,570 back to the host device 300 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 timestamp and the measured active time to verify the certificate (Act 585) and verify the CRL (Act 590). The time at which the expiration time of the certificate and CRL was generated After the evaluation, the memory device 200 sends the OK message back to the host device 300, and other steps of the authentication method, if any, can be performed. Once the entity is authenticated, (By setting a secure channel between the player 301 and the DRM module 207), otherwise, if the certificate and / or the CRL expire, the memory device 200 will fail the authentication attempt To the host device 300. The host device 300 may in turn initiate a timestamp 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. Because the measured active time may be inaccurate, the "time extension" techniques described above may be used to improve time evaluation accuracy. However, it is possible that the "extended" active time may actually be greater than the actual time. When examining the TUP, the "over-extended" active time causes a new timestamp. However, when verifying a certificate or CRL, the "over-extended" active time can prevent an appropriate entity from being authenticated. Thus, it may not be desirable to use "time extension" when generating a time estimate for authentication.

In summary, in the method, the memory device 200 determines whether a new timestamp is needed before attempting to authenticate the entity and to receive a request to authenticate the entity. If a new timestamp is required, the memory device 200 attempts to authenticate the entity by generating a new timestamp based on the new timestamp and comparing the time estimate against the certificate and / or CRL validity period . If a new timestamp is not needed, the memory device attempts to authenticate the entity by generating a time estimate based on the final timestamp and comparing the time estimate 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 timestamp is obtained before authenticating the entity. In other words, checking the TUP and getting a new timestamp does not require that the entity be authenticated before checking the TUP or before a new timestamp is obtained. This contrasts with systems that use a single server to provide both timestamps and DRM licenses. The server requires memory device authentication before providing the time stamp (or other information) to the memory device. This provides a "catch 22" situation to authenticate the server, and a new time is required, but a new timestamp can only be obtained after the server is authenticated. To avoid this situation, some prior systems do not use time for authentication processing. While avoiding the "catch 22" situation, the ignore time can lead to authenticating the entity that should not be authenticated (e.g., because the certificate and / or CRL has expired).

By dividing the time server 100 from entities attempting to authenticate to 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 , And causes the player 301 to transmit a time stamp update from the time server 100 (see FIG. 3). These timestamps are used to generate a time estimate where the entity's credentials can be validated for authentication. An "empty channel " refers to a communication pipeline that is established without first authenticating the entity. By contrast, a "secure channel" refers to a communication pipeline that is established only after an entity is authenticated.

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

When an entity is authenticated to the memory device 200, it may perform various actions indicated in the grant control record (PCR) of the ACR. 3, player 301 may communicate with DRM module 207 over a secure channel to access protected content 205 of memory device 200. For example, (As another example, the ACR for storage application 302 allows application 302 to store protected content 205 in memory device 200). The DRM module 207 attempts to validate the DRM license 206 for the protected content 205 before unlocking the protected content (e.g., although the player 301 has been authenticated, but the content is protected To determine if the license is still valid and has expired). To this end, the DRM module 207 requests time estimation from the time module 204 of the memory device 204. (The time module 204 is the software described above used to store and generate the various components used to generate the time estimate (e.g., time stamp, active time, number of power cycles, "extension" / Or hardware). The DRM module 207 compares the generated time estimate with the expiration date and / or validity period of the license 206 to determine whether the license is valid or not. The DRM module 207 may perform additional checks to validate the license, such as (but not limited to) determining whether the protected content 205 has been played more than a certain number of times.

As noted above, the later the timestamp is, the more accurate the time estimate will be. In this embodiment, the TUP of the ACR determines whether a timestamp update is required. Thus, the TUP effectively determines how accurate the generated time estimate is for DRM license validation. In determining the parameters of the TUP, we find a balance between the need for service providers to provide services in consideration of expiration, and the need for end users to be uncomfortable when it is necessary to connect host devices to the network to obtain a new timestamp There is a need. If the time tolerance is too close, the service provider may lose the 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 costly to obtain the requested timestamp update.

When the memory device 200 has a single ACR with a single TUP (or all the multiple ACRs sharing the same TUP), a single "one size all fit" TUP finds the right balance for all service providers I can not. Thus, in this embodiment, the memory device 200 has multiple ACRs 201,202 with different TUPs (TUP1, TP2) that can be configured by the associated service provider. As discussed above, through the use of other ACRs, the memory device 200 can be configured to authenticate using other authentication schemes (symmetric, asymmetric authentication, etc.). The use of different ACRs allows configurable time tolerances. That is, through the use of configurable TUPs of ACRs, the service providers can determine whether one or more of the time-valid parameters (e.g., active time, number of power cycles, "extended" active time / This is considered obsolete and you can define your own time tolerance by specifying when to trigger the timestamp update. By forming configurable TUPs, the service provider can configure the time tolerance according to the particular needs and the relationships of end users instead of relying on a single "one size fits all" TUP.

For example, some service providers generate certificates for a very short period of time (e.g., 10 minutes). By allowing the end user to obtain a new certificate every hour that 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 of the end user requesting the certificate . Thus, for this business model, the service provider needs strict tolerances for currency definition. As another example, if the service provider has a very flexible install base of end users, the service provider may want to call the certificate frequently as a major part of the business model. In this situation, the service provider wants a strict time tolerance to ensure that the most recent CRL is used for authentication. On the other hand, if the service provider provides a monthly subscription service that users regularly access the service provider ' s web site to obtain new content and receive a forced timestamp update, the service provider may request the end- It does not strictly require time tolerance because it can be connected.

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

For example, consider a situation in which a user downloads a movie for two hours to his memory device under a license that says that the movie can only be watched for 24 hours. The service provider may not be able to watch the movie after the 24 hour period, but he may not want to inconvenience the normal user by accessing the network to obtain a new timestamp. Thus, the service provider may decide to place the TUP on a license that requires a new timestamp if the active time is four hours or more (the amount of active time required to view the two-hour movie twice). If the active time is greater than four 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 timestamp is required. (Alternatively, 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, ten or more power cycles may indicate that the memory device has been used for more than 24 hours) . If the time stamp generated by the new timestamp is valid and indicates a license, the DRM module 207 will cause the movie to be played again.

By allowing the per-license TUP to be configured, the TUP can be tailored to the content. Thus, instead of expiring a movie after 24 hours, if the movie expires a week later, the licensing time tolerance 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 use a license to trigger a time update 70 hours after the active time (i.e., 7 days multiplied by 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 should be viewed once, then the TUP can be designed such that a new timestamp is required three minutes after the active time have.

The business model of the service provider may be considered in designating the TUP. For example, at present, the monthly subscription service is a popular business model for distributing rights to protected music. In a music subscription service, a user downloads a lot of desired music from a service provider's web site and allows him to play the desired music several times a 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 in his memory device. Users who frequently visit the service provider's website for more songs will receive a new timestamp when connecting to the website; Thus, memory devices will provide a more accurate time estimate. However, users downloading a relatively large amount of music can not necessarily reconnect to the service provider's web site each month before expiring the license. When the user ultimately reconnects for more music, the service provider can bill the user for the time he plays music outside of the license periods. As a result, as a business model, the service provider for monthly subscription may want a different time tolerance than the service provider of the pay-per-use content, It may not proceed to the web site again. In this situation, because the user is more likely to go back for more music on a subscription service each month than the pay-per-use service, the service provider may ask the customer to get a new timestamp even if he ultimately returns to the website. You may not want a strict time tolerance to be embarrassed. Having a less stringent time tolerance means that customers who never return to the service provider's website will be able to play music for longer than a month of licensing (for example, one month of active time instead of one month of actual time) You can do it. However, in view, the service provider can determine that the unauthorized use has an acceptable sacrifice to prevent customers return inconveniences and embarrassment.

As another example, consider a business model in which a service provider wants to provide a point to advertise on 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 ads related to the stores 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, the location-specific point advertisement can not be delivered. To ensure this occurrence, the TUP of the content may be set to a very small amount (e.g., one minute of active time) to ensure that the user is connected to the network to obtain a new timestamp. Once the user connects to the network, the network can know the location of the cell phone and push the appropriate ad content to the cell phone. On the other hand, if the service provider can make money by knowing how much the content is played, the time tolerance may be less stringent.

As illustrated by the above examples, through the use of configurable TUPs on license files, the service provider of a particular content is not to embarrass the customers by requiring him to connect the host device to the network during timestamp update You can notify whenever you are balancing a time update that you think is appropriate. It should be noted that one service on the memory device may be shut down after a certain time and that other services on the memory device are still enabled because the memory device in this embodiment is a multi-purpose, multi-application memory device with multiple TUPs do. That is, although authenticated, the player can play certain content on the memory device, but can not play other content on the memory device unless a new timestamp is obtained due to other 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. (Applications may sometimes be referred to herein as "extended" or "internal extended" In the embodiment shown in FIG. 3, the application has the form of a DRM module 207. However, other applications may be used, for example e-trade, banking, credit card, electronic money, life measurement, access control, personal data, or secure e-mail functionality. It should also be noted that although only a single application is shown in memory device 200 in Fig. 3, the memory device may have several applications (e. G., DRM module and e-trade module).

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

While the central security system provides the access control mechanism and protects the data stored in the memory device so that the data is only accessed by the appropriate authorized entities, the central security system itself can not understand and process the data it protects. There are applications that run on memory devices that can understand and handle 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, the central security system can be considered as an application-independent toolbox that can be configured. In operation, the service provider defines an ACR that places the application on the memory device and associates the application with a particular entity. At the point of view of the central security system, it is not necessary to know which application is being executed (e.g., an application is DRM license validation, e-trade function, etc.) and only entities authenticated to a particular ACR are allowed to communicate with applications defined in the ACR Is allowed. 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 situations, central security systems and applications need to know the time. For example, the central security system does not need to know the time for time-based authentication (e.g., asymmetric authentication) and the application needs to know the time for a time-based operation (e.g., DRM license validation) . As noted above, the memory device has a central time module that can provide time for both the applications running on the memory device and the central security system. For example, referring to FIG. 3, module 204 not only provides time for asymmetric ACRs 201 and 202 to authenticate various entities, but also provides time to DRM module 207 to verify license validity can do. 8, in some situations, an application on a memory device may choose to use host time in addition to or instead of time from a memory device's time module.

FIG. 8 illustrates a memory device 600 in communication with host device 700. FIG. Host device 700 includes an entity (here player 710) and has some mechanism (e.g., a battery backup clock) for providing time 720. In this embodiment, the memory device 600 includes a symmetric ACR 610 (although an asymmetric ACR may be used), a time module 620, a DRM module 630, a protected content 640, and a protected content 640). ≪ / RTI > (In Figure 8, the application of the memory device is the DRM module 630. It is noted that other types of applications may be used, and one or more applications may be implemented within the memory device). When the player 710 authenticates to the memory device 600 using the symmetric ACR 610, the secure channel 660 may communicate with the player 710 and the DRM module 630 in accordance with the parameters set in the symmetric ACR 610. [ . The DRM module 630 and the player 710 are not known to each other because the service provider defines the symmetric ACR 610 to associate the DRM module 630 with the player 710. Thus, there is a certain level of reliability between the DRM module 630 and the player 710 because they are counterpart members of the same group. Based on this trustworthiness, the DRM module 630 may be programmed to allow the host time 720 from the 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: the time from the host time 720 and the central time module 620 of the memory device. There are advantages and disadvantages associated with each of these time sources. The module 620 may not be accurate at the host time 720 provided by the battery backup continuous clock over time because the time module 620 of the memory device does not continue to track the track of time. On the other hand, due to all the security precautions described above, over time, the module 620 may be able to change the host time 720, especially if the user of the host device 700 can change the 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 that an application can not 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 slowness (or name) of the host time 720 and the time from the time module 620. [ The application may be programmed to generate a time estimate using both time sources in some manner (e. G., Taking an average of the 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 host device through authentication processing (e.g., 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 can 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 the software application. (In addition to not trusting the host time from a relatively unreliable host device, the application can not trust an entity running on the host device, e.g., using content keys, license values or periods, or license change rights. (In place of providing the encryption keys and content to the host device.) However, if the host is a closed system such as an MP3 player, the host ' The application running on the host device 600 may trust the host time 720 rather than when the host device 700 is an MP3 player as compared to when the host device 700 is a PC .

In one embodiment, player 710 pushes host time 720 to DRM module 630 when sending a request to play DRM module 630 to play the 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, the 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 measurement during future sessions. Optionally, the host time 720 may be stored for future use by the application, and the "time-extending" 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-base operation of the application and not for updating the time of the time module 620 (because the application is an "extension" Because it is not. Preferably, the time in the time module 620 is only updated using the reliable time servers (which are part of the same reliable camp as the central security system) as described above. It should be noted that when some applications are executed in the memory device 600, each application may have two time sources: the time from the time module 620 and the time from the host device operating the entity communicating with the application time. However, it may be desirable that the host time associated with one application is used only for that application and not for other applications associated with other host devices.

As discussed above, an application running on memory device 600 (such as DRM module 630) may compare the time from the time module 620 to the host time 720 and may be programmed to use the slowness (or name) . For example, the host time 720 may indicate that the host 700 is unable to connect to the time server for a sufficiently long time as the time asymmetry occurs in the host time 720 or because the host clock is hacked. Time. Also as noted above, the host time 720 may be stored for future use by the application. Combining these considerations, the host time 720 can be stored (either alone or with time from the time module 620) for later comparison with the time received from other host devices. Based on the comparison, the memory device may determine whether to use the time from the current host device or from the previous host device to perform the time-based operation. For example, a memory device may be programmed to take a name of two times if the time base action is "not earlier " than the action and to take a slow of the two times if the time base action times are not & . In this manner, the timestamps received from other trusted host devices can be used as a reference for a single multi-host anti-rollback mechanism with respect to a single time server.

As noted above, a non-time-based authentication system (such as symmetric authentication) may be used to authenticate the host device. This makes the application's time base behavior (e.g., DMR operation) independent of the authentication time server. That is, since only the time from the host device or the DRM server is used, the time-based behavior of the application does not depend on the time from the authentication time server or the time module of the 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 the time based on the authentication time server, the time-based application can perform its operation using the host time.

It should be noted that any of the above embodiments may be used alone or in combination. Other embodiments that may be used in these embodiments are described in the incorporated patent applications by reference. In addition, it is presently preferred that these embodiments be implemented in a TrustedFlash ^TM memory device by SanDisk Corporation, but it should be understood that these embodiments may be used for any type of memory device. In addition, these embodiments can be used for non-memory device fields when encountering a general problem that has an inaccurate clock and needs to know or use time. Additionally, some or all of the acts described above may be performed exclusively on the host device (or some other device) instead of the memory device.

It is intended that the detailed description, rather than as a definition of the invention and the forms of illustration which the invention may take, is intended to be understood. The following claims include all equivalents to which the scope of the invention is defined. Acts listed in the claims can be performed in any order - not necessarily in the order in which they are listed. Finally, it should be noted that any aspect of any of the preferred embodiments described herein can 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-engine, 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; Licenses for protected content

Claims (20)

A method for authenticating an entity to a memory device,
In a memory device,
Receiving a request to authenticate an entity using a time-based authentication technique;
Before attempting to authenticate the entity, determining whether a new timestamp is needed;
If a new timestamp is needed, receiving the new timestamp and then attempting to authenticate the entity using a time estimate based on the new timestamp,
If a new timestamp is not needed,
Measuring an active time of the memory device in relation to a previously received timestamp using a time counter in the memory device that is active only when the memory device is active;
Determining by comparing an accuracy of an active time previously measured by the memory device with an actual time during the time period for at least a portion of the inaccuracy resulting from a down time of the memory device;
Adjusting the active time measured based on the determined accuracy;
Generating a time estimate by adding the active time measured and adjusted to the previously received timestamp;
And attempting to authenticate the entity using the generated time estimate. delete 2. The method of claim 1, wherein determining whether a new timestamp is needed comprises: determining a number of power cycles of the memory device after the last timestamp received by the memory device, an active time of the memory device after the last timestamp, Wherein the time stamp is based on at least one of the measured and adjusted active time of the memory device after the time stamp. 2. The method of claim 1, wherein an attempt to authenticate the entity is made using an asymmetric authentication procedure. 2. The method of claim 1, wherein attempting to authenticate the entity comprises determining whether a certificate is valid. 2. The method of claim 1, wherein attempting to authenticate the entity comprises determining whether a certificate revocation list (CRL) is valid. 2. The method of claim 1, wherein the new timestamp is generated by a host device connected to a memory device. 2. The method of claim 1, wherein the memory device stores digital rights management (DRM) keys and licenses to unlock protected content stored on a memory device. 2. The method of claim 1, wherein determining whether a new timestamp is required comprises determining whether a timestamp update policy (TUP) of an access control record (ACR) associated with the entity requests a new timestamp. Authentication method. 2. The method of claim 1, wherein the new timestamp is transmitted over an idle channel. 13. A memory device comprising:
A memory array for storing a number of different timestamp update policies (TUP) that specify when new timestamps are needed;
Communicating with the memory array,
Receiving a request to authenticate the entity using time-based authentication technology,
Prior to attempting to authenticate the entity, determining whether a new timestamp is required based on the TUP associated with the entity,
If a new timestamp is needed, attempt to authenticate the entity using a time estimate based on the new timestamp after receiving the new timestamp,
If a new timestamp is not needed,
Measuring an active time of the memory device with respect to a previously received timestamp using a time counter in the memory device that is active only when the memory device is active,
Determining an accuracy of an active time previously measured by the memory device for a predetermined period of time due to at least a portion of the inaccuracy resulting from a down time of the memory device, with an actual time during the time period,
Adjusting the active time measured based on the determined accuracy,
Generating a time estimate by adding the active time measured and adjusted to the previously received time stamp,
To attempt to authenticate the entity using the generated time estimate
Working, circuit
≪ / RTI > delete 12. The method of claim 11, wherein the TUP associated with the entity comprises:
The number of power cycles of the memory device after the last timestamp received by the memory device, the active time of the memory device after the last timestamp, and the measured and adjusted active time of the memory device after the last timestamp ≪ / RTI > 12. The memory device of claim 11, wherein the circuitry is operative to attempt to authenticate the entity using an asymmetric authentication procedure. 12. The memory device of claim 11, wherein the circuitry is operative to attempt to authenticate an entity by determining whether the certificate is valid. 12. The memory device of claim 11, wherein the circuitry is operative to attempt to authenticate an entity by determining whether a certificate revocation list (CRL) is valid. 12. The memory device of claim 11, wherein the new timestamp is generated by a host device connected to a memory device. 12. The memory device of claim 11, wherein the memory device stores digital rights management (DRM) keys and licenses for unlocking protected content stored on a memory device. 12. The memory device of claim 11, wherein the plurality of TUPs are part of a respective plurality of access control records (ACRs). 12. The memory device of claim 11, wherein the new timestamp is transmitted over an idle channel.

Images