WO2007028241A2 - Method and system for data security of recording media - Google Patents

Method and system for data security of recording media Download PDF

Info

Publication number
WO2007028241A2
WO2007028241A2 PCT/CA2006/001465 CA2006001465W WO2007028241A2 WO 2007028241 A2 WO2007028241 A2 WO 2007028241A2 CA 2006001465 W CA2006001465 W CA 2006001465W WO 2007028241 A2 WO2007028241 A2 WO 2007028241A2
Authority
WO
WIPO (PCT)
Prior art keywords
data
key
storage medium
data storage
decryption
Prior art date
Application number
PCT/CA2006/001465
Other languages
French (fr)
Other versions
WO2007028241A3 (en
Inventor
Jean-Francois Poirier
Original Assignee
Universal Data Protection Corporation
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Universal Data Protection Corporation filed Critical Universal Data Protection Corporation
Publication of WO2007028241A2 publication Critical patent/WO2007028241A2/en
Publication of WO2007028241A3 publication Critical patent/WO2007028241A3/en

Links

Classifications

    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
    • G11B20/00094—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving measures which result in a restriction to authorised record carriers
    • G11B20/00115—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving measures which result in a restriction to authorised record carriers wherein the record carrier stores a unique medium identifier
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
    • G11B20/00188—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving measures which result in a restriction to authorised devices recording or reproducing contents to/from a record carrier
    • G11B20/00195—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving measures which result in a restriction to authorised devices recording or reproducing contents to/from a record carrier using a device identifier associated with the player or recorder, e.g. serial numbers of playback apparatuses or MAC addresses
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
    • G11B20/0021—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
    • G11B20/0021—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier
    • G11B20/00217—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier the cryptographic key used for encryption and/or decryption of contents recorded on or reproduced from the record carrier being read from a specific source
    • G11B20/00224—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier the cryptographic key used for encryption and/or decryption of contents recorded on or reproduced from the record carrier being read from a specific source wherein the key is obtained from a remote server
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
    • G11B20/0021—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier
    • G11B20/00217—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier the cryptographic key used for encryption and/or decryption of contents recorded on or reproduced from the record carrier being read from a specific source
    • G11B20/00253—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier the cryptographic key used for encryption and/or decryption of contents recorded on or reproduced from the record carrier being read from a specific source wherein the key is stored on the record carrier
    • G11B20/00347—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier the cryptographic key used for encryption and/or decryption of contents recorded on or reproduced from the record carrier being read from a specific source wherein the key is stored on the record carrier wherein the medium identifier is used as a key
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
    • G11B20/0021—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier
    • G11B20/00485—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier characterised by a specific kind of data which is encrypted and recorded on and/or reproduced from the record carrier
    • G11B20/00492—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier characterised by a specific kind of data which is encrypted and recorded on and/or reproduced from the record carrier wherein content or user data is encrypted
    • G11B20/00507—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier characterised by a specific kind of data which is encrypted and recorded on and/or reproduced from the record carrier wherein content or user data is encrypted wherein consecutive physical data units of the record carrier are encrypted with separate encryption keys, e.g. the key changes on a cluster or sector basis
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
    • G11B20/00731—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving a digital rights management system for enforcing a usage restriction
    • G11B20/00746—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving a digital rights management system for enforcing a usage restriction wherein the usage restriction can be expressed as a specific number
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
    • G11B20/00731—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving a digital rights management system for enforcing a usage restriction
    • G11B20/00746—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving a digital rights management system for enforcing a usage restriction wherein the usage restriction can be expressed as a specific number
    • G11B20/00797—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving a digital rights management system for enforcing a usage restriction wherein the usage restriction can be expressed as a specific number wherein the usage restriction limits the number of times a content can be reproduced, e.g. using playback counters
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10—Digital recording or reproducing
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B23/00—Record carriers not specific to the method of recording or reproducing; Accessories, e.g. containers, specially adapted for co-operation with the recording or reproducing apparatus ; Intermediate mediums; Apparatus or processes specially adapted for their manufacture
    • G11B23/28—Indicating or preventing prior or unauthorised use, e.g. cassettes with sealing or locking means, write-protect devices for discs
    • G11B23/283—Security features, e.g. digital codes
    • G11B23/284—Security features, e.g. digital codes on the record carrier
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41—Structure of client; Structure of client peripherals
    • H04N21/426—Internal components of the client ; Characteristics thereof
    • H04N21/42646—Internal components of the client ; Characteristics thereof for reading from or writing on a non-volatile solid state storage medium, e.g. DVD, CD-ROM
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/432—Content retrieval operation from a local storage medium, e.g. hard-disk
    • H04N21/4325—Content retrieval operation from a local storage medium, e.g. hard-disk by playing back content from the storage medium
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
    • H04N21/44204—Monitoring of content usage, e.g. the number of times a movie has been viewed, copied or the amount which has been watched
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4627—Rights management associated to the content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/835—Generation of protective data, e.g. certificates
    • H04N21/8352—Generation of protective data, e.g. certificates involving content or source identification data, e.g. Unique Material Identifier [UMID]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/91—Television signal processing therefor
    • H04N5/913—Television signal processing therefor for scrambling ; for copy protection
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11C—STATIC STORES
    • G11C7/00—Arrangements for writing information into, or reading information out from, a digital store
    • G11C7/24—Memory cell safety or protection circuits, e.g. arrangements for preventing inadvertent reading or writing; Status cells; Test cells
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/91—Television signal processing therefor
    • H04N5/913—Television signal processing therefor for scrambling ; for copy protection
    • H04N2005/91357—Television signal processing therefor for scrambling ; for copy protection by modifying the video signal
    • H04N2005/91364—Television signal processing therefor for scrambling ; for copy protection by modifying the video signal the video signal being scrambled
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/84—Television signal recording using optical recording
    • H04N5/85—Television signal recording using optical recording on discs or drums

Definitions

  • the described embodiments relate to a method and system for providing improved data security for recording media.
  • the invention relates to a method and system for providing improved encryption of data stored on recording media and for monitoring use of the stored data.
  • Certain data storage products may contain data which is subject to copyright and it is therefore desirable to prevent unauthorized copying of such data.
  • Conventional data protection measures are used in relation to some CDs or DVDs in an attempt to prevent unauthorized copying.
  • One example of such conventional protection measures is to add a secure sector to the optical disc that cannot be copied by normal CD/DVD writers. This secure sector contains information that will enable the disk to be read. Thus, unless the secure sector is also copied to the new disc, the new disc cannot be read. This protection technique will only be effective as long as the secure sector is not rewritable by available CD or DVD copiers. Similar problems may be encountered in protecting computer program instructions stored on data storage media.
  • Described embodiments generally relate to methods of encoding data on a data storage medium and methods of decoding and reading such encoded data. Other aspects relate to systems or apparatus for performing these methods. Still other aspects relate to systems and methods for monitoring use of data recorded on data storage media. These aspects are particularly suited to protecting proprietary data against unauthorized or excessive copying, where the proprietary data is embodied on a data storage medium that is publicly available for rent or sale.
  • embodiments relate to a method of encoding data on a data storage medium.
  • the method comprises the steps of: receiving a quantity of data to be stored on a data storage medium, the quantity of data including payload data and data delimiters; determining a unique identifier of the data storage medium; allocating an encoding key to the data storage medium, the encoding key being associated with the unique identifier; dividing the quantity of data into a plurality of data blocks of a predetermined size; encoding each data block using the encoding key to generate an encoded data block of the predetermined size; and storing all encoded data blocks on the data storage medium so that the quantity of data is stored on the data storage medium in encoded form.
  • the method may further include writing the unique identifier to the data storage medium, either in encoded or unencoded form.
  • the data storage medium may be an optical recording medium, such as an optical disc.
  • the optical disc may be used for storage of audio and/or video data, for example.
  • the optical disc may store other kinds of data, such as generic or specific data files or software program instructions. Other forms of data storage may be used, providing they can be written to at least once and can be read by a reading device.
  • the unique identifier may be a serial number of the optical recording medium.
  • the step of determining may include reading the serial number from the optical recording medium.
  • the encoding may include performing a logic operation on each data block, where the encoding key and the data block are operands of the logic operation.
  • the encoding key may be a fixed key. Alternatively, the encoding key may be a variable key.
  • variable key may be used to further encode the data blocks without further altering the predetermined size of the data blocks.
  • the variable key encoding may be performed before or after the fixed key encoding.
  • the variable key may vary for each data block.
  • the variable key may depend, for example, on the location of the data block on the data storage medium.
  • the variable key may be determined based on the fixed key or the unique identifier.
  • the variable key may be determined from a series of numbers, optionally pseudo-random or random numbers, based on the fixed key or the unique identifier.
  • Another aspect relates to a data storage medium storing data encoded according to the method described above.
  • inventions relate to a method of decoding encoded data stored on a data storage medium.
  • the encoded data includes payload data and data delimiters.
  • the method comprises:
  • the method may further comprise buffering a plurality of the decoded data blocks, determining the payload data in the decoded data blocks based on the data delimiters and processing the payload data.
  • Step f) may further comprise processing the encoded data using a first logic function and a first key specific to the reading device to generate intermediate encoded data.
  • step g) may further comprise processing the intermediate encoded data using a second logic function and the encryption code to generate the decoded data blocks.
  • the first unique identifier may be, or be derived from, a serial number of the data storage medium and step b) may include reading the serial number from the data storage medium.
  • the data storage medium may be an optical recording medium, such as an optical disc or any other kind of data storage medium.
  • the decryption code may be a fixed code.
  • the decryption code may be a variable code. If the decryption code is a variable code, it may vary for each data block.
  • the data storage medium may be replaced with another data source, such as a data stream transmitted from another device.
  • a further aspect relates to a method of monitoring use of data stored on a data storage medium.
  • the data is stored on a data storage medium using an encoding key and the data storage medium has a unique identifier.
  • the method comprises the steps of: receiving a decryption key request from a data reading entity in relation to the data storage medium, the decryption key request including a reading device identifier and the unique identifier; determining a use number of the data storage medium based on the unique identifier; comparing the use number with a predetermined use limit of the data storage medium; and incrementing the use number if the use number is less than the predetermined use limit.
  • the method may further comprise storing the reading device identifier with the use number in a use record for the data storage medium.
  • the method may further comprise the steps of: determining the encoding key based on the unique identifier; generating a decryption key based on the encoding key and the reading device identifier; and transmitting the decryption key to the data reading entity in response to the decryption key request.
  • the decryption key may be generated as an output of a logic function, where the encoding key and the reading device identifier are operands of the logic function.
  • the unique identifier may be, or be derived from, a serial number of the data storage medium.
  • Embodiments may provide improved data security for data stored on data storage media, such as software, audio data on compact discs (CDs) and video data on digital video discs (DVDs), by encoding the data stored on the storage media with an encryption key that is known only to the entity that stores the data on the recording media.
  • data storage media such as software, audio data on compact discs (CDs) and video data on digital video discs (DVDs)
  • CDs compact discs
  • DVDs digital video discs
  • the decryption key is only received from the validation entity in response to provision of a serial number of the device attempting to read the storage medium and an identifier of the storage medium itself.
  • the decryption key is not the same as the encryption key. Rather, the decryption key is specific to the recording medium and the device reading the recording medium.
  • Use of a variable key instead of, or in addition to, the fixed key advantageously provides for further improved security. If a variable key is used in the encoding, a corresponding variable key is used in the decryption process.
  • the encoded data is read from the storage medium and is conditioned using a logic function to generate intermediate encoded data.
  • this intermediate encoded data can not be decoded without receiving a decryption key from the validation entity.
  • a prospective copier may read the data stored on the storage medium, if the copier tries to generate a meaningful output from the intermediate encoded data, such output would only appear as noise.
  • the decryption key provided by the validation entity in order to decrypt the intermediate encoded data is specific to the recording medium and to the reading device. The same key cannot be used to decrypt another recording medium which has the same original data stored on it as each recording medium uses a different encoding key. Similarly, the same key will not be valid for a different reading device.
  • a further aspect relates to a data processing device for an encrypted data storage medium.
  • the data processing device comprises reading means for reading encrypted data stored on the data storage medium and a processor.
  • the processor is in communication with the reading means for processing the encrypted data and controls the reading means.
  • the processor has means for determining a first unique identifier of the data processing device and a second unique identifier of the data storage medium, and means for receiving a decryption code generated by a code provider based on the first and second unique identifiers.
  • the processor is configured to decrypt the encrypted data based on the decryption code.
  • Figure 1 is a block diagram of a system for reading encoded recording media
  • Figure 2 is a process flow diagram of a method of obtaining a decryption key for decrypting encrypted data stored on data storage media
  • Figure 3 is a process flow diagram of a method of decrypting encrypted data stored on data storage media
  • Figure 4 is a process flow diagram of a method of encrypting data and storing the data on data storage media.
  • Figure 5 is a block diagram of a system for reading encoded recording media.
  • the described embodiments are suited to encoding data to be stored on data storage media, such as software, audio or video data, which, due to their vulnerability to piracy, require increased data security in order to limit or prevent unauthorized copying.
  • data storage media such as software, audio or video data
  • some embodiments may be described with reference to an optical disc, as one example of data storage media. It should be understood, however, that the described embodiments may be applied to other forms of data storage media.
  • the encoding and decoding methods described herein may be employed alone or in combination with other encryption and decryption methods, such as may be known to persons skilled in the art.
  • Figure 1 is a block diagram of a system 100 for reading encoded recording media.
  • the system 100 includes a reading device 110, such as an optical disc reader, a data storage medium 120, such as a compact disc or other form of rewritable non-volatile storage medium, and a code provider 130 located remotely from reading device 110.
  • Reading device 110 has associated therewith a data output destination 140, which may be, for example, a computer processor or digital signal processor.
  • the digital signal processor may be in a television or other display having audio and video display capabilities in order that a customer can see and/or hear video and/or audio signals corresponding to the data stored on the data storage medium 120.
  • the data output destination 140 may be any suitably secure data processing device.
  • Reading device 110 comprises a digital media reader 150 and a data processor 160.
  • the digital media reader 150 is controlled by data processor 160 to read the data encoded on data storage medium 120 according to conventional means and provides the encoded data thus read to data processor 160 for decryption and processing according to its data type.
  • data including payload data and data delimiters
  • a serial number or other unique identifier of the data storage medium 120 is also stored thereon.
  • the unique identifier is preferably unencoded, although it may alternatively be encoded.
  • the unique identifier may be stored in a particular location on digital recoding medium 120, for example at the very beginning or end of the encoded data or in a special location, such as the inner circle of the disc, separate from the encoded data.
  • the unique identifier is readily readable by digital media reader 150.
  • the unique identifier may be recorded on the data storage medium 120 so as to be visible to a person so that the person can manually enter the unique identifier through a user interface 135.
  • Data storage medium 120 may be of any suitable kind for storing data, including optical storage media, volatile and non-volatile memory devices, magnetic data storage media or any other mechanical, chemical, electrical or physical means of storing data, providing there is a suitable reading device, such as digital media reader 150, for reading the stored data.
  • a suitable reading device such as digital media reader 150
  • Specific examples of data storage medium 120 include optical discs, digital audio tapes (DATs) and memory cards or sticks. Embodiments of the invention are particularly useful in protecting data stored (pre-recorded) on commercially available data storage products.
  • data storage medium 120 may be replaced by a data source, such as a streaming or other data source. In one sense, data storage medium 120 may be generalized as one form of data source.
  • the origin or form of storage of the data source is unimportant to the data processor 160, so long as data processor 160 can identify a unique identifier of the data source (to obtain the decryption code) and can process the data according to the format information in the decryption code.
  • Data processor 160 may be any suitable data processor having a speed and operating capacity to perform a series of logical operations in quick succession.
  • data processor 160 may have a data throughput efficiency suitable for handling data quantities in the order of several megabytes to several gigabytes.
  • Reading device 110 further comprises a memory 170, which may include flash memory or other read-only memory (ROM) and random access memory (RAM). As will be described in further detail below, memory 170 may store information on predetermined data formats and logic operations that may be used in the encoding and decoding. Memory 170 may be distinct from data processor 160, as shown in Figure 1 , or it may form a part of the architecture of data processor 160. The serial number or other unique identifier of the reading device 110 or data processor 160 (or both) is stored in memory 170. Alternatively, the serial number or other unique identifier may be stored in a memory internal to data processor 160, if memory 170 is separate from data processor 160.
  • ROM read-only memory
  • RAM random access memory
  • Memory 170 may be encrypted (and decrypted) according to the methods described in co-owned and co-pending United States Utility Patent Application Serial No. 11/350,839, filed February 10, 2006, entitled “Method and System for Microprocessor Data Security", the entire contents of which is hereby incorporated by reference.
  • System 100 further includes a user interface 135 in communication with data processor 160, either as part of a user interface provided by a device housing reading device 110 and operably associated therewith, or as a separate interface device, such as a remote control.
  • user interface 135 may be any known form of user interface, including, for example, a keyboard, mouse, display screen or other peripheral, allowing a user of the system 100 to interface with the reading device 110.
  • user interface 135 may include other interface means, such as a small keypad and display, remote control or a two-way speech synthesizer.
  • Code provider 130 is preferably in communication with data processor 160 over a network, such as the Internet, where the reading device 110, or a host device housing reading device 110, is in connection with the network, either through a wired or wireless connection.
  • a network such as the Internet
  • Code provider 130 is located remotely from reading device 110 and may be a computer system controlled by an entity responsible for monitoring use of the data storage medium 120 and for receiving requests for a decryption key to decrypt data stored on data storage media, such as data storage media 120. Code provider 130 also records the requests and the unique identifiers identified in the requests and thereby monitors the level of use of the data storage media 120. [0045] Code provider 130 may allow fully automated data exchange with data processor 160. Alternatively, code provider 130 may accept decryption key requests through a form on a web page, an automated voice response (AVR) system or a call center operator, for example, and reply with the decryption key accordingly.
  • AVR automated voice response
  • code provider 130 In response to requests for decryption keys, code provider 130 generates a decryption key based on the information provided in the request and transmits the decryption code, including a decryption key and any other relevant information for assisting decryption, to reading device 110. However, if the code provider 130 determines that the decryption code should not be provided in response to the request (as described below in relation to Figure 2), code provider 130 transmits a notification to this effect to the user for display to the user through user interface 135.
  • the decryption code when the code provider 130 provides the decryption code to reading device 110, the decryption code has an expiry date associated therewith. Whether or not the decryption code has an expiry date, the decryption code is stored in memory 170 for subsequent use when decrypting the data encoded on data storage medium 120.
  • the contents of the decryption code provided by code provider 130 is described in further detail below in relation to Tables 3A and 3B.
  • a third party such as a DVD (or other data) rental business, may request a time-limited decryption code from code provider 130 and the third party can then provide the received decryption code to the consumer, for example on a printed sheet, such as the rental receipt.
  • Method 200 assumes that a data storage medium (encoded according to an embodiment of the invention, such as that described in relation to Figure 4) has been inserted into a reading device, such as reading device 110.
  • a reading device such as reading device 110.
  • method 200 is described by way of example with reference to an optical disc as the data storage medium 120.
  • Method 200 begins at step 210, in which digital media reader 150 determines the serial number or other unique identifier of the optical disc, either by reading it directly from the disc or by requesting a user to provide it via user interface 135.
  • data processor 160 receives the unique identifier from digital media reader 150, if read from data storage medium 120, or from user interface 135, and accesses a unique identifier of the reading device 110 stored in memory 170.
  • a unique identifier of data processor 160 may be provided instead of a unique identifier of reading device 110 as the basis for requesting the decryption code from code provider 130.
  • step 215 data processor 160 checks whether a decryption code corresponding to the serial number of the data storage medium 120 has previously been received and, if so, whether the decryption code remains valid.
  • step 220 if there is no decryption code stored for the particular data storage medium 120 being read, or if the stored code is no longer valid, data processor 160 provides the unique identifiers of the data storage medium 120 and reading device 100 (or data processor 160) to code provider 130 as part of a decryption key request. If data processor 160 is not in communication with code provider 130, the user is requested via user interface 135 to provide the unique identifiers to the code provider 130 in an alternative fashion, for example by telephone, and to retrieve a corresponding decryption code.
  • step 215 data processor 160 proceeds to process the encoded data stored on data storage medium 120 at step 280 to decrypt that data (according to the method described below in relation to Figure 3) using the stored decryption code and provide the decrypted data to data output destination 140.
  • data processor 160 preferably provides the unique identifiers in one or more data packets, which may be transmitted in encrypted form using, for example, a secure socket layer (SSL) protocol.
  • SSL secure socket layer
  • a use number indicative of the number of times the particular storage medium 120 has been the subject of a valid decryption key request, is checked at step 240, to determine whether the storage medium 120 has previously been validated (i.e. the subject of a granted decryption key request). If, at step 240, it is determined that the storage medium 120 has been previously validated, the code provider 130 then compares the use number with a use limit at step 250.
  • the storage medium If the use number is equal to the use limit, the storage medium
  • the use limit may be any number determined by the entity controlling code provider 130 (or a copyright owner or licensee of the encoded data, if not the same entity) to constitute a reasonable limit on the number of different users corresponding to normal use of the storage medium 120.
  • the use limit may be a low number, such as 2 or 3, while for an audio CD, the use limit may be higher, such as 20 to 100.
  • code provider 130 records the decryption key request, increments the use number and stores the unique identifier of the reading device 110 in the data record of the data storage medium 120, at step 270.
  • the code provider generates a decryption code, based on the unique identifiers of the data storage medium 120 and reading device 110 and sends the generated decryption code back to data processor 160, together with any relevant format information for the data processor 160 to determine how to decrypt the data encoded on data storage medium 120.
  • the decryption code and format information is preferably provided to data processor 160 in one or more packets, which are preferably encrypted.
  • Tables 3A and 3B may include data indicative of one or more of a key validity condition, a variable key, an encoding logic function and a checksum.
  • the format information may merely help the data processor 160 to determine that it has received the correct decryption code, for example, by checking the checksum, or it may be used to determine which logic functions to use in decrypting the stored data or how to determine the variable key (if used in the encoding process) necessary for decryption of the data.
  • the format information may specify different format codes corresponding to different formats. These format codes and the corresponding decryption formats are stored in memory 170 and are accessed by data processor 160 in response to receipt of the format information. The data processor 160 then uses the decryption formats corresponding to the specified format code when decoding the data on data storage medium 120. [0059] Once data processor 160 has received the decryption code and format information, it proceeds, at step 280, to process the data read from the data storage medium 120 using the applicable decryption format determined from the format information.
  • Method 300 begins with step 310, at which the decryption code, including format information, is retrieved, for example according to method 200.
  • the decryption code is checked by data processor 160 for validity, for example using the checksum provided with the format information. Alternatively, there may be a validity condition associated with the decryption code, such as a limited time period during which the code is valid. If the code is determined not to be valid at step 320, the user may be notified via user interface 135 at step 330.
  • data processor 160 instructs digital media reader 150 to read a block of encoded data from the data storage medium 120 into a first buffer in memory 170, at step 340.
  • the size of the data block read at step 340 may be the minimum block size used during the encoding. For example, if the data was encoded on a byte-by-byte basis, the encoded data blocks read at step 340 may be the size of a single byte. Alternatively, a multiple of the minimum block size may be read at step 340 so that a number of blocks are buffered together in the first buffer.
  • step 350 the quantity of data read into the first buffer at step
  • Step 350 processes each data block (of minimum block size) separately according to the first logic function and the processed blocks are sequentially stored in a second buffer in memory 170.
  • Each data block is then processed at step 360, using a second logic function and the decryption code to generate a decrypted block. If the blocks were originally encoded using a variable key, each decrypted block generated at step 360 is only partially decrypted and undergoes further processing at step 365. Step 365 involves processing the partially decrypted blocks using a third logic function and the variable key to generate fully decrypted blocks. The fully decrypted blocks are then sent, at step 370, to data output destination 140 by data processor 160. At step 380, the data processor 160 checks whether any more blocks can be read from the data storage medium 120 for processing. If there are more blocks to be processed, steps 340 to 370 are repeated.
  • the decryption process is determined by data processor 160 to be complete, at step 390.
  • the blocks, or a number of the blocks are read from the data storage medium 120 and processed in sequence.
  • all data blocks may be read from the data storage medium and stored in the second buffer according to steps 340 and 350, with steps 360 to 370 being performed after step 380, so that the entire data contents of the data storage medium 120 is stored in the second buffer and is then processed block-by-block according to steps 360 to 370.
  • the data may be processed on a block-by-block basis, requiring only a single block to be stored, if necessary, at each processing stage.
  • the first, second and third logic functions used in steps 350, 360 and 365, respectively, may be any suitable logic function for translating or transposing bits within the data block.
  • suitable logic functions may include, but are not limited to, the exclusive-OR (XOR) function, a hash function, addition, subtraction or bit shifting.
  • the first, second and third logic functions may be different or the same and may comprise combinations of functions.
  • step 365 is necessary in order to properly decode the data. If a variable key was used in the encoding, the format information received with the decryption code specifies the variable key that was used in the encoding. The format information received with the decryption code specifies the variable key format and a starting value so that the sequence of pseudo- random values making up the variable key can be reproduced.
  • variable key can be generated according to a seed value provided to a linear feedback shift register (LFSR) circuit within data processor 160.
  • LFSR linear feedback shift register
  • the sequence of pseudo-random values generated by the LFSR circuit in step 365 will be the same as those used in the encoding process, provided the same seed value is input into the LFSR circuit and the LFSR circuits on the encoding and decoding sides use the same tapping points.
  • alternative methods of repeatably generating a number sequence may be used, resulting in either a pseudo-random number sequence or a non- random number sequence.
  • the original encryption key used for the data storage medium 120 is never provided as such. Rather, the encryption key is used with the device specific key to generate, at code provider 130, a decryption key, which is then sent to data processor 160.
  • Table 1 The application of the keys, and the transformation of the data using the keys, is illustrated in Table 1 below, using example data and key values for a data block size of one byte.
  • Column 1 of Table 1 shows the original data prior to encryption, in hexadecimal and binary form.
  • Column 2 shows the data of column 1 after it has been passed through an XOR function with key A and then saved on the data storage medium 120.
  • Key A is the original encoding key, which is stored in the data record of the data storage medium 120 maintained in a database accessible to code provider 130.
  • Key A may be numerically related to the serial number of the data storage medium 120 or it may be a random key value allocated to the data storage medium 120 and associated with its serial number in the data record.
  • Table 1 Table 1 :
  • Column 3 shows the data of column 2 when read into a buffer of reading device 110 and processed with key B using an XOR function.
  • Key B is the unique identifier of the reading device 110 supplied to code provider 130 with the decryption key request.
  • Column 4 shows the data of column 3 processed with key C using an XOR logic function, thereby generating the original data of column 1.
  • Key C is the decryption key generated by code provider 130 from keys A and B using, in this example, an XOR logic function.
  • key C equals key A XOR key B.
  • the logic function used to generate key C from keys A and B may vary.
  • C f(A, B), where f() is a logic function (which may itself be comprised of a combination of logic functions).
  • Key C may then be used to obtain the original data using the logical inverse of f().
  • the original data is obtained using key C by applying an inverse of that function to the encoded data.
  • Method 400 begins at step 410, at which the data storage medium 120 is loaded into, or otherwise connected with, a writing device so that data can be written to the data storage medium 120.
  • Method 400 may, for example, be performed by code provider 130 or on behalf of the entity controlling code provider 130.
  • an encoding key is allocated to the data storage medium 120 and associated with the serial number or other unique identifier of the data storage medium 120, if the encoding key is not the same as the serial number or other unique identifier.
  • the data to be encoded on the data storage medium is allocated to the data storage medium 120 and associated with the serial number or other unique identifier of the data storage medium 120, if the encoding key is not the same as the serial number or other unique identifier.
  • This size may be, for example, one byte or an integer multiple thereof.
  • the block size may be a number of bits not divisible by 8.
  • each block of data is encoded using the encoding key allocated at step 420.
  • the bit length of the encoding key and data blocks are preferable the same.
  • Step 440 involves performing a logic function on each data block using the encoding key to generate an encoded block.
  • the logic function used in step 440 may any suitable logic function for which an inverse of the function can be used in decoding. Examples of suitable logic functions are described in relation to method 300 above.
  • a variable key may also be used to encode each block, at step 450.
  • the encoding key allocated at step 420 and used in step 440 may be a variable key.
  • the variable key is separate to the encoding key, which is according to one preferred embodiment, a fixed key.
  • step 450 includes generating a sequence of numbers, which may be pseudo-random numbers, for use in the encoding. For each data block to be encoded, it is subjected to a further logic function using one of the sequence of numbers constituting the variable key to generate an encoded block, which is then stored on the data storage medium 120 at step 460. If the variable key encoding is not used, the encoded data blocks generated from step 440 are stored on the data storage medium 120 at step 460.
  • the sequence of numbers constituting the variable key may be a repeating sequence and may be pseudo-random.
  • the variable key must be repeatable, so that the same sequence used in the encoding can be generated during the decoding process.
  • a starting value or seed value of the variable key is recorded together with the encoding key in the data record of the data storage medium 120.
  • the variable key may be generated using a LFSR circuit, such as is described and shown in U.S. application no. 11/350,839, using a particular seed value and having predetermined tapping points. In such a case, the configuration of the tapping points is also stored in the data record and transmitted with the seed value in the format information.
  • the unique identifier of the data storage medium is also written to the data storage medium 120 in an unencoded form, at step 470.
  • the unique identifier may be written to the start or end of the encoded data, using some form of data delimiter in order to separate the unique identifier from the encrypted data.
  • the unique identifier may be written to a part of the data storage medium 120 not normally used for storing bulk data, so that it is stored separately to the encrypted data.
  • System 500 is a more specific example of the system 100 shown in Figure 1 , particularly suitable for reading data stored on optical media, such as an optical disc 520.
  • System 500 includes a reading device 510 that is similar to reading device 110, but has an analog signal processor 555 interposed between the optical media reader 150 and data processor 160.
  • System 500 further includes an output device 540 for receiving data processed by reading device 510.
  • Reading device 150 may be, for example, a computer having an optical disc drive, a video game console, a digital video disc player or an audio compact disc player.
  • Output device 540 may be any suitable output device for receiving and processing the processed data from data processor 160, such as a computer processor, visual display and/or sound system.
  • optical media reader 150 converts the optical signals reflected from optical disc 520 into analog electrical signals
  • these analog signals are provided to analog signal processor 555, which converts the signals into a digital output to data processor 160.
  • Data processor 160 treats this digital output as the encoded data stored on optical disc 520 and processes it as described previously.
  • Data processor 160 controls optical media reader 150 to read the data stored on optical disc 520 according to known techniques.
  • optical media reader 150 and analog signal processor 555 read and process the data according to known techniques.
  • Output device 540 includes a digital signal processor 560 and a data output 580. If the output device 540 is a television or other visual display, for example, digital signal processor 560 will process the data stream output from data processor 160 and pass the processed data to data output 580 to display the video information. The form and function of digital signal processor
  • output device 540 which may be any one of a number of visual, audio, audio-visual or other device that is designed to receive and output or store the received data.
  • the data stream output from data processor 160 to digital signal processor 560 may be unencrypted.
  • the data output from data processor 160 may be encrypted. If such encryption is used, it may be based upon a simple encryption scheme using a key known to the data processor 160, such as a serial number of data processor 160.
  • data processor 160 may encode the data that it has decrypted from optical disc 520 using a new key, and send the encoded data to digital signal processor 560.
  • digital signal processor 560 In order for digital signal processor 560 to be able to decode the data from data processor 160, it must have received a decryption key corresponding (i.e.
  • data processor 160 transmits a decoding key to digital signal processor 560, which stores the key in memory (not shown).
  • the decoding key may be stored in the memory of digital signal processor 560 in a protected manner, such as is described in U.S. Utility Patent Application Serial No. 11/350,839.
  • digital signal processor 560 processes all incoming data using the decoding key. For this purpose, a simple logic function, such as an XOR or hash function, may be used, both at the data processor 160 during the encoding and at the digital signal processor 560 during the decoding.
  • the digital signal processor 560 may store the decoding key (which is the logical inverse of the encoding key) permanently or until it is rewritten by data processor 160, for example using a specific key write command. Digital signal processor 560 may only accept a key rewrite command that specifies the previous key, to authenticate the command. In one embodiment, the decoding key may be entered through a user interface (not shown) associated with digital signal processor 560.
  • the encoding of data transmitted by data processor 160 to output device 540 advantageously causes the output device 540 to only be able to read data from reading device 510.
  • reading device 510 is a DVD player
  • output device 540 is a television
  • This may serve as a disincentive to prospective thieves of televisions and other home entertainment equipment, including speakers.
  • Column 3 shows the original data encoded with the variable key value using an XOR function.
  • the data of column 3 is then further encoded with a fixed key (key A) using an XOR function and stored on the data storage medium 120 in the form shown in column 4.
  • Column 5 shows the data of column 4 as read by reading device 110 or 510, using key B, which is the unique identifier of the reading device 110 or 510.
  • the data of column 5 is processed using key C and an XOR function, to generate the intermediately decoded data shown in column 6.
  • the data of column 6 is then processed using the variable key values of column 2 and an XOR function to generate the fully decoded data shown in column 7, which is the same as the original data shown in column 1.
  • the logic functions used in this example are all XOR functions, it should be understood that other suitable functions may be used in the encoding and decoding processes, providing the encoding logic functions have suitable inverse functions for the decoding process.
  • Tables 2A and 2B show an example of data encoding and decoding using a fixed key in combination with a variable key, alternative embodiments may use only a variable key or may use two or more fixed or variable keys instead of a combination.
  • Tables 3A and 3B below examples of format information comprised in the decryption code are illustrated.
  • examples of format information are shown, as examples 1 and 2, for the case where the format information includes a key lifetime value, for example as a number of hours.
  • the lifetime value indicates the time during which the decryption key transmitted with the format information is valid. Once the key lifetime expires, the decryption key becomes unusable by reading device 110 or 510.
  • the format information includes a validation checksum for checking whether the encryption key and format information may have been corrupted, for example during transmission from the code provider 130.
  • the format information includes a key format code, which the reading device 110 or 510 uses to determine (according to a stored reference table in memory 170) which logic functions and decoding methods to use and the decoding process.
  • the key format code may specify a format that uses a combination of XOR functions and hash functions and specifies that an LFSR circuit is to be used to generate a pseudo-random number sequence based on a seed value transmitted with the format information.
  • the key format code may specify a format that does not employ variable key decoding or that does not specify a key lifetime. Accordingly, the key format code will dictate whether the variable key seed value or key lifetime value is necessary for the decoding process.
  • Examples 3 and 4 where the format information includes a specified validity period of the decryption key, including a start and end date during which the decryption key is valid.
  • the format information in these examples also includes a validation checksum, a format code and a seed value.
  • the data block size may be varied in the encoding process. For example, a pseudo-random or non-random number sequence may be used to determine the block size of each data block. If the number sequence is pseudo-random, an LFSR circuit may be used to generate the number sequence. During decoding, the same pseudo-random or non- random number sequence is used to determine the data block size. If the encoding process used varying data block sizes, this is indicated by the format code transmitted with the decryption code and the format information includes a seed value for generating the appropriate number sequence. [00100] Embodiments are described above in relation to the Figures and Tables. It should be understood that these embodiments are provided by way of example only and that some variation or modification of the features and/or elements of the embodiments may be made without departing from the spirit and scope of the described embodiments, and all such variations and beneficiations are included within that scope.

Abstract

Described embodiments generally relate to methods of encoding data on a data storage medium and methods of decoding and reading such encoded data. Other aspects relate to systems or apparatus for performing these methods. Still other aspects relate to systems and methods for monitoring use of data recorded on data storage media. These aspects are particularly suited to protecting proprietary data against unauthorized or excessive copying, where the proprietary data is embodied on a data storage medium that is publicly available for rent or sale.

Description

Title: METHOD AND SYSTEM FOR DATA SECURITY OF RECORDING
MEDIA
Technical Field [0001] The described embodiments relate to a method and system for providing improved data security for recording media. In particular, the invention relates to a method and system for providing improved encryption of data stored on recording media and for monitoring use of the stored data.
Background [0002] Certain data storage products, for example, such as optical media like compact discs (CDs) or digital video discs (DVDs), may contain data which is subject to copyright and it is therefore desirable to prevent unauthorized copying of such data. Conventional data protection measures are used in relation to some CDs or DVDs in an attempt to prevent unauthorized copying. [0003] One example of such conventional protection measures is to add a secure sector to the optical disc that cannot be copied by normal CD/DVD writers. This secure sector contains information that will enable the disk to be read. Thus, unless the secure sector is also copied to the new disc, the new disc cannot be read. This protection technique will only be effective as long as the secure sector is not rewritable by available CD or DVD copiers. Similar problems may be encountered in protecting computer program instructions stored on data storage media.
[0004] Further, it is known to store data on recording media using data delimiters to identify sectors and blocks of data within which the payload data are stored. Such sectors and blocks use data delimiters in order to indicate to the reading device the start and end of a block or sector. If only the payload data is encrypted, a prospective copier can still use the data delimiters to readily identify the location of the payload data on the storage medium, which may assist the copier to decrypt the payload data. [0005] It is desired to address or ameliorate one or more shortcomings or disadvantages associated with prior data security methods or systems for data storage media, or to at least provide a useful alternative to such prior methods or systems.
Summary
[0006] Described embodiments generally relate to methods of encoding data on a data storage medium and methods of decoding and reading such encoded data. Other aspects relate to systems or apparatus for performing these methods. Still other aspects relate to systems and methods for monitoring use of data recorded on data storage media. These aspects are particularly suited to protecting proprietary data against unauthorized or excessive copying, where the proprietary data is embodied on a data storage medium that is publicly available for rent or sale.
[0007] In one aspect, embodiments relate to a method of encoding data on a data storage medium. The method comprises the steps of: receiving a quantity of data to be stored on a data storage medium, the quantity of data including payload data and data delimiters; determining a unique identifier of the data storage medium; allocating an encoding key to the data storage medium, the encoding key being associated with the unique identifier; dividing the quantity of data into a plurality of data blocks of a predetermined size; encoding each data block using the encoding key to generate an encoded data block of the predetermined size; and storing all encoded data blocks on the data storage medium so that the quantity of data is stored on the data storage medium in encoded form.
[0008] The method may further include writing the unique identifier to the data storage medium, either in encoded or unencoded form. [0009] The data storage medium may be an optical recording medium, such as an optical disc. The optical disc may be used for storage of audio and/or video data, for example. Alternatively, the optical disc may store other kinds of data, such as generic or specific data files or software program instructions. Other forms of data storage may be used, providing they can be written to at least once and can be read by a reading device. [0010] The unique identifier may be a serial number of the optical recording medium. The step of determining may include reading the serial number from the optical recording medium. The encoding may include performing a logic operation on each data block, where the encoding key and the data block are operands of the logic operation. The encoding key may be a fixed key. Alternatively, the encoding key may be a variable key.
[0011] A variable key may be used to further encode the data blocks without further altering the predetermined size of the data blocks. The variable key encoding may be performed before or after the fixed key encoding. The variable key may vary for each data block. The variable key may depend, for example, on the location of the data block on the data storage medium. In another example, the variable key may be determined based on the fixed key or the unique identifier. The variable key may be determined from a series of numbers, optionally pseudo-random or random numbers, based on the fixed key or the unique identifier.
[0012] Another aspect relates to a data storage medium storing data encoded according to the method described above.
[0013] In another aspect, embodiments relate to a method of decoding encoded data stored on a data storage medium. The encoded data includes payload data and data delimiters. The method comprises:
a) providing a reading device for reading the data storage medium;
b) determining a first unique identifier of the data storage medium;
c) determining a second unique identifier of the reading device;
d) providing the first and second unique identifiers to a validation entity;
e) receiving a decryption code from the validation entity in response to step d); - A -
f) reading the encoded data from the data storage medium; and
g) decoding the encoded data in data blocks of a predetermined size using the decryption code to generate decoded data blocks.
[0014] The method may further comprise buffering a plurality of the decoded data blocks, determining the payload data in the decoded data blocks based on the data delimiters and processing the payload data. Step f) may further comprise processing the encoded data using a first logic function and a first key specific to the reading device to generate intermediate encoded data.
In such an embodiment, step g) may further comprise processing the intermediate encoded data using a second logic function and the encryption code to generate the decoded data blocks.
[0015] The first unique identifier may be, or be derived from, a serial number of the data storage medium and step b) may include reading the serial number from the data storage medium. The data storage medium may be an optical recording medium, such as an optical disc or any other kind of data storage medium.
[0016] The decryption code may be a fixed code. Alternatively, the decryption code may be a variable code. If the decryption code is a variable code, it may vary for each data block. [0017] In another aspect of the decoding method, the data storage medium may be replaced with another data source, such as a data stream transmitted from another device.
[0018] A further aspect relates to a method of monitoring use of data stored on a data storage medium. The data is stored on a data storage medium using an encoding key and the data storage medium has a unique identifier. The method comprises the steps of: receiving a decryption key request from a data reading entity in relation to the data storage medium, the decryption key request including a reading device identifier and the unique identifier; determining a use number of the data storage medium based on the unique identifier; comparing the use number with a predetermined use limit of the data storage medium; and incrementing the use number if the use number is less than the predetermined use limit.
[0019] The method may further comprise storing the reading device identifier with the use number in a use record for the data storage medium. The method may further comprise the steps of: determining the encoding key based on the unique identifier; generating a decryption key based on the encoding key and the reading device identifier; and transmitting the decryption key to the data reading entity in response to the decryption key request.
[0020] The decryption key may be generated as an output of a logic function, where the encoding key and the reading device identifier are operands of the logic function. The unique identifier may be, or be derived from, a serial number of the data storage medium.
[0021] Embodiments may provide improved data security for data stored on data storage media, such as software, audio data on compact discs (CDs) and video data on digital video discs (DVDs), by encoding the data stored on the storage media with an encryption key that is known only to the entity that stores the data on the recording media. When a customer has purchased an encoded recording medium, for example, to play the audio and/or video files or read the software programs that are stored thereon, the customer must obtain a decryption key before being able to read the recording medium with the reading device. This may be done automatically by the reading device but may alternatively be done manually, for example, by telephone or by accessing a secure site over the Internet using a browser application.
[0022] The decryption key is only received from the validation entity in response to provision of a serial number of the device attempting to read the storage medium and an identifier of the storage medium itself. The decryption key is not the same as the encryption key. Rather, the decryption key is specific to the recording medium and the device reading the recording medium. Use of a variable key instead of, or in addition to, the fixed key advantageously provides for further improved security. If a variable key is used in the encoding, a corresponding variable key is used in the decryption process. [0023] Because all of the bits on the recording medium are encoded, including data delimiters, it is not possible for prospective copiers to identify the beginning or end of the payload data when it is copied. Even if the recording medium is copied, it may not be readable because the data delimiters would not be apparent to the reading device.
[0024] Further, according to certain embodiments, the encoded data is read from the storage medium and is conditioned using a logic function to generate intermediate encoded data. However, this intermediate encoded data can not be decoded without receiving a decryption key from the validation entity. Thus, while a prospective copier may read the data stored on the storage medium, if the copier tries to generate a meaningful output from the intermediate encoded data, such output would only appear as noise. The decryption key provided by the validation entity in order to decrypt the intermediate encoded data is specific to the recording medium and to the reading device. The same key cannot be used to decrypt another recording medium which has the same original data stored on it as each recording medium uses a different encoding key. Similarly, the same key will not be valid for a different reading device.
[0025] A further aspect relates to a data processing device for an encrypted data storage medium. The data processing device comprises reading means for reading encrypted data stored on the data storage medium and a processor. The processor is in communication with the reading means for processing the encrypted data and controls the reading means. The processor has means for determining a first unique identifier of the data processing device and a second unique identifier of the data storage medium, and means for receiving a decryption code generated by a code provider based on the first and second unique identifiers. The processor is configured to decrypt the encrypted data based on the decryption code.
Brief description of the drawings [0026] Embodiments are hereinafter described in further detail, by way of example only, with reference to the accompanying drawings, in which: [0027] Figure 1 is a block diagram of a system for reading encoded recording media;
[0028] Figure 2 is a process flow diagram of a method of obtaining a decryption key for decrypting encrypted data stored on data storage media; [0029] Figure 3 is a process flow diagram of a method of decrypting encrypted data stored on data storage media;
[0030] Figure 4 is a process flow diagram of a method of encrypting data and storing the data on data storage media; and
[0031] Figure 5 is a block diagram of a system for reading encoded recording media.
Detailed description
[0032] The described embodiments are suited to encoding data to be stored on data storage media, such as software, audio or video data, which, due to their vulnerability to piracy, require increased data security in order to limit or prevent unauthorized copying. For the purpose of illustration, some embodiments may be described with reference to an optical disc, as one example of data storage media. It should be understood, however, that the described embodiments may be applied to other forms of data storage media. Further, the encoding and decoding methods described herein may be employed alone or in combination with other encryption and decryption methods, such as may be known to persons skilled in the art.
[0033] The terms "encrypt" and "encode" and respective variations thereof are used interchangeably in this description. Similarly, the terms "decrypt" and "decode" and their variations are also used interchangeably. [0034] Referring now to the drawings, Figure 1 is described in further detail. Figure 1 is a block diagram of a system 100 for reading encoded recording media. The system 100 includes a reading device 110, such as an optical disc reader, a data storage medium 120, such as a compact disc or other form of rewritable non-volatile storage medium, and a code provider 130 located remotely from reading device 110. Reading device 110 has associated therewith a data output destination 140, which may be, for example, a computer processor or digital signal processor. For audio or video data, the digital signal processor may be in a television or other display having audio and video display capabilities in order that a customer can see and/or hear video and/or audio signals corresponding to the data stored on the data storage medium 120. The data output destination 140 may be any suitably secure data processing device.
[0035] Reading device 110 comprises a digital media reader 150 and a data processor 160. The digital media reader 150 is controlled by data processor 160 to read the data encoded on data storage medium 120 according to conventional means and provides the encoded data thus read to data processor 160 for decryption and processing according to its data type. As all of the data (including payload data and data delimiters) stored on data storage medium 120 is encoded, it must be read in blocks of one or more bytes and provided to data processor 160 for decryption before it can be processed and provided to data output destination 140.
[0036] Although all of the data stored on the data storage medium 120 is encoded, a serial number or other unique identifier of the data storage medium 120 is also stored thereon. The unique identifier is preferably unencoded, although it may alternatively be encoded. The unique identifier may be stored in a particular location on digital recoding medium 120, for example at the very beginning or end of the encoded data or in a special location, such as the inner circle of the disc, separate from the encoded data. In one embodiment, the unique identifier is readily readable by digital media reader 150. In an alternative embodiment, the unique identifier may be recorded on the data storage medium 120 so as to be visible to a person so that the person can manually enter the unique identifier through a user interface 135.
[0037] Data storage medium 120 may be of any suitable kind for storing data, including optical storage media, volatile and non-volatile memory devices, magnetic data storage media or any other mechanical, chemical, electrical or physical means of storing data, providing there is a suitable reading device, such as digital media reader 150, for reading the stored data. Specific examples of data storage medium 120 include optical discs, digital audio tapes (DATs) and memory cards or sticks. Embodiments of the invention are particularly useful in protecting data stored (pre-recorded) on commercially available data storage products. [0038] In an alternative embodiment, data storage medium 120 may be replaced by a data source, such as a streaming or other data source. In one sense, data storage medium 120 may be generalized as one form of data source. In this context, the origin or form of storage of the data source is unimportant to the data processor 160, so long as data processor 160 can identify a unique identifier of the data source (to obtain the decryption code) and can process the data according to the format information in the decryption code.
[0039] Data processor 160 may be any suitable data processor having a speed and operating capacity to perform a series of logical operations in quick succession. For example, data processor 160 may have a data throughput efficiency suitable for handling data quantities in the order of several megabytes to several gigabytes.
[0040] Reading device 110 further comprises a memory 170, which may include flash memory or other read-only memory (ROM) and random access memory (RAM). As will be described in further detail below, memory 170 may store information on predetermined data formats and logic operations that may be used in the encoding and decoding. Memory 170 may be distinct from data processor 160, as shown in Figure 1 , or it may form a part of the architecture of data processor 160. The serial number or other unique identifier of the reading device 110 or data processor 160 (or both) is stored in memory 170. Alternatively, the serial number or other unique identifier may be stored in a memory internal to data processor 160, if memory 170 is separate from data processor 160.
[0041] Memory 170 may be encrypted (and decrypted) according to the methods described in co-owned and co-pending United States Utility Patent Application Serial No. 11/350,839, filed February 10, 2006, entitled "Method and System for Microprocessor Data Security", the entire contents of which is hereby incorporated by reference.
[0042] System 100 further includes a user interface 135 in communication with data processor 160, either as part of a user interface provided by a device housing reading device 110 and operably associated therewith, or as a separate interface device, such as a remote control. If reading device 110 is part of a computer, such as a personal computer (PC) or server system, user interface 135 may be any known form of user interface, including, for example, a keyboard, mouse, display screen or other peripheral, allowing a user of the system 100 to interface with the reading device 110. Alternatively, depending on the form in which reading device 110 is embodied, user interface 135 may include other interface means, such as a small keypad and display, remote control or a two-way speech synthesizer.
[0043] Code provider 130 is preferably in communication with data processor 160 over a network, such as the Internet, where the reading device 110, or a host device housing reading device 110, is in connection with the network, either through a wired or wireless connection.
[0044] Code provider 130 is located remotely from reading device 110 and may be a computer system controlled by an entity responsible for monitoring use of the data storage medium 120 and for receiving requests for a decryption key to decrypt data stored on data storage media, such as data storage media 120. Code provider 130 also records the requests and the unique identifiers identified in the requests and thereby monitors the level of use of the data storage media 120. [0045] Code provider 130 may allow fully automated data exchange with data processor 160. Alternatively, code provider 130 may accept decryption key requests through a form on a web page, an automated voice response (AVR) system or a call center operator, for example, and reply with the decryption key accordingly. [0046] In response to requests for decryption keys, code provider 130 generates a decryption key based on the information provided in the request and transmits the decryption code, including a decryption key and any other relevant information for assisting decryption, to reading device 110. However, if the code provider 130 determines that the decryption code should not be provided in response to the request (as described below in relation to Figure 2), code provider 130 transmits a notification to this effect to the user for display to the user through user interface 135.
[0047] In one embodiment, when the code provider 130 provides the decryption code to reading device 110, the decryption code has an expiry date associated therewith. Whether or not the decryption code has an expiry date, the decryption code is stored in memory 170 for subsequent use when decrypting the data encoded on data storage medium 120. The contents of the decryption code provided by code provider 130 is described in further detail below in relation to Tables 3A and 3B.
[0048] In one embodiment, a third party, such as a DVD (or other data) rental business, may request a time-limited decryption code from code provider 130 and the third party can then provide the received decryption code to the consumer, for example on a printed sheet, such as the rental receipt. This would require the consumer or rental business to provide the serial number or other identifier of reading device 110 when renting the DVD (or other data) so that the code provider 130 can generate an appropriate decryption code in response.
[0049] Referring now to Figure 2, a method of obtaining a decryption key for decrypting encoded data stored on data storage media is described, the method being designated by reference indicator 200. Method 200 assumes that a data storage medium (encoded according to an embodiment of the invention, such as that described in relation to Figure 4) has been inserted into a reading device, such as reading device 110. For purposes of illustration, method 200 is described by way of example with reference to an optical disc as the data storage medium 120. [0050] Method 200 begins at step 210, in which digital media reader 150 determines the serial number or other unique identifier of the optical disc, either by reading it directly from the disc or by requesting a user to provide it via user interface 135. At this step, data processor 160 receives the unique identifier from digital media reader 150, if read from data storage medium 120, or from user interface 135, and accesses a unique identifier of the reading device 110 stored in memory 170. In an alternative embodiment, a unique identifier of data processor 160 may be provided instead of a unique identifier of reading device 110 as the basis for requesting the decryption code from code provider 130. [0051] In step 215, data processor 160 checks whether a decryption code corresponding to the serial number of the data storage medium 120 has previously been received and, if so, whether the decryption code remains valid.
[0052] At step 220, if there is no decryption code stored for the particular data storage medium 120 being read, or if the stored code is no longer valid, data processor 160 provides the unique identifiers of the data storage medium 120 and reading device 100 (or data processor 160) to code provider 130 as part of a decryption key request. If data processor 160 is not in communication with code provider 130, the user is requested via user interface 135 to provide the unique identifiers to the code provider 130 in an alternative fashion, for example by telephone, and to retrieve a corresponding decryption code. If a valid decryption code is stored in memory 170, then following step 215 data processor 160 proceeds to process the encoded data stored on data storage medium 120 at step 280 to decrypt that data (according to the method described below in relation to Figure 3) using the stored decryption code and provide the decrypted data to data output destination 140.
[0053] In step 220, data processor 160 preferably provides the unique identifiers in one or more data packets, which may be transmitted in encrypted form using, for example, a secure socket layer (SSL) protocol. Once code provider 130 receives the encryption key request packet, it parses the packet at step 230 to determine the unique identifiers of the storage medium 120 and reading device 100. Code provider 130 then uses the storage medium unique identifier to try to find a corresponding data record of the storage medium 120.
[0054] Once the data record for the storage medium 120 is located in a database (not shown) of the code provider 130, a use number, indicative of the number of times the particular storage medium 120 has been the subject of a valid decryption key request, is checked at step 240, to determine whether the storage medium 120 has previously been validated (i.e. the subject of a granted decryption key request). If, at step 240, it is determined that the storage medium 120 has been previously validated, the code provider 130 then compares the use number with a use limit at step 250.
[0055] If the use number is equal to the use limit, the storage medium
120 is determined to have been used its maximum number of times (i.e. by a maximum number of unique users) and the user is notified, at step 260, of the use limit by transmission of a return packet to data processor 160. The use limit may be any number determined by the entity controlling code provider 130 (or a copyright owner or licensee of the encoded data, if not the same entity) to constitute a reasonable limit on the number of different users corresponding to normal use of the storage medium 120. For example, for valuable software, the use limit may be a low number, such as 2 or 3, while for an audio CD, the use limit may be higher, such as 20 to 100.
[0056] If the storage medium 120 had not been previously validated or if the use limit has not been met, code provider 130 records the decryption key request, increments the use number and stores the unique identifier of the reading device 110 in the data record of the data storage medium 120, at step 270. As part of step 270, the code provider generates a decryption code, based on the unique identifiers of the data storage medium 120 and reading device 110 and sends the generated decryption code back to data processor 160, together with any relevant format information for the data processor 160 to determine how to decrypt the data encoded on data storage medium 120. The decryption code and format information is preferably provided to data processor 160 in one or more packets, which are preferably encrypted. [0057] The format information, as will be described further in relation to
Tables 3A and 3B, may include data indicative of one or more of a key validity condition, a variable key, an encoding logic function and a checksum. The format information may merely help the data processor 160 to determine that it has received the correct decryption code, for example, by checking the checksum, or it may be used to determine which logic functions to use in decrypting the stored data or how to determine the variable key (if used in the encoding process) necessary for decryption of the data.
[0058] The format information may specify different format codes corresponding to different formats. These format codes and the corresponding decryption formats are stored in memory 170 and are accessed by data processor 160 in response to receipt of the format information. The data processor 160 then uses the decryption formats corresponding to the specified format code when decoding the data on data storage medium 120. [0059] Once data processor 160 has received the decryption code and format information, it proceeds, at step 280, to process the data read from the data storage medium 120 using the applicable decryption format determined from the format information.
[0060] Referring now to Figure 3, there is shown a process flow diagram of a method of decrypting encrypted data stored on a data storage medium, the method being designated generally by reference numeral 300. Method 300 begins with step 310, at which the decryption code, including format information, is retrieved, for example according to method 200. At step 320, the decryption code is checked by data processor 160 for validity, for example using the checksum provided with the format information. Alternatively, there may be a validity condition associated with the decryption code, such as a limited time period during which the code is valid. If the code is determined not to be valid at step 320, the user may be notified via user interface 135 at step 330.
[0061] If the decryption code is determined to be valid, data processor 160 instructs digital media reader 150 to read a block of encoded data from the data storage medium 120 into a first buffer in memory 170, at step 340. The size of the data block read at step 340 may be the minimum block size used during the encoding. For example, if the data was encoded on a byte-by-byte basis, the encoded data blocks read at step 340 may be the size of a single byte. Alternatively, a multiple of the minimum block size may be read at step 340 so that a number of blocks are buffered together in the first buffer.
[0062] At step 350, the quantity of data read into the first buffer at step
340 is processed using a first logic function and a key specific to the reading device 100, which may be the unique identifier of the reading device 100. The key used in step 350 must be the same number or code as the unique identifier provided to the code provider 130 at step 220. Step 350 processes each data block (of minimum block size) separately according to the first logic function and the processed blocks are sequentially stored in a second buffer in memory 170.
[0063] Each data block is then processed at step 360, using a second logic function and the decryption code to generate a decrypted block. If the blocks were originally encoded using a variable key, each decrypted block generated at step 360 is only partially decrypted and undergoes further processing at step 365. Step 365 involves processing the partially decrypted blocks using a third logic function and the variable key to generate fully decrypted blocks. The fully decrypted blocks are then sent, at step 370, to data output destination 140 by data processor 160. At step 380, the data processor 160 checks whether any more blocks can be read from the data storage medium 120 for processing. If there are more blocks to be processed, steps 340 to 370 are repeated. Otherwise, the decryption process is determined by data processor 160 to be complete, at step 390. [0064] In the above described embodiment, the blocks, or a number of the blocks, are read from the data storage medium 120 and processed in sequence. Alternatively, all data blocks may be read from the data storage medium and stored in the second buffer according to steps 340 and 350, with steps 360 to 370 being performed after step 380, so that the entire data contents of the data storage medium 120 is stored in the second buffer and is then processed block-by-block according to steps 360 to 370. In a further alternative, the data may be processed on a block-by-block basis, requiring only a single block to be stored, if necessary, at each processing stage.
[0065] The first, second and third logic functions used in steps 350, 360 and 365, respectively, may be any suitable logic function for translating or transposing bits within the data block. Such suitable logic functions may include, but are not limited to, the exclusive-OR (XOR) function, a hash function, addition, subtraction or bit shifting. The first, second and third logic functions may be different or the same and may comprise combinations of functions.
[0066] If a variable key was used in the encoding of data onto data storage medium 120, then step 365 is necessary in order to properly decode the data. If a variable key was used in the encoding, the format information received with the decryption code specifies the variable key that was used in the encoding. The format information received with the decryption code specifies the variable key format and a starting value so that the sequence of pseudo- random values making up the variable key can be reproduced.
[0067] In one embodiment, the variable key can be generated according to a seed value provided to a linear feedback shift register (LFSR) circuit within data processor 160. The sequence of pseudo-random values generated by the LFSR circuit in step 365 will be the same as those used in the encoding process, provided the same seed value is input into the LFSR circuit and the LFSR circuits on the encoding and decoding sides use the same tapping points. Instead of using an LFSR circuit to generate a pseudo-random number sequence, alternative methods of repeatably generating a number sequence may be used, resulting in either a pseudo-random number sequence or a non- random number sequence.
[0068] By reading the data from data storage medium 120 into a buffer and processing it using a key specific to the reading device 110 (such as its unique identifier), and receiving a decryption key from code provider 130 that is derived from the original encoding key used for the particular data storage medium 120 and a key specific to the reading device 100, the original encryption key used for the data storage medium 120 is never provided as such. Rather, the encryption key is used with the device specific key to generate, at code provider 130, a decryption key, which is then sent to data processor 160.
[0069] The application of the keys, and the transformation of the data using the keys, is illustrated in Table 1 below, using example data and key values for a data block size of one byte. Column 1 of Table 1 shows the original data prior to encryption, in hexadecimal and binary form. Column 2 shows the data of column 1 after it has been passed through an XOR function with key A and then saved on the data storage medium 120. Key A is the original encoding key, which is stored in the data record of the data storage medium 120 maintained in a database accessible to code provider 130. Key A may be numerically related to the serial number of the data storage medium 120 or it may be a random key value allocated to the data storage medium 120 and associated with its serial number in the data record. [0070] Table 1 :
Figure imgf000018_0001
Figure imgf000019_0001
COLUMN 1 COLUMN 2 COLUMN 3 COLUMN 4
[0071] Column 3 shows the data of column 2 when read into a buffer of reading device 110 and processed with key B using an XOR function. Key B is the unique identifier of the reading device 110 supplied to code provider 130 with the decryption key request. Column 4 shows the data of column 3 processed with key C using an XOR logic function, thereby generating the original data of column 1. Key C is the decryption key generated by code provider 130 from keys A and B using, in this example, an XOR logic function. Thus, in this example, key C equals key A XOR key B. Depending on the logic functions used in the encryption, the logic function used to generate key C from keys A and B may vary. This relationship may be generalized as C = f(A, B), where f() is a logic function (which may itself be comprised of a combination of logic functions). Key C may then be used to obtain the original data using the logical inverse of f(). In other words, if the data encoded using keys A and B is a function of the original data, the original data is obtained using key C by applying an inverse of that function to the encoded data.
[0072] Referring now to Figure 4, a method of encoding a data storage medium is described in further detail and designated generally by reference numeral 400. Method 400 begins at step 410, at which the data storage medium 120 is loaded into, or otherwise connected with, a writing device so that data can be written to the data storage medium 120. Method 400 may, for example, be performed by code provider 130 or on behalf of the entity controlling code provider 130.
[0073] At step 420, an encoding key is allocated to the data storage medium 120 and associated with the serial number or other unique identifier of the data storage medium 120, if the encoding key is not the same as the serial number or other unique identifier. [0074] At step 430, the data to be encoded on the data storage medium
120 is divided into blocks of a predetermined size. This size may be, for example, one byte or an integer multiple thereof. Alternatively, the block size may be a number of bits not divisible by 8.
[0075] At step 440, each block of data is encoded using the encoding key allocated at step 420. The bit length of the encoding key and data blocks are preferable the same. Step 440 involves performing a logic function on each data block using the encoding key to generate an encoded block. The logic function used in step 440 may any suitable logic function for which an inverse of the function can be used in decoding. Examples of suitable logic functions are described in relation to method 300 above.
[0076] Optionally, a variable key may also be used to encode each block, at step 450. In one embodiment, the encoding key allocated at step 420 and used in step 440 may be a variable key. However, in the embodiment of method 400 shown in Figure 4, the variable key is separate to the encoding key, which is according to one preferred embodiment, a fixed key. If the encoding also uses a variable key, step 450 includes generating a sequence of numbers, which may be pseudo-random numbers, for use in the encoding. For each data block to be encoded, it is subjected to a further logic function using one of the sequence of numbers constituting the variable key to generate an encoded block, which is then stored on the data storage medium 120 at step 460. If the variable key encoding is not used, the encoded data blocks generated from step 440 are stored on the data storage medium 120 at step 460.
[0077] The sequence of numbers constituting the variable key may be a repeating sequence and may be pseudo-random. Importantly, the variable key must be repeatable, so that the same sequence used in the encoding can be generated during the decoding process. For this purpose, a starting value or seed value of the variable key is recorded together with the encoding key in the data record of the data storage medium 120. In one embodiment, the variable key may be generated using a LFSR circuit, such as is described and shown in U.S. application no. 11/350,839, using a particular seed value and having predetermined tapping points. In such a case, the configuration of the tapping points is also stored in the data record and transmitted with the seed value in the format information.
[0078] Once the encoded data blocks are stored on data storage medium 120, the unique identifier of the data storage medium is also written to the data storage medium 120 in an unencoded form, at step 470. For example, the unique identifier may be written to the start or end of the encoded data, using some form of data delimiter in order to separate the unique identifier from the encrypted data. Alternatively, the unique identifier may be written to a part of the data storage medium 120 not normally used for storing bulk data, so that it is stored separately to the encrypted data.
[0079] Referring now to Figure 5, there is shown a block diagram of a system for reading encoded recording media according to another embodiment, designated generally by reference numeral 500. System 500 is a more specific example of the system 100 shown in Figure 1 , particularly suitable for reading data stored on optical media, such as an optical disc 520.
[0080] System 500 includes a reading device 510 that is similar to reading device 110, but has an analog signal processor 555 interposed between the optical media reader 150 and data processor 160. System 500 further includes an output device 540 for receiving data processed by reading device 510. Reading device 150 may be, for example, a computer having an optical disc drive, a video game console, a digital video disc player or an audio compact disc player. Output device 540 may be any suitable output device for receiving and processing the processed data from data processor 160, such as a computer processor, visual display and/or sound system. [0081] In reading device 510, once optical media reader 150 converts the optical signals reflected from optical disc 520 into analog electrical signals, these analog signals are provided to analog signal processor 555, which converts the signals into a digital output to data processor 160. Data processor 160 treats this digital output as the encoded data stored on optical disc 520 and processes it as described previously. Data processor 160 controls optical media reader 150 to read the data stored on optical disc 520 according to known techniques. Similarly, optical media reader 150 and analog signal processor 555 read and process the data according to known techniques.
[0082] Output device 540 includes a digital signal processor 560 and a data output 580. If the output device 540 is a television or other visual display, for example, digital signal processor 560 will process the data stream output from data processor 160 and pass the processed data to data output 580 to display the video information. The form and function of digital signal processor
560 and data output 580 will depend on the form and function of output device 540, which may be any one of a number of visual, audio, audio-visual or other device that is designed to receive and output or store the received data.
[0083] In one embodiment of system 500, the data stream output from data processor 160 to digital signal processor 560 may be unencrypted. In an alternative embodiment of system 500, the data output from data processor 160 may be encrypted. If such encryption is used, it may be based upon a simple encryption scheme using a key known to the data processor 160, such as a serial number of data processor 160. For example, data processor 160 may encode the data that it has decrypted from optical disc 520 using a new key, and send the encoded data to digital signal processor 560. [0084] In order for digital signal processor 560 to be able to decode the data from data processor 160, it must have received a decryption key corresponding (i.e. as a logical inverse) to the encryption key used by data processor 160 to encode the data. Accordingly, prior to transmitting the encoded data, data processor 160 transmits a decoding key to digital signal processor 560, which stores the key in memory (not shown). [0085] The decoding key may be stored in the memory of digital signal processor 560 in a protected manner, such as is described in U.S. Utility Patent Application Serial No. 11/350,839. Subsequent to receipt of the decoding key from data processor 160, digital signal processor 560 processes all incoming data using the decoding key. For this purpose, a simple logic function, such as an XOR or hash function, may be used, both at the data processor 160 during the encoding and at the digital signal processor 560 during the decoding. The digital signal processor 560 may store the decoding key (which is the logical inverse of the encoding key) permanently or until it is rewritten by data processor 160, for example using a specific key write command. Digital signal processor 560 may only accept a key rewrite command that specifies the previous key, to authenticate the command. In one embodiment, the decoding key may be entered through a user interface (not shown) associated with digital signal processor 560.
[0086] The encoding of data transmitted by data processor 160 to output device 540 advantageously causes the output device 540 to only be able to read data from reading device 510. In the example where reading device 510 is a DVD player and output device 540 is a television, this would have the effect that, if the television is stolen, it cannot be used by any DVD player other than that which uses the correct encoding key in transmitting its output signal to the television, thereby thwarting one possible purpose of the theft. This may serve as a disincentive to prospective thieves of televisions and other home entertainment equipment, including speakers.
[0087] Apart from the differences described above in relation to Figure
500, memory 170, data processor 160, optical media reader 150, user interface 135 and code provider 130 operate in a similar manner to that described in relation to system 100 in Figure 1. [0088] With reference to Tables 2A and 2B below, encryption and decryption of data to and from data storage medium 120 or optical disc 520 using a variable key is described in further detail. As with column 1 of Table 1 , column 1 in Table 2A shows the original data, prior to being encoded. Each of the columns of Tables 1 , 2A and 2B show the data in hexadecimal form, as well as in binary form, using an example data block size of one byte for illustrative purposes. The keys used in the encryption and decryption are also one byte in the illustrated examples. The encryption and decryption keys are preferably, although not necessarily, the same size as the data blocks. It should be understood that the size of the data blocks and keys may vary depending on the requirements.
[0089] Table 2A:
Figure imgf000024_0001
Figure imgf000025_0001
COLUMN 1 COLUMN 2 COLUMN 3 COLUMN 4
[0090] Table 2B:
Figure imgf000025_0002
Figure imgf000026_0001
COLUMN 5 COLUMN 6 COLUMN 7
[0091] Column 2 of Table 2A shows a variable key generated by an
LFSR circuit, based on an example seed value of 8 and a particular tapping configuration. Column 3 shows the original data encoded with the variable key value using an XOR function. The data of column 3 is then further encoded with a fixed key (key A) using an XOR function and stored on the data storage medium 120 in the form shown in column 4.
[0092] Column 5 (Table 2B) shows the data of column 4 as read by reading device 110 or 510, using key B, which is the unique identifier of the reading device 110 or 510. Once the decoding key C is received from code provider 130, the data of column 5 is processed using key C and an XOR function, to generate the intermediately decoded data shown in column 6. The data of column 6 is then processed using the variable key values of column 2 and an XOR function to generate the fully decoded data shown in column 7, which is the same as the original data shown in column 1. While the logic functions used in this example are all XOR functions, it should be understood that other suitable functions may be used in the encoding and decoding processes, providing the encoding logic functions have suitable inverse functions for the decoding process. [0093] While Tables 2A and 2B show an example of data encoding and decoding using a fixed key in combination with a variable key, alternative embodiments may use only a variable key or may use two or more fixed or variable keys instead of a combination.
[0094] In Tables 3A and 3B below, examples of format information comprised in the decryption code are illustrated. In Table 3A, examples of format information are shown, as examples 1 and 2, for the case where the format information includes a key lifetime value, for example as a number of hours. The lifetime value indicates the time during which the decryption key transmitted with the format information is valid. Once the key lifetime expires, the decryption key becomes unusable by reading device 110 or 510.
[0095] Table 3A:
Example 1
Example 2
Figure imgf000027_0001
[0096] Table 3B:
Example 3
Example 4
Figure imgf000028_0001
[0097] In the examples illustrated in Tables 3A and 3B, the format information includes a validation checksum for checking whether the encryption key and format information may have been corrupted, for example during transmission from the code provider 130. Further, the format information includes a key format code, which the reading device 110 or 510 uses to determine (according to a stored reference table in memory 170) which logic functions and decoding methods to use and the decoding process. For example, the key format code may specify a format that uses a combination of XOR functions and hash functions and specifies that an LFSR circuit is to be used to generate a pseudo-random number sequence based on a seed value transmitted with the format information. In another example, the key format code may specify a format that does not employ variable key decoding or that does not specify a key lifetime. Accordingly, the key format code will dictate whether the variable key seed value or key lifetime value is necessary for the decoding process.
[0098] In table 3B, two examples of format information are shown as
Examples 3 and 4, where the format information includes a specified validity period of the decryption key, including a start and end date during which the decryption key is valid. The format information in these examples also includes a validation checksum, a format code and a seed value.
[0099] In one embodiment, the data block size may be varied in the encoding process. For example, a pseudo-random or non-random number sequence may be used to determine the block size of each data block. If the number sequence is pseudo-random, an LFSR circuit may be used to generate the number sequence. During decoding, the same pseudo-random or non- random number sequence is used to determine the data block size. If the encoding process used varying data block sizes, this is indicated by the format code transmitted with the decryption code and the format information includes a seed value for generating the appropriate number sequence. [00100] Embodiments are described above in relation to the Figures and Tables. It should be understood that these embodiments are provided by way of example only and that some variation or modification of the features and/or elements of the embodiments may be made without departing from the spirit and scope of the described embodiments, and all such variations and beneficiations are included within that scope.

