WO2010067346A1

WO2010067346A1 - Method and apparatus for protecting content in a storage device

Info

Publication number: WO2010067346A1
Application number: PCT/IL2008/001613
Authority: WO
Inventors: Eran Shen
Original assignee: SanDisk IL Ltd
Current assignee: Western Digital Israel Ltd
Priority date: 2008-12-14
Filing date: 2008-12-14
Publication date: 2010-06-17
Anticipated expiration: 2011-06-14

Abstract

A method for protecting content in a non-volatile storage device operatively coupled to a host device is disclosed herein. In some embodiments, a request is received in the non-volatile storage device to access a protectable data object residing in a 'host-hidden' data region of the non-volatile storage device that is hidden from the host. In response to this request, the following steps may be carried out by the non-volatile storage device: (i) ascertaining, in accordance with an identifier of the requested data object, an active security policy; and (ii) subject to ascertaining an active security-policy, enforcing such active security policy for the requested data object. In some embodiments, a different active security policy is respectively applied to each one or more data objects. Storage devices configured to effect one or more methods disclosed herein and computer program products are also disclosed herein.

Description

METHOD AND APPARATUS FOR PROTECTING CONTENT IN A STORAGE

DEVICE

INVENTOR: ERAN SHEN FIELD OF THE INVENTION

The present invention relates to methods and apparatus for securing data (for example, firmware objects) residing in a storage device (for example, a flash memory device) coupled to a host device

BACKGROUND AND RELATED ART

Peripheral storage devices are well-known in the art of computing, in form factors such as USB flash drives (UFD); PC-cards; and small storage cards used with digital cameras, music players, handheld and palmtop computers, and cellular telephones. Peripheral storage devices also include portable magnetic disks and portable digital appliances (music players and cellular telephones) that double as general-purpose storage devices.

Unfortunately, there are many situations where data stored on a peripheral storage device (for example, data related to device configuration) is subject to attack. In one example, a cracker may replace a firmware file with malicious code which may be executed instead of the firmware file. In another example, a cracker may replace a configuration file with a 'malicious' configuration file.

In yet another example, a flash storage device stores digital cash, which is represented by a file (for example, $100) stored on a flash device. When a portion of the digital cash is "spent" (for example, $20) this file may be updated to indicate that the user possesses only a reduced amount of cash (in this example, $80). However, a malicious user may dishonestly carry out the following: before the digital cash (for example, the $20 is spent), the malicious-user could take a bit-by-bit image of the original digital cash file (in this example, representing $100). After the portion of the digital cash is spent, the malicious user could carry out a "re-flash" of the file where the file representing the reduced amount of digital cash (in this example, representing $80) is replaced with an earlier version of the file which represents the entire amount of digital cash (in this example, $100). It is noted that this is just one example, and that there are many circumstances where it is possible to effect a "re-flash" attack by replacing, in an unauthorized manner" a "later" version of a file stored in flash with an "earlier" version of the same file using the bit-by-bit digital image of the earlier version.

Because of the negative consequences associated with allowing unauthorized users to have unfettered access to all data stored on the peripheral storage device, a number of countermeasures may be employed in order to secure data residing on a peripheral storage device. In one example, files are encrypted with a secret function, and are decrypted when loaded from non-volatile storage into RAM memory — for example, firmware files may be stored in NAND storage in an encrypted form, and decrypted when loaded in loaded in RAM for execution. If a cracker attempts to replace a data object (for example, a firmware object) with a malicious data object, then when the decryption function is run on the malicious data object, the object may end up "garbled" and would not be able to cause the intended harm. In another example, when data objects are accessed, an attempt is first made to "verify" the data object - for example, by verifying a message digest such as a MAC using a secret function. Only if the verification of the data object is "successful" is the data object allowed to be executed by the microprocessor of the storage device.

There is an ongoing need for improved techniques and apparatus for protecting content stored in peripheral storage device, for example, peripheral flash memory devices.

A Discussion of FIG. 1

FIG. 1 is a block diagram of a flash memory system including a flash memory device 120 operatively coupled to host device HO via a host-device interface 180. The flash memory device 120 includes a flash controller 140 which writes data received from host device 110 into flash memory 130, and retrieves data from flash memory 130.

