|Publication number||US20060059338 A1|
|Application number||US 11/265,899|
|Publication date||Mar 16, 2006|
|Filing date||Nov 3, 2005|
|Priority date||May 9, 2000|
|Also published as||US7536726, US7577853, US7584512, US7603721, US20060053283, US20060053284, US20060059352, US20060059355, US20060059366, US20060064585, US20060064595, US20060064596|
|Publication number||11265899, 265899, US 2006/0059338 A1, US 2006/059338 A1, US 20060059338 A1, US 20060059338A1, US 2006059338 A1, US 2006059338A1, US-A1-20060059338, US-A1-2006059338, US2006/0059338A1, US2006/059338A1, US20060059338 A1, US20060059338A1, US2006059338 A1, US2006059338A1|
|Inventors||David Feinleib, Carl Gulledge, Wassef Haroun, Joachim Kempin, Kurt Kolb, Brian Moran, Edward Stubbs, Jacob Swed|
|Original Assignee||Microsoft Corporation|
|Export Citation||BiBTeX, EndNote, RefMan|
|Referenced by (1), Classifications (7), Legal Events (1)|
|External Links: USPTO, USPTO Assignment, Espacenet|
This application is a divisional application of U.S. patent application Ser. No. 09/568,095, filed May 9, 2000, which is hereby incorporated by reference herein.
This invention relates to computers and operating systems. More particularly, the invention relates to restricting usage of software and hardware on a computer.
Computer technology is continually advancing, resulting in new computers that are more powerful and cheaper than their predecessors. Such advancement has had a significant affect on people, expanding the types of tasks people perform with their computers as well as increasing the number of people who use computers.
Many computers are currently manufactured with a general purpose “open architecture” operating system installed. An open architecture operating system refers to an operating system that makes numerous functions available to the user and also allows the user to modify the computer by installing additional software programs on the computer that provide additional functionality to the user or by removing software programs from the computer. The operating system can make a wide variety of functionality available to the user, such as recreational or educational programs, reference programs, productivity programs (such as word processing or database functionality), communications programs, etc.
One problem inherent in open architecture systems is they are generally licensed with complete use rights and/or functionality that may be beyond the need or desire of the system purchaser. Consequentially, the purchase price of these systems being indifferent to usage scenarios means users with limited needs pay the same rate for these systems as those with universal needs.
An additional problem with open architecture systems is that virtually anyone can write an application that can be executed on the system. Some applications or devices may not operate properly due to a problem with the application or associated driver, yet many users associate such problems with the manufacturer of the system. Thus, it would be beneficial to provide a way for the manufacturer of the system to control the extensibility of the system.
The invention described below addresses these disadvantages by providing restricted software and hardware usage on a computer.
According to one aspect of the invention, a client computer runs an operating system that executes applications by loading them using an application loader and executes device drivers for peripheral devices by loading the drivers using a device loader. The client computer also includes a digest catalog that includes digital signatures for program files that can be executed by the client computer. When attempting to load an application or driver, the appropriate loader checks whether a digital signature for the corresponding program file(s) is included in the digest catalog. If no such digital signature is included, then the loader does not load the program file(s) corresponding to the application or driver.
According to another aspect of the invention, the digest catalog includes, for each program file corresponding to an application or driver that should be executable by the computer, a digitally signed hash value that is generated from a hash function based on the corresponding program file. When attempting to load a particular file, the loader generates a hash value and compares it to the decrypted hash values in the digest catalog. If the comparison results in no matches, then the corresponding program file (and thus the application or driver) is not loaded.
According to another aspect of the invention, a consumer initially purchases a computer with restricted functionality at a price that is less than the price that would be charged for a computer with full functionality. Subsequently, the user can, at an additional cost, acquire a digital key that allows the restrictions to be removed, upgrading the computer to full functionality.
According to another aspect of the invention, a consumer can execute additional applications or drivers on his or her computer by obtaining appropriate digital signatures for the additional applications or drivers to add to the digest catalog. In exchange for payment, a software or hardware vendor will acquire a digital signature(s) for the appropriate program files from the supplier of the program files. The digital signature(s) will then be transmitted to the consumer in exchange for payment to the vendor. The digital signature(s) can then be added to the digest catalog at the consumer's computer, so that the next time he or she attempts to execute the application or driver the appropriate signatures will be in the digest catalog and the program files will be loaded.
According to another aspect of the invention, a consumer can execute additional applications or drivers on his or her computer by obtaining the appropriate digital signatures for such applications or drivers from the same OEM (original equipment manufacturer) as manufactured the consumer's computer. The consumer's computer executes only applications that have in the digest catalog a digital signature of the OEM. Thus, the OEM can limit what additional applications are made available to the consumer.
According to another aspect of the invention, the OEM maintains a digest catalog that can be made available to the consumer's computer (either locally at the computer or remotely). The consumer, in exchange for payment, is given access to the digest catalog so that any applications for which a corresponding digital signature exists in the OEM's digest catalog can be executed at the client computer. The consumer can be given a limited amount of time (e.g., one month or one year) within which he or she can access the OEM's digest catalog.
The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings. The same numbers are used throughout the figures to reference like components and/or features.
Client computer 102 represents any of a wide variety of conventional computing devices. Examples of client computers 102 include personal computers (e.g., portable, palm-top, or desktop computers), microprocessor-based or programmable consumer electronics (e.g., a “WEBTV” terminal or a gaming console), etc.
Supplier 104 represents the source of additional electronic content, such as software applications or other files including instructions and/or data for a software application. Supplier 104 can be the actual author(s) of the electronic content, or alternatively an agent of the author(s) or other intervening device(s) between the actual author(s) and the network 110. The electronic content can be designed to be a complete product by itself when executed by computer 102, or alternatively can be designed to work in conjunction with other software or hardware component(s).
Vendor 106 is a retailer of the electronic content provided by supplier 104. Examples of vendor 106 include an Independent Software Vendor (ISV) or an Independent Hardware Vendor (IHV) that sell the electronic content provided by supplier 104 for use with computers 102.
OEM 108 is a manufacturer and retailer of computers 102. OEM 108 may also be a retailer of the electronic content provided by supplier 104.
The bus 148 represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. The system memory includes read only memory (ROM) 150 and random access memory (RAM) 152. A basic input/output system (BIOS) 154, containing the basic routines that help to transfer information between elements within computer 142, such as during start-up, is stored in ROM 150. Computer 142 further includes a hard disk drive 156 for reading from and writing to a hard disk, not shown, connected to bus 148 via a hard disk driver interface 157 (e.g., a SCSI, ATA, or other type of interface); a magnetic disk drive 158 for reading from and writing to a removable magnetic disk 160, connected to bus 148 via a magnetic disk drive interface 161; and an optical disk drive 162 for reading from or writing to a removable optical disk 164 such as a CD ROM, DVD, or other optical media, connected to bus 148 via an optical drive interface 165. The drives and their associated computer-readable media provide nonvolatile storage of computer readable instructions, data structures, program modules and other data for computer 142. Although the exemplary environment described herein employs a hard disk, a removable magnetic disk 160 and a removable optical disk 164, it should be appreciated by those skilled in the art that other types of computer readable media which can store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks, random access memories (RAMs) read only memories (ROM), and the like, may also be used in the exemplary operating environment.
A number of program modules may be stored on the hard disk, magnetic disk 160, optical disk 164, ROM 150, or RAM 152, including an operating system 170, one or more application programs 172, other program modules 174, and program data 176. Operating system 170 can be any of a variety of operating systems, such as any of the “Windows” family of operating systems available from Microsoft Corporation of Redmond, Wash. A user may enter commands and information into computer 142 through input devices such as keyboard 178 and pointing device 180. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are connected to the processing unit 144 through an interface 182 that is coupled to the system bus. A monitor 184 or other type of display device is also connected to the system bus 148 via an interface, such as a video adapter 186. In addition to the monitor, personal computers typically include other peripheral output devices (not shown) such as speakers and printers.
Computer 142 can optionally operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 188. The remote computer 188 may be another 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 computer 142, although only a memory storage device 190 has been illustrated in
When used in a LAN networking environment, computer 142 is connected to the local network 192 through a network interface or adapter 196. When used in a WAN networking environment, computer 142 typically includes a modem 198 or other means for establishing communications over the wide area network 194, such as the Internet. The modem 198, which may be internal or external, is connected to the system bus 148 via a serial port interface 168. In a networked environment, program modules depicted relative to the personal computer 142, or portions thereof, may be stored in the remote memory storage device. 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.
Computer 142 can also optionally include one or more broadcast tuners 200. Broadcast tuner 200 receives broadcast signals either directly (e.g., analog or digital cable transmissions fed directly into tuner 200) or via a reception device (e.g., via an antenna or satellite dish (not shown)).
Generally, the data processors of computer 142 are programmed by means of instructions stored at different times in the various computer-readable storage media of the computer. Programs and operating systems are typically distributed, for example, on floppy disks or CD-ROMs. From there, they are installed or loaded into the secondary memory of a computer. At execution, they are loaded at least partially into the computer's primary electronic memory. The invention described herein includes these and other various types of computer-readable storage media when such media contain instructions or programs for implementing the steps described below in conjunction with a microprocessor or other data processor. The invention also includes the computer itself when programmed according to the methods and techniques described below. Furthermore, certain sub-components of the computer may be programmed to perform the functions and steps described below. The invention includes such sub-components when they are programmed as described. In addition, the invention described herein includes data structures, described below, as embodied on various types of memory media.
For purposes of illustration, programs and other executable program components such as the operating system are illustrated herein as discrete blocks, although it is recognized that such programs and components reside at various times in different storage components of the computer, and are executed by the data processor(s) of the computer.
In the discussion below, embodiments of the invention will be described in the general context of computer-executable instructions, such as program modules, being executed by one or more conventional personal computers. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate that various embodiments of the invention may be practiced with other computer system configurations, including hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. In a distributed computer environment, program modules may be located in both local and remote memory storage devices.
Alternatively, embodiments of the invention can be implemented in hardware or a combination of hardware, software, and/or firmware. For example, one or more modules for implementing the invention can be embodied in one or more application specific integrated circuits (ASICs).
Applications 202 represent software applications that can be executed by computer 102. Any of a wide variety of software applications can be executed by computer 102, including productivity, recreational, educational, entertainment, etc. applications. Device drivers 204 represent software modules that include instructions and/or data. A device driver 204 controls a corresponding peripheral device, allowing operating system 200 to communicate with the peripheral device when coupled to computer 102. Examples of such peripheral devices include input devices (such as digital cameras, scanners, keyboards, cursor control devices, etc.), output devices (such as monitors, printers, etc.), and combinations thereof (e.g., modems, network adapters, etc.).
Selected components of operating system 200 are illustrated in
Device loader 206 includes instructions for loading device drivers 204 stored in one or more files of nonvolatile memory into the volatile system RAM. Once loaded into system RAM, the processor of computer 102 can execute (or otherwise access) the drivers, enabling operating system 200 to communicate with the corresponding peripheral devices.
Similarly, application loader 208 includes instructions for loading applications 202 stored in one or more files of nonvolatile memory into the volatile system RAM. Once loaded into system RAM, the processor of computer 102 can execute (or otherwise access) the application. It should be noted that although device drivers and applications are loaded into system RAM, at various times some of their instructions may be stored in nonvolatile memory instead (e.g., using a conventional “swap” file on a hard disk).
Digest catalog 210 stores digitally signed identifiers of the various applications 202 and device drivers 204 that should be executable on computer 102. Applications and drivers that “should be executable” on computer 102 refers to applications and/or drivers for which a supplier 104 of
Cryptography module 212 performs the necessary cryptographic functions of the invention, including generating and verifying digital signatures, encrypting and decrypting information, generating hash values from cryptographic hash functions, etc. The discussion herein assumes that the reader is familiar with public key cryptography. For a basic introduction to cryptography, the reader is directed to a text written by Bruce Schneier and entitled, “Applied Cryptography: Protocols, Algorithms, and Source Code in C,” published by John Wiley & Sons, copyright 1994 (second edition 1996).
Access control list 214 stores a set of one or more entities that are allowed to modify digest catalog 210. An entity can be an individual or group of individuals, or alternatively machines (e.g., an identifier of supplier 104 or OEM 108 of
File system module 216 manages the storage of applications 202 and device drivers 204, as well as application data files (not shown) in the nonvolatile storage device(s) of computer 102.
Certain functions of operating system 200 may not be available to the user, illustrated as restricted portion 218. Functionality of operating system 200 may be restricted, for example, in exchange for a lower purchase price for computer 102. However, upon certain conditions being satisfied, an optional upgrade module 220 can “unlock” restricted portion 218 making the restricted functionality available to the user. Such restricted functionality and “unlocking” is discussed in more detail below.
Sealed computer 232 includes various software applications and device drivers for a general purpose open architecture operating system. However, additional software applications and device drivers cannot be added to the computer 232, thereby “sealing” the computer and restricting it to executing only specified software applications and device drivers.
The sealing of computer 232 ensures that consumer 236 is limited to executing only specific applications and device drivers (e.g., only those applications that are installed on computer 232 by vendor/OEM 234 and included on computer 232 at the time it is distributed to consumer 236). By preventing additional device drivers from being installed on computer 232, consumer 236 is further prevented from adding any additional peripheral devices (which would require an additional device driver(s)) to computer 232.
Purchase of a sealed computer 232 can be a great benefit for consumer 236. For example, consumer 236 could purchase a sealed computer at a lower price 238 than he or she would have paid for a non-sealed computer.
A computer 102 of
When a user wants to execute a particular software application 202, application loader 208 generates a hash value for the application 202 and checks whether a corresponding digitally signed hash value exists in digest catalog 210. If such a digitally signed hash value exists, then loader 208 loads the application; otherwise, loader 208 does not load the application. Analogous checks are performed by device loader 206 prior to loading a device driver 204 for use with a particular hardware device.
Other techniques for sealing the computer 102 can also be used, either in addition to or in place of the use of digest catalog 210 discussed above. For example, file system module 216 can prevent the alteration of the files stored on the storage devices of computer 102, such as by ignoring any requests to add or delete files. File system module 216 can prevent the alteration of files based on their location within the storage hierarchy of the storage devices (e.g., files cannot be deleted from particular folders or directories), based on their location on the storage device (e.g., files cannot be written to particular sectors of a hard disk), or alternatively without regard for the location of the files.
Initially, a file that is to be accessible at the computer device is selected (act 252), such as a file including instructions for an application 202 or device driver 204. A hash value is then generated for the selected file (act 254). The hash value can be generated using any of a wide variety of conventional hash functions, including cryptographic one-way hash functions. Typically, such hash functions produce a different hash value for different input values.
The generated hash value is then digitally signed (act 256). The hash value can be digitally signed using any of a wide variety of conventional encryption techniques, such as the well-known RSA (Rivest, Shamir, and Adelman) public-key encryption technique. By digitally signing the hash value, device loader 206 or application loader 208 can subsequently verify that the hash value was signed by the appropriate device (e.g., supplier 104, vendor 106, or OEM 108) as discussed in more detail below.
The digitally signed hash value is then added to the digest catalog 210 (act 258). A check is then made as to whether any additional files are to be accessible at the computer (act 260). If no additional files are to be accessible at the computer, then the process ends (act 262). Otherwise, acts 252-258 are repeated for an additional file.
Eventually, a request to load a software application 202 or device driver 204 is received (act 272). In response to the request, application loader 208 (or device loader 206) generates a hash value for the file(s) including the requested application (or device driver) (act 274). The hash function used to generate the hash value in act 274 is the same hash function as was used to generate the hash value in act 254 of
Application loader 208 (or device loader 206) then decrypts the hash values in digest catalog 210 (act 276). The manner in which the hash values are decrypted is dependent on the manner in which they were encrypted. By way of example, if RSA public-key encryption was used to digitally sign the hash values in act 256 of
Once decrypted, loader 208 (or loader 206) compares the decrypted hash values to the hash value generated in act 274 (act 278), and determines whether the generated hash value matches any of the decrypted hash values. If there is no match, then the request is denied and the requested software application 202 or device driver 204 is not loaded (act 282). However, if there is a match, then the request is executed and the requested software application 202 or device driver 204 is loaded and executed (act 284).
Thus, even if a user were to obtain additional application or device driver files and add them to computer 102, he or she would be unable to execute the corresponding application or driver as loader 206 or loader 208 would not load the files. Additionally, in some situations the user would be prevented from installing the application or device driver on computer 102. For example, many applications include an executable “setup” file that is executed by the processor of computer 102 and that controls the installation of the necessary files for the application. In such situations, if a digitally signed hash value for the setup file is not included in digest catalog 210, then the setup file could not be loaded and executed on computer 102.
Functionality of operating system 200 can be restricted in a variety of manners in addition to or in place of the use of digest catalog 210 described above. In accordance with one embodiment, the instructions that are executed by a processor to carry out the restricted functions are contained, in encrypted form, in restricted portion 218 of operating system 200. These instructions may be grouped together in particular files that are encrypted, or alternatively distributed (in encrypted form) throughout the instructions of operating system 200.
Referring again to
Initially, upgrade module 220 obtains a digital key to unlock the full version of the operating system (act 302). The digital key is then used to turn off or disable the lock down mechanisms(s) at the computer (act 304). In one implementation, the lock down mechanisms are disabled by disabling the signature checking of device loader 206 and application loader 208 described above if the digital key is verified as being from the appropriate vendor (or OEM or supplier). This verification can be performed, for example, using the RSA public key of the vendor (or OEM or supplier).
The digital key is also used to decrypt any necessary files to generate the full version of the operating system (act 306). In one implementation, this decryption includes decrypting all of the instructions in restricted portion 218. The exact manner in which the decryption occurs is dependent on the manner in which the files were originally encrypted (which is known to upgrade module 220, or alternatively which is provided to upgrade module 220 by the appropriate vendor, OEM, or supplier).
The digital key can be used to decrypt the necessary files to generate the full version of the operating system (act 306) in any of a variety of manners. By way of example, the digital key obtained in act 302 may be (or may include) an RSA public key corresponding to the RSA private key that was used to encrypt the files prior to their placement in computer 102. This RSA public key can be used in a conventional manner to decrypt the encrypted files. The full version functionality of the operating system is then installed (act 308), making all of the functions in restricted portion 218 available to the user.
Returning again to
Supplier 330 provides a digital signature 332 to vendor 326, which in turn provides digital signature 332 to consumer 322. By distributing digital signatures in the manner illustrated in
Supplier 330 can optionally insist that vendor 326 satisfy various standards in order to obtain a digital signature. For example, supplier 330 may verify the identity of vendor 326 (e.g., using public key encryption techniques) and/or obtain assurances from vendor 326 that improper actions will not be taken with digital signature(s) it receives from supplier 330.
Additionally, supplier 330 may optionally provide a sum of money 334 (or alternatively other compensation) to an OEM 336 based on the receipt of money 328. Supplier 330 may do so, for example, to provide an additional incentive to OEM 336 to market/advertise products for which supplier 330 provides digital signatures 332.
By distributing digital signatures in the manner illustrated in
Consumer 352 provides an agreed upon sum of money 358 (or alternatively other compensation) to OEM in exchange for a digital signature that can be added to digest catalog 210. The digital signature can be provided directly to consumer 352 from OEM 354 (illustrated as digital signature 360), or alternatively via vendor 356 (illustrated as digital signature 362).
The digital signature that OEM 354 can provide to consumer 352 is received from supplier 364. Supplier 364 generates a digital signature (e.g., a digitally signed hash value) 366 for the application or device driver file(s) that correspond to the request of consumer 352. This digital signature 366 may be provided to consumer 352 as digital signature 360 or 362. Alternatively, OEM 354 may also digitally sign digital signature 366 and provide the resultant digital signature to consumer 352 as signature 360 or 362. Alternatively, supplier 364 may digitally sign files in different manners for different OEMs, thereby alleviating OEM 354 from having to re-sign the signatures it receives but still tying the digital signature to OEM 354.
OEM 354 also provides an agreed upon sum of money 368 (or alternatively other compensation) to supplier 364 in exchange for the digital signature 366. OEM 354 may also provide an agreed upon sum of money 370 (or alternatively other compensation) to vendor 356 (e.g., if the request for the ability to use the particular software application or device driver came from vendor 356, or if the digital signature is provided to consumer 352 via vendor 356).
Distributing digital signatures in the manner illustrated in
Consumer 352 can receive significant benefit from such a distribution method, as the cost of the initial computer 102 can be reduced; additional costs would be incurred only if and when consumer 352 wants the ability to execute the additional software applications or device drivers.
Furthermore, by obtaining subsequent software applications and device drivers directly from the same OEM as manufactured the computer, an additional level of assurance can be provided to the consumer that the requested applications/drivers will execute properly on computer 102. For example, a computer as described herein that cost the same amount—or more—would be advantageous to people because the OEM would allow only “high quality” (e.g., tested and verified) drivers and/or applications to be run on the computer, resulting in a more reliable experience for the end user.
Digest catalog 210 can be located locally at computer 102, or alternatively can be located at a remote location or separated among computer 102 and one or more remote locations.
In order to execute a particular software application or device driver, the appropriate loader 206 or 208 communicates over network 110 with server 382. The digitally signed hash value(s) for the files of the requested application or driver are compared to those in digest catalog 384 and loaded only if a match is found. This comparison can be performed locally at client 102 (e.g., by loaders 206 and 208) or alternatively remotely at server 382 and an indication returned to computer 102 from server 382 of the result of the comparison.
A consumer may provide monetary or other compensation to the owner of server 382 (e.g., OEM 354 of
The distribution models discussed above provide various techniques for expanding and/or contracting user rights. After distribution of a computer to a user, the user's rights can be expanded and/or contracted by, for example, a supplier 104 or OEM 108. The computer will not execute applications and/or drivers for which the user does not have appropriate rights, thereby limiting the user's ability to use the computer beyond the agreed upon rights.
Although the description above uses language that is specific to structural features and/or methodological acts, it is to be understood that the invention defined in the appended claims is not limited to the specific features or acts described. Rather, the specific features and acts are disclosed as exemplary forms of implementing the invention.
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7962737 *||Nov 21, 2007||Jun 14, 2011||Dell Products L.P.||Methods, media and apparatus for booting diskless systems|
|Cooperative Classification||G06F2221/0742, G06F21/121, G06F21/51|
|European Classification||G06F21/51, G06F21/12A|
|Jan 15, 2015||AS||Assignment|
Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC, WASHINGTON
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MICROSOFT CORPORATION;REEL/FRAME:034766/0001
Effective date: 20141014