Claims

Claims
1. A method of encoding data on a data storage medium, comprising:
receiving a quantity of data to be stored on the data storage medium, the quantity of data including payload data and data delimiters;
determining a unique identifier of the data storage medium;
allocating an encoding key to the data storage medium, the encoding key being associated with the unique identifier;
dividing the quantity of data into a plurality of data blocks of a predetermined size;
encoding each data block using the encoding key to generate an encoded data block of the predetermined size; and
storing all encoded data blocks on the data storage medium so that the quantity of data is stored on the data storage medium in encoded form.
2. The method of claim 1 , wherein the data storage medium is an optical recording medium.
3. The method of claim 1 or claim 2, wherein the step of determining includes reading the unique identifier from the data storage medium.
4. The method of any one of claims 1 to 3, wherein the encoding includes performing a logic operation on each data block, where the encoding key and the data block are operands of the logic operation.
5. The method of any one of claims 1 to 4, wherein the predetermined size is one byte.
6. The method of any one of claims 1 to 5, wherein the encoding key is a fixed key.
7. The method of claim 6, further comprising, prior to the step of storing, further encoding each data block using a variable key to generate a further encoded data block of the predetermined size.
8. The method of claim 6, further comprising, after the step of allocating and before the step of encoding, partially encoding each data block using a variable key to generate a partially encoded data block of the predetermined size.
9. The method of claim 7 or 8, wherein the variable key varies for each data block.
10. The method of any one of claims 7 to 9, wherein the variable key is determined based on the fixed key or the unique identifier.
11. The method of any one of claims 7 to 10, wherein the variable key is a repeatably generated pseudo-random number.
12. The method of claim 11, wherein a linear feedback shift register is used to generate the variable key, based on a predetermined seed value.
13. A method of decoding encoded data stored on a data storage medium, the encoded data including payload data and data delimiters, the method comprising:
a) providing a reading device for reading the data storage medium;
b) determining a first unique identifier of the data storage medium;
c) determining a second unique identifier of the reading device;
d) providing the first and second unique identifiers to a validation entity;
e) receiving a decryption code from the validation entity in response to step d);
f) reading the encoded data from the data storage medium; and g) decoding the encoded data in data blocks of a predetermined size using the decryption code to generate decoded data blocks.
14. The method of claim 13, further comprising:
h) buffering a plurality of the decoded data blocks;
i) determining the payload data in the decoded data blocks based on the data delimiters; and
j) processing the payload data.
15. The method of claim 13 or 14, wherein step f) further comprises processing the encoded data using a first logic function and a first key specific to the reading device to generate intermediate encoded data and step g) further comprises processing the intermediate encoded data using a second logic function and the decryption code to generate the decoded data blocks.
16. The method of any one of claims 13 to 15, wherein the data storage medium is an optical recording medium.
17. The method of any one of claims 13 to 16, wherein step b) includes reading the unique identifier from the data storage medium.
18. The method of any one of claims 13 to 17, wherein the decryption code comprises a fixed code.
19. The method of any one of claims 13 to 18, wherein the decryption code comprises a variable code.
20. The method of claim 19, wherein the variable code varies for each data block.
21. The method of any one of claims 13 to 17, wherein the decryption code includes a fixed code and a variable code.
22. The method of any one of claims 19 to 21, wherein the variable code is used to generate a sequence of keys for decoding the encoded data.
23. The method of claim 22, wherein each of the keys in the sequence of keys is used to decode a respective data block.
24. The method of claim 22 or claim 23, wherein the variable code includes a seed value and a linear feedback shift register (LFSR) is used to generate the sequence of keys based on the seed value.
25. A method of monitoring use of data stored on a data storage medium using an encoding key, the data storage medium having a unique identifier, the method comprising:
receiving a decryption key request from a data reading entity in relation to the data storage medium, the decryption key request including a reading device identifier and the unique identifier;
determining a use number of the data storage medium based on the unique identifier;
comparing the use number with a predetermined use limit of the data storage medium; and
incrementing the use number if the use number is less than the predetermined use limit.
26. The method of claim 25, further comprising storing the reading device identifier with the use number in a use record of the data storage medium.
27. The method of claim 25 or claim 26, further comprising the steps of:
determining the encoding key based on the unique identifier;
generating a decryption key based on the encoding key and the reading device identifier; and transmitting the decryption key to the data reading entity in response to the decryption key request.
28. The method of any one of claims 25 to 27, wherein the decryption key is generated as an output of a logic function and the encoding key and the reading device identifier are operands of the logic function.
29. The method of any one of claims 25 to 28, wherein the unique identifier is, or is derived from, a serial number of the data storage medium.
30. The method of claim 27, where the step of transmitting includes transmitting format information with the decryption key, the format information being indicative of an encoding format used to encode the data stored on the data storage medium.
31. The method of claim 30, wherein the format information includes data indicative of at least one of a key validity condition, a variable key, an encoding logic function and a checksum.
32. The method of claim 31 , wherein the variable key comprises a seed value for generating a pseudo-random number sequence as the variable key.
33. The method of claim 32, wherein a linear feedback shift register (LFSR) is used to generate the pseudo-random number sequence based on the seed value.
34. The method of any one of claims 31 to 33, wherein the key validity condition includes a key validity period.
35. A data processing device for an encrypted data storage medium, the device comprising:
a reader for reading encrypted data stored on the data storage medium; and a processor in communication with the reader for processing the encrypted data and controlling the reader, the processor being configured to determine a first unique identifier of the data processing device and a second unique identifier of the data storage medium, and to receive a decryption code generated by a code provider based on the first and second unique identifiers, the processor being further configured to decrypt the encrypted data based on the decryption code.
36. The data processing device of claim 35, wherein the processor is configured to communicate with the code provider over a network.
37. The data processing device of claim 36, wherein the processor is configured to generate a decryption key request based on the first and second unique identifiers and to transmit the decryption key request to the code provider over the network.
38. The data processing device of any one of claims 35 to 37, wherein the decryption code includes a decryption key and format information and wherein the processor is configured to determine a decryption format of the encrypted data based on the format information and to decrypt the encrypted data based on the decryption key and the decryption format.
39. A data storage medium storing data encoded according to the method of any one of claims 1 to 12.
PCT/CA2006/001465 2005-09-07 2006-09-07 Method and system for data security of recording media WO2007028241A2 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US71433905P 2005-09-07 2005-09-07
US60/714,339 2005-09-07

