HK1172976B - Security system for computing resource prereleases - Google Patents

Description

Security system for computing resource pre-distribution

Technical Field

The present invention relates to computing resource pre-publishing, and more particularly, to a security system for computing resource pre-publishing.

Background

Many creators of computing devices build them to run only very specific, well-defined computing resources, such as code embedded in software or firmware, greatly limiting (including completely limiting) the types and kinds of resources that end users can run on. Some examples of such devices are mobile devices and imagesSony Xbox And Windows PhoneThe game console of (1). Maintaining control over the code running on these systems is a major part of the efficient operation of these devices and the user experience provided by these devices.

An important part of the process of distributing prototypes or pre-releases of computing resources to customers, such as code for upgrades or new functions embedded in software or firmware, is the correct validation of the software, which takes time and delays the release of new or improved prototypes tested by the customer. For example, a party creating a software game running on a particular type of game console may wish to pre-release different versions of the game to see which is most popular. In another example, a party may wish to make prototype upgrades available as soon as possible to keep up with competitors' releases.

Disclosure of Invention

Techniques are provided for accessing, by a user computer system, a pre-release computing resource associated with a privilege set. Pre-release computing resources have not received a full amount of validation testing as releases to the public, and the expectation of security running on any user computer system for the resource is very high. Some examples of pre-release resources are alpha (alpha) or beta (beta) versions of firmware, boot code, hypervisors, system code, third party drivers, third party software, or other software that may run on the user computer system to be protected.

The privilege set includes as members a set of pre-release resources and a set of user computer systems having permission or privileges to access the set of pre-release resources. The pre-release resource is associated with different sets of privileges based on its security risk level. Some examples of factors used to determine the security risk level include a limit on the number of user computer systems at risk of an integrity failure of the pre-release resource, the operational layer of the user computer system affected by the resource, and the security test certification level at which the pre-release resource was successful. The user computer system satisfies membership criteria to be within the privilege set. One example of a membership criterion is whether a limit on the number of user computer systems in the collection has been reached. In another example, a user computer system must possess a required resource, such as a version of the system software. In addition, members within the higher privilege set that the privilege set may be located grant a hierarchy that reduces membership within the privilege set.

In one embodiment, a method for accessing a pre-release computing resource associated with a privilege set includes supplying a privilege set identifier to a user computer system for membership within the privilege set. Membership in the privilege set required by the resource is verified based on the privilege set identifier and the resource privilege set identifier of the resource.

In one embodiment, a user computer system includes a processor having access to a communication interface and a memory. The communication interface allows the processor to communicate with a software pre-release computer system. The memory stores software for programming the processor to obtain a privilege set identifier from the software pre-release computer system and store the identifier in the memory. Additionally, the processor downloads, via the communication interface, a software pre-release associated with the privilege set. The memory also stores software pre-releases. In one example, the software pre-release includes code for verifying that the user computer system has membership in a privilege set associated with the release based on the privilege set identifier. If the user computer system lacks membership, then the software pre-release is no longer executed.

The technology provides embodiments for automatic provisioning of privilege sets. The privilege sets may be located in a hierarchy based on security risk levels. In one example, the higher privileged privilege set also has membership in the lower privileged set. In one embodiment, a method includes associating a pre-release computing resource with a privilege set by generating a privilege set identifier for the resource. In response to satisfaction of the membership criteria for the privilege set, a privilege set identifier is generated for the user computer system that grants membership.

The privilege set identifier and the pre-release resource are distributed to the user computer system. For user computer systems that lack membership in a privilege set, the resource is not executable.

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

Drawings

FIG. 1A illustrates an example embodiment of a target recognition, analysis, and tracking system for a user participating in a game.

FIG. 1B illustrates a block diagram view of an example capture device of a target recognition, analysis, and tracking system in which embodiments of the technology may operate.

FIG. 2A illustrates an example embodiment of a user computer system, which may be a computing environment in which embodiments of the technology may operate.

FIG. 2B illustrates another example embodiment of a user computer system that may be a computing environment in which embodiments of the technology may operate.

FIG. 3A illustrates an example of the operational layers of software that may perform privilege checks and be stored in non-volatile memory.

FIG. 3B illustrates an example of privilege checking software stored in non-volatile memory as part of a software pre-release application.

FIG. 3C illustrates an example of a removable storage medium storing a secure data item that may be used in one or more embodiments of the technology.

FIG. 4A illustrates an example of software components that may be included in privilege set checking software.

FIG. 4B illustrates another example of software for privilege set checking that may be included, at least in part, in a downloaded software pre-release.

FIG. 5A illustrates an example embodiment of a system architecture for a membership authorization computer system that includes hardware and software components.

FIG. 5B illustrates an example of software components and data items that may be included in or utilized by a membership authorization software application.

FIG. 6 is a flow diagram of an embodiment of a method for automatically provisioning privilege sets.

FIG. 7 is a flow diagram of an embodiment of a method for associating a resource with a privilege set.

FIG. 8 is a flow diagram of an embodiment of a method for distributing a privilege set identifier indicating membership to a user computer system.

FIG. 9 is a flow diagram of an embodiment of a method for a user computer system to access a pre-release computing resource associated with a privilege set.

FIG. 10 is a method automatically supplied by a user computer system to obtain membership in a privilege set

FIG. 11 is a flow diagram of an embodiment of a method for determining the validity of a privilege set identifier received from a remote authorization computer system.

FIG. 12 is a flow diagram of an embodiment of a method for verifying membership of a user computer system in a privilege set associated with a pre-release resource.

FIG. 13 is a flow diagram of an embodiment of a method for determining whether a user computer system shares membership with a pre-release resource within the same set.

Detailed Description

Techniques provide embodiments of a security model for provisioning privilege sets to control security risks associated with pre-release computing resources and to derive benefits from rapid prototyping. By limiting the use of code to a particular set of systems, a careful balance can be maintained between the risk of omitting or using a curtailed validation check altogether and the advantage of allowing code to run on the system sooner.

A number of factors contribute to the security risk of pre-release resources. One example is the validation test level of computer security issues. Several security tests are performed in the integrity check to verify that the release is resilient to security threats. Some examples of security tests are threat modeling, pen testing, fuzz testing, and data flow verification. If the pre-release resource delivers a particular number of tests or a particular type of test, the resource is assigned a level of security test authentication success. This level is less than full authentication, but provides a baseline for risk assessment. For example, a successful test result may qualify a computing resource for integrity certification indicating a level of protection from a particular risk.

Other factors that contribute to the level of security test authentication success assigned may be that the operation of the resource has not been completely tested or tested in a different scenario to verify that it is operating as expected. Since many security holes come from unstable code, general testing and general stability in a user computer system greatly contribute to the overall resilience of the user computer system (e.g., phone or console). Hackers can compromise software or firmware using viruses and malicious programs such as trojan horses and backdoors. The risk of compromised resources varies, but can be significant. In one example, compromised software may cause license checks to be disabled so that pirated versions of the software may be executed in the computer system. In another example, a dedicated computer system, such as a game console, may be reused to run software not intended for the console.

Any poorly written code that inadvertently relies on the correct behavior of the hardware, relying on the formatting of data read from storage or the network, may result in vulnerabilities used by attackers. In addition, a local user of the hardware may attack a user computer system, such as a user console, through various means. For example, a user may connect the system to user accessible and non-user accessible buses and send maliciously developed data over these buses. Simple and complex changes to hardware may result in a user computer system receiving maliciously developed data. Hardware memory may be directly attacked and maliciously formed data files created on flash or on a drive. The networked devices may even be implemented to affect the networking of the user computer systems. For example, changes may be made to upstream routers and Network Address Translation (NAT) devices that affect Dynamic Host Configuration Protocol (DHCP) and Domain Name System (DNS) protocols.