In the example of FIG. 1, flash controller 140 includes microprocessor 150, RAM 170 and ROM 160. Flash device controller 140 may include any computer readable medium storing software and/or firmware and/or any hardware element(s) including but not limited to field programmable logic array (FPLA) element(s), hard-wired logic element(s), field programmable gate array (FPGA) element(s), and application-specific integrated circuit (ASIC) element(s). Any instruction set architecture may be used in controller 140 including but not limited to reduced instruction set computer (RISC) architecture and/or complex instruction set computer (CISC) architecture.

Although the example of FIG. 1 applies to the specific case of flash memory devices, it is appreciated the various teachings disclosed herein may be applicable to devices that include other types of non- volatile memory (for example, magnetic medium) instead of, or in addition to, flash memory.

SUMMARY OF EMBODIMENTS

Various embodiments address these and related issues, examples of which embodiments, including methods and systems, are provided herein. One embodiment is a method of protecting content in a storage device. The method comprises the steps of (a) receiving in a storage device a request to access a protectable data object residing in a data region of the storage device that is hidden from a host to which the storage device is operatively connected, and (b) in response to such request: i) ascertaining, in accordance with an identifier of the requested data object, an active security policy; and ii) subject to the ascertaining of the active security-policy, enforcing such active security policy for the requested data object, wherein a different active security policy is respectively applied to each one or more data objects.

According to different embodiments, the active security policy may include any combination of a decryption policy and/or a signed-code verification policy and/or an anti-re-flashing policy.

hi some embodiments, i) the ascertaining is carried out in accordance with contents of a multi-policy security data-structure including identifiers of the protectable data objects and representations of security policies, each object identifier of a respective data object being associated within the multi-policy security data-structure with at least one of: A) a respective decryption policy for the respective data object; B) a respective signed-code verification policy for the respective data object; and C) a respective anti-re- flashing policy for the respective data object; and ii) the ascertained security policy is ascertained in accordance with a security policy representation which ^"matches the identifier of the requested data object within the multi-policy security-data structure.

The multi-policy security data-structure may reside in any location within the storage device. In one example, the multi-policy security data-structure resides in host- hidden system data region of the non- volatile memory.

In one implementation, at least one of the ascertaining and the enforcing is carried out by execution of security-enforcement firmware stored in the host-hidden system data region of the non- volatile memory.

For example, the method may further comprise the step of responding to a powering-up of the data storage device, using a device controller of the storage device in which a reference to the security enforcement firmware is hardcoded into the device processor, by invoking, in accordance with the hardcoded reference, the security enforcement firmware.

Alternatively or additionally, at least one of the ascertaining and the enforcing is carried out by a device controller of the data-storage device which is hard-coded to carry out at least one of the ascertaining and the enforcing.

In some embodiments, the first and second data objects reside in standard non- secure non- volatile memory. In some embodiments, the first and/or second data objects are firmware objects.

In one particular example, the first and/or second data objects are flash management firmware objects.

In yet other embodiments, the first and/or second data objects are configuration files for configuring the storage device.

In some embodiments, the method is carried out such that different respective decryption policies are ascertained and enforced for the first and second data objects.

Alternatively or additionally, the method is carried out such that different respective signed-code verification policies are ascertained and enforced for the first and second data objects.

Alternatively or additionally, the method is carried out such that different respective anti-re-flashing policies are ascertained and enforced for the first and second data objects.

Another embodiment is a data-storage device for providing data-storage services to a host device operatively-coupled to the data-storage device, the data-storage device comprising: a) a non-volatile memory including a first region that is accessible to the host device and a second region that is hidden from the host device, the second region being configured to store a plurality of protectable data objects each of which are hidden from the host device including a first data object and a second data object different from the first data object; b) a device controller for executing firmware code; and c) firmware security-enforcement code which, when executed by the device processor, is operative, whenever a request is made to access one of the protectable data objects residing in the second region, to respond to the request by: i) ascertaining, in accordance with an identifier of the requested data object, an active one security policy; and ii) enforcing the ascertained active security policy for the requested data object.

In some embodiments, execution of the firmware security-object enforcement code is operative, for a first data object and a second data object different from the first data object, to ascertain and enforce different respective decryption and/or signed-code verification and/or anti-reflashing policies for the first and second objects. For example, this may be carried out in accordance with different respective object identifiers of the first and second data objects.