Publications (2)

Publication Number Publication Date
WO2007028241A2 true WO2007028241A2 (en) 2007-03-15
WO2007028241A3 WO2007028241A3 (en) 2007-04-26

Family

ID=37836177

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CA2006/001465 WO2007028241A2 (en) 2005-09-07 2006-09-07 Method and system for data security of recording media

Country Status (2)

Country Link
US (1) US20070177433A1 (en)
WO (1) WO2007028241A2 (en)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080031451A1 (en) * 2005-11-14 2008-02-07 Jean-Francois Poirier Method and system for security of data transmissions
GB0615392D0 (en) * 2006-08-03 2006-09-13 Wivenhoe Technology Ltd Pseudo random number circuitry
JP2010045535A (en) * 2008-08-11 2010-02-25 Buffalo Inc Cryptographic-key management system, external device, and cryptographic-key management program
JP5615386B2 (en) * 2010-03-08 2014-10-29 ダグ カーソン アンド アソシエーツ，インク． Write repetitive pattern features on a substrate
US20120079281A1 (en) * 2010-06-28 2012-03-29 Lionstone Capital Corporation Systems and methods for diversification of encryption algorithms and obfuscation symbols, symbol spaces and/or schemas
US10008057B2 (en) * 2014-08-08 2018-06-26 Live Nation Entertainment, Inc. Short-range device communications for secured resource access
US10679539B2 (en) * 2017-08-10 2020-06-09 Outward, Inc. Two-dimensional compositing
CN112100983A (en) * 2020-08-14 2020-12-18 许继集团有限公司 Identification code used in system and generation method of identification code

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5412718A (en) * 1993-09-13 1995-05-02 Institute Of Systems Science Method for utilizing medium nonuniformities to minimize unauthorized duplication of digital information
US5917910A (en) * 1995-10-16 1999-06-29 Sony Corporation Encrypting method and apparatus, recording method, decrypting method and apparatus, and recording medium
WO2000067258A1 (en) * 1999-04-30 2000-11-09 Thomson Licensing S.A. Method and apparatus for processing digitally encoded audio data
JP2003274186A (en) * 1994-09-21 2003-09-26 Ricoh Co Ltd Encoding device