Another risk factor is how many user computer systems are to receive the pre-release resource. In other words, what the size of the risk pool is. Any vulnerabilities found in less than fully validated resources (e.g., software) will therefore only have an impact, business impact, and user experience impact proportional to the number of user computer systems it runs. Furthermore, in some embodiments, the more dangerous a computing resource is and the fewer validity checks that are applied to the resource, the less the privilege set of the user computer system to which the resource is restricted. Techniques provide for the provision of privilege sets that scale with how much of the audience is.

Another risk factor is the functionality of the operational layer of the user computer system that will be changed by the pre-release resource. For example, in a multimedia console 100 like that discussed in fig. 2A below, a pre-release update to a firmware driver in the audio processing unit 123 using an error or a piece of malware may interfere with the smooth execution or user experience of a 3D real-time gaming application. While undesirable, it is not as bad as the software pre-release of a new hypervisor with a backdoor that would allow hackers to hack the hypervisor and thereby affect the extensive operation of most of the multimedia console 100.

By provisioning pre-release resources to qualify for membership in privilege sets and granting membership in those privilege sets to user computer systems, techniques provide a security model that balances protection from security risks with rapid prototyping needs. In most embodiments, provisioning and verification of membership in a privilege set having a security risk level is independent of licensing the pre-release resource. In other words, for security purposes, the user computer system may have privileges to execute pre-release resources, but still need to obtain a license to execute the pre-release.

FIG. 1A provides an example of a context in which the current technology may be useful. FIG. 1A illustrates an example embodiment of a target recognition, analysis, and tracking system. The target recognition, analysis, and tracking system 10 may be used to recognize, analyze, and/or track a human target such as the user 18. Embodiments of the target recognition, analysis, and tracking system 10 include a computing environment 12 for executing a gaming or other application, and an audiovisual device 16 for providing audio and visual representations from the gaming or other application. The system 10 also includes a capture device 20 for capturing locations in 3D and movements performed by the user, which the computing environment 12 receives, interprets, and uses to control the gaming or other application.

Embodiments of the computing environment 12 may include hardware components and/or software components such that the computing system 12 may be used to execute applications such as gaming applications and non-gaming applications. In one embodiment, the computing environment 12 may include a processor, such as a standardized processor, a specialized processor, a microprocessor, or the like that may execute instructions stored on a processor readable storage device for performing the processes described herein.

The system 10 also includes one or more capture devices 20 for capturing image data related to one or more users and/or objects sensed by the capture devices. In embodiments, the capture device 20 may be used to capture information related to the movement and gestures of one or more users, which is received by the computing environment and used to present, interact with, and/or control aspects of a gaming or other application. Examples of the computing environment 12 and the capture device 20 are explained in more detail below.

Embodiments of the target recognition, analysis, and tracking system 10 may be connected to an audio/visual device 16 having a display 14. The device 16 may be, for example, a television, a monitor, a High Definition Television (HDTV), or the like that may provide game or application visuals and/or audio to a user. For example, the computing environment 12 may include a video adapter such as a graphics card and/or an audio adapter such as a sound card that may provide audio/visual signals associated with a game or other application. The audio/visual device 16 may receive the audio/visual signals from the computing environment 12 and may then output game or application visuals and/or audio associated with the audio/visual signals to the user 18. According to one embodiment, the audio/visual device 16 may be connected to the computing environment 12 by, for example, an S-video cable, a coaxial cable, an HDMI cable, a DVI cable, a VGA cable, a component video cable, or the like.

In an example embodiment, the application executing in the computing environment 12 may be a game with real-time interaction, such as a boxing game being played by the user 18. For example, the computing environment 12 may use the audiovisual device 16 to provide a visual representation of a boxing opponent 22 to the user 18. The computing environment 12 may also use the audiovisual device 16 to provide a visual representation of a player avatar 24 that the user 18 may control with his or her movements. For example, the user 18 may throw a punch in physical space, which causes the player avatar 24 to throw a punch in game space. Thus, according to an example embodiment, the capture device 20 captures a 3D representation of a punch in physical space using the techniques described herein. The processor in the capture device 20 (see FIG. 1B) and the computing environment 12 of the target recognition, analysis, and tracking system 10 may be used to recognize and analyze the punch of the user 18 in physical space so that the punch may be interpreted in real-time as a gesture or game control of the player avatar 24 in game space.

FIG. 1B illustrates a block diagram view of an example of a capture device 20 that may be used in the target recognition, analysis, and tracking system 10. In an example embodiment, the capture device 20 may be configured to capture video having a depth image that may include depth values via any suitable technique including, for example, time-of-flight, structured light, stereo image, or the like. According to one embodiment, the capture device 20 may organize the calculated depth information into "Z layers," or layers perpendicular to a Z axis extending from the depth camera along its line of sight.

As shown in FIG. 1B, according to an example embodiment, the image camera component 22 may include an IR light component 24, a three-dimensional (3-D) camera 26, and an RGB camera 28 that may be used to capture a depth image of a scene. For example, in time-of-flight analysis, the IR light component 24 of the capture device 20 may emit an infrared light onto the scene and may then use sensors on the photosurfaces of the cameras 26 and/or 28 to sense the backscattered light from the surface of one or more targets and objects in the scene.

In an example embodiment, the capture device 20 may also include a processor 32 in operable communication with the image camera component 22. Processor 32 may include a standardized processor, a specialized processor, a microprocessor, or the like that may execute instructions for receiving the depth image, determining whether a suitable target may be included in the depth image, converting the suitable target into a skeletal representation or model of the target, or any other suitable instruction.

The capture device 20 may also include a memory component 34, which memory component 34 may store instructions that may be executed by the processor 32, images or frames of images captured by the 3-D camera or RGB camera, or any other suitable information, images, or the like. According to an example embodiment, the memory component 34 may include Random Access Memory (RAM), Read Only Memory (ROM), cache, flash memory, a hard disk, or any other suitable storage component. As shown in FIG. 1B, in one embodiment, the memory component 34 may be a separate component in communication with the image camera component 22 and the processor 32. According to another embodiment, the memory component 34 may be integrated into the processor 32 and/or the image camera component 22.

As shown in FIG. 1B, the capture device 20 may communicate with the computing environment 12 via a communication link 36. The communication link 36 may be a wired connection including, for example, a USB connection, a firewire connection, an ethernet cable connection, and/or a wireless connection such as a wireless 802.11b, 802.11g, 802.11a, or 802.11n connection.

In addition, the capture device 20 may provide the depth information and images captured by, for example, the 3-D camera 26 and/or the RGB camera 28, as well as a skeletal model that may be generated by the capture device 20, to the computing environment 12 via the communication link 36. Various known techniques exist for determining whether a target or object detected by capture device 20 corresponds to a human target. Skeletal mapping techniques may then be used to determine various body parts on the user's skeleton. Other techniques include converting the image into a mannequin representation of the person and converting the image into a mesh model representation of the person.

The skeletal model may then be provided to the computing environment 12 such that the computing environment may track the skeletal model and render an avatar associated with the skeletal model. Under the control of gesture recognition engine software 190, computing environment 12 may also determine which control commands to execute in an application executing on the computer environment based on, for example, gestures of the user that have been recognized from three-dimensional movements of portions of the skeletal model.

