Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
• • 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/443—OS processes, e.g. booting an STB, implementing a Java virtual machine in an STB or power management in an STB
  • H04N21/4431—OS processes, e.g. booting an STB, implementing a Java virtual machine in an STB or power management in an STB characterized by the use of Application Program Interface [API] libraries
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F15/00—Digital computers in general; Data processing equipment in general
  • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
  • G06F15/163—Interprocessor communication
  • G06F15/173—Interprocessor communication using an interconnection network, e.g. matrix, shuffle, pyramid, star, snowflake
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
  • G06F21/51—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
• • 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/4424—Monitoring of the internal components or processes of the client device, e.g. CPU or memory load, processing speed, timer, counter or percentage of the hard disk space used

Definitions

• Some multimedia playback systems provide limited interactive graphics during audio/video playback.
• the greater capabilities of interactive playback systems present greater opportunities for malfeasance. It is critical to maintain the security of the playback system against viruses, spyware and other malicious software. Malicious software could cause the interactive playback system to malfunction or gather and transmit private user information.
• an interactive playback system may be connected to a network. The software or user information could propagate from the playback system to other computing systems attached to the network. Consequently, it is critical that the interactive playback system include adequate security provisions.
• a security system which controls the privileges of unsigned applications in the field of interactive multimedia.
• Interactive multimedia is an environment in which applications typically manage multimedia objects including graphics, audio and video responsively to user input events on a synchronized real-time, frame-accurate basis.
• Applications here are termed "iHD" applications as they relate to high-definition DVD (digital versatile disk) media.
• iHD high-definition DVD
• the disclosed security system is applicable to other interactive multimedia environments more generally.
• the system in particular applies to application security, not content security, and establishes a framework for application security, including a signature system, and further provides file formats that support security.
• Interactive multimedia applications run on an interactive playback system may be either signed or unsigned.
• Signed applications are allowed practically unlimited applications. Unsigned applications are greatly restricted in what the same can access. Moreover, if both signed and unsigned applications are running, both are given only the security level and access privileges of the unsigned application. Providing for unsigned applications allows for home-authored discs customizable with rich interactivity features, but restricts access to networks, e.g., the Internet, and sensitive information stored within the playback system, to authorized parties.
• Signed applications may be provided with special file formats, allowing determination of the signature status without requiring parsing of the entire file.
• Fig. 1 is a flowchart illustrating a method of assigning privileges to applications where signature statuses of applications are detected from a disk.
• Fig. 2 is a flowchart illustrating a method of assigning privileges to applications where the signature status of an applications is detected upon loading into a playback system.
• FIG. 3 is a flowchart illustrating creation of an author identifier - keyed directory.
• Fig. 4 is a schematic depiction of an application file.
• Interactive multimedia applications are those in which the application is responsive to user events.
• An example is a menu implemented within an application that is accessed by the user, in which the user submits an input that causes the application to change state.
• the interactivity may lead, for example, to changes in how the video stream is displayed.
• an underlying video may be a high-definition movie.
• the graphic overlay may be part of a commentary by the director of the movie, showing, e.g., a schematic of various camera locations overlayed on top of the scene itself.
• the user may, employing the remote control, switch to a view envisioned by any of those camera locations.
• interactive applications for use in the playback system may be either signed or unsigned. Signed applications are those which inherit a root certificate from a trusted root authority (e.g., a movie studio) and are considered safe. [00014] Signed applications are given high-level access privileges. This almost- unrestricted privilege allows access to, e.g., networking, file I/O, security and diagnostic APIs, and may access persistent storage to store and retrieve data that is to persist across invocations of the application.
• Unsigned applications are given low-level access privileges. They are denied access to the type of functionality afforded by high access. They may be limited to the utilization of the markup language, as well as, e.g., certain objects from the following exemplary APIs in ECMAScript: XML (without the I/O functionality); globalization; drawing functions associated with graphics elements; and user input operations.
• This level of functionality prohibits access to any networking, security, or file I/O. Any attempt to call a function outside the above namespaces or load resources from persistent local storage may result in an exception which will terminate the application.
• a set of applications is present on a media disk, e.g., a HD- DVD, and the same are employed to run an interactive graphics and video application.
• the media disk is received by the playback system (step 12).
• the playback system which may be a general purpose computer system or a more specialized media center system, determines the signature status of the applications on the media (step 14). If the signature status of all applications is determined (step 16) to be signed, then all of the applications are given the high access privileges (step 18). If the signature status of any one application is determined to be unsigned, then all of the applications are given low access privileges (step 22).
• an unsigned application may be loaded into the playback system (step 24).
• the signature status of the application is then detected (step 26). If the signature status is determined (step 28) to be signed, then the application may be run at a high privilege access level (step 32). However, if the signature status is determined (step 28) to be unsigned, then the application is run at a low privilege access level (step 34).
• the application is run directly from the media (step 36), e.g. a disk.
• the media e.g. a disk.
• step 36 e.g. a disk.
• additional applications are loaded (step 38), then they may be tested or not for their signature status: in general, they will be afforded a low access level (step 34). If an application is signed and thus given high access privileges, and then a later application is loaded and is unsigned, then the high access application is lowered to the low-access level.
• the playback system may include employment of a set of author identifiers that are detected (step 44) upon the media introduction (step 42) into the playback system.
• each media or application may be associated with an author identifier, which uniquely identifies content authors, and which is particularly important to the security of applications in persistent storage, i.e., those which can access persistent storage to store and retrieve data that are desired to be persistent across invocations.
• the author identifier is then associated with creation (step 46) of a directory associated with that author identifier.
• the application from that media may access only the directory corresponding to its author identifier in persistent storage.
• the file system, as the application views it, is rooted in that directory. While the application can manage subdirectories, it cannot go above its root directory and see other author's data.
• the author identifier may be associated with either a disk, including all the applications on that disk, or a single application, either on that disk, spread over several disks, or otherwise loaded into the playback system, e.g., via an internet download.
• a given media may be associated with a single author identifier, but a given author identifier may be found on multiple media.
• Another embodiment may be to use the identifier referred to by the key that signed the application. Assuming that different applications may be signed by different persons on a single media, this embodiment would lead to even greater segregation of storage. Using the chain of certificates instead of the last signature would do so even more.
• APPLICATION STRUCTURE [00022] The structure of a signed application is now described.
• a signed application 50 may include a manifest file 52 and at least one resource file 54.
• the manifest file 52 is signed with the author's signature and certificate and authenticates all the resources it references.
• the application may have its manifest file 52 and all resource files 54-58 bundled into an uncompressed archive 48.
• the file format for archive 48 need not even support encryption.
• the archive file 48 is in essence a container and generally does not need to be signed independently.
• the manifest file 52 may reference each of the resource files 54-58 of the interactive application.
• the archive 48 architecture may be specified such that the archive 48 may be streamed efficiently, e.g., the signed manifest file 52 may be the first file within the archive 48, allowing the verification of the signature without reading the entire archive. Subsequent versions of the archive format may be backwards compatible with previous ones.
• Authentication of the data in the archive 48 may be provided by the use of, e.g., XML-Signature as defined by RFC 3275.
• MANIFEST FILE FORMAT e.g., XML-Signature as defined by RFC 3275.
• the format of the signed manifest file 52 may make use of a subset of the W3C Recommendation for XML-Signature Syntax and Processing defined by RFC 3275. In this way, the following subset of elements may be included and supported: ds: Signature ds : S ignature Value ds: SignatureType ds:Reference ds:Reference/ds:DigestValue
• ds:Reference elements Other elements may be determined by the system.
• Digest values for each resource item included in the manifest may be listed as ds:Reference elements.
• CERTIFICATES AND SIGNATURES [00027]
• the required certificate type may be, e.g., X.509.
• the signature method as defined by ds:SignatureMethod may be RSA-SHAl .
• the canonicalization method may be specified to be Exclusive XML Canonicalization 1.0.
• the digest method may be the same as the signature method, RSA-SHAl .
• the key information may be inferred by the system from the identity of the media or local storage area from which the application is being run. CERTIFICATE REVOCATION LISTS
• each interactive video and graphics application author can include a Content Revocation List ("CRL") which lists the bundle file digest values of revoked applications.
• This CRL may be included in a separate file.
• This file contains a list of bundle signature digests which have been revoked, and the signature of the content creator who authored the disc. Assuming that the original author's signature of each revoked application matches that of the signature in the CRL file, the application digests listed will be stored in the content provider's restricted area of local storage and will be no longer allowed to run. If a CRL is included in an application, it may be given a recognizable name such as Revocation.xml.
• the application author may desire to replace the revoked application with a new version. This can be accomplished in several different ways. Titles running on Internet-connected players may be caused to check their home servers for updated playlists or interactive video and graphics bundles which specify newly downloaded applications. Alternatively, the media revoking an application could also supply the replacement itself.
• Ui/z represents a unsigned integer of « bits.
• Ui8 is an 8-bit unsigned integer
• Ui32 is a 32-bit one.
• An array of type is indicated by using square brackets, and the length of the array is indicated in between those brackets. If the length depends on a previous field, that field's name, or a shorter name indicated in the field, can be used to refer to the value of that field. Hexadecimal values are indicated using the Oxdd notation. All variable-length strings, and hence resource names, may be encoded using UTF-8 using a Pascal string notation (8-bit length followed by bytes).
• resource names must be file system names or logical URIs.
• the directory in which an archive file will be extracted may be considered to be the root of the file system during that extraction. In that way, all names will be made relative to that directory, so that absolute paths will behave the same as relative ones. If a name results in a location outside of that directory, the name and the entry may be considered invalid.
• the following sections give more detailed information about various fields and sections of the above exemplary archive file.
• This is a "magic number" used to uniquely identify archives. It may consist of the string “iHDar”, i.e., iHD archive, coded as a sequence of 5-character values in UTF-8, ASCII, etc., i.e. 0x69, 0x48, 0x44, 0x61, 0x72. Version Field
• the version field allows an archive reader to read different versions of the archive format. By looking at the version field, one can know what to expect in the different sections of the file, and thus read information that was not present in some versions of the file format.
• the value of this field may be, e.g., 0x01. Future versions may have values from 0x02 to Oxff.
• the resource catalog includes a number of resource entries. Each entry follows the same format.
• resource offset for B is equal to the sum of A's resource offset and resource length.
• Resource Checksum This represents a CRC-32 checksum of the resource, as defined by ISO 3309.
• the resource data block contains all the bytes for the resources, in the order they appear in the resource catalog. There is generally no explicit separation between two resources, as their offsets and lengths are well-known quantities.
• the system may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer.
• program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types.
• the system and method may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network.
• program modules may be located in both local and remote computer storage media including memory storage devices.
• Computer readable media can be any available media that can be accessed by a computer and includes both volatile and nonvolatile media, removable and non-removable media.
• Computer readable media may comprise computer storage media and communication media.
• Computer storage media includes both volatile and nonvolatile, removable and nonremovable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data.
• Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by a computer.
• Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media.
• modulated data signal means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal.
• communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of the any of the above should also be included within the scope of computer readable media.
• wired media such as a wired network or direct-wired connection
• wireless media such as acoustic, RF, infrared and other wireless media. Combinations of the any of the above should also be included within the scope of computer readable media.
• Examples of well known computing systems, environments, and/or configurations that may be suitable that may be used include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, mobile telephones, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like. [0049]
• the systems and methods described herein may be implemented in software or hardware or both using techniques some of which are well known in the art.

