US20010052073A1 - Storage controller conditioning host access to stored data according to security key stored in host-inaccessible metadata - Google Patents
Storage controller conditioning host access to stored data according to security key stored in host-inaccessible metadata Download PDFInfo
- Publication number
- US20010052073A1 US20010052073A1 US09/825,456 US82545601A US2001052073A1 US 20010052073 A1 US20010052073 A1 US 20010052073A1 US 82545601 A US82545601 A US 82545601A US 2001052073 A1 US2001052073 A1 US 2001052073A1
- Authority
- US
- United States
- Prior art keywords
- storage
- security key
- data
- controller
- host
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000003860 storage Methods 0.000 title claims abstract description 360
- 230000003750 conditioning effect Effects 0.000 title description 2
- 238000013500 data storage Methods 0.000 claims description 73
- 238000000034 method Methods 0.000 claims description 33
- 238000012545 processing Methods 0.000 claims description 19
- 230000008569 process Effects 0.000 claims description 7
- 238000009877 rendering Methods 0.000 claims 5
- 230000006870 function Effects 0.000 abstract description 17
- 230000008901 benefit Effects 0.000 description 9
- 238000004891 communication Methods 0.000 description 5
- 230000003287 optical effect Effects 0.000 description 5
- 238000010586 diagram Methods 0.000 description 4
- 238000004519 manufacturing process Methods 0.000 description 4
- 101001077478 Homo sapiens RNA guanine-N7 methyltransferase activating subunit Proteins 0.000 description 3
- 102100025054 RNA guanine-N7 methyltransferase activating subunit Human genes 0.000 description 3
- 230000009286 beneficial effect Effects 0.000 description 3
- 238000012937 correction Methods 0.000 description 3
- 230000007246 mechanism Effects 0.000 description 3
- 230000004044 response Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000013459 approach Methods 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 239000000470 constituent Substances 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 238000013508 migration Methods 0.000 description 1
- 230000005012 migration Effects 0.000 description 1
- 238000003825 pressing Methods 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 230000001105 regulatory effect Effects 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
- G06F21/107—License processing; Key processing
- G06F21/1077—Recurrent authorisation
Definitions
- the present invention concerns access security for digital data. More particularly, the invention is implemented in a storage or device controller to regulate data security using a key and other parameters stored in metadata. Among other benefits, this enables the storage controller or device to be attached directly to a network without compromising security or having to add an intermediate server to perform security functions.
- the common storage is often coupled to individual user computers via intermediate hardware such as storage servers and networks.
- the common storage may be a single device, but more often comprises many different physical storage devices.
- Some examples of multi-user storage systems are: (1) corporate Intranet systems accessed by employee users, (2) telephone records accessible by telephone operator-users located around the state, nation, or world, (3) banking records accessed by remote customer-users operating automatic teller machines, and (4) engineering design specifications or models accessed by engineer-users working together on a technical project. A variety of other arrangements are also known.
- the invention provides access security for stored digital data by using a storage or device controller to regulate data security according to a security key and other parameters stored in metadata. This enables the storage controller or device to be attached directly to a network without compromising security or having to add an intermediate server to perform security functions.
- the storage system of this invention includes a storage controller coupled to a digital data storage.
- the controller is also coupled to, or at least accessible by, one or more hosts.
- the digital data storage contains host-accessible user data accessed by the storage controller on behalf of hosts, as well as host-inaccessible metadata used by the storage controller to manage the user data.
- the storage controller receives a write request from one of the hosts. Such a request includes a proposed key and target data to be written to storage.
- the storage controller stores the target data as host-accessible user data, and also stores the key as host-inaccessible metadata associated with the target data. Thereafter, the storage controller requires hosts to provide a key matching or having another prescribed relation to the stored key as a condition to granting future host requests to access the stored target data.
- the invention may be implemented to provide a method of conditioning host access to stored data according to keys stored in host-inaccessible metadata.
- the invention may be implemented to provide an apparatus, such as a data storage system, utilizing storage controllers configured to condition host access to stored data according to keys stored in host-inaccessible metadata.
- the invention may be implemented to provide a signal-bearing medium or tangibly embodying a program of machine-readable instructions executable by a machine such as a storage controller to manage storage as discussed herein.
- the invention may also be embodied by logic circuitry configured to manage storage as discussed herein.
- the invention affords its users with certain distinct advantages. For instance, by using a storage controller rather than a server or host machine as a security gate, the invention provides storage security for a variety of different host computers that utilize comparatively incompatible operating systems. As another benefit, the invention is inexpensive because it may be implemented to provide data security using a network attached storage controller without using an expensive server machine. Similarly, the invention does not burden the processing and input/output resources of existing host machines with security functions, since security is implemented on the storage controller level. The invention is also beneficial because it provides a flexibility in implementation and may be applied in a variety of different environments. For instance, the invention may be applied to sound recordings to limit playback to users that have purchased an appropriate key. The invention also provides a number of other advantages and benefits, which should be apparent from the following description of the invention.
- FIG. 1A is a block diagram of the hardware components and interconnections of a data storage system according to the invention.
- FIGS. 1 B- 1 E are block diagrams showing different system configurations according to the invention.
- FIG. 1F is a block diagram showing several exemplary storage tracks and their constituent data objects and metadata according to the invention.
- FIG. 2 is a block diagram of a digital data processing machine according to with the invention.
- FIG. 3 shows an exemplary signal-bearing medium according to the invention.
- FIG. 4A is a flowchart showing operations performed to allocate data storage according to the invention.
- FIG. 4B is a flowchart showing operations performed to write data to storage according to the invention.
- FIG. 5 is a flowchart showing controller operations performed to process a Read request according to the invention.
- FIG. 6 is a flowchart showing operations performed by a new host to join the data storage system of the invention.
- One aspect of the invention concerns a data storage system, which may be embodied by various hardware components and interconnections as shown by the system 100 of FIG. 1A.
- the system 100 includes multiple host machines 102 - 104 , a network 130 , a storage controller 106 , and digital data storage 108 (“storage”).
- the host machines 102 - 104 are coupled to the network 130 .
- some or all of the hosts may be interconnected by various links (not shown).
- the hosts include respective host application programs 110 - 112 .
- “host” comprises any machine, user, application program, process, or other entity, that submits storage access requests to the storage controller 106 .
- storage access requests of the illustrated hosts may arise from other sources (not shown), such as wireless telephones, sensors, satellites, or other sources.
- the host machines 102 - 104 comprise various hardware devices suitable to generate storage access requests, such as personal computers, mainframe computers, computer workstations, supercomputers, or other suitable machines.
- the illustrated host machines 102 - 104 may be running respective application programs 110 - 112 , from which the need for nonvolatile storage access arises.
- the host machines 102 - 104 may be running a variety of different operating systems (not shown), which may even be incompatible with each other.
- Some exemplary operating systems include MVS, UNIX, WINDOWS NT, etc.
- Some or all of the host machines 102 - 104 may be interconnected by communications links (not shown) such as wires, cables, fiber optic lines, wireless links, satellite, telephone lines, etc.
- communications links such as wires, cables, fiber optic lines, wireless links, satellite, telephone lines, etc.
- some or all of the host machines 102 - 104 may be completely unrelated, such as different host machines coupled to the Internet (i.e., the network 130 ) at different sites around the world.
- the host machines 102 - 104 may include respective interfaces (not shown), such as ESCON links, small computer system interfaces (SCSIs), telephone/DSUcable modems, intelligent channels, and the like to interface with each other, the network 130 , etc.
- each host machine 102 - 104 may be running one or more application programs, exemplified by the programs 110 - 112 .
- the application programs 110 - 112 generate “storage access requests” seeking access to the storage 108 .
- each storage access requests includes one or more of the following components:
- a requested access type such as Read, Write, Update, Allocate, Allocate and Write, etc.
- the system 100 may also include one or more networks, such as the illustrative network 130 .
- the network 130 is helpful to illustrate the embodiment (as shown in FIG. 1A) where the storage controller 106 provides network-attached storage.
- the network 130 comprises any desired communication path(s) interconnecting host machines such as 102 - 104 .
- host machines such as 102 - 104 .
- One example is the public Internet or a corporate Intranet.
- Other examples include bus, star, or token ring configurations.
- the network 130 may utilize one or more local, metropolitan, and/or wide area networks.
- the network 130 may utilize TCP/IP, Systems Network Architecture, Ethernet, or any other desired protocol. Ordinarily skilled artisans (having the benefit of this disclosure) will also recognize other network configurations and protocols to implement the network 130 .
- the storage controller 106 acts as network-attached storage, benefitting from the cost-savings of omitting a server or other intermediate gate. Nonetheless, a server, secondary host, or other machine may be interposed between the storage controller 106 and host machines 104 if desired. Furthermore, the network 130 may be omitted from the system entirely, in which case the storage controller 106 is coupled to a host machine 102 - 104 individually, coupled to a server or other intermediate machine that is itself coupled to the host machine, or coupled to a user interface for direct access by users.
- the storage controller 106 works with formatting, layout, encoding, parity checking, error correction, and other aspects of physically storing data on the media encompassed by the storage 108 .
- the storage controller 106 generates, reads, formats, and utilizes host-invisible metadata that is stored with host-accessible “user data” in the storage 108 .
- the host machines 102 - 104 and application programs 110 - 112 deal with the user data itself, but cannot access the metadata.
- the hosts may reference user data according to logical addresses, in which case the storage controller 106 translates between logical addresses (as used by the hosts) and physical addresses (relating to the storage media itself).
- the storage controller 106 may be implemented in a number of different ways.
- the storage controller 106 may be implemented by a device controller. Some examples include a hard drive controller, optical disk controller, CD-ROM controller, tape drive, floppy diskette drive, or other mechanism that is associated with a particular removable or nonremovable media type.
- the storage controller 106 may comprise one or more supervisory processing machines managing a number of subservient device controllers. Some examples include the IBM xSeries 150 Network Attached Storage, IBM Enterprise Storage Server Models F10 and F20, IBM RAMAC product line, etc.
- FIGS. 1 B- 1 D illustrate several exemplary configurations of storage controllers and devices, as discussed below.
- the storage controller 106 includes an interface 120 to communicate with the network 130 (as illustrated), server, host, etc.
- the interface 120 may comprise an intelligent digital input/output communication channel, modem, interface card, bus, backplane, port, connector, or any other interface suitable to the particular application.
- the storage 108 serves to store data as directed by the storage controller 106 .
- the storage 108 may include storage media along with one or more device controllers that are managed by the storage controller 106 , as in the examples of FIGS. 1 B- 1 C.
- the storage 108 may include the media only, where the media's device driver embodies the storage controller 106 , as in the example of FIG. 1D.
- the storage 108 may be implemented by media of various types, such as magnetic disk drive, magnetic tape, optical disk, optical tape, semiconductor memory, a combination of the foregoing, or any other suitable digital data storage media.
- the storage 108 may be configured as a single “logical” device, where data is actually stored on separate physical devices.
- the storage 108 may be implemented by the magnetic disk drive media units of an IBM RAMAC disk drive system.
- any of the embodiments of FIGS. 1 B- 1 D may be implemented as a local storage/retrieval apparatus by substituting a user interface for the component as “network.”
- the storage or device controller grants different access rights to people operating the user interface depending upon the security key that they supply.
- FIG. 1E describes a particular example of this embodiment, including a playback device 174 that comprises a music CD player that selectively plays songs stored on removable CD media 176 according to a security key entered by a user 178 via a user interface 170 .
- Security functions are implemented by device controller 172 .
- the CD media 176 is write-only, and the approved security keys for each song are stored on the media at the time of manufacture.
- the user interface 170 may comprise a keypad for entering security keys.
- the user interface 170 may comprise a module to receive tangible security keys such as 171 , which comprise plug-in chips/cassettes that are plugged-in to the interface 170 , magnetic cards that are swiped or waved past the interface 170 , etc., where the tangible security key 171 contains a machine-readable representation of a security key.
- tangible security keys such as 171 , which comprise plug-in chips/cassettes that are plugged-in to the interface 170 , magnetic cards that are swiped or waved past the interface 170 , etc.
- the tangible security key 171 contains a machine-readable representation of a security key.
- users purchase a music CD for one low price, and then purchase the tangible security key containing the security key associated with to the songs they wish to hear.
- CDs are given in the foregoing example, other media may be used without departing from the invention.
- the controller 106 operates as a gate, selectively accepting or refusing hosts' access requests according to a preestablished data security scheme. Since this scheme is implemented by the controller 106 rather than one or more hosts 102 - 104 , the hosts are available for other tasks. Additionally, the storage controller's centrality and independence from the hosts 102 - 104 is conducive to access by hosts of many different operating systems. Furthermore, the controller's security features enable the storage controller 106 to be used as network-attached storage, providing security without the need for a server or other intermediate security gate.
- the controller 106 includes a controller security module 122 , which performs the controller's security functions.
- the security module 122 may comprise a hardware component, such as one or more computers, microprocessors, logic circuits, ASICs, or other digital data processing apparatus. Alternatively, the security module 122 may be an application program comprising a sequence of programming instructions executed by one or more processors of the controller 106 .
- the controller's gating function requires it to consult a “reference location” containing a security key associated with the data being sought.
- the stored security key may be called the “reference security key.”
- the controller 106 evaluates the reference security key against a proposed security key from the storage access request to determine whether the request should be permitted. The contents and use of security keys are discussed in greater detail below.
- the reference location constitutes storage space accessible to the controller 106 , and in one example comprises data (including the reference security key) stored at the controller 106 as illustrated by the storage use map 124 .
- the map 124 may be located elsewhere if desired such as in the storage 108 or other site accessible to the controller 108 .
- TABLE 1 depicts an example of the storage use map 124 , in the form of a lookup table.
- the “storage region” column identifies regions in the storage 108 .
- the “reference security key” lists an access key that governs access to the associated storage region.
- the storage controller 106 may utilize the reference security key to govern access to the storage region according to various techniques, such as password, public/private key encryption, or others as explained in detail below. In this simplified example, reference keys of “1” and “2” are provided for ease of explanation, however more complicated codes may be used.
- the associated “security type” also called “access level” designates the security precautions applicable to the corresponding storage region.
- the security type may specify operations that are prohibited without the requesting host submitting an input key (also called “proposed security key”) that satisfies the prescribed reference security key.
- the security type may require the storage controller to prevent, without host provision of a proposed security key that satisfies the reference security key, one or more of the following operations: read, write, delete, update, format, etc.
- TABLE 1 may be condensed by listing abbreviated pointers to other storage locations that contain the actual values of storage region, reference security key, and/or security type. Furthermore, TABLE 1 may be encrypted by controller 106 to prevent accidental/malicious access of its contents.
- TABLE 1 may omit anything to do with read security, wherein the storage controller 106 stores user data encrypted with an associated security key, and read security is thereby inherently provided by the storage controller 106 decrypting user data with whatever proposed key is supplied by the host.
- encryption may use the public/private key architecture, where each user can only encrypt all public data and private data associated with the user's private key.
- the storage controller 106 may carry out its gate function by incorporating the reference security key into metadata associated with user data in the storage 108 .
- the storage use map 124 may be omitted.
- FIG. 1F describes an example of a subsection of storage 108 implementing this feature.
- FIG. 1F illustrates the contents of several exemplary tracks 150 - 153 of data that reside upon a magnetic disk storage medium in the storage 108 .
- the tracks 150 - 153 are shown in linear form for ease of explanation.
- Each track 150 - 153 includes a respective region of user data 160 - 163 and an associated region of metadata 155 - 158 .
- the metadata regions 155 - 158 may precede the user data regions 160 - 163 (as shown), follow the user data, be interspersed with the user data, or another arrangement as suits the application.
- the storage controller 106 initially stores the user data on behalf of hosts that provide the data; the storage controller 106 may also carry out host requests to modify, read, delete, or otherwise manage such user data.
- the user data 160 - 163 is said to be host-accessible.
- the metadata 155 - 158 is used solely by the storage/device controllers to manage storage and retrieval of the user data. In this sense, the metadata 155 - 158 is host-inaccessible.
- the block 140 shows the contents of metadata 155 in greater detail, according to one example.
- the metadata block 140 includes information such as the track address 142 , number of bytes 142 of user data in that track, error correction control information 144 , parity information 145 , a reference security key 146 , and security type 147 .
- Different or other 141 , 148 items of metadata may also be used, depending upon the application.
- the reference security key 146 and security type 147 have function and content as described above in conjunction with TABLE 1.
- each item of metadata (and its reference key and security type) pertains to one track, which constitutes the storage region associated with that metadata.
- the reference security key 146 governs host access to the track 150 .
- a reference security key may be associated with a multi-track data object by listing that reference security key in the metadata of each track occupied by the data object.
- the present invention also contemplates a variety of other approaches, where the reference security key 146 and security type 147 are stored in metadata associated with a data object, extent, byte, range of tracks or address, sector, block, record, file, page, record, logical cylinder, logical device, physical device, or another suitable arrangement depending upon the application. Furthermore, multiple security keys may be provided with each item of user data, with one, some, or all of the security keys having a different security type associated therewith.
- FIG. 1F is now re-described in the context FIG. 1E, described above.
- the storage 108 comprises a CD or other sound recording 176 and the storage controller 106 comprises a playback device 174 .
- reference one or more s are incorporated into metadata associated with recorded songs, tracks, or other segments at the time of manufacture, and the storage use map 124 is omitted.
- the items 150 - 153 refer to music “tracks” on the sound recording media, where each track corresponds (for example) to a different song.
- Each track 150 - 153 includes a respective region of sound recording data (referred to as a “song without any intended limitation”) 160 - 163 and an associated region of metadata 155 - 158 .
- the metadata regions 155 - 158 may precede the songs 160 - 163 (as shown), follow the songs, be interspersed with the songs, or another arrangement as suits the application.
- the block 140 shows the contents of metadata 155 in greater detail, according to one example.
- the metadata block 140 includes information such as the address 142 of the associated song 160 on the media 176 , number of bytes 142 that the song 160 occupies in that track, error correction control information 144 , parity information 145 , a reference security key 146 , and security type 147 .
- Different or other 141 , 148 items of metadata may also be used, depending upon the application.
- the reference security key 146 and security type 147 have function and content similar to that described above, however only the security type “Playback Requires Security Key” is utilized. Thus, if a user cannot provide the requisite security key, the device controller 172 will not play the subject song.
- additional reference keys and associated security types may be provided with each track.
- the CD manufacturer or record label may offer an inexpensive license enabling users to listen to a limited number of songs (such as songs one, two, and three), and a more expensive license enabling users to listen to all songs on the media 176 .
- a sufficient number of security keys and security types may be stored to anticipate access to every possible combination of some or all of the songs on the CD, so that users could purchase a license limited to songs desired by that user.
- every song of an artist may be put on a single media, with user access limited by security key to the songs associated with that security key.
- the storage controller 106 may be embodied by various hardware components and interconnections.
- the apparatus 200 includes a processor 202 , such as a microprocessor or other processing machine, coupled to a storage 204 .
- the storage 204 includes a fast-access storage 206 , as well as nonvolatile storage 208 .
- the fast-access storage 206 may comprise random access memory, and may be used to store the programming instructions executed by the processor 202 .
- the nonvolatile storage 208 may comprise, for example, one or more magnetic data storage disks such as a “hard drive”, a tape drive, or any other suitable storage device.
- the apparatus 200 also includes an input/output 210 , such as a line, bus, cable, electromagnetic link, or other means for exchanging data with the processor 202 .
- a different aspect of the invention concerns a method of providing access security for digital data by using a storage or device controller to regulate data security according to a security key and other parameters stored in the data's metadata. This enables the storage controller or device controller to be attached directly to a network without compromising security or having to add an intermediate server to perform security functions.
- such a method may be implemented, for example, by operating the storage controller 106 (or device controller 172 ), as implemented by a digital data processing apparatus 200 , to execute a sequence of machine-readable instructions.
- These instructions may reside in various types of signal-bearing media.
- This signal-bearing media may comprise, for example, RAM (not shown) contained within the controller 106 , as represented by the fast-access storage 206 .
- the instructions may be contained in another signal-bearing media, such as a magnetic data storage diskette 300 (FIG. 3), directly or indirectly accessible by the processor 202 .
- the instructions may be stored on a variety of machine-readable data storage media, such as DASD storage (e.g., a conventional “hard drive” or a RAID array), magnetic tape, electronic read-only memory (e.g., ROM, EPROM, or EEPROM), an optical storage device (e.g. CD-ROM, WORM, DVD, digital optical tape), paper “punch” cards, or other suitable signal-bearing media including transmission media such as digital and analog and communication links and wireless.
- DASD storage e.g., a conventional “hard drive” or a RAID array
- magnetic tape e.g., magnetic tape, electronic read-only memory (e.g., ROM, EPROM, or EEPROM), an optical storage device (e.g. CD-ROM, WORM, DVD, digital optical tape), paper “punch” cards, or other suitable signal-bearing media including transmission media such as digital and analog and communication links and wireless.
- the machine-readable instructions may comprise software object code, compiled from a language such
- FIG. 4A shows a sequence 400 performed to allocate space in the storage 108 according to the invention.
- allocation as discussed herein is a host-managed operation. Allocation may be driven by the storage controller 106 in other examples.
- FIG. 4A is described in the context of the environment described above in FIGS. 1 A- 1 D, 1 F, 2 , 3 .
- step 402 The sequence is initiated in step 402 , when one of the application programs 110 - 112 experiences conditions requiring allocation of storage.
- the condition causing step 402 may further dictate relevant aspects of the necessary allocation operation, such as (1) the type of storage device to be used in the allocation operation if the storage 108 contains different types of storage media, ( 2 ) the size of region to allocate, and (3) other pertinent aspects.
- Allocated storage regions may be expressed in terms of any convenient or appropriate unit of granularity, such as one or more disk sectors, disk tracks, disk “extents”, logical volumes, address ranges, blocks, tape tracks, files, datasets, etc. Storage regions may also have user-specified sizes, in which event this additional characteristic may be included in the allocation request.
- one or more storage regions may comprise subsets of a larger data structure, such as a database, file, storage group, dataset, etc; advantageously, this embodiment may facilitate different levels of security for subsets of a larger data structure.
- step 406 the application program 110 - 112 chooses a desired level of security for the region to be allocated.
- the levels of security also called “security types” or “access levels” include:
- “none” may be used as a default value if another security type is not chosen.
- step 406 the application program 110 - 112 generates a reference security key (if some type of security was selected in step 406 ) to be used by the controller 106 in regulating future host access to the allocated storage region.
- the “reference” security key provides a reference copy against which hosts' proposed keys are to be evaluated.
- the reference security key of step 408 may comprise an alphabetic, numeric, alphanumeric, or other machine-readable code.
- the reference security key may comprise a 256-bit digital number, selected in accordance with a public key encryption scheme, as discussed below.
- the application programs 110 - 112 may be configured such that, if the host seeks to extend an already-allocated storage region, the storage step 408 utilizes the region's existing reference security key instead of generating a new one.
- step 408 the application program 110 - 112 issues a requestto allocate storage or extend allocation of already-allocated storage (step 412 ).
- This request includes the reference security key and security type of steps 406 , 408 and may be issued in the form of a command to a host operating system, another application program on the same host that manages storage requests, or directly to the storage controller 106 .
- step 414 is performed, where the recipient relays the allocation request to the controller 106 , for example, by issuing an allocate command with a set-reference-key parameter, specifically directing the controller 106 to associate the provided reference key and security type with the storage region to be allocated.
- step 414 may be omitted.
- the recipient storage controller 106 may provide the security key on behalf of the host, in which case step 408 is omitted.
- step 414 the controller 106 stores the security type and reference security key in a prescribed reference location, in association with the allocated storage region (step 416 ).
- the reference location is the storage use map 124 ; in this embodiment, the controller 106 in step 416 stores the key and security type in the map 124 .
- the reference location may comprise host-inaccessible metadata in the allocated storage region itself, as explained above in conjunction with FIG. 1F; in this example, step 416 involves storing these items in metadata such as 155 - 158 , the associated user data being empty.
- step 416 the requested allocation is complete, and the sequence 400 ends in step 418 .
- the allocated storage region is now available for selective access by the hosts, depending upon the established security type and the hosts' ability to provide an acceptable key.
- FIG. 4B shows a sequence 450 performed to write data to the storage 108 according to the invention.
- the sequence 450 is initiated in step 462 , when an occasion arises for one of the application programs 110 - 112 to write data to the storage 108 .
- step 464 the application program 110 - 112 chooses a desired security type for the data to be written.
- the security types in this example include read/write protect, write protect, and none as explained above.
- the application program 110 - 112 After step 464 , the application program 110 - 112 generates a reference security key (step 466 ); step 466 may be omitted if “none” was selected as the security type in step 464 .
- the reference security key of step 466 comprises an alphabetic, numeric, alphanumeric, or other machine-readable code as discussed above.
- step 466 comprises the application program attempting to supply the believed reference security key for the previously written data.
- step 468 the application program 110 - 112 issues a write request (step 468 ).
- the write request constitutes a command to write data to the storage 108 , and may specify relevant aspects of the operation, such as the type of storage device to be used in the Write operation if the storage 108 contains different storage modes, and other pertinent aspects.
- step 468 involves the application program 110 - 112 issuing a Write request along with the user data to be written, a proposed key (if attempting to modify existing data), and a new reference key and security type (if writing new data).
- the request of step 468 may be issued to a host operating system, another application program on the same host that manages storage requests, or directly to the storage controller 106 .
- step 470 is performed, where the recipient relays the Write request to the controller 106 .
- the recipient may provide its directions to the controller 106 by issuing a Write command with a set-reference-key parameter, specifically directing the controller 106 to associate the provided reference key and security type with the user data proposed for storage.
- the Write request recipient may provide its directions to the controller 106 in the form of a Write command with a proposed-key-parameter.
- the controller 106 determines whether the user data proposed for storage is new or existing in the storage 108 (step 472 ). This is performed by cross-referencing information from the Write request (from step 470 ) with information that the controller 106 maintains about data in the storage 108 . If the proposed data object is new, the controller 106 stores the data, and also stores the security type and reference security key in a prescribed reference location, in association with the allocated storage region (step 482 ). As mentioned above, one example of the reference location is the storage use map 124 ; in this embodiment, the controller 106 in step 482 stores the reference security key and security type in the map 124 .
- the reference location may comprise host-inaccessible metadata in the user data itself, as explained above in conjunction with FIG. 1F; in this example, step 482 involves storing these items in the metadata associated with the identified user data. For example, they may be stored preceding the user data, in a metadata header, as shown in FIG. 1F. Other locations may be used instead, such as metadata interspersed throughout the data object, a metadata suffix, or another location. In the case of a write operation, step 482 also involves the storage controller 106 writing the user data to storage 108 .
- the controller 106 may direct the storage 108 to employ the reference security key to encode the user data during the Write operation of step 482 .
- the controller 106 may use the reference security key to encode the user data supplied by the host and then store the data as encoded.
- Encoding and decoding in this embodiment may use a number of different techniques that are well known to those in the relevant art. For instance, one useful technique is public/private key encryption. By using such encoding/decoding, stored data enjoys two levels of protection: (1) one level, by the controller 106 requiring requesting hosts to submit a proper proposed key to access the user data, and (2) another level, by encoding the user data itself with the security key.
- step 472 advances to step 474 , where the controller 106 consults the reference security key and security type fields 146 - 147 associated with the user data to determine the security type and reference security key.
- the controller 106 in step 476 determines whether the proposed Write operation is allowed. Namely, the Write operation is not allowed if the security type of the existing user data is “read/write protect” or “write protect” and the proposed key is not appropriate to the reference security key. For instance, the proposed/reference keys may be required to match, or there be a match between derivatives of one or both. If the Write operation is not allowed, step 476 advances to step 480 , where the controller 106 rejects the requested Write operation.
- step 476 advances to step 480 , where the controller 106 performs the Write operation upon the storage 108 .
- the controller 106 may direct the storage 108 to employ the reference security key in encoding data during the Write operation of step 480 .
- sequence 450 ends after completion of steps 478 , 480 , or 482 .
- FIG. 5 shows a sequence 500 of reading data from storage 108 .
- FIG. 5 is described in the context of the environment described above in FIGS. 1 A- 1 D, 1 F, 2 , 3 .
- the sequence 500 begins in step 502 when an occasion arises for one of the application programs 110 - 112 to read data from the storage 108 .
- This may originate from a source such as an internal process of the application program, another application program of the requesting host, a user terminal or other input device (not shown) coupled to the host, another computer coupled to the host, etc.
- the application program In step 503 , responsive to the event of step 502 , the application program generates a Read request including (1) identification of desired user data (“target user data”), such as by name, logical or physical storage location, storage device, etc., and (2) a proposed key for use by the controller 106 to determine whether the application program should have access to the requested user data.
- target user data identification of desired user data
- storage device such as by name, logical or physical storage location, storage device, etc.
- step 503 If the Read request of step 503 seeks access to user data whose security type is “none,” the proposed key may be omitted from step 503 .
- the Read request of step 503 may be issued to the host machine, another application program, or directly to the controller 106 .
- step 504 the controller 106 receives the Read request of step 503 .
- the controller 106 determines whether the target user data is protected, i.e., whether a reference location has associated a reference security key with the target user data (step 506 ). This is performed by the controller 106 consulting the storage use map 124 (one example) or the metadata (other example). If the target user data does not have an associated reference security key, this storage region has no security protection and further analysis is unnecessary.
- the routine 500 passes from step 506 to step 516 , where the controller 106 operates the storage 108 to read and output the requested user data. Following step 516 , the sequence 500 ends in step 518 .
- step 506 advances to step 508 .
- step 508 the controller 106 determines user data's security type. Namely, the controller 106 consults the reference location to retrieve the security type associated with the target user data, and thereby determine whether Read operations are permitted without submittal of a suitable proposed access key.
- step 508 may be performed by the controller 106 consulting the security type 147 in metadata to see whether Read operations are protected. Alternatively, step 508 may be performed by the controller 106 consulting the storage use map 124 to determine whether Read operations are protected.
- step 508 advances to step 516 , where the controller 106 directs the storage 108 to read and output the requested data object (step 516 ), and then the sequence 500 ends in step 518 .
- the reference security key may be used to decrypt the user data if the user data has been encrypted.
- step 508 finds that Reads of the requested user data are protected, the routine 500 advances from step 508 to step 510 .
- the controller 106 checks the host-submitted proposed key (received in step 504 ) against the reference security key (found in the reference location, e.g., key 146 or storage use map 124 ).
- step 510 involves comparing the proposed and reference security keys to see whether they match.
- step 510 may apply a predetermined processing sequence to derive a second key from the proposed key (such as by decryption using a different, prescribed private key), with this derived key being compared against the reference key.
- the reference security key may be processed to derive a second key, with this derived key being compared to the proposed key.
- Other alternatives are also contemplated, such as processing both reference and proposed keys and comparing their derivatives.
- step 512 advances to step 514 where the controller 106 returns an error condition to the requesting host. Otherwise, if step 512 finds that the proposed key (or its derivative) matches the reference access key (or its derivative), the proposed access key is valid, and the controller 106 directs the storage 108 to complete the requested Read operation in step 516 . After steps 514 or 516 , the sequence 500 ends in step 518 .
- the controller 106 may direct the storage 108 to employ the reference security key in decoding data during the Read operation of step 516 .
- the controller 106 uses the reference security key to decode the stored user data, and then provides the decoded data to the requesting host.
- decoding may utilize a number of different techniques that are well known to those in the relevant art, such as public/private key encryption.
- step 516 the routine 500 ends in step 518 .
- FIG. 5 Another description of FIG. 5 is now made to specifically illustrate the playback of data from CD media 176 in the environment of FIG. 1E.
- the CD media 176 comprises a read-only music CD that is provided with one or more reference security keys 146 and operation parameters 147 (as described in FIG. 1F) at the time of manufacture.
- the storage use map 124 is omitted, since the media 176 contains security information in its metadata.
- the media 176 may contain several different reference keys 146 in association with each song.
- the sequence 500 begins in step 502 when a user 178 decides to listen to one or more songs on the CD 176 .
- the user 178 submits a proposed security key by entering the key into the user interface 170 , or by providing a tangible security key 171 to the interface 170 .
- the user interface 170 responsive to the event of step 502 , the user interface 170 generates a Play request including (1) identification of one or more desired songs, such as by name, logical or physical storage location, storage device, etc., and (2) the user's proposed key.
- the interface 170 forwards the Play request to the device controller 172 to determine whether the user should have access to the requested user data. If the Play request of step 503 seeks access to user data whose security type is not “Playback Requires Security Key,” the proposed key may be omitted from step 503 .
- step 504 the controller 172 receives the Play request of step 503 .
- the controller 172 determines whether the target song tracks is protected, i.e., whether each requested song track has an associated reference key (step 506 ). This is performed by the controller 172 consulting the song track's metadata. If the target song track does not have any associated reference keys, this area has no security protection and further analysis is unnecessary.
- the routine 500 passes from step 506 to step 516 , where the controller 172 provides an audible output of the requested song track from the media 176 . Following step 516 , the sequence 500 ends in step 518 .
- step 506 advances to step 508 .
- step 508 the controller 172 determines song track's security type. Namely, the controller 172 consults security type 147 in metadata stored on the media 176 to determine whether Play operations are permitted without submittal of a suitable proposed access key. If Play operations are not protected, step 508 advances to step 516 , where the controller 172 interacts with the media 176 to read and output (Play) the requested song track (step 516 ), and then the sequence 500 ends in step 518 .
- the proposed key may be used to decrypt the requested song if the song has been stored on the media 176 with encryption.
- step 508 finds that Playback of the requested song track is protected, the routine 500 advances from step 508 to step 510 .
- the controller 172 checks the user-submitted proposed key (received in step 504 ) against the reference security key (found in the requested song's metadata).
- step 510 involves comparing the proposed and reference security keys to see whether they match.
- step 510 may apply a predetermined processing sequence to derive a second key from the proposed key (such as by decryption using a prescribed private key), with this derived key being compared against the reference security key.
- the reference security key may be processed to derive a second key, with the derived key being compared to the proposed key.
- Other alternatives are also contemplated, such as processing both reference and proposed keys and comparing their derivatives.
- step 512 concludes that the proposed key is not valid. In this case, the controller 172 returns an error condition to the requesting host in step 514 . Otherwise, if the proposed key (or its derivative) matches the reference access key (or its derivative), step 512 concludes that the proposed access key is valid, and the controller 172 directs the storage 108 to complete the requested Play operation in step 516 . After steps 514 or 516 , the sequence 500 ends in step 518 .
- FIG. 6 shows a sequence 600 performed by a new host in order to join the system 100 , and participate in future allocation and/or data access requests.
- the example of FIG. 6 is described in the context of the environment described above in FIGS. 1 A- 3 .
- the new host obtains reference security keys for the user data to be accessed in the future.
- the new host must configure its own interface (not shown) with the controller 106 to properly communicate the contents of a storage access request.
- the new host obtains one or more existing reference security keys from a source such as other hosts 102 - 104 , the controller 106 , application programs 110 - 112 , user input, system administrator, etc.
- This step is optional, however, since there may be no need or intention for the new host to access user data that is already protected.
- a host-host exchange of reference security keys may be conducted over the network 130 or over the links (not shown), for example.
- the new host's application program reconfigures its interface with the controller in step 606 .
- the new host's interface may comprise an ESCON interface, small computer standard interface (SCSI), parallel or serial port, telephone modem, or any other digital data communications medium compatible with the particular embodiment of controller used in the system 100 .
- the host interface may already be configured to receive storage access requests, e.g., components such as identification of targeted user data, security types, etc.; in this case, step 606 involves reconfiguring the host interface to accept submittal of proposed keys in the future.
- an ESCON interface this may involve adding a new channel command word, or modifying an existing channel command word to accept an proposed access key.
- the SCSI protocol is modified in step 606 to accept the input access parameter.
- the addition of new hosts does not require any security modification since the reference security keys are stored at the controller 106 or storage 108 .
- an internal setting may be provided within the controller 106 to bypass key checking in certain predefined environments or events.
- bypass may be desirable during disaster recovery, backup, data migration, and other operations.
- the controller 106 may additionally recognize a “reset-key” command issued by hosts 102 - 104 .
- the reset-key command directs the controller 106 to alter the access characteristics of an allocated storage region or stored data object.
- An illustrative reset-key includes a proposed key, along with a replacement reference security key and/or security type for the allocated storage region or user data.
- the controller 106 validates the proposed key, and then proceeds to update its reference location (e.g., storage use map 124 or metadata). Otherwise, if the proposed key is invalid, the controller 106 fails the reset request.
- the invention also contemplates a “clear-key” command issued by hosts 102 - 104 to remove security protection of an allocated storage region or stored data object.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Multimedia (AREA)
- Technology Law (AREA)
- Computer Hardware Design (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Storage Device Security (AREA)
Abstract
A storage controller conditions host access to stored data objects upon host provision of a proposed key with matching or other prescribed relation to a security key stored in host-inaccessible metadata that is associated with the stored data object. The security key may be established upon writing the data or allocating storage space, for example. This enables the storage controller or device to be attached directly to a network without compromising security or having to add an intermediate server to perform security functions. Another implementation concerns sound recording playback devices that only play sound tracks for which the user has purchased an appropriate security key.
Description
- This application is a continuation-in-part of co-pending U.S. application Ser. No. 09/096,962, entitled “STORAGE SYSTEM WITH DATA-DEPENDENT SECURITY,” filed on Jun. 12, 1998 in the names of the present inventors.
- 1. Field of the Invention
- The present invention concerns access security for digital data. More particularly, the invention is implemented in a storage or device controller to regulate data security using a key and other parameters stored in metadata. Among other benefits, this enables the storage controller or device to be attached directly to a network without compromising security or having to add an intermediate server to perform security functions.
- 2. Description of the Related Art
- To get the most out of their storage systems, system administrators often provide common storage for access by multiple different users. The common storage is often coupled to individual user computers via intermediate hardware such as storage servers and networks. The common storage may be a single device, but more often comprises many different physical storage devices. Some examples of multi-user storage systems are: (1) corporate Intranet systems accessed by employee users, (2) telephone records accessible by telephone operator-users located around the state, nation, or world, (3) banking records accessed by remote customer-users operating automatic teller machines, and (4) engineering design specifications or models accessed by engineer-users working together on a technical project. A variety of other arrangements are also known.
- In these systems, security of common storage is one difficult challenge facing storage system engineers. Since the common storage is effectively coupled to all users (via intermediate server machines), it is often necessary to consider the user's identity in deciding whether to provide (or deny) access to stored data. Some data may be suitable for all users to access, whereas other data may be only suitable for access by selected users. As an example, it may be desirable to provide all employees of the company access to the company's telephone directory stored on a common storage facility, while making personnel files available only to those in the human resources department.
- Many known data security mechanisms address this problem by operating a central host or server as an access gate. This is feasible when the server alone is attached to the common storage, and therefore constitutes a natural gate. In this arrangement, all access requests are routed through this server, which accepts or rejects each request according to the identity of the requesting user and the content of the request. The server implements its security features by running a security software program. As one variation of this arrangement, there may be multiple servers coupled to the common storage, with each server running the same security program under the same operating system. These multiple servers can provide more users with concurrent access to the common storage. One example of a server comprises an IBM model S/390 product using the MVS operating system, where each server is coupled to a RAMAC storage subsystem.
- Although conventional server-based storage configurations have proven satisfactory in many cases, many organizations are moving toward “network attached storage,” which aims to save costs by placing storage systems directly on the network and thereby avoiding intermediate server machines. For especially convenient widespread and accessible use, storage systems are even coupled directly to the Internet in many cases. This avoids the need to purchase a dedicated server machine to serve as an intermediate security gate. This arrangement is especially beneficial for data that is being distributed, posted, or otherwise made available to users on a “read-only” basis because known mechanisms at the device or storage controller level may be invoked to universally prevent changes to the data.
- Although this arrangement is beneficial insofar as it saves costs and conveniently makes data widely available, there are still some limitations. Chiefly, conventional network attached storage is not adequate for those users seeking to make data widely accessible yet selectively permit some users to modify and delete data. To implement more advanced security schemes, network designers must add-in intermediate security gates such as storage severs. In addition to the added cost, compatibility problems can arise, especially with data that is being shared on such a widespread basis as the Internet. Namely, it may be difficult or prohibitively expensive to program the server with a security scheme that is compatible with a diverse array of expected machines, such as WINDOWS machines, UNIX machines, MVS computers, SUN workstations, etc.
- Consequently, known storage and security arrangements are not completely adequate due to these and other unsolved problems.
- Broadly, the invention provides access security for stored digital data by using a storage or device controller to regulate data security according to a security key and other parameters stored in metadata. This enables the storage controller or device to be attached directly to a network without compromising security or having to add an intermediate server to perform security functions.
- The storage system of this invention includes a storage controller coupled to a digital data storage. The controller is also coupled to, or at least accessible by, one or more hosts. The digital data storage contains host-accessible user data accessed by the storage controller on behalf of hosts, as well as host-inaccessible metadata used by the storage controller to manage the user data. Initially, the storage controller receives a write request from one of the hosts. Such a request includes a proposed key and target data to be written to storage. The storage controller stores the target data as host-accessible user data, and also stores the key as host-inaccessible metadata associated with the target data. Thereafter, the storage controller requires hosts to provide a key matching or having another prescribed relation to the stored key as a condition to granting future host requests to access the stored target data.
- In one embodiment, the invention may be implemented to provide a method of conditioning host access to stored data according to keys stored in host-inaccessible metadata. In another embodiment, the invention may be implemented to provide an apparatus, such as a data storage system, utilizing storage controllers configured to condition host access to stored data according to keys stored in host-inaccessible metadata. In still another embodiment, the invention may be implemented to provide a signal-bearing medium or tangibly embodying a program of machine-readable instructions executable by a machine such as a storage controller to manage storage as discussed herein. Similarly, the invention may also be embodied by logic circuitry configured to manage storage as discussed herein.
- The invention affords its users with certain distinct advantages. For instance, by using a storage controller rather than a server or host machine as a security gate, the invention provides storage security for a variety of different host computers that utilize comparatively incompatible operating systems. As another benefit, the invention is inexpensive because it may be implemented to provide data security using a network attached storage controller without using an expensive server machine. Similarly, the invention does not burden the processing and input/output resources of existing host machines with security functions, since security is implemented on the storage controller level. The invention is also beneficial because it provides a flexibility in implementation and may be applied in a variety of different environments. For instance, the invention may be applied to sound recordings to limit playback to users that have purchased an appropriate key. The invention also provides a number of other advantages and benefits, which should be apparent from the following description of the invention.
- FIG. 1A is a block diagram of the hardware components and interconnections of a data storage system according to the invention.
- FIGS.1B-1E are block diagrams showing different system configurations according to the invention.
- FIG. 1F is a block diagram showing several exemplary storage tracks and their constituent data objects and metadata according to the invention.
- FIG. 2 is a block diagram of a digital data processing machine according to with the invention.
- FIG. 3 shows an exemplary signal-bearing medium according to the invention.
- FIG. 4A is a flowchart showing operations performed to allocate data storage according to the invention.
- FIG. 4B is a flowchart showing operations performed to write data to storage according to the invention.
- FIG. 5 is a flowchart showing controller operations performed to process a Read request according to the invention.
- FIG. 6 is a flowchart showing operations performed by a new host to join the data storage system of the invention.
- The nature, objectives, and advantages of the invention will become more apparent to those skilled in the art after considering the following detailed description in connection with the accompanying drawings.
- Storage System
- One aspect of the invention concerns a data storage system, which may be embodied by various hardware components and interconnections as shown by the system100 of FIG. 1A. The system 100 includes multiple host machines 102-104, a
network 130, astorage controller 106, and digital data storage 108 (“storage”). The host machines 102-104 are coupled to thenetwork 130. Optionally, some or all of the hosts may be interconnected by various links (not shown). The hosts include respective host application programs 110-112. As used herein, “host” comprises any machine, user, application program, process, or other entity, that submits storage access requests to thestorage controller 106. Furthermore, storage access requests of the illustrated hosts may arise from other sources (not shown), such as wireless telephones, sensors, satellites, or other sources. - Hosts
- As illustrated, the host machines102-104 comprise various hardware devices suitable to generate storage access requests, such as personal computers, mainframe computers, computer workstations, supercomputers, or other suitable machines. The illustrated host machines 102-104 may be running respective application programs 110-112, from which the need for nonvolatile storage access arises. According to one advantage of the invention, the host machines 102-104 may be running a variety of different operating systems (not shown), which may even be incompatible with each other.
- Some exemplary operating systems include MVS, UNIX, WINDOWS NT, etc. Some or all of the host machines102-104 may be interconnected by communications links (not shown) such as wires, cables, fiber optic lines, wireless links, satellite, telephone lines, etc. Alternatively, some or all of the host machines 102-104 may be completely unrelated, such as different host machines coupled to the Internet (i.e., the network 130) at different sites around the world. The host machines 102-104 may include respective interfaces (not shown), such as ESCON links, small computer system interfaces (SCSIs), telephone/DSUcable modems, intelligent channels, and the like to interface with each other, the
network 130, etc. - As mentioned above, each host machine102-104 may be running one or more application programs, exemplified by the programs 110-112. Among other functions, the application programs 110-112 generate “storage access requests” seeking access to the
storage 108. In the presently illustrated example, each storage access requests includes one or more of the following components: - 1) A requested access type, such as Read, Write, Update, Allocate, Allocate and Write, etc.
- 2) If the requested access type is “Write”, one or more data objects to be written to
storage 108. - 3) A key (optional) to be used by the
controller 106 in determining access rights to the data objects involved in the subject access request. - 4) In the case of an allocation request, specification of a storage size to allocate or identification of a particular storage region to allocate.
- The contents, processing, and use of storage access requests are discussed in greater detail below.
- Network
- Optionally, the system100 may also include one or more networks, such as the
illustrative network 130. Thenetwork 130 is helpful to illustrate the embodiment (as shown in FIG. 1A) where thestorage controller 106 provides network-attached storage. - The
network 130 comprises any desired communication path(s) interconnecting host machines such as 102-104. One example is the public Internet or a corporate Intranet. Other examples include bus, star, or token ring configurations. Thenetwork 130 may utilize one or more local, metropolitan, and/or wide area networks. Thenetwork 130 may utilize TCP/IP, Systems Network Architecture, Ethernet, or any other desired protocol. Ordinarily skilled artisans (having the benefit of this disclosure) will also recognize other network configurations and protocols to implement thenetwork 130. - With the foregoing connection of the
network 130 to thestorage controller 106, thestorage controller 106 acts as network-attached storage, benefitting from the cost-savings of omitting a server or other intermediate gate. Nonetheless, a server, secondary host, or other machine may be interposed between thestorage controller 106 andhost machines 104 if desired. Furthermore, thenetwork 130 may be omitted from the system entirely, in which case thestorage controller 106 is coupled to a host machine 102-104 individually, coupled to a server or other intermediate machine that is itself coupled to the host machine, or coupled to a user interface for direct access by users. - Storage Controller—Introduction
- Broadly, the
storage controller 106 comprises a special purpose digital data 15=processing machine dedicated to managing storage of data upon thestorage 108. In contrast to servers and other machines, thestorage controller 106 works with formatting, layout, encoding, parity checking, error correction, and other aspects of physically storing data on the media encompassed by thestorage 108. Accordingly, thestorage controller 106 generates, reads, formats, and utilizes host-invisible metadata that is stored with host-accessible “user data” in thestorage 108. In contrast, the host machines 102-104 and application programs 110-112 deal with the user data itself, but cannot access the metadata. The hosts may reference user data according to logical addresses, in which case thestorage controller 106 translates between logical addresses (as used by the hosts) and physical addresses (relating to the storage media itself). - The
storage controller 106 may be implemented in a number of different ways. For instance, thestorage controller 106 may be implemented by a device controller. Some examples include a hard drive controller, optical disk controller, CD-ROM controller, tape drive, floppy diskette drive, or other mechanism that is associated with a particular removable or nonremovable media type. In another embodiment, thestorage controller 106 may comprise one or more supervisory processing machines managing a number of subservient device controllers. Some examples include theIBM xSeries 150 Network Attached Storage, IBM Enterprise Storage Server Models F10 and F20, IBM RAMAC product line, etc. FIGS. 1B-1D illustrate several exemplary configurations of storage controllers and devices, as discussed below. - The
storage controller 106 includes aninterface 120 to communicate with the network 130 (as illustrated), server, host, etc. Theinterface 120 may comprise an intelligent digital input/output communication channel, modem, interface card, bus, backplane, port, connector, or any other interface suitable to the particular application. - Digital Data Storage
- As explained above, the
storage 108 serves to store data as directed by thestorage controller 106. Thestorage 108 may include storage media along with one or more device controllers that are managed by thestorage controller 106, as in the examples of FIGS. 1B-1C. In a different example, thestorage 108 may include the media only, where the media's device driver embodies thestorage controller 106, as in the example of FIG. 1D. - In any case, the
storage 108 may be implemented by media of various types, such as magnetic disk drive, magnetic tape, optical disk, optical tape, semiconductor memory, a combination of the foregoing, or any other suitable digital data storage media. Thestorage 108 may be configured as a single “logical” device, where data is actually stored on separate physical devices. As a specific example, thestorage 108 may be implemented by the magnetic disk drive media units of an IBM RAMAC disk drive system. - Non-network Implementation
- As still another example of the implementation of this invention, any of the embodiments of FIGS.1B-1D may be implemented as a local storage/retrieval apparatus by substituting a user interface for the component as “network.” In this embodiment, as described in greater detail below, the storage or device controller grants different access rights to people operating the user interface depending upon the security key that they supply.
- FIG. 1E describes a particular example of this embodiment, including a
playback device 174 that comprises a music CD player that selectively plays songs stored onremovable CD media 176 according to a security key entered by auser 178 via auser interface 170. Security functions are implemented bydevice controller 172. Here, theCD media 176 is write-only, and the approved security keys for each song are stored on the media at the time of manufacture. - The
user interface 170 may comprise a keypad for entering security keys. To enhance security, instead of using a keypad, theuser interface 170 may comprise a module to receive tangible security keys such as 171, which comprise plug-in chips/cassettes that are plugged-in to theinterface 170, magnetic cards that are swiped or waved past theinterface 170, etc., where thetangible security key 171 contains a machine-readable representation of a security key. In this embodiment, users purchase a music CD for one low price, and then purchase the tangible security key containing the security key associated with to the songs they wish to hear. Although CDs are given in the foregoing example, other media may be used without departing from the invention. - Storage Controller
- Gate Function
- In addition to its function in managing the
storage 108, thecontroller 106 operates as a gate, selectively accepting or refusing hosts' access requests according to a preestablished data security scheme. Since this scheme is implemented by thecontroller 106 rather than one or more hosts 102-104, the hosts are available for other tasks. Additionally, the storage controller's centrality and independence from the hosts 102-104 is conducive to access by hosts of many different operating systems. Furthermore, the controller's security features enable thestorage controller 106 to be used as network-attached storage, providing security without the need for a server or other intermediate security gate. - Storage Controller—Gate Function, First Example
- The
controller 106 includes acontroller security module 122, which performs the controller's security functions. Thesecurity module 122 may comprise a hardware component, such as one or more computers, microprocessors, logic circuits, ASICs, or other digital data processing apparatus. Alternatively, thesecurity module 122 may be an application program comprising a sequence of programming instructions executed by one or more processors of thecontroller 106. - Generally, as a condition to granting storage access to hosts, the controller's gating function requires it to consult a “reference location” containing a security key associated with the data being sought. The stored security key may be called the “reference security key.” The
controller 106 evaluates the reference security key against a proposed security key from the storage access request to determine whether the request should be permitted. The contents and use of security keys are discussed in greater detail below. - The reference location constitutes storage space accessible to the
controller 106, and in one example comprises data (including the reference security key) stored at thecontroller 106 as illustrated by thestorage use map 124. Themap 124 may be located elsewhere if desired such as in thestorage 108 or other site accessible to thecontroller 108. TABLE 1 (below) depicts an example of thestorage use map 124, in the form of a lookup table.TABLE 1 EXEMPLARY STORAGE USE MAP REFERENCE SECURITY STORAGE REGION KEY SECURITY TYPE 00001 1 WRITE 00002 1 WRITE 00003 1 WRITE 00004 NONE NO SECURITY 00005 NONE NO SECURITY 00006 2 READ/WRITE 00007 2 READ/WRITE 00008 NONE NO SECURITY - In the example of TABLE 1, the “storage region” column identifies regions in the
storage 108. The “reference security key” lists an access key that governs access to the associated storage region. Thestorage controller 106 may utilize the reference security key to govern access to the storage region according to various techniques, such as password, public/private key encryption, or others as explained in detail below. In this simplified example, reference keys of “1” and “2” are provided for ease of explanation, however more complicated codes may be used. For each storage region, the associated “security type” (also called “access level”) designates the security precautions applicable to the corresponding storage region. For example, the security type may specify operations that are prohibited without the requesting host submitting an input key (also called “proposed security key”) that satisfies the prescribed reference security key. The security type may require the storage controller to prevent, without host provision of a proposed security key that satisfies the reference security key, one or more of the following operations: read, write, delete, update, format, etc. - As a variation, TABLE 1 may be condensed by listing abbreviated pointers to other storage locations that contain the actual values of storage region, reference security key, and/or security type. Furthermore, TABLE 1 may be encrypted by
controller 106 to prevent accidental/malicious access of its contents. - As still another variation, TABLE1 may omit anything to do with read security, wherein the
storage controller 106 stores user data encrypted with an associated security key, and read security is thereby inherently provided by thestorage controller 106 decrypting user data with whatever proposed key is supplied by the host. In this example, encryption may use the public/private key architecture, where each user can only encrypt all public data and private data associated with the user's private key. - Storage Controller—Gate Function, Second Example
- As an alternative to the
storage use map 124, thestorage controller 106 may carry out its gate function by incorporating the reference security key into metadata associated with user data in thestorage 108. In this embodiment, thestorage use map 124 may be omitted. - FIG. 1F describes an example of a subsection of
storage 108 implementing this feature. For ease of discussion FIG. 1F illustrates the contents of several exemplary tracks 150-153 of data that reside upon a magnetic disk storage medium in thestorage 108. Although it is understood that disk tracks are actually circular, the tracks 150-153 are shown in linear form for ease of explanation. Each track 150-153 includes a respective region of user data 160-163 and an associated region of metadata 155-158. The metadata regions 155-158 may precede the user data regions 160-163 (as shown), follow the user data, be interspersed with the user data, or another arrangement as suits the application. - The
storage controller 106 initially stores the user data on behalf of hosts that provide the data; thestorage controller 106 may also carry out host requests to modify, read, delete, or otherwise manage such user data. Thus, the user data 160-163 is said to be host-accessible. In contrast, the metadata 155-158 is used solely by the storage/device controllers to manage storage and retrieval of the user data. In this sense, the metadata 155-158 is host-inaccessible. - The
block 140 shows the contents ofmetadata 155 in greater detail, according to one example. Themetadata block 140 includes information such as thetrack address 142, number ofbytes 142 of user data in that track, errorcorrection control information 144,parity information 145, areference security key 146, andsecurity type 147. Different or other 141, 148 items of metadata may also be used, depending upon the application. Thereference security key 146 andsecurity type 147 have function and content as described above in conjunction with TABLE 1. - Without any intended limitation, the foregoing example shows items of metadata155-158 that number one per track 150-153. In this example, each item of metadata (and its reference key and security type) pertains to one track, which constitutes the storage region associated with that metadata. Thus, in this example, the
reference security key 146 governs host access to thetrack 150. As a further enhancement, a reference security key may be associated with a multi-track data object by listing that reference security key in the metadata of each track occupied by the data object. The present invention also contemplates a variety of other approaches, where thereference security key 146 andsecurity type 147 are stored in metadata associated with a data object, extent, byte, range of tracks or address, sector, block, record, file, page, record, logical cylinder, logical device, physical device, or another suitable arrangement depending upon the application. Furthermore, multiple security keys may be provided with each item of user data, with one, some, or all of the security keys having a different security type associated therewith. - In the case of removable storage media (such as CD-ROM or floppy diskettes), it may be advantageous to structure the metadata and/or user data to be unreadable by conventional device controllers. This prevents reading of the media by a conventional device controller that is not programmed to honor the security-features of the metadata155-158.
- Storage Controller—Gate Function, Second Example (CD-ROM)
- FIG. 1F is now re-described in the context FIG. 1E, described above. Here, the
storage 108 comprises a CD or other sound recording 176 and thestorage controller 106 comprises aplayback device 174. In this example, reference one or more s are incorporated into metadata associated with recorded songs, tracks, or other segments at the time of manufacture, and thestorage use map 124 is omitted. In this example, rather than describing tracks of a magnetic storage disk, the items 150-153 refer to music “tracks” on the sound recording media, where each track corresponds (for example) to a different song. Each track 150-153 includes a respective region of sound recording data (referred to as a “song without any intended limitation”) 160-163 and an associated region of metadata 155-158. The metadata regions 155-158 may precede the songs 160-163 (as shown), follow the songs, be interspersed with the songs, or another arrangement as suits the application. - All contents of the sound recording are permanently written at the time of manufacture. Therefore, neither the metadata155-158 nor the songs 160-163 are rewritable. The songs 160-163 are said to be user-accessible, since they are audibly played back to the
user 178. In contrast, the metadata 155-158 are used solely by thecontroller 172 to manage retrieval of the songs, and is therefore considered user-inaccessible. The metadata 155-158 is structured to prevent reading by conventional CD players. - The
block 140 shows the contents ofmetadata 155 in greater detail, according to one example. Themetadata block 140 includes information such as theaddress 142 of the associatedsong 160 on themedia 176, number ofbytes 142 that thesong 160 occupies in that track, errorcorrection control information 144,parity information 145, areference security key 146, andsecurity type 147. Different or other 141, 148 items of metadata may also be used, depending upon the application. Thereference security key 146 andsecurity type 147 have function and content similar to that described above, however only the security type “Playback Requires Security Key” is utilized. Thus, if a user cannot provide the requisite security key, thedevice controller 172 will not play the subject song. Optionally, additional reference keys and associated security types (not shown) may be provided with each track. In this way, the CD manufacturer or record label may offer an inexpensive license enabling users to listen to a limited number of songs (such as songs one, two, and three), and a more expensive license enabling users to listen to all songs on themedia 176. Furthermore, if desired, a sufficient number of security keys and security types may be stored to anticipate access to every possible combination of some or all of the songs on the CD, so that users could purchase a license limited to songs desired by that user. In this embodiment, rather than pressing dozens of media with different combinations of songs thereon (as in the current state of the art), every song of an artist may be put on a single media, with user access limited by security key to the songs associated with that security key. - Exemplary Digital Data Processing Apparatus
- The storage controller106 (or device controller 172) may be embodied by various hardware components and interconnections. One example is given by the digital
data processing apparatus 200 in FIG. 2. Theapparatus 200 includes aprocessor 202, such as a microprocessor or other processing machine, coupled to astorage 204. In the present example, thestorage 204 includes a fast-access storage 206, as well asnonvolatile storage 208. The fast-access storage 206 may comprise random access memory, and may be used to store the programming instructions executed by theprocessor 202. Thenonvolatile storage 208 may comprise, for example, one or more magnetic data storage disks such as a “hard drive”, a tape drive, or any other suitable storage device. Theapparatus 200 also includes an input/output 210, such as a line, bus, cable, electromagnetic link, or other means for exchanging data with theprocessor 202. - Despite the specific foregoing description, ordinarily skilled artisans (having the benefit of this disclosure) will recognize that the apparatus discussed above may be implemented in a machine of different construction, without departing from the scope of the invention. As a specific example, one of the
components storage 204 may be provided on-board theprocessor 202, or even provided externally to theapparatus 200. - In addition to the various hardware embodiments described above, a different aspect of the invention concerns a method of providing access security for digital data by using a storage or device controller to regulate data security according to a security key and other parameters stored in the data's metadata. This enables the storage controller or device controller to be attached directly to a network without compromising security or having to add an intermediate server to perform security functions.
- Signal-bearing Media
- In the context of FIGS.1A-2, such a method may be implemented, for example, by operating the storage controller 106 (or device controller 172), as implemented by a digital
data processing apparatus 200, to execute a sequence of machine-readable instructions. These instructions may reside in various types of signal-bearing media. This signal-bearing media may comprise, for example, RAM (not shown) contained within thecontroller 106, as represented by the fast-access storage 206. Alternatively, the instructions may be contained in another signal-bearing media, such as a magnetic data storage diskette 300 (FIG. 3), directly or indirectly accessible by theprocessor 202. Whether contained in thestorage 204, thediskette 300, or elsewhere, the instructions may be stored on a variety of machine-readable data storage media, such as DASD storage (e.g., a conventional “hard drive” or a RAID array), magnetic tape, electronic read-only memory (e.g., ROM, EPROM, or EEPROM), an optical storage device (e.g. CD-ROM, WORM, DVD, digital optical tape), paper “punch” cards, or other suitable signal-bearing media including transmission media such as digital and analog and communication links and wireless. In an illustrative embodiment of the invention, the machine-readable instructions may comprise software object code, compiled from a language such as “C”, etc. - Allocating Storage
- FIG. 4A shows a
sequence 400 performed to allocate space in thestorage 108 according to the invention. For purposes of illustration, without any limitation, allocation as discussed herein is a host-managed operation. Allocation may be driven by thestorage controller 106 in other examples. For ease of explanation, but without any limitation intended, the example of FIG. 4A is described in the context of the environment described above in FIGS. 1A-1D, 1F, 2, 3. - The sequence is initiated in
step 402, when one of the application programs 110-112 experiences conditions requiring allocation of storage. Thecondition causing step 402 may further dictate relevant aspects of the necessary allocation operation, such as (1) the type of storage device to be used in the allocation operation if thestorage 108 contains different types of storage media, (2) the size of region to allocate, and (3) other pertinent aspects. Allocated storage regions may be expressed in terms of any convenient or appropriate unit of granularity, such as one or more disk sectors, disk tracks, disk “extents”, logical volumes, address ranges, blocks, tape tracks, files, datasets, etc. Storage regions may also have user-specified sizes, in which event this additional characteristic may be included in the allocation request. If desired, one or more storage regions may comprise subsets of a larger data structure, such as a database, file, storage group, dataset, etc; advantageously, this embodiment may facilitate different levels of security for subsets of a larger data structure. - In
step 406, the application program 110-112 chooses a desired level of security for the region to be allocated. In this example, the levels of security, also called “security types” or “access levels” include: - 1) “read/write protect” where both Reads and Writes are prohibited. Here, the
storage controller 106 prevents reading and writing to the associated storage region unless the host presents an appropriate key. - 2) “write protect” where Writes are prohibited but Reads permitted. Here, as discussed in greater detail below, the
controller 106 will prevent hosts from writing the storage region unless the host presents an appropriate key. The associated storage region may be freely read. - 3) “none” or “no security,” where any host can read and write to this storage region without presenting a key. As an example, “none” may be used as a default value if another security type is not chosen.
- In addition to the foregoing security types, additional parameters may be included, such as a per-access specification that applies the specified security type only for certain accesses, such as “all” accesses by a host, or only the “first” access by the host. After
step 406, the application program 110-112 generates a reference security key (if some type of security was selected in step 406) to be used by thecontroller 106 in regulating future host access to the allocated storage region. The “reference” security key provides a reference copy against which hosts' proposed keys are to be evaluated. The reference security key ofstep 408 may comprise an alphabetic, numeric, alphanumeric, or other machine-readable code. As an example, the reference security key may comprise a 256-bit digital number, selected in accordance with a public key encryption scheme, as discussed below. Optionally, the application programs 110-112 may be configured such that, if the host seeks to extend an already-allocated storage region, thestorage step 408 utilizes the region's existing reference security key instead of generating a new one. - After
step 408, the application program 110-112 issues a requestto allocate storage or extend allocation of already-allocated storage (step 412). This request includes the reference security key and security type ofsteps storage controller 106. If the allocation command is issued to the host machine or another application program,step 414 is performed, where the recipient relays the allocation request to thecontroller 106, for example, by issuing an allocate command with a set-reference-key parameter, specifically directing thecontroller 106 to associate the provided reference key and security type with the storage region to be allocated. On the other hand, if the allocation request is given directly to thestorage controller 106,step 414 may be omitted. As an alternative to the foregoing, therecipient storage controller 106 may provide the security key on behalf of the host, in whichcase step 408 is omitted. - Following
step 414, (or step 412 ifstep 414 is omitted) thecontroller 106 stores the security type and reference security key in a prescribed reference location, in association with the allocated storage region (step 416). As mentioned above, one example of the reference location is thestorage use map 124; in this embodiment, thecontroller 106 instep 416 stores the key and security type in themap 124. In another example, the reference location may comprise host-inaccessible metadata in the allocated storage region itself, as explained above in conjunction with FIG. 1F; in this example,step 416 involves storing these items in metadata such as 155-158, the associated user data being empty. - After
step 416, the requested allocation is complete, and thesequence 400 ends instep 418. In the allocated storage region is now available for selective access by the hosts, depending upon the established security type and the hosts' ability to provide an acceptable key. - Writing Data to Storage
- FIG. 4B shows a sequence450 performed to write data to the
storage 108 according to the invention. For ease of explanation, but without any limitation intended, the example of FIG. 4B is described in the context of the environment described above in FIGS. 1A-1D, 1F, 2, 3. The sequence 450 is initiated instep 462, when an occasion arises for one of the application programs 110-112 to write data to thestorage 108. - In
step 464, the application program 110-112 chooses a desired security type for the data to be written. The security types in this example include read/write protect, write protect, and none as explained above. Afterstep 464, the application program 110-112 generates a reference security key (step 466);step 466 may be omitted if “none” was selected as the security type instep 464. The reference security key ofstep 466 comprises an alphabetic, numeric, alphanumeric, or other machine-readable code as discussed above. - Optionally, the application programs110-112 may be configured such that, if the present Write operation seeks to append, update, or otherwise modify previously written data,
step 466 comprises the application program attempting to supply the believed reference security key for the previously written data. - After
step 466, the application program 110-112 issues a write request (step 468). The write request constitutes a command to write data to thestorage 108, and may specify relevant aspects of the operation, such as the type of storage device to be used in the Write operation if thestorage 108 contains different storage modes, and other pertinent aspects. More particularly,step 468 involves the application program 110-112 issuing a Write request along with the user data to be written, a proposed key (if attempting to modify existing data), and a new reference key and security type (if writing new data). The request ofstep 468 may be issued to a host operating system, another application program on the same host that manages storage requests, or directly to thestorage controller 106. - If the Write request is issued to the host machine or another application program,
step 470 is performed, where the recipient relays the Write request to thecontroller 106. In the case of a new Write, the recipient may provide its directions to thecontroller 106 by issuing a Write command with a set-reference-key parameter, specifically directing thecontroller 106 to associate the provided reference key and security type with the user data proposed for storage. For data that already exists on thestorage 108, the Write request recipient may provide its directions to thecontroller 106 in the form of a Write command with a proposed-key-parameter. - Following
step 470, thecontroller 106 determines whether the user data proposed for storage is new or existing in the storage 108 (step 472). This is performed by cross-referencing information from the Write request (from step 470) with information that thecontroller 106 maintains about data in thestorage 108. If the proposed data object is new, thecontroller 106 stores the data, and also stores the security type and reference security key in a prescribed reference location, in association with the allocated storage region (step 482). As mentioned above, one example of the reference location is thestorage use map 124; in this embodiment, thecontroller 106 instep 482 stores the reference security key and security type in themap 124. In another example, the reference location may comprise host-inaccessible metadata in the user data itself, as explained above in conjunction with FIG. 1F; in this example,step 482 involves storing these items in the metadata associated with the identified user data. For example, they may be stored preceding the user data, in a metadata header, as shown in FIG. 1F. Other locations may be used instead, such as metadata interspersed throughout the data object, a metadata suffix, or another location. In the case of a write operation, step 482 also involves thestorage controller 106 writing the user data tostorage 108. - As one enhancement to the embodiment described above, the
controller 106 may direct thestorage 108 to employ the reference security key to encode the user data during the Write operation ofstep 482. Namely, thecontroller 106 may use the reference security key to encode the user data supplied by the host and then store the data as encoded. Encoding and decoding in this embodiment may use a number of different techniques that are well known to those in the relevant art. For instance, one useful technique is public/private key encryption. By using such encoding/decoding, stored data enjoys two levels of protection: (1) one level, by thecontroller 106 requiring requesting hosts to submit a proper proposed key to access the user data, and (2) another level, by encoding the user data itself with the security key. - On the other hand, if the proposed user data to be written already exists in storage, step472 advances to step 474, where the
controller 106 consults the reference security key and security type fields 146-147 associated with the user data to determine the security type and reference security key. Thecontroller 106 instep 476 then determines whether the proposed Write operation is allowed. Namely, the Write operation is not allowed if the security type of the existing user data is “read/write protect” or “write protect” and the proposed key is not appropriate to the reference security key. For instance, the proposed/reference keys may be required to match, or there be a match between derivatives of one or both. If the Write operation is not allowed, step 476 advances to step 480, where thecontroller 106 rejects the requested Write operation. For instance, thecontroller 106 may return an error message to the requesting host. On the other hand, if the requested Write is permitted, step 476 advances to step 480, where thecontroller 106 performs the Write operation upon thestorage 108. Optionally, thecontroller 106 may direct thestorage 108 to employ the reference security key in encoding data during the Write operation ofstep 480. — - The sequence450 ends after completion of
steps - Reading Data from Storage—General
- FIG. 5 shows a
sequence 500 of reading data fromstorage 108. For ease of explanation, but without any limitation intended thereby, the example of FIG. 5 is described in the context of the environment described above in FIGS. 1A-1D, 1F, 2, 3. - The
sequence 500 begins instep 502 when an occasion arises for one of the application programs 110-112 to read data from thestorage 108. This may originate from a source such as an internal process of the application program, another application program of the requesting host, a user terminal or other input device (not shown) coupled to the host, another computer coupled to the host, etc. Instep 503, responsive to the event ofstep 502, the application program generates a Read request including (1) identification of desired user data (“target user data”), such as by name, logical or physical storage location, storage device, etc., and (2) a proposed key for use by thecontroller 106 to determine whether the application program should have access to the requested user data. If the Read request ofstep 503 seeks access to user data whose security type is “none,” the proposed key may be omitted fromstep 503. The Read request ofstep 503 may be issued to the host machine, another application program, or directly to thecontroller 106. - In
step 504, thecontroller 106 receives the Read request ofstep 503. In response, thecontroller 106 determines whether the target user data is protected, i.e., whether a reference location has associated a reference security key with the target user data (step 506). This is performed by thecontroller 106 consulting the storage use map 124 (one example) or the metadata (other example). If the target user data does not have an associated reference security key, this storage region has no security protection and further analysis is unnecessary. In this case, the routine 500 passes fromstep 506 to step 516, where thecontroller 106 operates thestorage 108 to read and output the requested user data. Followingstep 516, thesequence 500 ends instep 518. - If the target user data is protected, however, step506 advances to step 508. In
step 508 thecontroller 106 determines user data's security type. Namely, thecontroller 106 consults the reference location to retrieve the security type associated with the target user data, and thereby determine whether Read operations are permitted without submittal of a suitable proposed access key. In one example, step 508 may be performed by thecontroller 106 consulting thesecurity type 147 in metadata to see whether Read operations are protected. Alternatively, step 508 may be performed by thecontroller 106 consulting thestorage use map 124 to determine whether Read operations are protected. If Read operations are not protected, step 508 advances to step 516, where thecontroller 106 directs thestorage 108 to read and output the requested data object (step 516), and then thesequence 500 ends instep 518. Optionally, the reference security key may be used to decrypt the user data if the user data has been encrypted. - If
step 508 finds that Reads of the requested user data are protected, the routine 500 advances fromstep 508 to step 510. Instep 510, thecontroller 106 checks the host-submitted proposed key (received in step 504) against the reference security key (found in the reference location, e.g., key 146 or storage use map 124). In one example,step 510 involves comparing the proposed and reference security keys to see whether they match. Alternatively, step 510 may apply a predetermined processing sequence to derive a second key from the proposed key (such as by decryption using a different, prescribed private key), with this derived key being compared against the reference key. Alternative, the reference security key may be processed to derive a second key, with this derived key being compared to the proposed key. Other alternatives are also contemplated, such as processing both reference and proposed keys and comparing their derivatives. - At any rate, if the proposed key (or its derivative) does not match the reference security key, the proposed key is not valid. In this case, step512 advances to step 514 where the
controller 106 returns an error condition to the requesting host. Otherwise, ifstep 512 finds that the proposed key (or its derivative) matches the reference access key (or its derivative), the proposed access key is valid, and thecontroller 106 directs thestorage 108 to complete the requested Read operation instep 516. Aftersteps sequence 500 ends instep 518. - As one enhancement to the embodiment described above, the
controller 106 may direct thestorage 108 to employ the reference security key in decoding data during the Read operation ofstep 516. In this embodiment, thecontroller 106 uses the reference security key to decode the stored user data, and then provides the decoded data to the requesting host. Such decoding may utilize a number of different techniques that are well known to those in the relevant art, such as public/private key encryption. - After
step 516, the routine 500 ends instep 518. - Reading Data from Storage—Local User Interface, Read-only Media
- Another description of FIG. 5 is now made to specifically illustrate the playback of data from
CD media 176 in the environment of FIG. 1E. In this example, theCD media 176 comprises a read-only music CD that is provided with one or morereference security keys 146 and operation parameters 147 (as described in FIG. 1F) at the time of manufacture. In this embodiment, thestorage use map 124 is omitted, since themedia 176 contains security information in its metadata. As described above, themedia 176 may contain severaldifferent reference keys 146 in association with each song. - Referring to FIG. 5 in conjunction with FIG. 1E, the
sequence 500 begins instep 502 when auser 178 decides to listen to one or more songs on theCD 176. Theuser 178 submits a proposed security key by entering the key into theuser interface 170, or by providing atangible security key 171 to theinterface 170. Instep 503, responsive to the event ofstep 502, theuser interface 170 generates a Play request including (1) identification of one or more desired songs, such as by name, logical or physical storage location, storage device, etc., and (2) the user's proposed key. Also instep 503, theinterface 170 forwards the Play request to thedevice controller 172 to determine whether the user should have access to the requested user data. If the Play request ofstep 503 seeks access to user data whose security type is not “Playback Requires Security Key,” the proposed key may be omitted fromstep 503. - In
step 504, thecontroller 172 receives the Play request ofstep 503. In response, thecontroller 172 determines whether the target song tracks is protected, i.e., whether each requested song track has an associated reference key (step 506). This is performed by thecontroller 172 consulting the song track's metadata. If the target song track does not have any associated reference keys, this area has no security protection and further analysis is unnecessary. In this case, the routine 500 passes fromstep 506 to step 516, where thecontroller 172 provides an audible output of the requested song track from themedia 176. Followingstep 516, thesequence 500 ends instep 518. - If the target song track is protected, however, step506 advances to step 508. In
step 508 thecontroller 172 determines song track's security type. Namely, thecontroller 172 consultssecurity type 147 in metadata stored on themedia 176 to determine whether Play operations are permitted without submittal of a suitable proposed access key. If Play operations are not protected, step 508 advances to step 516, where thecontroller 172 interacts with themedia 176 to read and output (Play) the requested song track (step 516), and then thesequence 500 ends instep 518. Optionally, the proposed key may be used to decrypt the requested song if the song has been stored on themedia 176 with encryption. - If
step 508 finds that Playback of the requested song track is protected, the routine 500 advances fromstep 508 to step 510. Instep 510, thecontroller 172 checks the user-submitted proposed key (received in step 504) against the reference security key (found in the requested song's metadata). In one example,step 510 involves comparing the proposed and reference security keys to see whether they match. Alternatively, step 510 may apply a predetermined processing sequence to derive a second key from the proposed key (such as by decryption using a prescribed private key), with this derived key being compared against the reference security key. Alternative, the reference security key may be processed to derive a second key, with the derived key being compared to the proposed key. Other alternatives are also contemplated, such as processing both reference and proposed keys and comparing their derivatives. - At any rate, if the proposed key (or its derivative) does not match the reference security key,
step 512 concludes that the proposed key is not valid. In this case, thecontroller 172 returns an error condition to the requesting host instep 514. Otherwise, if the proposed key (or its derivative) matches the reference access key (or its derivative),step 512 concludes that the proposed access key is valid, and thecontroller 172 directs thestorage 108 to complete the requested Play operation instep 516. Aftersteps sequence 500 ends instep 518. - Activate New Host
- FIG. 6 shows a
sequence 600 performed by a new host in order to join the system 100, and participate in future allocation and/or data access requests. For ease of explanation, but without any limitation intended thereby, the example of FIG. 6 is described in the context of the environment described above in FIGS. 1A-3. Generally, to add a new host, the new host obtains reference security keys for the user data to be accessed in the future. In addition, the new host must configure its own interface (not shown) with thecontroller 106 to properly communicate the contents of a storage access request. - More particularly, after the
sequence 600 begins instep 602, the new host obtains one or more existing reference security keys from a source such as other hosts 102-104, thecontroller 106, application programs 110-112, user input, system administrator, etc. This step is optional, however, since there may be no need or intention for the new host to access user data that is already protected. A host-host exchange of reference security keys may be conducted over thenetwork 130 or over the links (not shown), for example. - After
step 604, the new host's application program reconfigures its interface with the controller instep 606. The new host's interface (not shown) may comprise an ESCON interface, small computer standard interface (SCSI), parallel or serial port, telephone modem, or any other digital data communications medium compatible with the particular embodiment of controller used in the system 100. In one example, the host interface may already be configured to receive storage access requests, e.g., components such as identification of targeted user data, security types, etc.; in this case,step 606 involves reconfiguring the host interface to accept submittal of proposed keys in the future. In the case of an ESCON interface, this may involve adding a new channel command word, or modifying an existing channel command word to accept an proposed access key. In the case of a SCSI interface, the SCSI protocol is modified instep 606 to accept the input access parameter. - Advantageously, the addition of new hosts does not require any security modification since the reference security keys are stored at the
controller 106 orstorage 108. - Bypass
- Optionally, an internal setting may be provided within the
controller 106 to bypass key checking in certain predefined environments or events. For example, bypass may be desirable during disaster recovery, backup, data migration, and other operations. - Reset Access Key & Operation Parameter
- As an additional enhancementto the foregoing embodiment, the
controller 106 may additionally recognize a “reset-key” command issued by hosts 102-104. The reset-key command directs thecontroller 106 to alter the access characteristics of an allocated storage region or stored data object. An illustrative reset-key includes a proposed key, along with a replacement reference security key and/or security type for the allocated storage region or user data. In response, thecontroller 106 validates the proposed key, and then proceeds to update its reference location (e.g.,storage use map 124 or metadata). Otherwise, if the proposed key is invalid, thecontroller 106 fails the reset request. Along these lines, the invention also contemplates a “clear-key” command issued by hosts 102-104 to remove security protection of an allocated storage region or stored data object. - While the foregoing disclosure shows a number of illustrative embodiments of the invention, it will be apparent to those skilled in the art that various changes and modifications can be made herein without departing from the scope of the invention as defined by the appended claims. Furthermore, although elements of the invention may be described or claimed in the singular, the plural is contemplated unless limitation to the singular is explicitly stated. Additionally, ordinarily skilled artisans will recognize that operational sequences must be set forth in some specific order for the purpose of explanation and claiming, but the present invention contemplates various changes beyond such specific order.
Claims (41)
1. A data storage method for use in a storage system including a storage controller serving one or more hosts where the storage controller is coupled to a digital data storage, the storage containing host-accessible user data accessed by the storage controller on behalf of hosts and host-inaccessible metadata used by the storage controller to manage storage of the host-accessible data, the method comprising operations of:
the storage controller receiving a write request from one of the hosts, the request including target data and a security key;
the storage controller storing the target data in the digital data storage and storing the security key in metadata in association with the target data;
requiring host provision of a security key with prescribed relationship to the stored security key as a condition to granting future host requests to access the target data in the digital data storage.
2. The method of , the requiring operation comprising:
claim 1
requiring host provision of a security key matching the stored security key as condition to granting future host requests to access the target data in the digital data storage.
3. The method of , the requiring operation comprising:
claim 1
as a condition to granting future host requests to access the target data in the digital data storage, requiring host provision of a security key that matches the stored security key when processed by a predetermined encryption process.
4. The method of , the operation of the storage controller storing the target data comprising operations of:
claim 1
encrypting the target data with the security key and storing the encrypted target data.
5. The method of , where the digital data storage comprises a storage device including a device controller, and the storage controller is embodied by the device controller.
claim 1
6. A data storage method for use in a storage system including a storage controller coupled to a digital data storage where the storage controller serves one or more hosts, the storage containing host-accessible user data accessed by the storage controller on behalf of hosts and host-inaccessible metadata used by the storage controller to manage storage of the host-accessible data, the method comprising operations of:
the storage controller receiving an allocation request from one of the hosts;
the storage controller allocating a region of the digital data storage and storing a security key in metadata associated with the allocated region;
requiring host provision of a security key with prescribed relation to the stored security key as a condition to granting future host requests to access data in the allocated region of the digital data storage.
7. The method of , the requiring operation comprising:
claim 6
requiring host provision of a security key matching the stored security key as a condition to granting future host requests to access the target data in the digital data storage.
8. The method of , the requiring operation comprising:
claim 6
as a condition to granting future host requests to access the target data in the digital data storage, requiring host provision of a security key that matches the stored security key when processed by a predetermined encryption process.
9. The method of , where the digital data storage comprises a storage device including a device controller, and the storage controller is embodied by the device controller.
claim 6
10. A data security method for use in a storage system including a storage controller responsive to one or more hosts where the storage controller is coupled to a digital data storage, the storage containing host-accessible user data accessed by the storage controller on behalf of hosts and host-inaccessible metadata used by the storage controller to manage storage of the host-accessible data, the method comprising operations of:
the storage controller receiving a storage access request from one of the hosts, the request including a proposed security key and an identification of a requested data object contained on the digital data storage;
the storage controller retrieving a security key stored in metadata of the requested data object in the digital data storage, and then determining whether the stored security key and the proposed security key exhibit a prescribed relationship; and
only if the proposed and stored security keys exhibit the prescribed relationship, the storage controller executing the storage access request, otherwise aborting the storage access request.
11. The method of , the method being implemented such that the storage controller comprises a sound recording player and the host is a user.
claim 10
12. A signal-bearing medium tangibly embodying a program of machine-readable instructions executable by a digital processing apparatus to perform data storage operations in a storage system including a storage controller coupled to a digital data storage and serving data requests of one or more hosts, the storage containing host-accessible user data accessed by the storage controller on behalf of hosts and host-inaccessible metadata used by the storage controller to manage storage of the host-accessible data, the operations comprising:
the storage controller receiving a write request from one of the hosts, the request including target data and a security key;
the storage controller storing the target data in the digital data storage and storing the security key in metadata in association with the target data;
requiring host provision of a security key with prescribed relation to the stored security key as a condition to granting future host requests to access the target data in the digital data storage.
13. The medium of , the requiring operation comprising:
claim 12
requiring host provision of a security key matching the stored security key as a condition to granting future host requests to access the target data in the digital data storage.
14. The medium of , the requiring operation comprising:
claim 12
as a condition to granting future host requests to access the target data in the digital data storage, requiring host provision of a security key that matches the stored security key when processed by a predetermined encryption process.
15. The medium of , the operation of the storage controller storing the target data comprising operations of:
claim 12
encrypting the target data with the security key and storing the encrypted target data.
16. The medium of , where the digital data storage comprises a storage device including a device controller, and the storage controller is embodied by the device controller.
claim 12
17. A signal-bearing medium tangibly embodying a program of machine-readable instructions executable by a digital processing apparatus to perform data storage operations in a storage system including a storage controller coupled to a digital data storage and serving data requests of one or more hosts, the storage containing host-accessible user data accessed by the storage controller on behalf of hosts and host-inaccessible metadata used by the storage controller to manage storage of the host-accessible data, the operations comprising:
the storage controller receiving an allocation request from one of the hosts;
the storage controller allocating a region of the digital data storage and storing a security key in metadata associated with the allocated region;
requiring host provision of a security key with prescribed relation to the stored security key as a condition to granting future host requests to access data in the allocated region of the digital data storage.
18. The medium of , the requiring operation comprising:
claim 17
requiring host provision of a security key matching the stored security key as a condition to granting future host requests to access the target data in the digital data storage.
19. The medium of , the requiring operation comprising:
claim 17
as a condition to granting future host requests to access the target data from the digital data storage, requiring host provision of a security key that matches the stored security key when processed by a predetermined encryption process.
20. A signal-bearing medium tangibly embodying a program of machine-readable instructions executable by a digital processing apparatus to perform data storage operations in a storage system including a storage controller coupled to a digital data storage and serving one or more hosts, the storage containing host-accessible user data accessed by the storage controller on behalf of hosts and host-inaccessible metadata used by the storage controller to manage storage of the host-accessible data, the operations comprising:
the storage controller receiving a storage access request from one of the hosts, the request including a proposed security key and an identification of a requested data object contained on the digital data storage;
the storage controller retrieving a security key stored in metadata of the requested data object in the digital data storage, and then determining whether the. stored security key and the proposed security key exhibit the prescribed relationship; and
only if the proposed and stored security keys exhibit the prescribed relationship, the storage controller executing the storage access request, otherwise aborting the storage access request.
21. A data storage system accessible by one or more hosts, comprising:
a digital data storage containing user data and describing the user data;
the storage controller, coupled to the storage, and programmed to utilize the metadata to manage the user data while rendering the metadata inaccessible to hosts and to selectively access the user data on behalf of hosts by performing operations comprising:
receiving a write request from one of the hosts, the request including target data and a security key;
storing the target data in the digital data storage and storing the security key in metadata in association with the target data;
requiring host provision of a security key with prescribed relation to the stored security key as a condition to granting future host requests to access the target data in the digital data storage.
22. The system of , where the digital data storage comprises a storage device including a device controller, and the storage controller is embodied by the device controller.
claim 21
23. The system of , where the storage controller is embodied by a digital data processing apparatus dedicated to managing one or more device controllers.
claim 21
24. The system of , where the storage controller comprises a disk drive controller and the storage comprises magnetic disk media.
claim 21
25. The system of , where the storage controller comprises a removable storage media controller.
claim 21
26. The system of , further comprising a computer network coupled to the storage controller and interconnecting the storage controller to the hosts.
claim 21
27. A data storage system accessible by one or more hosts, comprising:
a digital data storage containing user data and metadata describing the user data;
a storage controller, coupled to the storage, and programmed to utilize the metadata to manage the user data while rendering the metadata inaccessible to hosts and to selectively access the user data on behalf of hosts and programmed to perform further operations comprising:
the storage controller receiving an allocation request from one of the hosts;
the storage controller allocating a region of the digital data storage and storing a security key in metadata associated with the allocated region;
requiring host provision of a security key with prescribed relation to the stored security key as a condition to granting future host requests to access data in the allocated region of the digital data storage.
28. The system of , where the digital data storage comprises a storage device including a device controller, and the storage controller is embodied by the device controller.
claim 27
29. The system of , where the storage controller is embodied by a digital data processing apparatus dedicated to managing one or more device controllers.
claim 27
30. The system of , where the storage controller comprises a disk drive controller and the storage comprises magnetic disk media.
claim 27
31. The system of , where the storage controller comprises a controller for removable storage media.
claim 27
32. The system of , further comprising a computer network coupled to the storage controller and interconnecting the storage controller to the hosts.
claim 27
33. A storage controller programmed to perform operations to manage access to digital data storage containing host-accessible user data accessible by the storage controller on behalf of hosts and also containing host-inaccessible metadata accessible by the storage controller to manage storage of the host-accessible data, the operations comprising:
the storage controller receiving a storage access request from one of the hosts, the request including a proposed security key and an identification of a requested data object contained on the digital data storage;
the storage controller retrieving a security key stored in metadata of the requested data object in the digital data storage, and then determining whether the stored security key and the proposed security key exhibit a prescribed relationship; and
only if the proposed and stored security keys exhibit the prescribed relationship, the storage controller executing the storage access request, otherwise aborting the storage access request.
34. The storage controller of , the storage controller being programmed such that the execution of the storage access requests comprises playback of recorded sounds contained on the digital data storage.
claim 33
35. A data storage system accessible by one or more hosts, comprising:
digital data storage means for containing user data; and
the storage controller means, coupled to the storage means, for utilizing the metadata to manage the user data while rendering the metadata inaccessible to hosts selectively accessing the user data on behalf of host:
receiving a write request from one of the hosts, the request including target data and a security key;
storing the target data in the storage means and storing the security key in metadata in association with the target data;
requiring host provision of a security key with prescribed relation to the stored security key as a condition to granting future host requests to access the target data in the storage means.
36. A data storage system accessible by one or more hosts, comprising:
digital data storage means for containing user data and metadata describing the user data;
the storage controller means, coupled to the storage means, for utilizing the metadata to manage the user data while rendering the metadata inaccessible to hosts selectively accessing the user data on behalf of hosts and managing access to the digital data storage by hosts by:
the storage controller receiving an allocation request from one of the hosts;
the storage controller allocating a region of the storage means and storing a security key in metadata associated with the allocated region;
requiring host provision of a security key with prescribed relation to the stored security key as a condition to granting future host requests to access data in the allocated region of the storage means.
37. A data storage system accessible by one or more hosts, comprising:
digital data storage means for containing user data and metadata describing the user data;
the storage controller means, coupled to the storage means, for utilizing the metadata to manage the user data while rendering the metadata inaccessible to hosts selectively accessing the user data on behalf of hosts and managing access to the digital data storage by hosts by:
the storage controller receiving a storage access request from one of the hosts, the request including a proposed security key and an identification of a requested data object contained on the storage means;
the storage controller retrieving a security key stored in metadata of the requested data object in the storage means, and then determining whether the stored security key and the proposed security key exhibit a prescribed relationship; and
only if the proposed and stored security keys exhibit the prescribed relationship, the storage controller executing the storage access request, otherwise aborting the storage access request.
38. A method of distributing sound recordings with selective playback characteristics, comprising operations of:
distributing machine-readable data storage media to customers, each including numerous sound segments each segment including a sound recording and metadata including an associated security key;
where the data storage media have a format that is unreadable by conventional playback devices, by including specific structure for use by playback devices requiring customer input of a security key with prescribed relationship to the stored security key as a condition to playback of the sound recording associated with the security key;
selling security keys to customers.
39. The method of , where certain sound segments are associated with multiple security keys such that different keys provide access to different combinations of sound segments.
claim 38
40. The method of , where one security key provides access to all sound segments on a data storage medium.
claim 39
41. The method of , where some data storage media have sound segments that do not include any associated security key.
claim 39
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/825,456 US6446209B2 (en) | 1998-06-12 | 2001-04-03 | Storage controller conditioning host access to stored data according to security key stored in host-inaccessible metadata |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/096,962 US6336187B1 (en) | 1998-06-12 | 1998-06-12 | Storage system with data-dependent security |
US09/825,456 US6446209B2 (en) | 1998-06-12 | 2001-04-03 | Storage controller conditioning host access to stored data according to security key stored in host-inaccessible metadata |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/096,962 Continuation-In-Part US6336187B1 (en) | 1998-06-12 | 1998-06-12 | Storage system with data-dependent security |
Publications (2)
Publication Number | Publication Date |
---|---|
US20010052073A1 true US20010052073A1 (en) | 2001-12-13 |
US6446209B2 US6446209B2 (en) | 2002-09-03 |
Family
ID=22259972
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/096,962 Expired - Lifetime US6336187B1 (en) | 1998-06-12 | 1998-06-12 | Storage system with data-dependent security |
US09/825,456 Expired - Lifetime US6446209B2 (en) | 1998-06-12 | 2001-04-03 | Storage controller conditioning host access to stored data according to security key stored in host-inaccessible metadata |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/096,962 Expired - Lifetime US6336187B1 (en) | 1998-06-12 | 1998-06-12 | Storage system with data-dependent security |
Country Status (1)
Country | Link |
---|---|
US (2) | US6336187B1 (en) |
Cited By (31)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020103903A1 (en) * | 2001-01-31 | 2002-08-01 | Bruton David Aro | Methods, systems and computer program products for selectively allowing users of a multi-user system access to network resources |
US20030023665A1 (en) * | 2001-07-27 | 2003-01-30 | Naoto Matsunami | Storage system having a plurality of controllers |
US20030220923A1 (en) * | 2002-05-23 | 2003-11-27 | International Business Machines Corporation | Mechanism for running parallel application programs on metadata controller nodes |
US20040098363A1 (en) * | 2002-11-19 | 2004-05-20 | International Business Machines Corporation | Hierarchical storage management using dynamic tables of contents and sets of tables of contents |
US20040143608A1 (en) * | 2003-01-21 | 2004-07-22 | Takahiro Nakano | Program with plural of independent administrative area information and an information processor using the same |
US20050160281A1 (en) * | 2001-07-25 | 2005-07-21 | Seagate Technology Llc | System and method for delivering versatile security, digital rights management, and privacy services |
US20060036823A1 (en) * | 2004-08-12 | 2006-02-16 | International Business Machines Corporation | Key-controlled object-based memory protection |
US20060143241A1 (en) * | 2002-11-27 | 2006-06-29 | Microsoft Corporation | System and method for scaleable multiplexed transactional log recovery |
US20060143505A1 (en) * | 2004-12-22 | 2006-06-29 | Dell Products L.P. | Method of providing data security between raid controller and disk drives |
US20060174352A1 (en) * | 2001-07-25 | 2006-08-03 | Seagate Technology Llc | Method and apparatus for providing versatile services on storage devices |
US20070067242A1 (en) * | 2005-09-19 | 2007-03-22 | International Business Machines Corporation | System and method for assigning sequence keys to a media player to enable hybrid traitor tracing |
US20070067244A1 (en) * | 2001-01-26 | 2007-03-22 | Hongxia Jin | Renewable traitor tracing |
US20070250710A1 (en) * | 2006-04-25 | 2007-10-25 | Seagate Technology Llc | Versatile secure and non-secure messaging |
US20070250915A1 (en) * | 2006-04-25 | 2007-10-25 | Seagate Technology Llc | Versatile access control system |
US20080010348A1 (en) * | 2006-07-06 | 2008-01-10 | International Business Machines Corporation | Method and program product for securing privacy of an e-mail address in an e-mail |
US7448077B2 (en) | 2002-05-23 | 2008-11-04 | International Business Machines Corporation | File level security for a metadata controller in a storage area network |
US7552191B1 (en) * | 2001-06-12 | 2009-06-23 | F5 Networks, Inc. | Method and apparatus to facilitate automatic sharing in a client server environment |
US20090235109A1 (en) * | 2006-04-25 | 2009-09-17 | Seagate Technology Llc | Hybrid computer security clock |
US20100217952A1 (en) * | 2009-02-26 | 2010-08-26 | Iyer Rahul N | Remapping of Data Addresses for a Large Capacity Victim Cache |
US7840769B1 (en) * | 2006-11-09 | 2010-11-23 | Chi Fai Ho | Method and system for play-only media player |
US8140622B2 (en) | 2002-05-23 | 2012-03-20 | International Business Machines Corporation | Parallel metadata service in storage area network environment |
US9098526B1 (en) * | 2003-12-04 | 2015-08-04 | Sheng Tai (Ted) Tsao | System and method for wireless device access to external storage |
US20150220452A1 (en) * | 2014-01-31 | 2015-08-06 | Lsi Corporation | System, Method and Computer-Readable Medium for Dynamically Mapping a Non-Volatile Memory Store |
US20160092461A1 (en) * | 2014-09-30 | 2016-03-31 | Apple Inc. | Inline keyed metadata |
US9378067B1 (en) | 2014-05-08 | 2016-06-28 | Springpath, Inc. | Automated load balancing across the distributed system of hybrid storage and compute nodes |
US20160210247A1 (en) * | 2015-01-16 | 2016-07-21 | Hamilton Sundstrand Corporation | Access key generation for computer-readable memory |
US9448927B1 (en) | 2012-12-19 | 2016-09-20 | Springpath, Inc. | System and methods for removing obsolete data in a distributed system of hybrid storage and compute nodes |
US10169169B1 (en) | 2014-05-08 | 2019-01-01 | Cisco Technology, Inc. | Highly available transaction logs for storing multi-tenant data sets on shared hybrid storage pools |
CN111026585A (en) * | 2019-12-05 | 2020-04-17 | 四川湖山电器股份有限公司 | Storage server hot standby switching method in recording and broadcasting system |
US10642689B2 (en) | 2018-07-09 | 2020-05-05 | Cisco Technology, Inc. | System and method for inline erasure coding for a distributed log structured storage system |
US10956365B2 (en) | 2018-07-09 | 2021-03-23 | Cisco Technology, Inc. | System and method for garbage collecting inline erasure coded data for a distributed log structured storage system |
Families Citing this family (75)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
TW425543B (en) * | 1998-04-14 | 2001-03-11 | Hitachi Ltd | Data reproduction method and device, data scrambling method, data recording method and device, recorded data reproduction device and the verification method thereof, and semiconductor chip |
US7536524B2 (en) | 1998-07-31 | 2009-05-19 | Kom Networks Inc. | Method and system for providing restricted access to a storage medium |
US9361243B2 (en) | 1998-07-31 | 2016-06-07 | Kom Networks Inc. | Method and system for providing restricted access to a storage medium |
CA2244626A1 (en) * | 1998-07-31 | 2000-01-31 | Kom Inc. | A hardware and software system |
US8234477B2 (en) * | 1998-07-31 | 2012-07-31 | Kom Networks, Inc. | Method and system for providing restricted access to a storage medium |
US6654886B1 (en) * | 1999-07-16 | 2003-11-25 | International Business Machines Corporation | Data processing system and method for permitting only preregistered hardware to access a remote service |
US6807620B1 (en) * | 2000-02-11 | 2004-10-19 | Sony Computer Entertainment Inc. | Game system with graphics processor |
US6446160B1 (en) * | 2000-09-28 | 2002-09-03 | International Business Machines Corporation | Multi-drive data storage system with analysis and selected demounting of idle data storage media |
US6813682B2 (en) * | 2000-09-29 | 2004-11-02 | Steven Bress | Write protection for computer long-term memory devices |
US6934852B2 (en) * | 2000-12-11 | 2005-08-23 | International Business Machines Corporation | Security keys for enhanced downstream access security for electronic file systems and drives |
US7231500B2 (en) | 2001-03-22 | 2007-06-12 | Sony Computer Entertainment Inc. | External data interface in a computer architecture for broadband networks |
US7093104B2 (en) * | 2001-03-22 | 2006-08-15 | Sony Computer Entertainment Inc. | Processing modules for computer architecture for broadband networks |
US7516334B2 (en) | 2001-03-22 | 2009-04-07 | Sony Computer Entertainment Inc. | Power management for processing modules |
US6809734B2 (en) | 2001-03-22 | 2004-10-26 | Sony Computer Entertainment Inc. | Resource dedication system and method for a computer architecture for broadband networks |
US6526491B2 (en) * | 2001-03-22 | 2003-02-25 | Sony Corporation Entertainment Inc. | Memory protection system and method for computer architecture for broadband networks |
US6826662B2 (en) | 2001-03-22 | 2004-11-30 | Sony Computer Entertainment Inc. | System and method for data synchronization for a computer architecture for broadband networks |
US7233998B2 (en) | 2001-03-22 | 2007-06-19 | Sony Computer Entertainment Inc. | Computer architecture and software cells for broadband networks |
FR2822971A1 (en) * | 2001-04-03 | 2002-10-04 | St Microelectronics Sa | SYSTEM AND METHOD FOR CONTROLLING ACCESS TO PROTECTED DATA STORED IN A MEMORY |
EP1430697B1 (en) * | 2001-06-25 | 2005-10-26 | Siemens Aktiengesellschaft | Method for transmitting data |
GB2377137B (en) * | 2001-06-27 | 2004-10-20 | Hewlett Packard Co | Network appliances |
GB2377043B (en) * | 2001-06-27 | 2005-01-05 | Hewlett Packard Co | Network storage devices |
US7036020B2 (en) * | 2001-07-25 | 2006-04-25 | Antique Books, Inc | Methods and systems for promoting security in a computer system employing attached storage devices |
US20030053630A1 (en) * | 2001-09-20 | 2003-03-20 | International Business Machines Corporation | Method and system for key usage control in an embedded security system |
JP2003132622A (en) * | 2001-10-22 | 2003-05-09 | Victor Co Of Japan Ltd | Recording device, reproducing device and recording medium |
US20030115476A1 (en) * | 2001-10-31 | 2003-06-19 | Mckee Bret | Hardware-enforced control of access to memory within a computer using hardware-enforced semaphores and other similar, hardware-enforced serialization and sequencing mechanisms |
JP4087149B2 (en) * | 2002-05-20 | 2008-05-21 | 株式会社日立製作所 | Disk device sharing system and computer |
US20030226024A1 (en) * | 2002-06-04 | 2003-12-04 | Qwest Communications International Inc. | Secure internet documents |
US20040153386A1 (en) * | 2002-08-19 | 2004-08-05 | George Eckerdt | Tangible security asset management system and methods thereof |
US7318137B2 (en) * | 2003-01-29 | 2008-01-08 | Steven Bress | Write protection for computer long-term memory devices with multi-port selective blocking |
US20040255145A1 (en) * | 2003-05-06 | 2004-12-16 | Jerry Chow | Memory protection systems and methods for writable memory |
JP4270946B2 (en) * | 2003-06-02 | 2009-06-03 | 三菱電機株式会社 | Navigation device |
US20060248595A1 (en) * | 2003-08-08 | 2006-11-02 | Koninklijke Philips Electronics N.V. | Reproducing encrypted content using region keys |
US20060288101A1 (en) * | 2003-08-19 | 2006-12-21 | Key Systems, Inc. | Multipurpose Interface and Control System |
JP2005128996A (en) * | 2003-09-30 | 2005-05-19 | Dainippon Printing Co Ltd | Information processing apparatus and system, and program |
US7562230B2 (en) * | 2003-10-14 | 2009-07-14 | Intel Corporation | Data security |
US20050114686A1 (en) * | 2003-11-21 | 2005-05-26 | International Business Machines Corporation | System and method for multiple users to securely access encrypted data on computer system |
CN1302403C (en) * | 2004-01-20 | 2007-02-28 | 威盛电子股份有限公司 | Optimization verification method for processor bus |
JP3976324B2 (en) * | 2004-02-27 | 2007-09-19 | 株式会社日立製作所 | A system that allocates storage areas to computers according to security levels |
US8224639B2 (en) | 2004-03-29 | 2012-07-17 | Sony Computer Entertainment Inc. | Methods and apparatus for achieving thermal management using processing task scheduling |
US20050262361A1 (en) * | 2004-05-24 | 2005-11-24 | Seagate Technology Llc | System and method for magnetic storage disposal |
US20060053282A1 (en) * | 2004-09-03 | 2006-03-09 | Mccown Steven H | Canister-based storage system security |
US7711965B2 (en) * | 2004-10-20 | 2010-05-04 | Intel Corporation | Data security |
US7565464B2 (en) * | 2004-12-14 | 2009-07-21 | Intel Corporation | Programmable transaction initiator architecture for systems with secure and non-secure modes |
US7904943B2 (en) * | 2004-12-28 | 2011-03-08 | O'connor Dennis M | Secure controller for block oriented storage |
US7412579B2 (en) * | 2004-12-30 | 2008-08-12 | O'connor Dennis M | Secure memory controller |
JP2006251932A (en) * | 2005-03-08 | 2006-09-21 | Canon Inc | Security management method and apparatus and program for security management |
US20060218201A1 (en) * | 2005-03-24 | 2006-09-28 | International Business Machines Corporation | System and method for effecting thorough disposition of records |
US7343468B2 (en) * | 2005-04-14 | 2008-03-11 | International Business Machines Corporation | Method and apparatus for storage provisioning automation in a data center |
US20060259674A1 (en) * | 2005-05-12 | 2006-11-16 | Robert Dunstan | Apparatus and method for granting access to a hardware interface shared between multiple software entities |
US7502872B2 (en) * | 2005-05-23 | 2009-03-10 | International Bsuiness Machines Corporation | Method for out of user space block mode I/O directly between an application instance and an I/O adapter |
US7464189B2 (en) * | 2005-05-23 | 2008-12-09 | International Business Machines Corporation | System and method for creation/deletion of linear block address table entries for direct I/O |
US7552240B2 (en) | 2005-05-23 | 2009-06-23 | International Business Machines Corporation | Method for user space operations for direct I/O between an application instance and an I/O adapter |
US20060265525A1 (en) * | 2005-05-23 | 2006-11-23 | Boyd William T | System and method for processor queue to linear block address translation using protection table control based on a protection domain |
US7502871B2 (en) * | 2005-05-23 | 2009-03-10 | International Business Machines Corporation | Method for query/modification of linear block address table entries for direct I/O |
US20070005815A1 (en) * | 2005-05-23 | 2007-01-04 | Boyd William T | System and method for processing block mode I/O operations using a linear block address translation protection table |
US20070050767A1 (en) * | 2005-08-31 | 2007-03-01 | Grobman Steven L | Method, apparatus and system for a virtual diskless client architecture |
US7500071B2 (en) * | 2005-08-31 | 2009-03-03 | International Business Machines Corporation | Method for out of user space I/O with server authentication |
US7657662B2 (en) * | 2005-08-31 | 2010-02-02 | International Business Machines Corporation | Processing user space operations directly between an application instance and an I/O adapter |
US20070168567A1 (en) * | 2005-08-31 | 2007-07-19 | Boyd William T | System and method for file based I/O directly between an application instance and an I/O adapter |
US7577761B2 (en) * | 2005-08-31 | 2009-08-18 | International Business Machines Corporation | Out of user space I/O directly between a host system and a physical adapter using file based linear block address translation |
US8201214B1 (en) * | 2005-09-30 | 2012-06-12 | Apple Inc. | Ad-hoc user account creation |
US9573067B2 (en) * | 2005-10-14 | 2017-02-21 | Microsoft Technology Licensing, Llc | Mass storage in gaming handhelds |
US20070124344A1 (en) * | 2005-11-29 | 2007-05-31 | International Business Machines Corporation | Method, apparatus and program storage device for providing web services-based data replication for Heterogeneous storage systems |
US8285747B1 (en) * | 2006-03-14 | 2012-10-09 | Netapp, Inc. | Incorporation of client storage into a storage system |
US9251382B2 (en) * | 2007-12-20 | 2016-02-02 | International Business Machines Corporation | Mapping encrypted and decrypted data via key management system |
US8090904B2 (en) * | 2008-02-01 | 2012-01-03 | Cru Acquisition Group, Llc | Reduced hard-drive-capacity detection device |
MX2010014464A (en) * | 2008-06-24 | 2011-02-22 | Nagravision Sa | Secure memory management system and method. |
US8954696B2 (en) | 2008-06-24 | 2015-02-10 | Nagravision S.A. | Secure memory management system and method |
US9317717B2 (en) * | 2012-12-28 | 2016-04-19 | Open Invention Network, Llc | Separate cryptographic keys for protecting different operations on data |
US20110035808A1 (en) * | 2009-08-05 | 2011-02-10 | The Penn State Research Foundation | Rootkit-resistant storage disks |
US8695104B2 (en) * | 2010-04-23 | 2014-04-08 | Dell Products, Lp | System and method for creating conditional immutable objects in a storage device |
US9960979B1 (en) * | 2013-03-12 | 2018-05-01 | Western Digital Technologies, Inc. | Data migration service |
GB2514428B (en) * | 2013-08-19 | 2016-01-13 | Visa Europe Ltd | Enabling access to data |
US9503455B2 (en) * | 2014-02-13 | 2016-11-22 | International Business Machines Corporation | Controlling access to storage devices shared by host systems |
US11163892B2 (en) * | 2019-01-09 | 2021-11-02 | International Business Machines Corporation | Buffering data until encrypted destination is unlocked |
Family Cites Families (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4322576A (en) | 1979-12-28 | 1982-03-30 | Racal-Milgo, Inc. | Message format for secure communication over data links |
US4423287A (en) | 1981-06-26 | 1983-12-27 | Visa U.S.A., Inc. | End-to-end encryption system and method of operation |
JPS60107155A (en) * | 1983-11-16 | 1985-06-12 | Hitachi Ltd | Data protection system of storage volume |
GB8704920D0 (en) | 1987-03-03 | 1987-04-08 | Hewlett Packard Co | Secure messaging system |
US5469556A (en) * | 1989-12-12 | 1995-11-21 | Harris Corporation | Resource access security system for controlling access to resources of a data processing system |
US5276876A (en) * | 1990-05-16 | 1994-01-04 | International Business Machines Corporation | Registration of resources for commit procedures |
US5070528A (en) | 1990-06-29 | 1991-12-03 | Digital Equipment Corporation | Generic encryption technique for communication networks |
US5432929A (en) * | 1992-09-09 | 1995-07-11 | International Business Machines Corporation | Storage subsystem having a modifiable key-lock |
US5455863A (en) | 1993-06-29 | 1995-10-03 | Motorola, Inc. | Method and apparatus for efficient real-time authentication and encryption in a communication system |
US5436972A (en) * | 1993-10-04 | 1995-07-25 | Fischer; Addison M. | Method for preventing inadvertent betrayal by a trustee of escrowed digital secrets |
US5572673A (en) * | 1993-12-01 | 1996-11-05 | Sybase, Inc. | Secure multi-level system for executing stored procedures |
CA2136919A1 (en) | 1993-12-09 | 1995-06-10 | John Timothy Hember | Local area network encryption decryption system |
US5557765A (en) | 1994-08-11 | 1996-09-17 | Trusted Information Systems, Inc. | System and method for data recovery |
US6181837B1 (en) * | 1994-11-18 | 2001-01-30 | The Chase Manhattan Bank, N.A. | Electronic check image storage and retrieval system |
US5615264A (en) | 1995-06-08 | 1997-03-25 | Wave Systems Corp. | Encrypted data package record for use in remote transaction metered data system |
US5592549A (en) * | 1995-06-15 | 1997-01-07 | Infosafe Systems, Inc. | Method and apparatus for retrieving selected information from a secure information source |
US5996075A (en) * | 1995-11-02 | 1999-11-30 | Sun Microsystems, Inc. | Method and apparatus for reliable disk fencing in a multicomputer system |
US5857021A (en) * | 1995-11-07 | 1999-01-05 | Fujitsu Ltd. | Security system for protecting information stored in portable storage media |
JPH09190236A (en) * | 1996-01-10 | 1997-07-22 | Canon Inc | Method, device and system for processing information |
US5748744A (en) * | 1996-06-03 | 1998-05-05 | Vlsi Technology, Inc. | Secure mass storage system for computers |
CA2262450A1 (en) * | 1996-08-02 | 1998-02-12 | David Lathrop | Method and apparatus for allowing distributed control of shared resources |
-
1998
- 1998-06-12 US US09/096,962 patent/US6336187B1/en not_active Expired - Lifetime
-
2001
- 2001-04-03 US US09/825,456 patent/US6446209B2/en not_active Expired - Lifetime
Cited By (67)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9520993B2 (en) | 2001-01-26 | 2016-12-13 | International Business Machines Corporation | Renewable traitor tracing |
US11108569B2 (en) | 2001-01-26 | 2021-08-31 | International Business Machines Corporation | Renewable traitor tracing |
US20070067244A1 (en) * | 2001-01-26 | 2007-03-22 | Hongxia Jin | Renewable traitor tracing |
US7702785B2 (en) * | 2001-01-31 | 2010-04-20 | International Business Machines Corporation | Methods, systems and computer program products for selectively allowing users of a multi-user system access to network resources |
US20020103903A1 (en) * | 2001-01-31 | 2002-08-01 | Bruton David Aro | Methods, systems and computer program products for selectively allowing users of a multi-user system access to network resources |
US7552191B1 (en) * | 2001-06-12 | 2009-06-23 | F5 Networks, Inc. | Method and apparatus to facilitate automatic sharing in a client server environment |
US7925894B2 (en) | 2001-07-25 | 2011-04-12 | Seagate Technology Llc | System and method for delivering versatile security, digital rights management, and privacy services |
US20050160281A1 (en) * | 2001-07-25 | 2005-07-21 | Seagate Technology Llc | System and method for delivering versatile security, digital rights management, and privacy services |
US20060174352A1 (en) * | 2001-07-25 | 2006-08-03 | Seagate Technology Llc | Method and apparatus for providing versatile services on storage devices |
US7216148B2 (en) | 2001-07-27 | 2007-05-08 | Hitachi, Ltd. | Storage system having a plurality of controllers |
US20030023665A1 (en) * | 2001-07-27 | 2003-01-30 | Naoto Matsunami | Storage system having a plurality of controllers |
US20030023784A1 (en) * | 2001-07-27 | 2003-01-30 | Hitachi, Ltd. | Storage system having a plurality of controllers |
US7260656B2 (en) * | 2001-07-27 | 2007-08-21 | Hitachi, Ltd. | Storage system having a plurality of controllers |
US7448077B2 (en) | 2002-05-23 | 2008-11-04 | International Business Machines Corporation | File level security for a metadata controller in a storage area network |
US7840995B2 (en) | 2002-05-23 | 2010-11-23 | International Business Machines Corporation | File level security for a metadata controller in a storage area network |
US20030220923A1 (en) * | 2002-05-23 | 2003-11-27 | International Business Machines Corporation | Mechanism for running parallel application programs on metadata controller nodes |
US8140622B2 (en) | 2002-05-23 | 2012-03-20 | International Business Machines Corporation | Parallel metadata service in storage area network environment |
US7010528B2 (en) | 2002-05-23 | 2006-03-07 | International Business Machines Corporation | Mechanism for running parallel application programs on metadata controller nodes |
US7693878B2 (en) | 2002-11-19 | 2010-04-06 | International Business Machines Corporation | Hierarchical storage management using dynamic tables of contents and sets of tables of contents |
US20040098363A1 (en) * | 2002-11-19 | 2004-05-20 | International Business Machines Corporation | Hierarchical storage management using dynamic tables of contents and sets of tables of contents |
US7412433B2 (en) | 2002-11-19 | 2008-08-12 | International Business Machines Corporation | Hierarchical storage management using dynamic tables of contents and sets of tables of contents |
US20080294611A1 (en) * | 2002-11-19 | 2008-11-27 | Matthew Joseph Anglin | Hierarchical storage management using dynamic tables of contents and sets of tables of contents |
US20060143241A1 (en) * | 2002-11-27 | 2006-06-29 | Microsoft Corporation | System and method for scaleable multiplexed transactional log recovery |
US8626721B2 (en) | 2002-11-27 | 2014-01-07 | Microsoft Corporation | System and method for scaleable multiplexed transactional log recovery |
US20100115055A1 (en) * | 2003-01-21 | 2010-05-06 | Takahiro Nakano | Virtual file servers with storage device |
US7970917B2 (en) | 2003-01-21 | 2011-06-28 | Hitachi, Ltd. | Virtual file servers with storage device |
US7673012B2 (en) | 2003-01-21 | 2010-03-02 | Hitachi, Ltd. | Virtual file servers with storage device |
US20040143608A1 (en) * | 2003-01-21 | 2004-07-22 | Takahiro Nakano | Program with plural of independent administrative area information and an information processor using the same |
US9219780B1 (en) * | 2003-07-22 | 2015-12-22 | Sheng Tai (Ted) Tsao | Method and system for wireless device access to external storage |
US9098526B1 (en) * | 2003-12-04 | 2015-08-04 | Sheng Tai (Ted) Tsao | System and method for wireless device access to external storage |
US7774561B2 (en) | 2004-08-12 | 2010-08-10 | International Business Machines Corporation | Key-controlled object-based memory protection |
US20080263301A1 (en) * | 2004-08-12 | 2008-10-23 | International Business Machines Corporation | Key-controlled object-based memory protection |
US20080168248A1 (en) * | 2004-08-12 | 2008-07-10 | International Business Machines Corporation | Key-controlled object-based memory protection |
US20060036823A1 (en) * | 2004-08-12 | 2006-02-16 | International Business Machines Corporation | Key-controlled object-based memory protection |
US7424584B2 (en) * | 2004-08-12 | 2008-09-09 | International Business Machines Corporation | Key-controlled object-based memory protection |
US7890727B2 (en) | 2004-08-12 | 2011-02-15 | International Business Machines Corporation | Key-controlled object-based memory protection |
US20060143505A1 (en) * | 2004-12-22 | 2006-06-29 | Dell Products L.P. | Method of providing data security between raid controller and disk drives |
US20070067242A1 (en) * | 2005-09-19 | 2007-03-22 | International Business Machines Corporation | System and method for assigning sequence keys to a media player to enable hybrid traitor tracing |
US7630497B2 (en) * | 2005-09-19 | 2009-12-08 | International Business Machines Corporation | System and method for assigning sequence keys to a media player to enable hybrid traitor tracing |
US20070250710A1 (en) * | 2006-04-25 | 2007-10-25 | Seagate Technology Llc | Versatile secure and non-secure messaging |
US8028166B2 (en) | 2006-04-25 | 2011-09-27 | Seagate Technology Llc | Versatile secure and non-secure messaging |
US8281178B2 (en) | 2006-04-25 | 2012-10-02 | Seagate Technology Llc | Hybrid computer security clock |
US8429724B2 (en) | 2006-04-25 | 2013-04-23 | Seagate Technology Llc | Versatile access control system |
US20070250915A1 (en) * | 2006-04-25 | 2007-10-25 | Seagate Technology Llc | Versatile access control system |
US20090235109A1 (en) * | 2006-04-25 | 2009-09-17 | Seagate Technology Llc | Hybrid computer security clock |
US8103724B2 (en) * | 2006-07-06 | 2012-01-24 | International Business Machines Corporation | Method and program product for securing privacy of an e-mail address in an e-mail |
US20080010348A1 (en) * | 2006-07-06 | 2008-01-10 | International Business Machines Corporation | Method and program product for securing privacy of an e-mail address in an e-mail |
US8108642B1 (en) * | 2006-11-09 | 2012-01-31 | TP Labs, Inc. | Method and system for play-only media player |
US7840769B1 (en) * | 2006-11-09 | 2010-11-23 | Chi Fai Ho | Method and system for play-only media player |
US20100217952A1 (en) * | 2009-02-26 | 2010-08-26 | Iyer Rahul N | Remapping of Data Addresses for a Large Capacity Victim Cache |
US9448927B1 (en) | 2012-12-19 | 2016-09-20 | Springpath, Inc. | System and methods for removing obsolete data in a distributed system of hybrid storage and compute nodes |
US10019459B1 (en) | 2012-12-19 | 2018-07-10 | Springpath, LLC | Distributed deduplication in a distributed system of hybrid storage and compute nodes |
US9965203B1 (en) | 2012-12-19 | 2018-05-08 | Springpath, LLC | Systems and methods for implementing an enterprise-class converged compute-network-storage appliance |
US9521198B1 (en) * | 2012-12-19 | 2016-12-13 | Springpath, Inc. | Systems and methods for implementing an enterprise-class converged compute-network-storage appliance |
US9720619B1 (en) | 2012-12-19 | 2017-08-01 | Springpath, Inc. | System and methods for efficient snapshots in a distributed system of hybrid storage and compute nodes |
US9582421B1 (en) | 2012-12-19 | 2017-02-28 | Springpath, Inc. | Distributed multi-level caching for storage appliances |
US10268592B2 (en) * | 2014-01-31 | 2019-04-23 | Avago Technologies International Sales Pte. Limited | System, method and computer-readable medium for dynamically mapping a non-volatile memory store |
US20150220452A1 (en) * | 2014-01-31 | 2015-08-06 | Lsi Corporation | System, Method and Computer-Readable Medium for Dynamically Mapping a Non-Volatile Memory Store |
US9378067B1 (en) | 2014-05-08 | 2016-06-28 | Springpath, Inc. | Automated load balancing across the distributed system of hybrid storage and compute nodes |
US10169169B1 (en) | 2014-05-08 | 2019-01-01 | Cisco Technology, Inc. | Highly available transaction logs for storing multi-tenant data sets on shared hybrid storage pools |
US20160092461A1 (en) * | 2014-09-30 | 2016-03-31 | Apple Inc. | Inline keyed metadata |
US10733146B2 (en) * | 2014-09-30 | 2020-08-04 | Apple Inc. | Inline keyed metadata |
US9645948B2 (en) * | 2015-01-16 | 2017-05-09 | Hamilton Sundstrand Corporation | Access key generation for computer-readable memory |
US20160210247A1 (en) * | 2015-01-16 | 2016-07-21 | Hamilton Sundstrand Corporation | Access key generation for computer-readable memory |
US10642689B2 (en) | 2018-07-09 | 2020-05-05 | Cisco Technology, Inc. | System and method for inline erasure coding for a distributed log structured storage system |
US10956365B2 (en) | 2018-07-09 | 2021-03-23 | Cisco Technology, Inc. | System and method for garbage collecting inline erasure coded data for a distributed log structured storage system |
CN111026585A (en) * | 2019-12-05 | 2020-04-17 | 四川湖山电器股份有限公司 | Storage server hot standby switching method in recording and broadcasting system |
Also Published As
Publication number | Publication date |
---|---|
US6336187B1 (en) | 2002-01-01 |
US6446209B2 (en) | 2002-09-03 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6446209B2 (en) | Storage controller conditioning host access to stored data according to security key stored in host-inaccessible metadata | |
US5748744A (en) | Secure mass storage system for computers | |
US9767322B2 (en) | Data transcription in a data storage device | |
US9588705B2 (en) | Efficient elimination of access to data on a writable storage media | |
US6704838B2 (en) | Hybrid data storage and reconstruction system and method for a data storage device | |
US7360057B2 (en) | Encryption of data in a range of logical block addresses | |
CN1331125C (en) | System and method for controlling the use and duplication of digital content distributed on removable media | |
US9384777B2 (en) | Efficient elimination of access to data on a writable storage media | |
US9116900B2 (en) | Methods for controlling remote archiving systems | |
US7793041B2 (en) | Method for controlling access to data of a tape data storage medium | |
US7864478B2 (en) | Verification of a tape data storage cartridge | |
US20090094228A1 (en) | Methods for control of digital shredding of media | |
US20090019245A1 (en) | Methods for implementation of data formats on a removable disk drive storage system | |
US20140215137A1 (en) | Methods for implementation of an archiving system which uses removable disk storage system | |
US20080140946A1 (en) | Apparatus, system, and method for protecting hard disk data in multiple operating system environments | |
US20060085413A1 (en) | Storage system and method of managing data stored in a storage system | |
US20020138747A1 (en) | Restricted data access | |
US20060206484A1 (en) | Method for preserving consistency between worm file attributes and information in management servers | |
KR20010022942A (en) | Redundancy implementation on object oriented data storage device | |
US7512735B2 (en) | Apparatus and method to control access to logical volumes | |
US7814552B2 (en) | Method and apparatus for an encryption system | |
US9251382B2 (en) | Mapping encrypted and decrypted data via key management system | |
US20090220089A1 (en) | Method and apparatus for mapping encrypted and decrypted data via a multiple key management system | |
JP3834223B2 (en) | Disk access control apparatus, disk access control method, information processing apparatus, program | |
JPS61276040A (en) | File access system |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:KERN, ROBERT FREDERIC;SOVIK, MARK ANTHONY;REEL/FRAME:011669/0498;SIGNING DATES FROM 20010323 TO 20010329 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
FPAY | Fee payment |
Year of fee payment: 4 |
|
FPAY | Fee payment |
Year of fee payment: 8 |
|
REMI | Maintenance fee reminder mailed | ||
FPAY | Fee payment |
Year of fee payment: 12 |
|
SULP | Surcharge for late payment |
Year of fee payment: 11 |