FIG. 2A illustrates an example embodiment of a user computer system that may be a computing environment for use in a target recognition, analysis, and tracking system like that shown in FIGS. 1A and 1B. The computing environment 12 may be a multimedia console 100, such as a gaming console. As shown in FIG. 2A, the multimedia console 100 includes a Central Processing Unit (CPU)101 having a level one cache 102, a level two cache 104, and a flash ROM 106. The level one cache 102 and the level two cache 104 temporarily store data and thus reduce the number of memory access cycles, thereby improving processing speed and throughput. CPU 101 may be configured to have more than one core, and thus additional level one and level two caches 102 and 104. The flash ROM106 may store executable code that is loaded during an initial phase of a boot process when the multimedia console 100 is powered ON.

A Graphics Processing Unit (GPU)108 and a video encoder/video codec (coder/decoder) 114 form a video processing pipeline for high speed, high resolution graphics processing. Data is transferred from the GPU108 to the video encoder/video codec 114 via a bus. The video processing pipeline outputs data to an a/V (audio/video) port 140 for transmission to a television or other display. A memory controller 110 is connected to the GPU108 to facilitate processor access to various types of memory 112, such as, but not limited to, RAM.

The multimedia console 100 includes an I/O controller 120, a system management controller 122, an audio processing unit 123, a network interface controller 124, a first USB host controller 126, a second USB host controller 128, and a front panel I/O subassembly 130 that are preferably implemented on a module 118. The USB controllers 126 and 128 serve as hosts for peripheral controllers 142(1) -142(2), a wireless adapter 148, and an external memory device 146 (e.g., flash memory, external CD/DVD ROM drive, removable media, etc.). The network interface 124 and/or wireless adapter 148 provide access to a network (e.g., the Internet, home network, etc.) and may be any of a wide variety of various wired or wireless adapter components including an Ethernet card, a modem, a Bluetooth module, a cable modem, and the like.

System memory 143 is provided to store application data that is loaded during the boot process. A media drive 144 is provided which may comprise a DVD/CD drive, hard drive, or other removable media drive, among others. The media drive 144 may be internal or external to the multimedia console 100. Application data may be accessed via the media drive 144 for execution, playback, etc. by the multimedia console 100. The media drive 144 is connected to the I/O controller 120 via a bus, such as a Serial ATA bus or other high speed connection (e.g., IEEE 1394).

The system management controller 122 provides various service functions related to ensuring availability of the multimedia console 100. The audio processing unit 123 and the audio codec 132 form a corresponding audio processing pipeline with high fidelity and stereo processing. Audio data is transmitted between the audio processing unit 123 and the audio codec 132 via a communication link. The audio processing pipeline outputs data to the A/V port 140 for reproduction by an external audio player or device having audio capabilities.

The front panel I/O subassembly 130 supports the functionality of the power button 150 and the eject button 152, as well as any LEDs (light emitting diodes) or other indicators exposed on the outer surface of the multimedia console 100. The system power supply module 136 provides power to the components of the multimedia console 100. A fan 138 cools the circuitry within the multimedia console 100.

The CPU 101, GPU108, memory controller 110, and various other components within the multimedia console 100 are interconnected via one or more buses, including serial and parallel buses, a memory bus, a peripheral bus, and a processor or local bus using any of a variety of bus architectures. By way of example, these architectures may include a Peripheral Component Interconnect (PCI) bus, a PCI-Express bus, and the like.

When the multimedia console 100 is powered ON, application data may be loaded from the system memory 143 into memory 112 and/or caches 102, 104 and executed on the CPU 101. The application may present a graphical user interface that provides a consistent user experience when navigating to different media types available on the multimedia console 100. In operation, applications and/or other media contained within the media drive 144 may be launched or played from the media drive 144 to provide additional functionalities to the multimedia console 100.

ROM106, caches 102, 104, memory 112, system memory 143, memory unit 146, and media drives are examples of computer-readable storage media, which are also discussed below.

The multimedia console 100 may be operated as a standalone system by simply connecting the system to a television or other display. In the standalone mode, the multimedia console 100 allows one or more users to interact with the system, watch movies, or listen to music. However, with the integration of broadband connectivity made available through the network interface 124 or the wireless adapter 148, the multimedia console 100 may further be operated as a participant in a larger network community.

When the multimedia console 100 is powered on, a set amount of hardware resources may be reserved for system use by the multimedia console operating system. These resources may include a reserve of memory (such as 16MB), a reserve of CPU and GPU cycles (such as 5%), a reserve of network bandwidth (such as 8kbs), and so on. Because these resources are reserved at system boot time, the reserved resources are not present from an application perspective.

In particular, the memory reservation is preferably large enough to contain the launch kernel, concurrent system applications, and drivers. The CPU reservation is preferably constant such that if the reserved CPU usage is not used by the system applications, the idle thread will consume any unused cycles.

With regard to the GPU reservation, lightweight messages generated by system applications (e.g., popups) are displayed by using a GPU interrupt to schedule code to render popup into an overlay. The amount of memory required for the overlay depends on the overlay area size, and the overlay preferably scales with the screen resolution. Where a complete user interface is used by a concurrent system application, it is preferable to use a resolution that is independent of the application resolution. A scaler may be used to set this resolution so that no frequency change is required and TV resynchronization is caused.

After the multimedia console 100 boots and system resources are reserved, concurrent system applications are executed to provide system functionality. The system functions are encapsulated in a set of system applications that execute within the reserved system resources described above. The operating system kernel identifies threads that are system application threads and not gaming application threads. The system applications are preferably scheduled to run on the CPU 101 at predetermined times and intervals in order to provide a consistent system resource view for the applications. The scheduling is done to minimize cache disruption caused by the gaming application running on the console.

When audio is needed by a concurrent system application, audio processing is asynchronously scheduled to the gaming application due to time sensitivity. A multimedia console application manager (described below) controls the audio level (e.g., mute, attenuate) of the gaming application when system applications are active.

The input devices (e.g., controllers 142(1) and 142(2)) are shared by the gaming application and the system application. Rather than reserving resources, the input devices are switched between the system application and the game application so that each has a focus of the device. The application manager preferably controls the switching of input stream without knowledge of the gaming application's knowledge and the driver maintains state information regarding focus switches. The cameras 26, 28 and capture device 20 may define additional input devices for the console 100.

FIG. 2B illustrates another example embodiment of a user computer system that may be a computing environment 210 including a personal computer, the computing environment 210 may be a computing environment 12 for a target recognition, analysis, and tracking system 10 like that shown in FIGS. 1A-1B. The computing system environment 210 is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the disclosed subject matter. Neither should the computing environment 210 be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary operating environment 210.

With reference to FIG. 2B, an exemplary system for implementing the techniques includes a general purpose computing device in the form of a computer 210. Components of computer 210 may include, but are not limited to, a processing unit 220, a system memory 230, and a system bus 221 that couples various system components including the system memory to the processing unit 220. The system bus 221 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus also known as mezzanine bus.

Computer 210 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer 210 and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes volatile and nonvolatile, removable and non-removable 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, memory sticks or cards, 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 computer 210. 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. The term "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. By way of example, and not limitation, 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 any of the above should also be included within the scope of computer readable media.

The system memory 230 includes computer storage media in the form of volatile and/or nonvolatile memory such as Read Only Memory (ROM)231 and Random Access Memory (RAM) 232. A basic input/output system 233(BIOS), containing the basic routines that help to transfer information between elements within computer 210, such as during start-up, is typically stored in ROM 231. RAM 232 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 220. By way of example, and not limitation, FIG. 2B illustrates operating system 234, application programs 235, other program modules 236, and program data 237.