Landscapes

• Engineering & Computer Science (AREA)
• Software Systems (AREA)
• Theoretical Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• Computer Hardware Design (AREA)
• Physics & Mathematics (AREA)
• Multimedia (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Signal Processing (AREA)
• Computer Networks & Wireless Communication (AREA)
• Databases & Information Systems (AREA)
• Library & Information Science (AREA)
• Mathematical Physics (AREA)
• Storage Device Security (AREA)
• Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
• Signal Processing For Digital Recording And Reproducing (AREA)

Priority Applications (12)

Applications Claiming Priority (4)

Publications (2)

Family

ID=37591080

Family Applications (1)

Country Status (15)

Cited By (1)

Families Citing this family (17)

Citations (2)

Family Cites Families (127)

• 2006
  • 2006-02-15 US US11/354,800 patent/US7941522B2/en not_active Expired - Fee Related
  • 2006-06-22 AU AU2006266227A patent/AU2006266227B2/en not_active Ceased
  • 2006-06-22 NZ NZ564513A patent/NZ564513A/en not_active IP Right Cessation
  • 2006-06-22 RU RU2007147634/08A patent/RU2421807C2/ru not_active IP Right Cessation
  • 2006-06-22 SG SG201004472-5A patent/SG162823A1/en unknown
  • 2006-06-22 WO PCT/US2006/024034 patent/WO2007005281A2/en not_active Ceased
  • 2006-06-22 EP EP06785212A patent/EP1899844A4/en not_active Withdrawn
  • 2006-06-22 CA CA2613054A patent/CA2613054C/en not_active Expired - Fee Related
  • 2006-06-22 JP JP2008519391A patent/JP5015148B2/ja not_active Expired - Fee Related
  • 2006-06-22 BR BRPI0613552-8A patent/BRPI0613552A2/pt not_active Application Discontinuation
  • 2006-06-22 KR KR1020077030273A patent/KR101238582B1/ko not_active Expired - Fee Related
  • 2006-06-22 MX MX2007016385A patent/MX2007016385A/es active IP Right Grant
• 2007
  • 2007-12-13 IL IL188131A patent/IL188131A/en active IP Right Grant
  • 2007-12-19 NO NO20076507A patent/NO20076507L/no not_active Application Discontinuation
  • 2007-12-31 EG EGNA2007001490 patent/EG25253A/xx active

Patent Citations (2)

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events