hi some embodiments, the device further comprises: d) a multi-policy security data-structure including identifiers of the protectable data objects and representations of security policies, each object identifier of a respective data object being associated with at least one of: A) a respective decryption policy for the respective data object; B) a respective signed-code verification policy for the respective data object; and C) a respective anti-re-flashing policy for the respective data object; and wherein the firmware security-object enforcement code is operative, upon execution, to effect the security policy ascertaining in accordance with a matching security policy representation which matches the identifier of the requested data object within the multi-policy security-data structure. Another embodiment is a data-storage device for providing data-storage services to a host device operatively-coupled to the data-storage device, the data-storage device comprising: a) a non- volatile memory including a first region that is accessible to the host device and a second region that is hidden from the host device, the second region being configured to store a plurality of protectable data objects each of which are hidden from the host device including a first data object and a second data object different from the first data object; b) a device controller which is hardcoded, whenever a request is made to access one of the protectable data objects residing in the second region, to respond to the request by: i) ascertaining, in accordance with an identifier of the requested data object, an active one security policy; and ii) enforcing the ascertained active security policy for the requested data object.

In some embodiments, the device controller is hardcoded, for a first data object and a second data object different from the first data object, to ascertain and enforce different respective decryption and/or signed code verification and/or anti-re-flashing policies for the first and second objects.

In some embodiments ,the data-storage device further comprises: d) a multi- policy security data-structure including identifiers of the protectable data objects and representations of security policies, each object identifier of a respective data object being associated with at least one of: A) a respective decryption policy for the respective data object; B) a respective signed-code verification policy for the respective data object; and C) a respective anti-re-flashing policy for the respective data object; and wherein the device controller is hardcoded, upon execution, to effect the security policy ascertaining in accordance with a matching security policy representation which matches the identifier of the requested data object within the multi-policy security-data structure.

Another embodiment is a computer program product, comprising a computer usable medium having a computer readable program code embodied therein, said computer readable program code adapted to be executed to implement a method of managing content by a storage device, the method comprising (a) receiving in a storage device a request to access a protectable data object residing in a data region of the storage device that is hidden from a host to which the storage device is operatively connected, and (b) in response to such request: i) ascertaining, in accordance with an identifier of the requested data object, an active security policy; and ii) subject to the ascertaining of the active security-policy, enforcing such active security policy for the requested data object, wherein a different active security policy is respectively applied to each one or more data objects.

Another embodiments is a data-storage device for providing data-storage services to a host device operatively coupled to the data-storage device, the data-storage device comprising: a) a non-volatile memory including a first region that is accessible to the host device and a second region that is hidden from the host device, the second region being configured to store a plurality of protectable data objects each of which are hidden from the host device including a first data object and a second data object different from the first data object; b) a device controller which is configured, whenever a request is made to access one of the protectable data objects residing in the second region, to respond to the request by: i) ascertaining, in accordance with an identifier of the requested data object, an active one security policy; and ii) enforcing the ascertained active security policy for the requested data object. hi some embodiments, the device controller is configured by firmware to effect, in response to the request, the ascertaining and/or the enforcing.

Alternatively or additionally, the device controller is hardcoded to effect, in response to the request, the ascertaining and/or the enforcing.

It is noted that features described above as pertaining to certain embodiments may also be included in other embodiments, unless indicated to the contrary herein below.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an exemplary flash memory system including a host device operatively coupled to a peripheral storage device.

FIG. 2 is a block diagram of a flash memory including a first data region that is accessible to the host and a second data region that is hidden from the host.

FIG. 3 is a flowchart of a routine for enforcing a security policy for a data object residing in a region of non- volatile memory hidden from the host.

DETAILED DESCRIPTION OF EMBODIMENTS