The computer 210 may also include other removable/non-removable, volatile/nonvolatile computer storage media. By way of example only, FIG. 2B illustrates a hard disk drive 240 that reads from or writes to non-removable, nonvolatile magnetic media, a magnetic disk drive 251 that reads from or writes to a removable, nonvolatile magnetic disk 252, a nonvolatile magnetic disk 252, and an optical disk drive 255 that reads from or writes to a removable, nonvolatile optical disk 256 such as a CD ROM or other optical media. In addition, FIG. 2B shows a removable media drive 253 that reads from or writes to a removable memory stick 254 or a removable memory card 254. In some examples, the memory card may be a flash memory card or stick. Other removable/non-removable, volatile/nonvolatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory, digital versatile disks, digital video tape, solid state RAM, solid state ROM, and the like. The hard disk drive 241 is typically connected to the system bus 221 through a non-removable memory interface such as interface 240, and magnetic disk drive 251, removable media drive 253, and optical disk drive 255 are typically connected to the system bus 221 by a removable memory interface, such as interface 250.

The drives and their associated computer storage media discussed above and illustrated in FIG. 2B, provide storage of computer readable instructions, data structures, program modules and other data for the computer 210. In FIG. 2B, for example, hard disk drive 241 is illustrated as storing operating system 244, application programs 245, other program modules 246, and program data 247. Note that these components can either be the same as or different from operating system 234, application programs 235, other program modules 236, and program data 237. Operating system 244, application programs 245, other program modules 246, and program data 247 are given different numbers here to illustrate that, at a minimum, they are different copies. A user may enter commands and information into the computer 210 through input devices such as a keyboard 262 and pointing device 261, commonly referred to as a mouse, trackball or touch pad. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 220 through a user input interface 260 that is coupled to the system bus, but may be connected by other interface and bus structures, such as a parallel port, game port or a Universal Serial Bus (USB). A monitor 291 or other type of display device is also connected to the system bus 221 via an interface, such as a video interface 290. In addition to the monitor, computers may also include other peripheral output devices such as speakers 297 and printer 296, which may be connected through an output peripheral interface 295.

The computer 210 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 280. The remote computer 280 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 210, although only a memory storage device 281 has been illustrated in fig. 2B. The logical connections depicted in FIG. 2B include a Local Area Network (LAN)271 and a Wide Area Network (WAN)273, but may also include other networks. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.

When used in a LAN networking environment, the computer 210 is connected to the LAN 271 through a network interface or adapter 270. When used in a WAN networking environment, the computer 210 typically includes a modem 272 or other means for establishing communications over the WAN 273, such as the Internet. The modem 272, which may be internal or external, may be connected to the system bus 221 via the user input interface 260, or other appropriate mechanism. In a networked environment, program modules depicted relative to the computer 210, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation, FIG. 2B illustrates remote application programs 285 as residing on memory device 281. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

Figures 3A-5B illustrate some examples of software modules or software subcomponents that may be present on a computer system that grants membership in a privilege set or on a user computer system that may be part of a privilege set. As described below, the particular naming and division of the modules, routines, features, attributes, methodologies and other aspects are not mandatory, and the mechanisms that implement the technology or its features may have different names, divisions and/or formats.

The software or firmware for provisioning and verifying membership in a privilege set may be located at one or more operating layers of the computer system because different pre-release resources are loaded and identified at different points in time of startup and operation of the computer system. Not all operating layers may access all memory locations of the computer system. For example, in one architecture of a user computer system, such as the multimedia console 100 in FIG. 2A, boot software cannot access a hard disk, such as the media drive 144, during the boot process, so the software loaded by the boot software to check or provision privileges to resources must be stored in memory accessible by the boot software. For example, the privilege check or provisioning code may be part of the boot software itself.

Furthermore, data items such as unique identifiers, privilege set identifiers, and privilege set keys that serve as part of different implementation examples for requesting or checking privileges to access pre-release resources may also be accessible at different layers of operation for access by privilege checking software in those layers.

In addition, pre-release of boot software may require loading via a removable storage medium such as a memory stick, flash memory card, DVD, or CD. Multiple copies of privilege check software may exist at various memory locations in a user computer system, depending on which operating layer, boot, hypervisor, system, or application may be privilege checking or provisioning.

Fig. 3A shows an example of the operational layers stored in an exemplary non-volatile memory 302 (flash memory in this example). Memory 302 represents non-volatile memory that may be located in different areas of a computer system. For example, the boot software 312 in the multimedia console 100 example of FIG. 2A may be stored in the ROM106 or as illustrated by the BIOS 233 in the ROM 231 in the computer 210 example of FIG. 2B. The boot software 312 includes software 310b, referred to for ease of reference only as privilege set checking software. For updates to the boot software itself or other system software that the hypervisor, operating system, or boot software may load, the privilege set check software 301b may obtain membership in the privilege set and verify that membership before loading such software for execution.

One or more unique identifiers 319 of the individual computer systems are also stored in the memory 302 for access even at the boot software layer. Also stored in memory 302 is a key vault 318 that includes a key set like the manufacturer's key, one or more keys unique to the user computer system, and other keys that can be subsequently uploaded in the manufacture of the computer (100, 210). A privilege set identifier 320 is also stored in the memory 302 that indicates which privilege sets the user computer system (100, 210) is a member of. In one example, the privilege set identifier is a bit field, and one or more bits set to a particular value may be used to indicate set membership. In the example of a bit field, a mask may be used to conveniently update set membership to access a pre-release resource without interfering with other memberships indicated in the bit field.

The privilege set identifier may be protected by one or more security features. For example, the privilege set identifier may be included with software data and/or code that is cryptographically integrity protected. In another example, privilege set identifier 320 may be stored in protected non-volatile memory. In another example, a cryptographically protected certificate (e.g., an asymmetric signature) of a particular instance of a user computer system that includes privileges may be used. An example of protected non-volatile memory is memory that is only accessible by the hypervisor.

Other layers of operation of the software in this embodiment include a hypervisor 314 stored in non-volatile memory (e.g., ROM106 of FIG. 2A), which the boot software 312 may cause to be executed by the processor 101 or may be loaded into system memory 143 in other examples. The hypervisor is sometimes referred to as a virtual machine manager, which controls the allocation of processors and resources (e.g., memory). The hypervisor may allow multiple operating systems to share a single hardware and control the allocation of resources among the operating systems.

As shown, the hypervisor 314 may also have a version of privilege set checking software 310h that checks software provisioning and checks privileges for pre-release versions or updates of software that the hypervisor may load. Similarly, system software 316 may also have a version of privilege set checking software 310s to execute when system software 316 loads a software application. One example of system software 316 is a kernel that may also be stored in ROM106 and loaded into system memory 143 by boot software 312 or hypervisor 314.

System software 316 and hypervisor 314 may access privilege set identifier 320 or privilege set key 326, which may be stored on disk (see fig. 3B) instead of in ROM or flash memory. Hypervisor 314 and system software 316 can access a hard disk, such as media drive 144 in FIG. 2A or memory interface 241 in FIG. 2B. In addition, other disks may be accessed by hypervisor 314 and system software 316 via, for example, USB controller 128 in FIG. 2A or via non-volatile memory interface 250 in FIG. 2B.

In some examples, a "flash version" may be used to refer to a version of software that includes boot software, a hypervisor, and system software.