Family Cites Families (55)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4513174A (en) * 1981-03-19 1985-04-23 Standard Microsystems Corporation Software security method using partial fabrication of proprietary control word decoders and microinstruction memories
FR2523745B1 (en) * 1982-03-18 1987-06-26 Bull Sa METHOD AND DEVICE FOR PROTECTING SOFTWARE DELIVERED BY A SUPPLIER TO A USER
US4573119A (en) * 1983-07-11 1986-02-25 Westheimer Thomas O Computer software protection system
US4776011A (en) * 1983-10-24 1988-10-04 Sony Corporation Recursive key schedule cryptographic system
US4740890A (en) * 1983-12-22 1988-04-26 Software Concepts, Inc. Software protection system with trial period usage code and unlimited use unlocking code both recorded on program storage media
US4633388A (en) * 1984-01-18 1986-12-30 Siemens Corporate Research & Support, Inc. On-chip microprocessor instruction decoder having hardware for selectively bypassing on-chip circuitry used to decipher encrypted instruction codes
JPS61166653A (en) * 1985-01-19 1986-07-28 Panafacom Ltd Processing system for address conversion error
US4984189A (en) * 1985-04-03 1991-01-08 Nec Corporation Digital data processing circuit equipped with full bit string reverse control circuit and shifter to perform full or partial bit string reverse operation and data shift operation
US5014234A (en) * 1986-08-25 1991-05-07 Ncr Corporation System with software usage timer and counter for allowing limited use but preventing continued unauthorized use of protected software
US5109413A (en) * 1986-11-05 1992-04-28 International Business Machines Corporation Manipulating rights-to-execute in connection with a software copy protection mechanism
US4817140A (en) * 1986-11-05 1989-03-28 International Business Machines Corp. Software protection system using a single-key cryptosystem, a hardware-based authorization system and a secure coprocessor
US5146575A (en) * 1986-11-05 1992-09-08 International Business Machines Corp. Implementing privilege on microprocessor systems for use in software asset protection
NL8602847A (en) * 1986-11-11 1988-06-01 Philips Nv METHOD FOR Ciphering / Deciphering and Device for Carrying Out the Method
JPH0192833A (en) * 1987-10-02 1989-04-12 Satoru Kubota Microprocessor including cipher translating circuit to prevent software from being illegally copied
JPH01296361A (en) * 1988-05-25 1989-11-29 Mitsubishi Electric Corp Memory card
US5007082A (en) * 1988-08-03 1991-04-09 Kelly Services, Inc. Computer software encryption apparatus
US4937861A (en) * 1988-08-03 1990-06-26 Kelly Services, Inc. Computer software encryption apparatus
US5081678A (en) * 1989-06-28 1992-01-14 Digital Equipment Corporation Method for utilizing an encrypted key as a key identifier in a data packet in a computer network
US5231662A (en) * 1989-08-01 1993-07-27 Tulip Computers International B.V. Method and device for enciphering data to be transferred and for deciphering the enciphered data, and a computer system comprising such a device
US5365589A (en) * 1992-02-07 1994-11-15 Gutowitz Howard A Method and apparatus for encryption, decryption and authentication using dynamical systems
US5351299A (en) * 1992-06-05 1994-09-27 Matsushita Electric Industrial Co., Ltd. Apparatus and method for data encryption with block selection keys and data encryption keys
US5319705A (en) * 1992-10-21 1994-06-07 International Business Machines Corporation Method and system for multimedia access control enablement
US5267311A (en) * 1992-12-08 1993-11-30 Bakhoum Ezzat G Intelligent diskette for software protection
JPH08101867A (en) * 1994-09-30 1996-04-16 Fujitsu Ltd Software use permission system
US5602916A (en) * 1994-10-05 1997-02-11 Motorola, Inc. Method and apparatus for preventing unauthorized monitoring of wireless data transmissions
DE69638018D1 (en) * 1995-02-13 2009-10-15 Intertrust Tech Corp Systems and procedures for managing secure transactions and protecting electronic rights
US5943422A (en) * 1996-08-12 1999-08-24 Intertrust Technologies Corp. Steganographic techniques for securely delivering electronic digital rights management control information over insecure communication channels
US5857021A (en) * 1995-11-07 1999-01-05 Fujitsu Ltd. Security system for protecting information stored in portable storage media
US5870470A (en) * 1996-02-20 1999-02-09 International Business Machines Corporation Method and apparatus for encrypting long blocks using a short-block encryption procedure
US5745577A (en) * 1996-07-25 1998-04-28 Northern Telecom Limited Symmetric cryptographic system for data encryption
FR2751767B1 (en) * 1996-07-26 1998-12-18 Thomson Csf SECURE DATA STORAGE SYSTEM ON CD-ROM
US5920861A (en) * 1997-02-25 1999-07-06 Intertrust Technologies Corp. Techniques for defining using and manipulating rights management data structures
US6094486A (en) * 1997-06-19 2000-07-25 Marchant; Brian E. Security apparatus for data transmission with dynamic random encryption
US6240183B1 (en) * 1997-06-19 2001-05-29 Brian E. Marchant Security apparatus for data transmission with dynamic random encryption
US6236728B1 (en) * 1997-06-19 2001-05-22 Brian E. Marchant Security apparatus for data transmission with dynamic random encryption
US6014745A (en) * 1997-07-17 2000-01-11 Silicon Systems Design Ltd. Protection for customer programs (EPROM)
US6061449A (en) * 1997-10-10 2000-05-09 General Instrument Corporation Secure processor with external memory using block chaining and block re-ordering
KR100279522B1 (en) * 1997-11-20 2001-03-02 니시무로 타이죠 Copy protection device and information recording medium used in such a copy protection device
US6192129B1 (en) * 1998-02-04 2001-02-20 International Business Machines Corporation Method and apparatus for advanced byte-oriented symmetric key block cipher with variable length key and block
EP0984346A1 (en) * 1998-09-02 2000-03-08 Hitachi Europe Limited Copy protection apparatus and method
US6442626B1 (en) * 1998-12-28 2002-08-27 Siemens Aktiengesellschaft Copy protection system only authorizes the use of data if proper correlation exists between the storage medium and the useful data
US6463538B1 (en) * 1998-12-30 2002-10-08 Rainbow Technologies, Inc. Method of software protection using a random code generator
US6625734B1 (en) * 1999-04-26 2003-09-23 Disappearing, Inc. Controlling and tracking access to disseminated information
CN100358034C (en) * 1999-04-28 2007-12-26 松下电器产业株式会社 Optical disk, optical disk recording and reproducing apparatus, method for recording reproducing, and delecting data on optical disk, and information procesisng system
US6367010B1 (en) * 1999-07-02 2002-04-02 Postx Corporation Method for generating secure symmetric encryption and decryption
JP4622064B2 (en) * 2000-04-06 2011-02-02 ソニー株式会社 Information recording apparatus, information reproducing apparatus, information recording method, information reproducing method, information recording medium, and program providing medium
WO2001099332A1 (en) * 2000-06-21 2001-12-27 Sony Corporation Information recording/reproducing apparatus and method
US6778974B2 (en) * 2001-02-02 2004-08-17 Matrix Semiconductor, Inc. Memory device and method for reading data stored in a portion of a memory device unreadable by a file system of a host device
US7134144B2 (en) * 2001-03-01 2006-11-07 Microsoft Corporation Detecting and responding to a clock rollback in a digital rights management system on a computing device
JP4016865B2 (en) * 2003-03-26 2007-12-05 ソニー株式会社 Content reproduction deadline management system, content reproduction deadline management method, terminal device, server device, program, and recording medium
US20040268120A1 (en) * 2003-06-26 2004-12-30 Nokia, Inc. System and method for public key infrastructure based software licensing
KR20050064624A (en) * 2003-12-24 2005-06-29 삼성전자주식회사 Apparatus for recording and playing storage medium and the method thereof
EP1724657A4 (en) * 2004-03-03 2010-11-24 Pioneer Corp Electronic device, control method thereof, security program and others
US20050262568A1 (en) * 2004-05-18 2005-11-24 Hansen Mark D System and method for managing access to protected content by untrusted applications
US7460668B2 (en) * 2004-07-21 2008-12-02 Divx, Inc. Optimized secure media playback control

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5412718A (en) * 1993-09-13 1995-05-02 Institute Of Systems Science Method for utilizing medium nonuniformities to minimize unauthorized duplication of digital information
JP2003274186A (en) * 1994-09-21 2003-09-26 Ricoh Co Ltd Encoding device
US5917910A (en) * 1995-10-16 1999-06-29 Sony Corporation Encrypting method and apparatus, recording method, decrypting method and apparatus, and recording medium
WO2000067258A1 (en) * 1999-04-30 2000-11-09 Thomson Licensing S.A. Method and apparatus for processing digitally encoded audio data