The claims below will be better understood by referring to the present detailed description of example embodiments with reference to the figures. The description, embodiments and figures are not to be taken as limiting the scope of the claims. It should be understood that not every feature of the presently disclosed methods and apparatuses is necessary in every implementation. It should also be understood that throughout this disclosure, where a process or method is shown or described, the steps of the method may be performed in any order or simultaneously, unless it is clear from the context that one step depends on another being performed first. As used throughout this application, the word "may" is used in a permissive sense (i.e., meaning "having the potential to'), rather than the mandatory sense (i.e. meaning "must").

Embodiments of the present invention relate to techniques and apparatus for protecting one or more data objects on a storage device that (i) is coupled to a host device; and (ii) includes an "internal" data region that is hidden from the host. In some embodiments, the protected "host-hidden" data objects that reside in this "internal" data region (i) are managed by an internal object-storage system (for example, an internal file system) and (ii) include one or more data objects used to configure the storage device - for example, firmware code objects or configuration files.

The present inventor is now disclosing a non-volatile storage device and method of operating the same whereby instead of enforcing a single "device- wide" internal security policy for every data object within the "host-hidden" data region of the storage device, each given data object of a plurality of data objects is protected in accordance with an object-specific security policy that is specific for the given data object.

According to presently-disclosed embodiments, it is possible to "customize" a respective security policy for each given data object in accordance with (i) perceived security threats (i.e. type of threats, severity of threats); and (ii) performance requirements (i.e. the need to avoid expending too many computational resources to provide a given level of security or). For objects where providing elevated security is of greater importance and/or objects where providing a faster response time is of lesser importance and/or objects for which it is desired^{^}to expend fewer computational resources, it is possible to provide a higher level of security. Conversely, for objects where providing elevated security is of lesser import and/or objects where providing a faster response time is of greater importance and/or objects for which conservation of computational resources is less of a priority, it is possible to provide a lesser level of security.

Before describing the figures, a non-limiting use case is presented.

A Non-Limiting Use Case

Thus, in one non-limiting example, four data objects reside in the host-hidden region of the non-volatile memory: Object A (a first firmware code object), Object B (a second firmware code objet), Object C (a configuration file), and Object D (a configuration file).

In this non-limiting example, three types of security policy may be configured on a per- object basis: a decryption policy, a signed-code verification policy and an anti-re-flashing policy.

Decryption Policy - each given data object of the plurality of data objects (for example, the four data objects Object A, Object B, Object C and Object D) is associated with a respective flag for respective decryption policy - in the event that the respective flag is set to "1" for the given data object, then an attempt is made to decrypt the given data object or a portion thereof (for example, using a secret key) when the data object is accessed - for example, when the data object is loaded into RAM from NAND flash or executed in XIP (eXecute In Place) NOR flash. It is understood that this attempt may consume computational resources and/or cause an increased "response time." Otherwise, in this non-limiting^~exaτπple, in the event that the respective flag is set to "0" for the given data object, then no attempt is made to decrypt the given data object (or a portion thereof) when the given data object is accessed.

Signed-Code Verification Policy - each given data object of the plurality of data objects (for example, the four data objects Object A, Object B, Object C and Object D) is associated with a respective flag for a respective decryption policy - in the event that the respective flag is set to "1" for the given data object, then when an attempt is made to access the given-data object, an attempt is made to verify the object's authenticity and/or data integrity using a secret key - for example, by verifying a message digest associated with the data object (for example, message authentication code (MAC)). In one example, this "verification data" for verifying the authenticity of the data object is provided within the data object itself- for example, the last 16 bytes of the data file. It is understood that this attempt may consume computational resources and/or cause an increased "response time." Otherwise, in this non-limiting example, in the event that the respective flag is set to "0" for the given data object, then no attempt is made to analyze a message digest in order to verify the given data object when the given data object is accessed.

Reflash Protection Policy - each given data object of the plurality of data objects (for example, the four data objects Object A, Object B, Object C and Object D) is associated with a respective flag for a respective re-flash protection policy. In the event that the bit is set to "1," then when the data object is accessed, an attempt is made to verify that the data object has not been "re-flashed" and that the data object has not been modified and then returned to an earlier state before modification. It is understood that this attempt may consume computational resources-aπd/oτ cause an increased "response time."

In this non-limiting example, for any given data-object, the security policy for each object may be described as a 3-bit word. For each bit of the 3-bit word, when the bit is set to "1" some type of "additional security" for the given data object may be provided. Although the current example relates to a 3 -bit word, it is appreciated that fewer or more bits may be used. Although the current example relates to three policies, it is appreciated that more or fewer policies may be selectively enforced on a per-object basis.

In one non-limiting example, the information about the object-specific security policies may be saved in a table (for example, an encrypted table stored in flash), where each row of the table includes a description of the data object (for example, a file name or file identifier) mapped to a description of the respective security policy for the data object (for example, the three-bit word).

Thus, in the current use case, one example of such a security table is as follows:

Object A 001

Object B . I l l

Object C 000

Object D 011

In this non-limiting case, the first bit of the 3 -bit word represents a "decryption policy," the second bit of the 3-bit word represents a "verifying policy," and the third bit of the 3- bit word represents an "anti-reflashing policy." In this non-limiting case, when Object A is accessed, (i) no attempt is made to decrypt the object; (ii) no attempt is made to verify the "signature" of the object; (iii) an attempt is made to determine if Object A has been re-flashed.

In this non-limiting case, when Object B is accessed, (i) an-attemptis made to decrypt the object; (ii) an attempt is made to verify the "signature" of the object; (iii) an attempt is made to determine if Object B has been re-flashed.

In this non-limiting case, when Object C is accessed,, (i) no attempt is made to decrypt the object; (ii) no attempt is made to verify the "signature" of the object; (iii) no attempt is made to determine if Object C has been re-flashed.

In this non-limiting case, when Object D is accessed, (i) no attempt is made to decrypt the object; (ii) an attempt is made to verify the "signature" of the object; (iii) an attempt is made to determine if Object D has been re-flashed.

This allows for "customization" of the security policy on an object-specific basis. Instead of enforcing a single device policy for every object in the host-hidden data region, it is possible to enforce a different security policy for each data object of a plurality of data objects.

We note that Objects A, B and D are associated with "active security policies" because these 'active security policies' require at least one positive activity upon access of the host-hidden data object - i.e. (i) the policy associated with Object A requires making an attempt to detect if Object A is reflashed and to deny access if Object A is reflashed, (ii) the policy associated with Object B requires decrypting Object B, verifying the digital signature (e.g. the message digest) of Object B and making an attempt to detect if Object B is reflashed and to deny access if Object B is reflashed; (iii) the policy associated with Object D requires verifying the digital signature (e.g. the message digest) of Object B and making an attempt to detect if Object B is reflashed and to deny access if Object B is reflashed.

In contrast, the policy associated with Object C does not require that any security measure is taken when Object C is accessed from the host-hidden data region 210 of the flash memory 10.

Although the present example relates to a "binary policy" (i.e. for each given policy type, a "1" means that some sort of active policy is enforced for the given policy type), it is appreciated that this is not a limitation. Thus, in other examples, instead of (or in addition to) storing data about whether or not to enforce a policy of a given policy type, data relating to how a policy of a given policy type is enforced may be stored in a data structure, and a given active security policy type may be enforced in different manners for different data objects. For example, for a first data object some sort of "computationally inexpensive" anti-reflashing routine may be used where only certain portions of the object are checked that verify that they have not been re-flashed, while for a second data object a different sort of anti-reflashing routine (for example, one which checks every bit of the object for re-flashing) may be used. A Discussion of FIG. 2

FIG. 2 is a block diagram of an exemplary flash memory in accordance. In the example of FIG. 2, the flash memory includes two regions: (i) a first host-accessible user data region 220 which is accessible by host device 110 and (ii) a "host-hidden" data region 210 that is hidden from the host. Thus, host device 110 may not read or execute any data object within host-hidden data region 210.

hi the example of FIG.2, the following items are stored within host-hidden data region: (i) a plurality of data objects 250A..250N, and (ii) a multi-policy security data structure 260 - for example a "security table" described in the previous use case.

One salient feature of multi-policy security data structure 260 is that it is "heterogeneous" with respect to data security policies — i.e. not every data object 250 of the plurality of data objects 250A is associated with an identical security policy. Instead, -policy security data structure 260 must includes: (i) a description of a first data object 250 that is associated, within security data structure 260, with a description of a first security policy; and (ii) a description of a second data object 250 different from the first data object that is associated, within security data structure 260, with a description of a second security policy.

Thus, the table in the previous use case associates Object A with policy 001 and Object B with a different policy - i.e. policy 111. Therefore this table is an example of a 'multi- policy' security data structure. Definitions

For convenience, in the context of the description herein, various terms are presented here. To the extent that definitions are provided, explicitly or implicitly, here or elsewhere in this application, such definitions are understood to be consistent with the usage of the defined terms by those of skill in the pertinent art(s). Furthermore, such definitions are to be construed in the broadest possible sense consistent with such usage.

A "data object" refers to any data or code object stored in non- volatile memory. Examples of "data objects" include but are not limited to firmware objects and configuration files.

A "request to access a data object" refers to a request passed to an "access routine" for accessing the object. The access routine and/or the "requester" may be a hardware module and/or an executing code module. The access routine may service the "access request" by making the data object available to the "requester" in a usable manner - for example, by loading the data object from magnetic medium or flash into RAM memory so that the data object is unencrypted within the RAM, or by executing the code object (for example, a firmware object).

"Enforcing" the security policy refers making the providing of access to the "requester" conditional upon the fulfilling the requirements of the security policy. The enforcing may be carried out at least in part by execution of an executable code module (for example, firmware). Alternatively or additionally, the enforcing may be carried out at least in part by hardware (for example, an ASIC circuit) which is "hardwired" to carry out the enforcing.

An "active security" policy (i) is a security policy whereby one or more security operations are carried out in response to a request for the object; and (ii) is a security policy that makes the providing of access to the "requester" conditional upon effecting one or more operations of a particular security policy.

Thus, an "active" decryption policy requires an attempt to be made to decrypt a requested data object in response to a request for the data object.

An "active" signed-code verification policy requires an attempt to be made to verify signed code of a requested data object in response to a request for the data object.

An "active" anti-flashing policy requires an attempt to be made to determine if the requested data object has been re-flashed in response to a request for the data object.

A data object that is "exposed" to the host device is an object which may be read and/or modified and/or erased by the host device and/or which may be executed by the host device microprocessor and/or which appears in a directory listing readable by the host device A data object which is "hidden" from the host device is an object which is not "exposed" to the host device. A Discussion of FIG. 3

FIG. 3 is a flow chart of a routine for enforcing security policies for a plurality of data objects on a "per-object" basis in accordance with some embodiments. In step S151, a request is received to access a data object residing in the "host-hidden" region 210 of non-volatile memory (for example, flash memory 130). In step S155, it is ascertained which security policy matches an identifier of the data object - for example, by performing a lookup in the multi-policy security data structure. In step S 157, a description of the matching security policy is retrieved from the multi-policy security data structure.

Thus, the operations of steps S155-S159 are an example of "ascertaining" an active security-policy.

In step S163, the security policy whose description is retrieved in step S159 is enforced for the data object.

In some embodiments, device controller 140 is hard-coded to carry out at least in part, any steps described in FIG. 3. Alternatively or additionally, one or more steps described in FIG. 3 is carried out, at least in part, by executable code that is executed by device controller 140.

It is further noted that any of the embodiments described above may further include receiving, sending or storing instructions and/or data that implement the operations described above in conjunction with the figures upon a computer readable medium. Generally speaking, a computer readable medium may include storage media or memory media such as magnetic or flash or optical media, e.g. disk or CD-ROM, volatile or nonvolatile media such as RAM, ROM, etc. as well as transmission media or signals such as electrical, electromagnetic or digital signals conveyed via a communication medium such as network and/or wireless links.

Having thus described the foregoing exemplary embodiments it will be apparent to those skilled in the art that various equivalents, alterations, modifications, and improvements thereof are possible without departing from the scope and spirit of the claims as hereafter recited. In particular, different embodiments may include combinations of features other than those described herein. Accordingly, the claims are not limited to the foregoing discussion.

Claims

WHAT IS CLAIMED IS:

I) A method of protecting content in a storage device, the method comprising: receiving in a storage device a request to access a protectable data object residing in a data region of the storage device that is hidden from a host to which the storage device is operatively connected, and in response to such request: i) ascertaining, in accordance with an identifier of the requested data object, an active security policy; and ii) subject to the ascertaining of the active security-policy, enforcing such active security policy for the requested data object, wherein a different active security policy is respectively applied to each one or more data objects.