Pre-release software is typically an update, repair, or enhancement of an application (e.g., a gaming application). Software and data items that are part of the pre-release software, when downloaded for the application, may perform at least part of the privilege check before resuming execution.

FIG. 3B shows an example of privilege checking software 310a stored in non-volatile memory 304 as part of a software pre-release application 322. The memory 304 is a hard disk in this example, but may also be stored on removable media. Application pre-release software 322 may also be downloaded and include at least a portion of privilege set check software 310 a. A privilege set identifier 320 and at least one privilege set key 326 are also stored in the non-volatile memory 304.

As will be discussed in more detail below, certain embodiments use security features as added protection: the privilege set identifier is received by the intended user computer system. In addition, data items that include resource privilege set identifiers associated with the resources are also protected.

In some embodiments, a user may receive a secure data item including a privilege set identifier via another computer resource location, such as via an email accessed by the user on a third party computer system other than the user computer system. The user may then download the secure data item and in some cases the pre-release software or firmware onto a removable storage medium, such as a compact disc, memory stick or memory card, or the like. For example, a new flash version including a pre-release boot version or a hypervisor may be retrieved in this manner. The user may insert removable media into a removable media interface, such as the USB controller 128, the removable non-volatile memory interface 250, and the example drives 253, 251, and 255 in FIG. 2A.

FIG. 3B illustrates an example of a removable storage medium 306 storing a secure data item that may be used in one or more embodiments of the technology. In this example, the secure data item 328 includes a privilege set identifier 320 and one or more unique identifiers 319 for the user computer system. In some examples, the one or more unique identifiers may be numbers that the user computer system randomly generates using a random number generator. In addition, the secure data item 328 may also include an encrypted privilege key for use in authenticating a resource or issuing a privilege set identifier.

A key based encryption scheme is typically used to protect the privilege set identifier data item. Symmetric or shared key encryption may be used whereby two communicating computer systems store the same key for encryption. In some examples, different keys may be used, but there is a defined relationship between them, so that one key can obtain another key from its key quite easily. In some examples, a stream cipher that encrypts one bit at a time may be used. In other examples, a block cipher is used that outputs encrypted data of a different length than the input length of unencrypted data. Some examples of standards for block ciphers are based on and derived from the Data Encryption Standard (DES) and the International Data Encryption Algorithm (IDEA).

Asymmetric encryption such as widely used public key encryption may also be used. Two keys are included. The first computer system publishes the public key for use by the second computer system to send data to. The private key is known only to the first computer system. The keys may be related, but in general it is very difficult to derive the private key from the public key using a defined relationship. The two keys or the asymmetric encryption cipher used by them are usually reversible, meaning that the private key can be used to encrypt data that only the public key can decrypt, and vice versa. Examples of passwords that can be used are RSA and other Public Key Cryptography Standards (PKCS).

The reversibility of asymmetric encryption can also be used to verify identity, as in the case of digital signatures. Message digest algorithms, along with asymmetric encryption, may be used to implement digital signatures. Message digest algorithms implement hash functions that are very difficult to reverse, so that it is likely that the resulting hash value will be unique. A hash function receives variable-sized input data and outputs a fixed-length hash value (e.g., a string). Some examples of message digest algorithms are the Secure Hash Algorithm (SHA) and MD2, MD4, MD5, and variations thereof.

In one example, a signed digital certificate may be created and verified as follows. The sender computer system generates a message digest, i.e., a hash value of the message content, and encrypts the message digest using the sender's private key. The recipient computer system receives the message and decrypts the message digest using the sender's public key. The recipient computes the message digest. If the recipient's message digest or hash value does not match the decrypted message digest, then the signature is not verified. Some examples of passwords that can be used to generate and verify digital signatures of certificates are RSA, Digital Signature Standard (DSS), and variations thereof.

In other examples, the secure data item may also be included in a security blob as described in RFC 2743.

Fig. 4A illustrates an example of software components that may be included in an embodiment of privilege set check software 310 shown in the various operating layers of fig. 3A-3C. The auto-provisioning software 402 performs processing of the request for the privilege set identifier so that the user computer system accesses the resource. Examples of such processing are further described below in the discussion of the figures.

In some instances, the user computer system will first obtain the resource, but the resource will not execute until the user computer system has membership in the privilege set. For example, the user may purchase or receive the pre-release resource by mail or in a store. In the case of software, a user may be able to download pre-release software, but unable to execute the software without requesting membership in the same privilege set as the software from an authorized computer system. In other cases, downloading software or firmware cannot be permitted until the privilege set identifier of the user computer system has been updated to indicate membership in the appropriate privilege set. Also, in some embodiments, a user may request membership in a particular privilege set without selecting a particular resource at the time of the request.

The membership verification software 404 verifies that a particular resource shares the same membership as the user computer system before execution of the resource is permitted. Examples of such processing are further described below in the discussion of the figures.

FIG. 4B illustrates another example of software for privilege set checking that may be included, at least in part, in a downloaded software pre-release. In this example, the membership verification software 404 is included in the downloaded software pre-release 322. In other examples, the pre-release may also include provisioning code.

The entity providing the pre-release resource provides hardware and software for communicating with the user computer system to automatically provision the privilege set. For example, with respect to the gaming console 12 of FIGS. 1A and 1B, the entity may be an online gaming service of the console that is accessible to embodiments of the computing environment 12 via the Internet. In addition, the entity provides hardware and software resources for tracking which pre-release resources are members of which privilege sets, and for determining which user computer systems qualify for which privilege sets. The entity's computer system may also assign security risk levels based on the logic and input data, such as the security risk factors described above. Example embodiments of these hardware and software components are described in fig. 5A and 5B.

FIG. 5A illustrates an example embodiment of a system architecture for a membership authorization computer system that includes hardware and software components. The system 500 includes a processing unit 502, which may include one or more processors, and includes local memory 503, which may embody various cache designs.

The communication bus 504 provides a communication path between various system components. For example, bus 504 provides processing unit 502 with access to memory controller 506, which memory controller 506 controls access to volatile memory 508 and non-volatile memory 510 in this example. Some examples of such non-volatile stored data are application programs, such as operating system 512, membership authorization software 514, database interface 526 for access via network interface 522 databases, such as privilege set database 527 and resource database 529 that stores software and software pre-releases discussed in detail below, and other software applications 516. These are merely examples of items that may be stored in non-volatile memory 510, and the memory of course includes other data and software.

The system 500 also includes one or more output device drivers 518 to control output devices 519 (e.g., a display, audio output devices), and at least one input device driver 520 to interpret input from input devices 521, such as a keyboard and pointing device.

One or more network interfaces 522 are also provided so that the membership authorization computer system 500 can communicate with one or more computer networks, such as through the internet 80, or access one or more databases 527, 529 through an internal network. The interface 522 may include wired, wireless, or both.

FIG. 5B illustrates an example of software components and data items that may be included in or utilized by a membership authorization software application. Many data items may be stored in a database like the embodiment of privilege set database 527 shown in detail in FIG. 5B.

Each privilege set is associated with a security risk level. In this embodiment, the security risk level may be defined in the risk level policy data item 552. Alternatively, the security risk level policies 552 for each set may be stored. The privilege set identifier 554 and privilege set key 556 may be linked to a risk policy. Examples of risks include a limit on the number of user computer systems allowed within a set, thereby limiting the number of user systems that may be affected by an integrity failure. For example, the risk pool or audience size for a beta version of a software gaming application may be limited to fifty thousand out of fifty million computer systems. Boot software updates may be limited to five thousand user computer systems. Other risk factor examples include the level of testing and authentication success performed on the pre-release resource, and the operational layer of the user computer system whose operation will be affected by the failure of the pre-release resource.