Also Published As

Publication number Publication date
WO2007028241A3 (en) 2007-04-26
US20070177433A1 (en) 2007-08-02

Similar Documents

Publication Publication Date Title
JP4790218B2 (en) Method and apparatus for supplying data set stored in database
JP4219680B2 (en) System, method and device for playing recorded audio, video or other content from non-volatile memory cards, compact discs or other media
JP3996912B2 (en) Content encryption using programmable hardware
US6691229B1 (en) Method and apparatus for rendering unauthorized copies of digital content traceable to authorized copies
US20070177433A1 (en) Method and system for data security of recording media
US20020073326A1 (en) Protect by data chunk address as encryption key
KR100856617B1 (en) Data transfer system, data transfer apparatus, data recording apparatus, data transfer method, and recording medium
CN101073238A (en) Protection of digital data content
KR100972831B1 (en) Protectiog method of encrypted data and reprodecing apparatus therof
JP2000267940A (en) Device and method for ciphering digital file, and recording medium therefor
WO2000075925A1 (en) Method and systems for protecting data using digital signature and watermark
JP2011123995A (en) Method and device of controlling distribution and use of digital work
JP2005512258A (en) System data integrity verification method and apparatus
JPH09128890A (en) Signal recording method and device therefor signal reproducing method and device therefor signal transmission method and device therefor
US20030091187A1 (en) Apparatus and method for reading or writing user data
US20060277415A1 (en) Content protection method and system
WO2000031744A1 (en) Copy management for data systems
US20040114759A1 (en) Information processing apparatus, information recording apparatus, information recording medium, computer program and information processing method
JP2000076136A (en) Recording and reproducing device
US8397303B2 (en) Memory controller, nonvolatile storage system, and data management method
US7127618B2 (en) Data protection via reversible data damage
JP4615073B2 (en) Data recording apparatus and method
US20030088773A1 (en) Method of and apparatus for preventing illicit copying of digital content
JP2000076789A (en) Encoded sound reproducing system for cd linear pcm data
WO2001073567A1 (en) Secure compact disc technology

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 06790642

Country of ref document: EP

Kind code of ref document: A2