2) The method of claim 1, wherein the active security policy includes a decryption policy.

3) The method of claiml, wherein the active security policy includes a signed-code verification policy.

4) The method of claiml, wherein the active security policy includes an anti-re-flashing policy.

5) The method of claim 1 wherein: i) the ascertaining is carried out in accordance with contents of a multi-policy security data-structure including identifiers of the protectable data objects and representations of security policies, each object identifier of a respective data object being associated within the multi-policy security data-structure with at least one of: A) a respective decryption policy for the respective data object;

B) a respective signed-code verification policy for the respective data object; and

C) a respective anti-re-flashing policy for the respective data object; and ii) the ascertained security policy is ascertained in accordance with a security policy representation which matches the identifier of the requested data object within the multi-policy security-data structure.

6) The method of claim 5 wherein the multi-policy security data-structure resides in the host-hidden system data region of the non- volatile memory.

7) The method of claim 1 wherein at least one of the ascertaining and the enforcing is carried out by execution of security-enforcement firmware stored in the host-hidden system data region of the non- volatile memory.

8) The method of claim 7 wherein the method further comprises responding to a powering-up of the data storage device, using a device controller of the storage device in which a reference to the security enforcement firmware is hardcoded into the device processor, by invoking, in accordance with the hardcoded reference, the security enforcement firmware. 9) The method of claim 1 wherein the wherein at least one of the ascertaining and the enforcing is carried out by a device controller of the data-storage device which is hard- coded to carry out at least one of the ascertaining and the enforcing.