Set membership criteria 562 includes criteria to be satisfied in order to be granted membership within a privilege set. One example is whether a limit on the number of users or user computer systems in the collection has been reached. In another example, a user computer system must possess the required resources. One example of a required resource is a particular version or versions of a computing resource, such as a kernel or hypervisor, indicated by a version number or range of version numbers. For example, the user computer system may lack boot software updates that the user computer system can repair by updating itself with the latest version of flash software.

Privilege set identifier 554 is set to indicate the particular privilege set membership of the resource and user computer system. At least one privilege set key 556 is identified for each privilege set. In the case of a public-private key pair, the privilege set key may be the public key for the private key stored only at the user computer system, or may be the private key paired with the public key sent to the user computer system. The member profile 558 of the user computer system includes a unique identifier for the system, a version number of a resource on the user computer system, a link to one or more privilege set identifiers, and one or more privilege set keys that are sent to identifier membership in different sets.

The software components in FIG. 5B use the data in the privilege set database 527 to perform their various functions. The privilege set qualification software 534 determines when the user computer system can be a member within the same privilege set as the resource based on privilege set membership criteria 562. The qualification software 534 notifies the member profile update software 542 of the new member, and the member profile update software 542 prepares the profile. Secure data item creation model 536 creates a secure data item such as secure data item 328 shown in FIG. 3C. The privilege transmission module 540 issues the secure data item including the privilege set identifier to the user computer system in response to the user computer being qualified.

The resource privilege set identifier generation software 538 generates a resource privilege set identifier for a resource that may be stored in the resource database 529 based on the resource's assigned privilege set. The resource profile in database 529 is updated to include the resource privilege set identifier. The generation software 538 may also insert the identifier into the resource in some cases or separately send to the user computer system via the privilege transfer module 540.

For illustrative context, fig. 6-13 are discussed with reference to the embodiments of fig. 2A-5B, although other computer system embodiments may implement the methods of fig. 6-13.

Before a user computer system requests membership in a set, an entity such as an online gaming service must establish a privilege set, formulate membership criteria and security risk levels such as per database (like privilege set database 527) available to software in order to automatically manage the privilege set on the entity side.

FIG. 6 is a flow diagram of an embodiment of a method 600 for automatically provisioning privilege sets. A remote membership authorization computer system like system 500 in fig. 5A and its software, such as membership authorization software 514, may implement the method. The discussion of fig. 6 references membership authorization software 514 and its sub-modules for illustrative context only. In step 602, the resource privilege set identifier generation module 538 identifies the assigned security risk level for the computing resource and, in step 604, associates the resource with the privilege set based on the identified security risk level. In one example, the security risk level may be determined and assigned by software, such as privilege set identifier generation module 538. In one example, the entity person may have entered metadata for the resource indicating the security risk level via the input device 521, which the generation module 538 stores in the resource database 529. In another example, metadata may have been entered for the resource, such as the risk pool size, the type of resource being modified by the pre-release resource, or the level of success of the certification test. Based on the weighting of the risk factors, the privilege set identifier generation module 538 may apply logic to assign a security risk level to the resource. The generation module 534 then generates a resource privilege set identifier for the resource that identifies it as a member of the privilege set.

In step 606, the privilege set qualification software 534 receives a request from a remote computer system to access a resource. In this embodiment, the request includes one or more unique identifiers of the user computer system. These unique identifiers are useful for security purposes and in tracking different user computer systems within different sets.

The privilege set qualification software 534 determines in step 608 whether the requesting user computer system has membership in the same privilege set as the resource. For example, the qualification software 534 may determine from the provided unique identifier or identifiers which versions or updates of the necessary flash software or other application software the user computer system has or lacks. The qualification software 534 can also determine whether a limit on the viewer size or the risk pool size of the privilege set has been reached.

In response to the user computer system having membership, the privilege transmission module 540 distributes a privilege set identifier indicating membership in the resource set to the user computer system in step 610. If the user computer system is not eligible for access, then the qualification software 534 may send a message to the user computer system indicating that access to the resource has been denied in step 612. The message may indicate the reason for the rejection, such as a lack of an update or version of the resource, so the user can repair this and attempt to register as a member again.

As shown in the more detailed implementation examples below, the secure data item creation module 536 may be used by the privilege set qualification software 534, the resource privilege set identifier generation module 538, or the privilege transmission module 540 to protect the privilege set identifier of a user or resource in the secure data item.

FIG. 7 is a flow diagram of an embodiment of a method for associating resources with privilege sets that may be used to implement step 604. The secure data item creation module 536 generates 702 a secure data item including the resource privilege set identifier and includes 704 the secure data item in the resource. For example, in software pre-release, the secure data item is stored in data or bits that are part of the pre-release software.

FIG. 8 is a flow diagram of an embodiment of a method for distributing a privilege set identifier indicating membership to a user computer system, as may be used to implement step 610 of FIG. 6. If the user computer system qualifies, the qualification software 534 assigns a privilege set identifier to the user computer system that indicates membership in the resource privilege set in step 802. The software 534 sends a message to the secure data item creation software 536 indicating the assignment. The secure data item 804 generates, in this example, an integrity certificate that includes a privilege set identifier and, in this example, one or more unique identifiers.

In one embodiment, the privilege sets have locations in a hierarchy. In some examples, membership within a privilege set provides access not only to resources associated with that privilege set, but also to resources associated with privilege sets that are deemed to have lower or less privileges. In step 806, the secure data item creation module signs the certificate with the key 556 specified for the privilege set of the assigned privilege set identifier. The secure data item creation module 536 alerts the privileged transmission module 540 that the secure data item (in this case the signed certificate) may be transmitted and the privileged transmission module 540 sends the certificate for use by the remote user computer system in step 808.

The user computer system also includes software for requesting and automatically provisioning its system as a member of the privilege set, thereby gaining access to the pre-release computing resource. In the provisioning process, the user computer system communicates with a remote computer system of the entity controlling the resource to obtain membership in the privilege set and thereby obtain permission or privileges to access the resource. One example of accessing a resource is executing the resource. The user computer system performs the verification of its own privileges of the execution resources locally. Figures 9 through 13 provide details of an embodiment of a method involving a user computer system attempting to access a pre-release resource associated with a privilege set. For illustrative purposes only, fig. 9-13 are discussed in the context of privilege set checking software 310 and its automatic provisioning software 402, and additionally membership verification software 404 of software pre-release 322 of fig. 4A and 4B. Of course, the methods may be performed in user computer systems having different configurations of hardware and software.

FIG. 9 is a flow diagram of an embodiment of a method for a user computer system to access a pre-release computing resource associated with a privilege set. When a user computer system attempts to register membership in a privilege set, the user computer system performs processing to receive, validate and store privilege identifiers to access resources such as higher risk pre-release software.

Pre-release resources such as beta software releases have a higher risk of security breaches due to, for example, fewer tests than publicly available software. Another factor contributing to a higher level of risk security is the degree of damage to the user computer system due to the operational layer of the user computer system being affected by the requested pre-release resource. For example, with beta flash releases of changes to boot software, hypervisor software or kernel software may cause catastrophic failure of a user computer system.

As an exemplary context, a user input to a user computer system, such as the multimedia console 100 or the computer system 210, indicates a request to download a prototype upgrade to a game application. In step 902, the privilege set check software 310 executing on the processor 101, 220 of the user system automatically provides membership in the privilege set of the computing resource for the user computer system. If the provisioning was successful, then in step 904, the privilege set check software 310 verifies the user computer system's membership in the privilege set prior to executing the resource. In another example, the resource is a software prototype 322, and its membership verification software 404 executing on the user computer system performs at least part of the verification of step 904.

FIG. 10 is a flow diagram of an embodiment of a method that a user computer system automatically provisions to obtain membership in a privilege set that may be used to implement step 902. The automated provisioning software 402 sends the one or more unique identifiers of the user computer systems in the request for the pre-release resource to the remote authorization computer system in step 1002. Auto-provisioning software 402 determines in step 1004 whether the request is approved based on the received message. If the request is not approved, then in step 1006, automated provisioning software 402 receives a message indicating that access is denied. As previously described, the message may indicate a reason for the rejection, such as a lack of a software update, which the user may then download and attempt to register again.

In step 1012, the automatic provisioning software 402 receives the secure data item including the privilege set identifier from the remote authorization system 500 and determines in step 1014 whether the privilege identifier is valid. If not, a message is sent to the remote authorization system indicating that the received privilege set identifier is invalid in step 1016. Some examples of the basis for invalidation include failure to decrypt the privilege set identifier, at least one unique identifier that does not match the transmitted unique identifier, or other mismatches between data items in the secure data item.

In other examples, the secure data item may be sent to the user via a computer system other than the user computer system. For example, a secure blob or certificate including a privilege set identifier may be sent to an email address. The user may then download the secure data item 328 onto the removable storage media 306 as in fig. 3C. The user inserts the removable storage media 306 into the user's computer system and the auto-provisioning software 402 reads the secure data item from the removable storage media 306.

In response to the privilege set identifier being valid, the auto-provisioning software stores the received privilege set identifier locally in memory (e.g., of the user computer system) in step 1018. Optionally, at this point, the resource may be placed in the user computer system in step 1020. In the case of firmware, the firmware may be downloaded and the computer system restarted to direct software identification. In the case of software, the software may be placed by downloading the software to a user computer system, and the kernel may perform privilege set checking, for example, in response to a user request to execute the software.

Particularly in the case of software and firmware, a resource may be downloaded first and then provisioning of the user computer system performed to see if the system is able to access the resource if the system does not already have a privilege set identifier that permits access to the resource. In other cases, the privilege set identifier must be obtained even if software or firmware is downloaded.

FIG. 11 is a flow diagram of an embodiment of a method for determining the validity of a privilege set identifier received from a remote authorization computer system that may be used to implement step 1014 of FIG. 10. The automatic provisioning software 402 receives the secure data from the remote authorized computer system in step 1102 and determines whether the local privilege set key can retrieve the privilege set identifier from the secure data item in step 1104. If the privilege set identifier is not successfully retrieved, the provisioning software 402 sends an error message to the remote authorization system 500 in step 1106.

In this embodiment, the locally stored privilege set key may be a private key corresponding to a public key sent by the user computer system as the unique identifier. Instead, the privilege set key may be a public key corresponding to a private key sent by the user computer system as a unique identifier or with a shared key of the remote authorization system 500. Additionally, the remote authorization system 500 may send the encrypted privilege set key before sending the secure data item. The provisioning software 402 decrypts the transmitted key and stores it locally for use in receiving the secure data item that includes the privilege set identifier. As shown in fig. 3A, 3B, and 3C, some keys in the key vault 318 are accessible to lower level software, such as boot software 312, hypervisor 314, and system software 316, and other keys may be stored at the application layer as in fig. 3B.

As previously described, in one embodiment there is a hierarchy of privilege sets. The position in the hierarchy is related to the privilege level of the set. Different security measures may be used to protect or ensure privilege set identifiers for privilege sets located at different locations in the hierarchy. For example, the key or identifier of the privilege set itself may be included with the software data and/or code that is cryptographically integrity protected. In the examples below, different signing keys may be associated with different sets of privileges. For example, a user computer system unique key known only to a unique user computer system may be used to protect integrity. Different privilege set identifiers representing different levels of privilege may be stored in memory locations with different levels of protection, which typically correspond to the risk levels of privilege sets in the hierarchy.

Different locally stored keys may be specified by the auto-provisioning software 402 to decrypt privilege sets of a particular privilege level. If the key can be retrieved, an additional security check is performed in step 1108 to determine if the retrieved privilege set key has an acceptable privilege level for the privilege set identifier in the secure data item.

For example, the auto-provisioning software 402 may try different keys in the order of, for example, the highest privilege designated key to the lowest privilege designated key until retrieval is successful or no more keys are available for trial. In another example, the privilege level of the resource is identified in a previous exchange for the request, and the key specified for that privilege level is first attempted. In one example, if the privilege level of the privilege set identifier is different than the privilege level of the retrieved key, the retrieved privilege set key does not have a privilege level that is acceptable for the privilege set identifier. As a result, the identifier is deemed invalid and the provisioning software 402 sends an error message to the remote authorization system 500 in step 1106.

If the retrieved key has a privilege level that is acceptable for the privilege set identifier, as another validity check, automatic provisioning software 402 determines whether one or more unique identifiers in the secure data item correspond to locally stored and previously transmitted identifiers in step 1110. For example, the same identifier as the transmitted identifier may prove to correspond. In other examples, a correspondence is shown if the unique identifier is a corresponding member of a pair or a derivative of a stored unique identifier. If there is a mismatch with at least one of the one or more unique identifiers, the provisioning software 402 sends an error message in step 1106. If the one or more unique identifiers all correspond, the provisioning software 402 updates the locally stored privilege set identifier based on the privilege set identifier in the secure data item in step 1112. In one example, the privilege set identifier may be a bit field in which bits are set to a predetermined specified value to indicate membership in the privilege set. One convenient way to verify membership in a privilege set is by applying a mask to see if one or more bits for that privilege set are set to a specified value. In addition, locally stored privilege set identifiers with membership in other sets can be conveniently updated to identify the latest membership obtained in automatic provisioning by applying a mask that changes only the bits that need to be updated.

Further, in some embodiments, the secure data item includes a new privilege set key from the authorization system 500. The privilege set key has the privilege level of the set identified in the privilege set identifier. The key may also be stored locally in the user computer system, such as in the key vault 318 or in a data storage location 326 on the disk. In one example, the privilege set key may be a private key in a public-private key pair.

In one example, the privilege set identifier grants the user computer system permission to access an integrity check of all resources associated with the privilege set indicated in the privilege set identifier. For example, once a user computer system has membership in a privilege set, the user computer system need not undergo a provisioning method to obtain another privilege set identifier in a request to download or otherwise obtain other resources associated with the same set.

FIG. 12 is a flow diagram of an embodiment of a method for verifying membership of a user computer system within a privilege set associated with a pre-release resource that may be used to implement step 904 of FIG. 9. Depending on the operating level of the pre-release computing resource, the operating level of the software (e.g., boot, hypervisor, or kernel) will receive a request to execute the pre-release computing resource in step 1202.

The membership verification software 404 retrieves the resource privilege set identifier from the pre-release resource in step 1204 and determines whether the privilege set identifier of the computer system indicates membership in the set indicated by the resource privilege set identifier in step 1206. For example, verification software 404 may compare them to see if the same bit field is set to indicate membership. If the user computer system and the resource are not members of the same privilege set, then the membership verification software 404 displays a message indicating that the request to execute the resource is not authorized in step 1208. In addition, the verification software 404 stops execution of the pre-release resource in step 1212. For example, a beta issue update for the game application will not be performed.