10) The method of claim 1 wherein the first and second data objects reside in standard non-secure non-volatile memory.

11) The method of claim 1 wherein the first and second data objects are firmware objects.

12) The method of claim 11 wherein the first and second data objects are flash management firmware objects.

13) The method of claim 1 the method is carried out such that different respective decryption policies are ascertained and enforced for the first and second data objects.

14) The method of claim 1 the method is carried out such that different respective signed- code verification policies are ascertained and enforced for the first and second data objects.

15) The method of claim 1 the method is carried out such that different respective anti-re- flashing policies are ascertained and enforced for the first and second data objects.

16) A data-storage device for providing data-storage services to a host device operatively coupled to the data-storage device, the data-storage device comprising: a) a non-volatile memory including a first region that is accessible to the host device and a second region that is hidden from the host device, the second region being configured to store a plurality of protectable data objects each of which are hidden from the host device including a first data object and a second data object different from the first data object; and b) a device controller which is configured, whenever a request is made to access one of the protectable data objects residing in the second region, to respond to the request by: i) ascertaining, in accordance with an identifier of the requested data object, an active one security policy; and ii) enforcing the ascertained active security policy for the requested data object.

17) The data-storage device of claim 16 wherein the device controller is configured by firmware to effect, in response to the request, at least one of the ascertaining and the enforcing.