If the privilege set identifier indicates that the resource is a member of the same privilege set as the user computer system, then control is returned to the operational layer of the user computer system that controls the pre-release resource, which is executed in step 1210. For example, if the user computer system has the privilege to execute a hypervisor patch, or other release of the β (test) bit, or data downloaded for the hypervisor, then privilege check software 310b of boot software 312 returns control to the boot software that invoked it, and the boot software passes control to the hypervisor load code of boot software 312.

FIG. 13 is a flowchart of an embodiment of a method for determining whether a user computer system shares membership with a pre-release resource within the same set, which may be used as one example for implementing step 1206 of FIG. 12. The membership verification software 404 determines in step 1302 whether the privilege set key signed an integrity certificate including the resource privilege set identifier. If the certificate is not signed by the privilege set key, the method returns to steps 1208 and 1212.

If the certificate has been signed by the privilege set key, the verification software 404 determines if the signing privilege set key is at a privilege level that is acceptable for the resource privilege set identifier in step 1306. For example, a key of a lower privilege set that decrypts a resource privilege set identifier indicating membership in a higher privilege set identifies an invalid certificate. If the signing key lacks the necessary privileges, the method returns to steps 1208 and 1212.

In step 1308, the membership verification software 404 determines whether the privilege set identifier of the computer system indicates membership in the set indicated by the resource privilege set identifier. For example, in the case where privilege set membership is indicated by one or more bits set in a bit field, a mask may be applied to compare the two identifiers to see if the specified bit is set to a value indicating membership. Again, if it is determined that the resource does not share membership in the same set as the user computer system, the method returns to steps 1208 and 1212.

If the resource is an intra-set member of the same user computer system, then the validation software 404 or some other code of the privilege set checking software 310 determines whether the expiration criteria in the integrity certificate are met in step 1310. If the expiration criteria are not met, the method returns to steps 1208 and 1212. If the expiration criteria are met, the method returns to step 1210 and the pre-release resource is executed.

In some examples, the expiration criteria may be time-based criteria. For example, the set date may be provided as the end date of execution of the software pre-release. In another example, the time-based criterion can be a time period beginning at a specified starting point in time, such as the time of the pre-release of the downloaded software. In other examples, the expiration criteria may be that the resource only works with a particular version of software and hardware components on the user computer system-e.g., a beta boot software update may have expiration criteria running on a version of the boot software that was previously publicly released. The user computer system may run the test update whenever the beta update is released with the boot software before. However, the user must download a new publicly released version of the flash memory software, including boot, hypervisor, and system software, in order to play the new game on a gaming console like the multimedia console 100. This limits the range of risks in the time domain and at which the user would likely wish to play a new game.

The present technology may be embodied in other specific forms without departing from its spirit or essential characteristics. Similarly, the particular naming and division of the modules, routines, features, attributes, methodologies and other aspects are not mandatory, and the mechanisms that implement the technology or its features may have different names, divisions and/or formats. Furthermore, as will be apparent to one of skill in the art, the modules, routines, features, attributes, methodologies and other aspects of the disclosed embodiments can be implemented as software, hardware, firmware or any combination of the three. Of course, where a component (an example of which is a module) is implemented as software, the component can be implemented as a standalone program, as part of a larger program, as a plurality of separate programs, as a statically or dynamically linked library, as a kernel loadable module, as a device driver, and/or in each and any other way known now or in the future to those of skill in the programming arts.

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims (8)

1. A method for accessing a pre-release computing resource associated with a privilege set, comprising:

provisioning a privilege set (902) including a set of user computer systems and pre-release computing resources to a user computer system for membership in the privilege set, and the privilege set having a security risk level indicating to an operating layer of the user computer system which pre-release computing resource to change by:

sending one or more unique identifiers of the user computer system to a remote authorization computer system (1002);

receiving and locally storing a privilege set identifier from the remote authorization system in response to membership criteria of the privilege set being met;

requesting and storing the pre-release computing resource from the remote authorization system on the user computer system;

verifying that the user computer system has membership in the privilege set required for the resource based on the privilege set identifier and a resource privilege set identifier for the resource (904):

receiving a request to execute the pre-release computing resource;

retrieving the resource privilege set identifier from the locally stored pre-release computation; and

determining whether the locally stored privilege set identifier matches the locally stored resource privilege set identifier; and

executing the pre-release computing resource in response to the locally stored privilege set identifier matching the resource privilege set identifier.

2. The method of claim 1, wherein:

verifying that the user computer system has membership in the privilege set required for the resource further comprises:

verifying (1302) whether an integrity certificate including the resource privilege set identifier has been signed by a privilege set key stored locally in the memory accessible by the user computer system; in response to verification of the signature of the privilege set key, determining whether a signing privilege set key is of an acceptable privilege level for the resource privilege set identifier (1306); and in response to the signing key not being at the acceptable privilege level, halting execution of the pre-release resource (1212).

3. The method of claim 1, wherein the security risk level represents a level of security test authentication success for the pre-release resource.

4. A user computer system, comprising:

a processor (101, 220);

a communication interface (124, 270) accessible by the processor to communicate with a remote computer system (500) for downloading a software pre-release (322) associated with a privilege set (320), the privilege set comprising a set of user computer systems and pre-release computing resources and the privilege set having a security risk level of the software pre-release indicating to an operational layer of the user computer systems which pre-release computing resource changes; and

a memory (302, 304, 306) accessible by the processor, the memory storing software (310) for programming the processor to obtain a privilege set identifier from the remote computer system and store the identifier in the memory and for storing a downloaded software pre-release;

the privilege set identifier (320) indicates membership of the user computer system within the privilege set, the membership granting permission to run the software pre-release (322);

the memory stores the software pre-release, for programming the processor to verify that the user computer system has membership in the privilege set associated with the downloaded software pre-release based on a match of the privilege set identifier with a resource privilege set identifier included in the downloaded software pre-release in response to a request to execute the software pre-release, and to stop execution of the software pre-release in response to a lack of membership of the user computer system.

5. The user computer system of claim 4,

the privilege set identifier of the user computer system has been included with the software pre-release that is otherwise cryptographically integrity protected.

6. The user computer system of claim 4,

the privilege set is one of a hierarchy of privilege sets; and

at least two identifiers, each of which is associated with a different set of privileges in the hierarchy, are protected by different security measures.

7. A method for automatic provisioning of privilege sets, comprising:

associating (604) a first pre-release computing resource with a first privilege set in a privilege set hierarchy by generating a resource privilege set identifier for the first pre-release computing resource, each privilege set in the hierarchy including a set of user computer systems and one or more pre-release computing resources and having a security risk level defined for each privilege set level in the hierarchy, each security risk level indicating to an operational layer of a respective one of the respective sets of user computer systems which respective one or more pre-release computing resources of the respective privilege set changed;

generating (702), for each user computer system that satisfies membership criteria of the first privilege set, a privilege set identifier that indicates membership in the first privilege set;

distributing the privilege set identifier and the first pre-release computing resource to the each user computer system that satisfies membership criteria for the first privilege set (610);

determining whether the privilege set identifier matches a resource privilege set identifier of the first pre-release computing resource; and

executing the first pre-release computing resource in response to the privilege set identifier matching a resource privilege set identifier of the first pre-release computing resource.

8. The method of claim 7, wherein distributing the privilege set identifier and the first pre-release resource to the each user computer system that satisfies the membership criteria for the first privilege set is independent of granting the user computer system use of the resource.