18) The data-storage device of claim 16 wherein the device controller is hardcoded to effect, in response to the request, at least one of the ascertaining and the enforcing.

19) The data-storage device of claim 16 wherein the device controller is operative, for a first data object and a second data object different from the first data object, to ascertain and enforce different respective decryption policies for the first and second objects.

20) The data-storage device of claim 16 wherein the device controller is operative, for a first data object and a second data object different from the first data object, to ascertain and enforce different respective signed-code verification policies for the first and second objects.

21) The data-storage device of claim 16 wherein the device controller is operative, for a first data object and a second data object different from the first data object, to ascertain and enforce different respective anti-re-flashing policies for the first and second objects.

22) The data-storage device of claim 16 further comprising: c) a multi-policy security data-structure including identifiers of the protectable data objects and representations of security policies, each object identifier of a respective data object being associated with aHeast one of:

A) a respective decryption policy for the respective data object;

C) a respective anti-re-flashing policy for the respective data object; and wherein the device controller is operative to effect the security policy ascertaining in accordance with a matching security policy representation which matches the identifier of the requested data object within the multi-policy security-data structure.

23) A computer program product, comprising a computer usable medium having a computer readable program code embodied therein, said computer readable program code adapted to be executed to implement a method of managing content by a storage device, the method comprising (a) receiving in a storage device a request to access a protectable data object residing in a data region of the storage device that is hidden from a host to which the storage device is operatively connected, and (b) in response to such request: i) ascertaining, in accordance with an identifier of the requested data object, an active security policy; and ii) subject to the ascertaining of the active security-policy, enforcing such active security policy for the requested data object, wherein a different active security policy is respectively applied to each one or more data objects.