Secure operating system booting in accordance with a reference platform list and data encapsulation

Abstract

Using one or more device health values to indicate a health state of a computing device can enable an operating system developer to directly manage the security configuration of the computing device. Generating a device health value involves initializing hardware components of the computing device according to configuration settings and loading an operating system during a boot of the computing device. The device health value is then generated based on a state of the hardware components and / or a state of a software stack including the operating system at boot. The device health value can be compared to a reference health value to determine whether the computing device is in a secure state.

Description

[0001] This application is a divisional application of the invention patent application "Starting a Secure Operating System According to a Reference Platform List and Data Encapsulation" filed on August 13, 2014, with application number 201811258859.7. Background Technology

[0002] Typically, computing devices utilize a security module to monitor the device's hardware platform and operating system during startup. This security module is usually a dedicated processing chip that receives status input from various components of the computing device during startup. The security module then provides status input to applications on the computing device. Applications generally use this status input to verify that the computing device is a secure platform for executing their applications; for example, that the operating system is up-to-date and free of known security vulnerabilities.

[0003] However, in many instances, due to the initialization of numerous hardware components, the security module receives a large amount of input from the hardware and software platform during startup. Furthermore, many applications are unable to handle the state input received from the security module. Developing applications capable of handling the excessive state input from computing devices with diverse hardware configurations to differentiate between secure and compromised computing devices typically requires significant resource expenditure. Often, application developers lack or are unwilling to invest such resources. Thus, while the security module is intended to assist in creating secure computing platforms, a large number of applications on computing devices frequently ignore the state input provided by the security module.

[0004] Thus, although the status input actually reflects the compromised computing device, the application still executes on that device. Executing such an application often inadvertently allows a malicious party to control the computing device and / or steal user data from it. Summary of the Invention

[0005] This document describes techniques for determining the health status of a computing device using one or more device health values ​​derived from a trust module on the computing device. These techniques can generate one or more reference health values ​​for the computing device. These reference health values ​​can be generated in advance using one or more reference computing devices having the same hardware and / or software configuration as the computing device. The reference health value can represent the state of the hardware platform and / or the software stack, including the operating system of the reference computing device, at startup. The reference health value can reflect the fact that the hardware platform and / or operating system of the reference computing device are known to be in a secure state. A reference computing device in a secure state may be free from known security issues. In some embodiments, the state of the hardware platform can be measured with respect to invariant hardware components (e.g., graphics processor, flash memory, etc.) relative to peripheral hardware components (e.g., external keyboard, mouse, docking station, etc.), where these invariant hardware components influence the security context of the computing device.

[0006] A trust module on a computing device can generate one or more device health values ​​representing the state of the computing device's hardware platform and / or operating system at startup. When each device health value matches a corresponding reference health value, the startup processing component on the computing device can determine that the computing device is in a safe state. Conversely, when any device health value does not match its corresponding reference health value, the component can determine that the computing device is in an undesirable state. Upon detecting an undesirable state, the startup processing component can initiate repairs to the software components on the computing device by executing a recovery environment (e.g., a parallel security software stack including a maintenance module). For example, the recovery environment can initiate repairs to corrupted data files, removal of malware or viruses, remapping of the operating system, installation of new firmware for one or more hardware components, etc., enabling the computing device to return to a safe state.

[0007] Conversely, a computing device operating in a secure state can execute numerous applications. For example, a computing device can use a corresponding health certificate to prove its secure state to another entity. Then, after accepting the health certificate, the entity can provide the requested services to the computing device. In another example, a computing device can use one or more keys distributed to it and bound to one or more reference health values ​​to perform tasks, such as regulating access to user data stored on the computing device. These one or more keys can uniquely identify the computing device. In some instances, mechanisms on the computing device can provide expiration dates for the one or more keys assigned to it to ensure that full access to the computing device depends on the computing device being periodically updated with the latest patches and software updates.

[0008] In at least one embodiment, generating one or more device health values ​​involves initializing the hardware components of the computing device and loading the operating system according to configuration settings during the startup of the computing device. Then, one or more device health values ​​are generated based on the state of the hardware components at startup and / or the state of the software stack, including the operating system. The device health values ​​can be compared with corresponding reference health values ​​to determine whether the computing device is in a safe state.

[0009] These technologies enable operating system developers to directly manage the configuration of computing devices as secure computing platforms. In this way, users are freed from the tasks of monitoring the health of computing devices, ensuring the latest updates and patches are installed, and verifying that the operating system is in a maintenance state. While in a maintenance state, the operating system may be free of known malware, viruses, and other malicious code. Instead, users can be assured that the computing device is in a secure state from startup and that they can trust the device to keep their confidential user data safe.

[0010] The present invention is provided in a simplified manner, reducing the selected concepts further described in the detailed embodiments below. The present invention is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. Attached Figure Description

[0011] Specific embodiments are described with reference to the accompanying drawings. In the drawings, the leftmost digit of the reference numeral indicates the figure in which that reference numeral first appears. The same reference numerals are used in different figures to indicate similar or identical items.

[0012] Figure 1 A block diagram illustrating an example scheme for assessing the health status of a user's computing device is provided, in which the assessed health status is used to authorize access to the user's computing device and / or to authorize access to services from a service provider.

[0013] Figure 2 This is a schematic diagram illustrating an example component of a reference computing device that generates a reference health status for evaluating the health status of a user's computing device.

[0014] Figure 3 The illustration shows a schematic diagram of an example component of a user computing device with a trust module that assesses the health status of the user computing device at least in part based on a comparison of the device's health value with a stored reference health value.

[0015] Figure 4 This is a flowchart illustrating an example process for generating reference health values ​​using one or more reference computing devices.

[0016] Figure 5A flowchart illustrating an example process for determining the health status of a user computing device based on a comparison of the user's computing device's health value with a reference health value is provided.

[0017] Figure 6 This is a flowchart illustrating an example process for generating device health values ​​for a user's calculated device.

[0018] Figure 7 This is a flowchart illustrating an example process for protecting user data stored on a user's computing device using one or more keys and a reference health value.

[0019] Figure 8 This is a flowchart illustrating an example process for using one or more keys associated with a reference health value to command update the operating system of a user's computing device. Detailed Implementation

[0020] This document describes techniques for determining the health status of a computing device using one or more device health values ​​derived from a trust module on the computing device. These techniques can generate one or more reference health values ​​for the computing device. These one or more reference health values ​​can be generated in advance using a reference computing device having the same hardware and / or software configuration as the computing device. These one or more reference health values ​​can represent the state of the hardware platform and / or the software stack, including the operating system of the reference computing device, at startup, where it is known that the hardware platform and operating system of the reference computing device do not have any known security issues.

[0021] A trust module on a computing device can generate one or more device health values, representing the state of the hardware platform and / or the software stack, including the computing device's operating system, at startup. A startup processing component on the computing device can compare each device health value with a corresponding reference health value to determine whether the computing device is in a secure or undesirable state. An undesirable state may indicate that the computing device is under some kind of threat. Upon detecting an undesirable state, the startup processing component initiates a repair of the software components on the computing device by executing a recovery environment. Conversely, a computing device running in a secure state can execute numerous applications. For example, the computing device can use one or more keys distributed to it and bound to one or more reference health values ​​to perform tasks such as controlling access to user data stored on the computing device.

[0022] In some instances, mechanisms on the computing device can provide expiration dates for one or more keys distributed to the computing device to ensure that full access to the computing device depends on the computing device being periodically updated with the latest patches and software updates. See below for reference. Figure 1-8 The present invention describes various embodiments of a technique for determining the health status of a computing device using a device health value derived from a trust module on the computing device.

[0023] Example Scheme

[0024] Figure 1 A block diagram illustrating an example scheme for assessing the health status of a computing device is provided, in which the assessed health status is used to authorize access to the user's computing device and to authorize access to services from a service provider. Example scheme 100 may include an authentication entity 102, a user computing device 104, and a service provider 106. Authentication entity 102 may be an operating system developer, a hardware platform manufacturer such as an original equipment manufacturer (OEM), or a third party trusted by both the operating system developer and the hardware platform manufacturer.

[0025] Verification entity 102 can be responsible for generating a reference health value 108 for user computing device 104. Verification entity 102 can use a reference computing device 110 with the same hardware and software configuration as user computing device 104 to generate the reference health value 108. For example, reference computing device 110 can have the same hardware components as user computing device 104, wherein the hardware components are configured to operate in the same manner. Furthermore, reference computing device 110 can execute the same operating system based on the same configuration settings as user computing device 104.

[0026] The reference health value 108 may represent the state of the hardware platform and / or the software stack, including the operating system of the reference computing device, at startup of the reference computing device, wherein the hardware platform and operating system of the reference computing device are known to be in a maintained state and there are no known security issues. In some embodiments, a health value module on the computing device 110 may generate the reference health value 108. The health value module may be a separate processor that collects measurements related to the state of the hardware platform of the reference computing device 110 and the software stack executing on the hardware platform at startup. The measurements are converted into a reference health value by the health value module of the reference computing device 110. However, in other embodiments, the health value module may be implemented as software running in a protected environment (i.e., executed by one or more processors of the reference computing device 110 from protected system memory of the reference computing device 110).

[0027] In some embodiments, measurements of the hardware platform of the reference computing device 110 may be performed with respect to invariant hardware components (e.g., graphics processor, flash memory, etc.) of the hardware platform, relative to peripheral hardware components (e.g., external keyboard, mouse, docking station, etc.), wherein the invariant hardware components affect the security background of the computing device. In this way, the reference health value is not affected by the attachment or removal of such secondary hardware components relative to the reference computing device 100.

[0028] Verification entity 102 may provide a reference health value to user computing device 104 via network 112. For example, server 114 operated by verification entity 102 may transmit reference health value 108 to user computing device 104. In various embodiments, network 112 may be a local area network (“LAN”), a larger network such as a wide area network (“WAN”), and / or many networks such as the Internet. Protocols for network communication (e.g., TCP / IP) may be used to implement network 112. Various wireless communication interface technologies (e.g., cellular, Wi-Fi, ultra-wideband, Bluetooth, satellite transmission) may be used to implement network 112. Alternatively or simultaneously, various wired communication technologies such as LAN Ethernet, WAN Ethernet, Universal Serial Bus (USB), High Speed ​​Serial Bus, etc., may also be used to implement network 112.

[0029] User computing device 102 may use trust module 116 to generate device health value 118. In various embodiments, trust module 116 may be a separate processor installed on user computing device 104 to facilitate platform security. For example, trust module 116 may be similar to a Trusted Platform Module (TPM) module conforming to the Trusted Platform Module (TPM) specification outlined by the Trusted Computing Group (TCG). However, in other embodiments, trust module 116 may be implemented as software running in a protected environment (i.e., executed by one or more processors of user computing device 104 from protected system memory of user computing device 104).

[0030] Trust module 116 can acquire measurements relating to the state of the hardware platform of user computing device 104 at startup and the state of the software stack including the operating system running on the hardware platform. Trust module 116 can generate a device health value 118 based on these measurements. When device health value 118 matches reference health value 108, startup processing component can determine that user computing device is in a secure state. Conversely, when device health value 118 does not match reference health value 108, startup processing component can determine that user computing device 104 is in an undesirable state. An undesirable state can indicate that the computing device is under threat to some extent. Upon detecting that user computing device 104 is in an undesirable state, startup processing component can initiate repairs to the software components on the computing device. For example, startup processing component can execute a recovery environment to initiate repairs to corrupted data files, removal of malware, remapping of the operating system, etc., so that user computing device 104 can be returned to a secure state. In at least one embodiment, the recovery environment can be a parallel security software stack including a maintenance module. Conversely, the user computing device 104 operating in a secure state can be allowed by the trust module 116 to execute numerous applications to perform tasks.

[0031] For example, as long as user computing device 104 is in a secure state, user computing device 104 can use one or more keys 120 distributed to user computing device 104 to protect data files on user computing device 104. In various embodiments, the one or more keys 120 may be cryptographic keys. Authentication entity 102 may distribute one or more keys 120 and a reference health value 108 to user computing device 104. In some instances, the one or more keys 120 may uniquely identify user computing device 104. Trust module 106 may generate an access key based on a combination of one or more keys 120 and the reference health value 108. Trust module 116 may use the access module to protect user data stored on user computing device 104. Thus, user data on the computing device can only be accessed by applications on user computing device 104 when one or more keys 120 are valid and the health value 118 obtained by trust module 116 at startup matches the stored reference health value 108.

[0032] In another example, verification entity 102 may provide user computing device 104 with a health certificate 122 and a reference health value 108. The health certificate 122 may be used by user computing device 104 to prove its security status to a service provider, such as service provider 106. Furthermore, service provider 106 may provide services to user computing device 104 via one or more servers 124. For example, the service provider may accept payments initiated at user computing device 104, transfer data files to user computing device 104, or establish a secure communication channel with user computing device 104. In some embodiments, the health certificate 122 may include one or more keys 120 for uniquely identifying user computing device 104.

[0033] In some embodiments, one or more keys 120 may have an expiration date. Consequently, some services provided by the user computing device 104 may become disabled. For example, after one or more keys 120 expire, data files protected using those keys may become inaccessible. Services can be restored when the user computing device 104 is updated with one or more new keys. However, the one or more keys 120 may be updated to new keys depending on the user computing device 104 accepting a software update 126. The software update 126 may include updates to the operating system, firmware updates to one or more hardware components of the hardware platform, updates to one or more applications installed on the user computing device 104, replacement certificates for health certificates 122, etc. In this way, the expiration of one or more keys 120 can be used to incentivize users of the user computing device 104 to keep their devices up-to-date with the latest security patches and software updates.

[0034] Example Components

[0035] Figure 2 This is a schematic diagram illustrating example components of a reference computing device 110, which generates reference health values ​​for assessing the health status of computing devices. In various embodiments, the reference computing device 110 may be a desktop computer, tablet computer, laptop computer, smartphone, game console, personal digital assistant (PDA), etc.

[0036] Reference computing device 110 may include hardware platform 202, platform firmware 204, memory 206, and health value module 208. Hardware platform 202 may include one or more hardware components, such as one or more processors 210, that enable software on reference computing device 110 to execute applications. The one or more processors 210 may include a central processing unit (CPU), a communication processing unit (GPU), a microprocessor, a digital signal processor, etc. Furthermore, while some functions and modules are described herein as being implemented by software and / or firmware that can execute on a processor, in other embodiments, any or all of the described functions may be implemented in hardware (e.g., as an ASIC, a dedicated processing unit, etc.) to perform some or all of the described functions. The described functions may be implemented as one or more hardware logic components, such as field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), etc. Other hardware components of the hardware platform may include network interface cards (NICs), sound cards, cameras, display interfaces, new applications, user interfaces, etc. Although shown separately for illustrative purposes, memory 206 may be part of hardware platform 202. Platform firmware 204 may include program instructions that enable operating system 214 to interact with hardware components of hardware platform 202. Thus, operating system 214 can instruct hardware components to perform any and / or generate data. The firmware of the hardware components may be stored in the persistent memory of the hardware components.

[0037] The memory 206 may be implemented using a computer-readable medium, such as a computer storage medium. Computer-readable media includes at least two types: computer storage media and communication media. Computer storage media includes volatile and non-volatile, removable and non-removable media implemented using any method or technology for storing information, which may be, for example, 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 technologies, CD-ROM, digital versatile disc (DVD), or other optical storage devices, magnetic tape, magnetic tape, disk storage devices or other magnetic storage devices, or any other tangible medium that can be used to store information for access by a computing device. Conversely, communication media may implement computer-readable instructions, data structures, program modules, or other data in modulated data signals (e.g., carrier waves, or other transmission mechanisms). As defined herein, computer storage media does not include communication media.

[0038] The memory 206 of the reference computing device 110 may store software components including an operating system 214 and a bootloader 216. The bootloader 216 may initialize one or more hardware components of the hardware platform 202. In various embodiments, the bootloader 216 may perform such initialization by powering on each hardware component and / or by providing instructions to each hardware component via its firmware hardware component. In some embodiments, the bootloader 216 may use a boot setting 218 to initialize the hardware platform 202. The boot setting 218 may specify specific hardware components of the hardware platform 202 to be initialized at startup. For example, the boot setting 218 may specify to power on a specific list of approved hardware components. Alternatively, the boot setting 218 may specify one or more criteria for selecting the hardware components to be initialized. For example, the boot setting 218 may limit initialization to each hardware component of the hardware platform 202 whose firmware is approved (e.g., digitally signed) by the verification entity 102. The boot setting 218 may also include specific configurations for initializing the hardware components of the hardware platform 202. For example, configurations can specify power levels, data transfer rates, memory allocations, etc., for hardware components. A specific configuration can be one approved by verification entity 102.

[0039] Once the hardware components are initialized, bootloader 216 can load operating system 214 into working memory (e.g., RAM) to instantiate the computing environment. The computing environment can support the execution of one or more applications. In some embodiments, bootloader 216 can load operating system 214 according to operating system configuration settings 220. Operating system configuration settings 220 can specify one or more data files 222 (e.g., libraries, drivers, configurations, etc.) of the operating system 214 to be loaded. Loading one or more data files 222 can customize the operating system 214 to perform specific services, provide specific functions, or display customized visual effects.

[0040] The health value module 208 can collect configuration values ​​from the hardware platform 202 and / or the operating system 214 when the reference computing device 110 starts up. Each configuration value for the hardware platform 202 can represent the state of a specific hardware component. Similarly, each configuration value for the operating system 214 represents the specific context of the operating system 214. The health value module 208 can be a separate processor module installed on the reference computing device 110. For example, the processor module can be similar to a TPM module conforming to the TPM specification outlined by the TCG. In some embodiments, the hardware platform 202 and / or the operating system 214 can provide configuration values ​​to the health value module 208 via a dedicated interface. In some embodiments, the hardware platform 202 can be configured to provide configuration values ​​with respect to invariant hardware components of the hardware platform 202. Such hardware components (e.g., graphics processors, flash memory, etc.) are components that affect the security context of the computing device, as opposed to peripheral hardware components (e.g., external keyboards, mice, docking stations, etc.).

[0041] The health value module 208 can store configuration values ​​in the configuration register 212. In some instances, the health value module 208 can discard configuration values ​​of peripheral hardware components from the configuration register 212. In various embodiments, the configuration register 212 may include two register portions. A first portion of the configuration register 212 may store configuration values ​​associated with the hardware platform 202, while a second portion may store configuration values ​​associated with the operating system 214.

[0042] The health value module 208 can generate a reference health value 108 based on the value stored in the configuration register 212. In at least one embodiment, the health value module 208 can generate the reference health value 108 by synthesizing configuration values ​​associated with the hardware platform 202 and the operating system 214. The health value module 208 can perform this generation using one or more arithmetic operations and / or one or more data transformation operations, provided that the resulting reference value 108 uniquely identifies the combination of input configuration values. The reference health value 108 can represent a computing device in a safe state.

[0043] In other embodiments, the health value module 208 may generate the reference health value 108 solely based on configuration values ​​associated with the hardware platform 202 or the operating system 214. Again, the health value module 208 may perform this synthesis using one or more arithmetic operations and / or one or more data transformation operations, provided that the resulting reference value 108 uniquely identifies the combination of input configuration values.

[0044] Therefore, in some instances, the health value module 208 can generate multiple reference health values ​​for the reference computing device 110. For example, the health value module 208 can generate a first reference health value based on configuration values ​​associated with the hardware platform 202, and a second reference health value based on configuration values ​​associated with the operating system 214. Furthermore, in other instances, the generation of the first and second reference health values ​​can be performed by two separate health value modules residing on two different reference computing devices. For example, the first reference health value could be generated by a hardware manufacturer using a first reference computing device, while the second reference health value could be generated by a software developer using a second reference computing device.

[0045] Verification entity 102 may store reference health values, such as reference health value 108, in server 114. Verification entity 102 may generate multiple reference health values ​​for multiple reference computing devices, each with a unique hardware and operating system configuration. In some instances, verification entity 102 may combine a first reference health value generated based on configuration values ​​associated with a hardware platform and a second reference health value generated based on configuration values ​​associated with an operating system to produce a combined reference health value. In various embodiments, verification entity 102 may use one or more arithmetic operations and / or one or more data transformation operations to produce the combined reference health value. In this way, verification entity 102 may generate numerous reference health values ​​for multiple computing devices released by multiple vendors. In the same way, verification entity 102 may also generate reference values ​​for different versions of a particular computing device. For example, verification entity 102 may generate a reference health value for a reference computing device with an original version of the operating system and another reference health value for the same reference computing device equipped with a newer version of the operating system. Verification entity 102 may distribute reference health values ​​to user computing devices, such as user computing device 104.

[0046] Figure 3 This is a schematic diagram illustrating example components of a user computing device 104. The user computing device 104 includes a trust module 116 that assesses the health status of the user computing device 104 based on a comparison of the computing device's device health value with a stored reference health value. In various embodiments, the user computing device 104 may be a desktop computer, tablet computer, laptop computer, smartphone, game console, personal digital assistant (PDA), etc.

[0047] User computing device 104 may include hardware platform 302, platform firmware 304, memory 306, and trust module 116. Hardware platform 302 may include one or more hardware components that enable software on user computing device 104 to execute, such as one or more processors 308. One or more components 308 may include a central processing unit (CPU), a communication processing unit (GPU), a microprocessor, a digital signal processor, etc. Furthermore, while some functions and modules are described herein as being implemented by software and / or firmware that can execute on a processor, in other embodiments, any or all of the described functions may be implemented in hardware (e.g., as an ASIC, a dedicated processing unit, etc.) to perform some or all of the described functions. The described functions may be implemented as one or more hardware logic components, such as field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), etc.

[0048] Other hardware components of the hardware platform may include a network interface card (NIC), a graphics processing unit (GPU), a sound card, a camera, a display interface, new applications, a user interface, etc. Although shown separately for illustrative purposes, memory 306 may be part of hardware platform 302. The user interface of user computing device 104 may include, but is not limited to, combinations of one or more of the following: a keypad, a keyboard, a mouse device, a gesture-receiving touchscreen, a microphone, a voice or speech recognition device, and any other suitable recognition or other electronic / software selection method.

[0049] Platform firmware 304 may include program instructions that enable operating system 310 to interact with hardware components of hardware platform 302. Thus, operating system 310 can instruct hardware components to perform any and / or generate data. The firmware of the hardware components may be stored in the persistent memory of the hardware components.

[0050] The memory 306 may be implemented using a computer-readable medium, such as a computer storage medium. Computer-readable media includes at least two types: computer storage media and communication media. Computer storage media includes volatile and non-volatile, removable and non-removable media implemented using any method or technology for storing information, which may be, for example, 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 technologies, CD-ROM, digital versatile disc (DVD), or other optical storage devices, magnetic tape, magnetic tape, disk storage devices or other magnetic storage devices, or any other tangible medium that can be used to store information for access by a computing device. Conversely, communication media may implement computer-readable instructions, data structures, program modules, or other data in modulated data signals (e.g., carrier waves, or other transmission mechanisms). As defined herein, computer storage media does not include communication media.

[0051] The memory 306 of the reference computing device 104 may store software components including an operating system 310, a bootloader 312, a maintenance module 314, and a data protection module 316. The bootloader 312 may initialize one or more hardware components of the hardware platform 302. In various embodiments, the bootloader 312 may perform such initialization by executing firmware associated with each hardware component. In some embodiments, the bootloader 312 may use a boot setting 318 to initialize the hardware platform 202. In various embodiments, the boot setting 318 may specify specific hardware components of the hardware platform 302 to be initialized at startup. For example, the boot setting 318 may specify to power on a specific list of approved hardware components.

[0052] Alternatively, startup settings 318 may specify one or more criteria for selecting hardware components to be initialized. For example, startup settings 318 may limit initialization to each hardware component of hardware platform 202 whose firmware has been approved (e.g., digitally signed) by verification entity 102. Startup settings 318 may also include specific configurations for initializing the hardware components of hardware platform 202. For example, the configuration may specify power levels, data transfer rates, memory allocations, etc., for the hardware components. The specific configuration may be a configuration approved by verification entity 102.

[0053] User computing device 104 may store operating system 310 in system volume 320 of memory 306. Once the hardware components are initialized, bootloader 312 may load operating system 310 into working memory (e.g., RAM) to instantiate the computing environment. The computing environment may support the execution of one or more applications 322. In some embodiments, bootloader 312 may load operating system 310 according to operating system configuration settings 324. Operating system configuration settings 324 may specify one or more data files 326 (e.g., libraries, drivers, configurations, etc.) of operating system 310 to be loaded. Loading one or more data files 326 may customize operating system 310 to perform specific services, provide specific functions, or display customized visual effects.

[0054] In some embodiments, hardware platform 302 may be the same as hardware platform 202, and operating system 310 may be the same as operating system 214. Furthermore, boot settings 318 may be the same as boot settings 218, and operating system configuration settings 324 may be the same as operating system configuration settings 220.

[0055] User data volume 328 may store user data 330. User data 330 may include user-generated data representing users such as user 128. For example, user data 330 may include documents drafted by the user using an application installed on the user's computing device 104, photos stored by the user in memory 306, etc. User data 330 may be protected by data protection module 316. In some embodiments, access key 332 may be used to encrypt or password-protect user data 330.

[0056] Trust module 116 can collect configuration values ​​from hardware platform 302 and / or operating system 310 when user computing device 104 starts up. Trust module 116 may be a separate processor module installed on user computing device 104. For example, the processor module may be similar to a TPM module conforming to the TPM specification outlined by TCG. Trust module 116 may have protection mechanisms such as encryption algorithms that protect data stored on trust module 116 from intrusion. In various embodiments, trust module 116 may operate in a manner similar to health value module 208 of reference computing device 110. Thus, trust module 116 can collect configuration values ​​from hardware platform 302 and / or operating system 310 in the same manner as health value module 208. Trust module 116 may store configuration values ​​in configuration register 334. In some instances, the stored configuration values ​​may exclude configuration values ​​associated with peripheral hardware components (e.g., external keyboard, mouse, docking station, etc.).

[0057] Subsequently, the trust module 116 can also generate a device health value 118 based on configuration values ​​obtained from the hardware platform 302 and / or the operating system 310, in the same manner as the health value module 208. A computational algorithm residing in the trust module 116 can generate the device health value 118. However, in some embodiments, the reference health value 108 and the device health value 118 may be generated solely based on configuration values ​​associated with the hardware platform or operating system. Alternatively, the trust module 116 can generate multiple device health values, for example, generating a first device health value based on configuration values ​​associated with the hardware platform 302 and a second device health value based on configuration values ​​associated with the operating system 310. For example, health values ​​obtained in this manner can be useful in determining health status when different operating systems are implemented on the same hardware platform, or vice versa.

[0058] The status evaluator 338 can compare the device health value 118 with a reference health value 108 to determine whether the user computing device 104 is in a safe or undesirable state. In various embodiments, the status evaluator 338 may be a startup processing component, such as a component of the startup loader 312. Alternatively, the status evaluator 338 may be a software component embedded in the trust module 116. The trust module 116 may receive a reference health value stored by the verification entity 102 from the server 114. Furthermore, the trust module 116 may provide the reference health value to the status evaluator 338. Alternatively, the status evaluator 338 may receive the reference health value directly from the server 114. In various embodiments, when the device health value 118 matches the reference health value 108, the status evaluator 338 may determine that the user computing device 104 is in a safe state. Conversely, when the device health value 118 does not match the reference health value 108, the status evaluator 338 may determine that the user computing device 104 is in an undesirable state. Alternatively, in instances where multiple reference health values ​​and multiple device health values ​​exist, the status evaluator 338 can determine that the user computing device 104 is in a safe state when each device health value is the same as its corresponding reference health value. Otherwise, the status evaluator 338 can determine that the user computing device 104 is in an undesirable state.

[0059] In various embodiments, the trust module 116 can bind one or more keys 120 to one or more reference health values. Thus, the reference health values ​​can be accessible as long as each device health value of the user-computed device 104 matches its defined reference health value. Therefore, the status evaluator 338 can check whether one or more device health values ​​match one or more reference health values ​​by attempting to access the keys 120 stored in the trust module 116. If the keys 120 are accessible, the status evaluator 338 can determine that the values ​​match. However, if the status evaluator 338 cannot access the keys 120, the status evaluator 338 can determine that each of the device health values ​​does not match the corresponding reference health value. However, in other embodiments, the status evaluator 338 can directly compare one or more device health values ​​with one or more reference health values.

[0060] If the user computing device 104 is found to be in an unwanted state, the status evaluator 338 can stop the execution of the operating system 310 to prevent the user 128 from accessing the computing environment provided by the operating system 310. Additionally, the status evaluator 310 can execute a recovery environment including the maintenance module 314. In various embodiments, the recovery environment can be provided by a parallel security software stack executed by one or more processors 308. In the recovery environment, the maintenance module 314 can perform repairs on software components on the computing device. For example, the maintenance module 314 can display a notification on the display of the user computing device 104 prompting the user to initiate a repair. This repair can include repairing corrupted data files, removing malware or viruses, remapping the operating system, installing new firmware for one or more hardware components, etc., so that the user computing device can return to a secure state. Any repair operations performed by the operating system 310 and application 322 can be directed to system volume 320. In various embodiments, the maintenance module 314 can utilize various maintenance applications to perform the repair. Such maintenance applications can include disk scanning applications, malware scanning applications, virus scanning applications, firmware flashing applications, remapping applications, etc. The maintenance application can be loaded onto the user's computing device 104 and / or made available from the server 114 of the verification entity 102.

[0061] For example, maintenance module 314 can establish a communication link with server 114 of verification entity 102 via network 112. Maintenance applications on server 114 can then use this communication link to establish a maintenance session. During the maintenance session, one or more maintenance applications can scan user computing device 104 to detect and repair errors. In some instances, repair may involve replacing data files on user computing device 104 with new data files on storage server 114, such as operating system 310, data file 326, application 322, and / or platform firmware 304. Since user data 330 is stored separately in user data volume 328, user data 330 is unaffected by any repairs to system volume 320 performed by maintenance module 314. This means that access to user data 330 can be restored after successful repair of applications and / or data in system volume 320. Furthermore, if trust module 116 determines that user computing device 104 is operating in a secure state, trust module 116 may allow user computing device 104 to operate normally and execute application 322.

[0062] In some embodiments, user computing device 104 may receive one or more keys 120 and a reference health value 108 from authentication entity 102. The one or more keys 120 may be unique keys specifically generated for user computing device 104. However, in other instances, the one or more keys 120 may be keys assigned to multiple identical user computing devices. Trust module 116 may pass one or more keys 120 to data protection module 316. Furthermore, data protection module 316 may use the one or more keys 120 to protect user data 330 stored in user data volume 328. In at least one embodiment, trust module 116 may use access key generator 340 to generate access key 332 based on a combination of one or more keys 120 and the reference health value. This generation may involve performing arithmetic operations and / or hash operations on one or more keys 120 and the reference health value 108. Trust module 116 may provide access key 332 to data protection module 316. Furthermore, data protection module 316 may use access key 332 to encrypt user data 330.

[0063] Subsequently, an application seeking access to user data 330 can provide access certificate 342 to data protection module 316. The application can generate access certificate 342 using the same technology used to generate access key 332, based on one or more keys 120 and device health value 118. Thus, if access certificate 342 can be used by data protection module 316 to decrypt user data 330, data protection module 316 can grant the application access to user data 330. Otherwise, data protection module 316 can deny the application access to user data 330. In an alternative embodiment, data protection module 316 can use access key 332 as a password to protect user data volume 328, instead of using access key 332 to encrypt user data 330.

[0064] In other embodiments, user computing device 104 may receive a health certificate 122 and a reference health value 108 from authentication entity 102. In some implementations, the health certificate 122 may encapsulate one or more keys 120 that uniquely identify user computing device 104. This means that the health certificate 122 is easily identifiable because it is specifically assigned to user computing device 104. The health certificate 122 can be used by user computing device 104 to prove to other devices that user computing device 104 is in a secure state, enabling user computing device 104 to access services. For example, user computing device 104 can use the health certificate 122 to negotiate a secure communication channel with another device to exchange sensitive information. In another example, user computing device 104 can use the health certificate 122 to protect permission to complete a procurement transaction. In some embodiments, the service provider receiving the health certificate 122 may send it to an authentication entity, such as authentication entity 102. The authentication entity may then return instructions regarding the verification of the health certificate 122. In other embodiments, a user computing device 104, which wishes to obtain services from service provider 106, may initially send a health certificate 122 to an authentication entity such as authentication entity 102. If authentication entity 102 determines that the health certificate 122 is valid, for example, not expired, the authentication entity may issue an authentication ticket to user computing device 104. Subsequently, user computing device 104 can use this authentication ticket to obtain services from service provider 106.

[0065] In some embodiments, one or more keys 120 may have an expiration date. The expiration date can be used to incentivize user 128 to keep user computing device 104 up-to-date and protect user computing device 104 from the latest security threats. For example, after one or more keys 120 expire, data files protected using one or more keys 120 may become inaccessible. Updating one or more keys 120 to new keys may depend on user computing device 104 accepting software update 126 from verification entity 102. For example, software update 126 and updates to one or more keys 120 may be distributed as a single data packet. Software update 126 may include updates to the operating system, firmware updates to the hardware platform, updates to one or more applications installed on user computing device 104, replacement health certificates for health certificate 122, etc. The replaced key and / or health certificate may be marked as invalid by verification entity 102.

[0066] In other embodiments, verification entity 102 may automatically send a new reference health value 108 to user computing device 104. A new reference health value 108 may be generated after updating the firmware and / or operating system files on reference computing device 110. Consequently, due to the mismatch between reference health value 108 and device health value 118, one or more functions of user computing device 104 may become inaccessible. User 128 can regain access to these functions by downloading software update 126 to user computing device 104.

[0067] However, in some embodiments, the verification entity 102 may automatically provide software updates 126 to the user computing device 104. Software updates 126 may be provided periodically and / or at times determined by the verification entity 102. The user 128 may select such automatic updates using the application settings of the maintenance module 314. In this way, the user 128 can be assured that the security status of the user computing device 104 is up-to-date and that the data stored on the user computing device 104 is protected.

[0068] Example process

[0069] Figure 4-8 Various example procedures are described for determining the health status of a computing device using device health values ​​derived from a trust module on the computing device. The order of operations described in each example procedure is not intended to be construed as a limitation, and any number of described operations can be combined and / or implemented in parallel in any order. Furthermore, Figure 4-8Each operation can be implemented in hardware, software, and / or a combination thereof. In the context of software, an operation can represent computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the described operation. The one or more processors may be included in an individual computing device or in multiple computing devices as part of, for example, a cloud. Generally, computer-readable instructions include routines, programs, objects, components, data structures, etc., that cause a particular function to be performed or a particular abstract data type to be implemented. In other embodiments, the operation of each example process may be performed by hardware logic circuitry such as an application-specific integrated circuit (ASIC).

[0070] Figure 4 This illustrates an example process 400 for generating reference health values ​​using one or more reference computing devices. At block 402, a bootloader 216 of the reference computing device 110 can initialize a reference hardware platform, such as hardware platform 202. In various embodiments, the bootloader 216 can perform such initialization by powering on each hardware component and / or by providing instructions to each hardware component via firmware associated with each hardware component. In some embodiments, the bootloader 216 can use boot settings 218 to initialize hardware platform 202.

[0071] In block 404, the health value module 208 of the reference computing device 110 can acquire one or more reference hardware configuration values. These one or more reference hardware configuration values ​​can represent the state of the initialized reference hardware platform 202. In various embodiments, the application programming interface of the hardware platform 202 can interact with the health value module 208 to transmit one or more reference hardware configuration values ​​to the health value module 208.

[0072] In box 406, bootloader 216 may load a reference operating system, such as operating system 214. In some embodiments, bootloader 216 may load operating system 214 according to operating system configuration settings 220. Operating system configuration settings 220 may specify one or more data files 222 (e.g., libraries, drivers, configurations, etc.) of the operating system 214 to be loaded.

[0073] In block 408, health value module 208 can acquire one or more reference operating system configuration values. The one or more operating system configuration values ​​can represent the state of the software stack, including the loaded operating system. In various embodiments, the application programming interface of operating system 214 can interact with health value module 208 to transmit one or more reference operating system configuration values ​​to health value module 208.

[0074] In block 410, health value module 208 can generate reference health value 108 based on one or more reference hardware configuration values ​​and / or one or more reference operating system configuration values. In various embodiments, health value module 208 can perform this generation using one or more arithmetic operations and / or one or more data transformation operations, provided that the resulting reference health value 108 uniquely represents a combination of input configuration values.

[0075] However, in other embodiments, multiple reference values ​​can be generated by the health value module 208. For example, the health value module 208 can generate a first reference health value based on configuration values ​​associated with the hardware platform 202, and a second reference health value based on configuration values ​​associated with the operating system 214. In some instances, the hardware platform 202 and the software stack including the operating system 214 can reside on two different reference computing devices. Thus, the verification entity 102 can send multiple reference health values ​​to a user computing device such as user computing device 014. Alternatively, the verification entity 102 can combine the first and second reference health values ​​into a combined reference health value for transmission to user computing device 104.

[0076] Figure 5 This illustrates an example process 500 for determining the health status of a user computing device based on a comparison of its device health value with a reference health value. In block 502, a trust module 116 on the user computing device 104 may store a reference health value, such as reference health value 108. The trust module 116 may receive reference health value 108 from a server 114 of the authentication entity 102. Reference health value 108 may be generated using a reference computing device 110 and may correspond to a secure device state.

[0077] In block 504, trust module 116 can generate a device health value, such as device health value 118, for the user computing device 104. In various embodiments, device health value 118 can be generated based on the state of hardware platform 302 at startup and / or the state of the software stack including operating system 310. Device health value 118 can represent the health status of user computing device 104.

[0078] In decision box 506, the status evaluator 338 can compare the device health value 118 with a reference health value 108. Therefore, if the device health value 118 matches the reference health value 108 ("Yes" at decision box 506), process 500 can proceed to box 510. In box 510, the status evaluator 338 can determine that the user device is in a safe state. Based on this determination, the status evaluator 338 can allow the user computing device 104 to operate normally. For example, the user computing device 104 can execute numerous applications in the computing environment provided by the operating system 310.

[0079] However, if the status evaluator 338 determines that the device health value 118 does not match the reference health value 108 ("No" at decision box 506), process 500 can proceed to box 512. In box 512, the status evaluator 338 can determine that the user computing device 104 is in an undesirable state. Therefore, the status evaluator 338 can stop the execution of the operating system 310 to prevent the user 128 from accessing the computing environment provided by the operating system 310. Additionally, the status evaluator 338 can execute a recovery environment including the maintenance module 314. In the recovery environment, the maintenance module 314 can perform repairs on the software components on the computing device. This repair may include repairing corrupted data files, removing malware or viruses, remapping the operating system, installing new firmware for one or more hardware components, etc. Remapping and / or installing new firmware can be achieved using data files downloaded from the verification entity 102. This repair can return the user computing device 104 to a safe state. After the repair, process 500 can loop back to box 504.

[0080] Figure 6 This is a flowchart illustrating an example process 600 for generating device health values ​​for a computing device. Example process 600 also shows block 504 of process 500. At 602, a bootloader 312 of the user computing device 104 can initialize the device hardware platform, such as hardware platform 302. In various embodiments, bootloader 216 can perform such initialization by powering on each hardware component and / or by providing instructions to each hardware component via its firmware hardware component. In some embodiments, bootloader 312 can use boot settings 318 to initialize hardware platform 302.

[0081] In block 604, the trust module 116 of the user computing device 104 can obtain one or more device hardware configuration values. These one or more device hardware configuration values ​​can represent the state of the initialized device hardware platform 302. In various embodiments, the application programming interface of the hardware platform 302 can interact with the trust module 116 to transmit one or more device hardware configuration values ​​to the trust module 116.

[0082] In box 606, bootloader 312 can load a device operating system, such as operating system 310. In some embodiments, bootloader 312 can configure operating system configuration settings 324 to load operating system 310. Operating system configuration settings 324 can specify one or more data files 326 (e.g., libraries, drivers, configurations, etc.) of the operating system 310 to be loaded.

[0083] At box 608, the bootloader 312 can acquire one or more device operating system configuration values. These one or more device operating system configuration values ​​can represent the state of the software stack, including the loaded operating system. In various embodiments, the application programming interface of operating system 310 can engage with trust module 116 to transmit one or more device operating system configuration values ​​to trust module 116.

[0084] In block 610, trust module 116 can generate device health value 118 based on one or more device hardware configuration values ​​and / or one or more device operating system configuration values. In various embodiments, health value module 208 can perform this generation using one or more arithmetic operations and / or one or more data transformation operations, provided that the resulting device health value 118 uniquely represents the combination of input configuration values.

[0085] Figure 7 This is a flowchart illustrating an example process for protecting user data stored on a user computing device using one or more keys and a reference health value. At block 702, the data protection module 316 on the user computing device 104 can generate an access key 332 based on one or more keys 120 and a reference health value 108 received from the authentication entity 102. The generation of the access key 332 may involve performing arithmetic operations and / or hash operations on the one or more keys 120 and the reference health value 108.

[0086] In block 704, data protection module 316 can use access key 332 to password-protect and / or encrypt user data 330 stored in user data volume 328. User data 330 may include data generated on behalf of the user. For example, user data 330 may include documents drafted by the user using an application installed on user computing device 104, photos stored by the user in memory 306, etc.

[0087] At block 706, data protection module 316 may receive an access certificate from an application such as application 322. Access certificate 342 may be generated based on one or more keys 120 and device health value 118. In various embodiments, the application may generate access certificate 342 based on one or more keys 120 and device health value 118, using the same technology used to generate access key 332. At block 708, data protection module 316 may compare access certificate 342 with access key 332.

[0088] In decision box 710, data protection module 316 can determine whether access certificate 342 matches access key 332. Therefore, if data protection module 316 determines that access certificate 342 matches access key 332 (yes at decision box 710), process 700 can proceed to box 712.

[0089] In block 712, data protection module 316 can provide an application with access to user data 330 stored on user computing device 104. For example, data protection module 316 can decrypt user data 330 to provide the application with a requested portion of user data 330.

[0090] However, if the data protection module 316 determines that the access certificate 342 does not match the access key 332 ("No" at decision box 710), process 700 can proceed to box 714. In box 714, the data protection module 316 can deny the application access to the user data 330 stored on the user computing device 104.

[0091] Figure 8 This is a flowchart illustrating an example process 800 for commanding the updating of the operating system of a user computing device using one or more keys associated with a reference health value. In block 802, a trust module 116 on the user computing device 104 may store one or more keys 120 associated with a reference health value 108. The user computing device 104 may receive such data from an authentication entity 102.

[0092] In decision box 804, trust module 116 can determine whether one or more keys are accessible, for example, not expired. Trust module 116 can perform such determinations periodically before generating device health values ​​and / or during operation of computing device 104. Thus, if trust module 116 determines that one or more keys 120 are accessible ("Yes" at decision box 804), process 800 can proceed to box 806. In box 806, trust module 116 can allow access to user computing device 104. For example, user computing device 104 can be allowed to execute numerous applications.

[0093] However, if trust module 116 determines that one or more keys 120 are inaccessible ("No" at decision box 804), process 800 can proceed to box 808. In box 808, trust module 116 can deny access to user computing device 104. For example, trust module 116 can send an instruction to bootloader 312. In response to this instruction, bootloader 312 can activate the recovery environment and, if appropriate, also stop the execution of operating system 310 based on the instruction.

[0094] In block 810, maintenance module 314 may prompt user 128 of user computing device 104 to initiate an update to user computing device 104. This update may include an update to platform firmware 304 and / or an update to operating system 310. In various embodiments, maintenance module 314 may prompt user 128 using a notification presented on the display of user computing device 104.

[0095] In block 812, maintenance module 314 can receive updates, one or more new keys, and a new reference health value in response to update initialization. In various embodiments, maintenance module 314 can initialize updates and other content after obtaining affirmative authorization from user 128. User 128 can provide this affirmative authorization using the user interface of user computing device 104.

[0096] In block 814, trust module 116 can generate a new device health value for user computing device 104 based on the state of the hardware platform and / or the state of operating system 310 at startup. In various embodiments, the new device health value is generated based on configuration values ​​related to the state of the hardware platform and / or the state of operating system 310.

[0097] In decision box 816, the status evaluator 338 can determine whether the new device health value matches the new reference health value. Therefore, if the status evaluator 338 determines that the new device health value matches the new reference health value ("Yes" at box 816), process 800 can loop back to box 806. Upon returning to box 806, the status evaluator 338 can allow access to the user computing device 104.

[0098] However, if the status evaluator 338 determines that the new device health value does not match the new reference health value (No at box 816), process 800 can loop back to box 808. Upon returning to box 808, the status evaluator 338 can deny access to the user computing device 104, allowing other boxes of process 800 to proceed.

[0099] In summary, this technology enables operating system developers to directly manage the configuration of computing devices as secure computing platforms. In this way, users are freed from the tasks of monitoring the health of computing devices, ensuring the latest updates and patches are installed, and verifying that the operating system is free of malware, viruses, and other malicious code. Instead, users can be assured that the computing device is in a secure state from startup, and can trust the device to keep confidential user data safe.

[0100] in conclusion

[0101] Finally, although the various embodiments have been described in language specific to structural features and / or methodological behavior, it should be understood that the subject matter defined in the appended presentation is not necessarily limited to the specific features and behaviors described. Rather, the specific features and behaviors are disclosed as exemplary forms of implementing the claimed subject matter.

Claims

1. A computing device, comprising: One or more processors; One or more computer-readable media having stored executable instructions, which, when executed by the one or more processors, are operable to perform a method for protecting user data, wherein the method includes: The computing device receives a reference health value from a remote system, the reference health value representing at least one of a hardware state or a software state associated with the reference computing system; The computing device receives one or more keys that uniquely identify the computing device; The computing device generates an access key based on the reference health value and the one or more keys; The computing device protects the user data using the access key by encrypting the user data on the computing device using at least the access key or by password protecting the user data using the access key; The computing device receives an access certificate from an application on the computing device for accessing the user data, the access certificate being generated based on one or more keys stored on the computing device and a computing device health value representing at least one of a hardware state or software state associated with the computing device; and The computing device grants access to the user data when the access certificate matches the access key, and denies access to the user data when the access certificate fails to match the access key.

2. The computing device as claimed in claim 1, wherein, The method further includes: the computing device generating the computing device health value.

3. The computing device as claimed in claim 2, wherein, The computing device health value is based on the software state, which includes at least the state of the operating system acquired during the loading of the operating system on the computing device.

4. The computing device as claimed in claim 2, wherein, The computing device health value is based on the hardware status, which includes one or more hardware configuration values ​​acquired during the startup of the computing device.

5. The computing device as claimed in claim 2, wherein, The computing device health value is based on both (1) the software state and (2) the hardware state, the software state including the state of the operating system acquired during the loading of the operating system at the computing device, and the hardware state including one or more hardware configuration values ​​acquired during the startup of the computing device.

6. The computing device as claimed in claim 1, wherein, The access key is a hash of the one or more keys and the reference health value.

7. The computing device as claimed in claim 1, wherein, The one or more keys and the reference health value are obtained from the same remote system.

8. A computer-implemented method for protecting user data on a computing device, wherein, The method includes: The computing device receives a reference health value from a remote system, the reference health value representing at least one of a hardware state or a software state associated with the reference computing system; The computing device receives one or more keys that uniquely identify the computing device; The computing device generates an access key based on the reference health value and the one or more keys; The computing device protects the user data using the access key by encrypting the user data on the computing device using at least the access key or by password protecting the user data using the access key; The computing device receives an access certificate from an application on the computing device for accessing the user data, the access certificate being generated based on one or more keys stored on the computing device and a computing device health value representing at least one of a hardware state or software state associated with the computing device; and The computing device grants access to the user data when the access certificate matches the access key, and denies access to the user data when the access certificate fails to match the access key.

9. The method of claim 8, wherein, The method further includes: the computing device generating the computing device health value.

10. The method of claim 9, wherein, The computing device health value is based on the software state, which includes at least the state of the operating system acquired during the loading of the operating system on the computing device.

11. The method of claim 9, wherein, The computing device health value is based on the hardware status, which includes one or more hardware configuration values ​​acquired during the startup of the computing device.

12. The method of claim 9, wherein, The computing device health value is based on both (1) the software state and (2) the hardware state, the software state including the state of the operating system acquired during the loading of the operating system at the computing device, and the hardware state including one or more hardware configuration values ​​acquired during the startup of the computing device.

13. The method of claim 8, wherein, The access key is a hash of the one or more keys and the reference health value.

14. The method of claim 8, wherein, The one or more keys and the reference health value are obtained from the same remote system.

15. One or more computer-readable hardware storage devices having stored executable instructions, which, when executed by one or more processors of a computing device, are operable to perform a method for protecting user data at the computing device, wherein... The method includes: The computing device receives a reference health value from a remote system, the reference health value representing at least one of a hardware state or a software state associated with the reference computing system; The computing device receives one or more keys that uniquely identify the computing device; The computing device generates an access key based on the reference health value and the one or more keys; The computing device protects the user data using the access key by encrypting the user data on the computing device using at least the access key or by password protecting the user data using the access key; The computing device receives an access certificate from an application on the computing device for accessing the user data, the access certificate being generated based on one or more keys stored on the computing device and a computing device health value representing at least one of a hardware state or software state associated with the computing device; and The computing device grants access to the user data when the access certificate matches the access key, and denies access to the user data when the access certificate fails to match the access key.

16. The one or more computer-readable hardware storage devices of claim 15, wherein, The method further includes: the computing device generating the computing device health value.

17. One or more computer-readable hardware storage devices as claimed in claim 16, wherein, The computing device health value is based on the software state, which includes at least the state of the operating system acquired during the loading of the operating system on the computing device.

18. One or more computer-readable hardware storage devices as claimed in claim 16, wherein, The computing device health value is based on the hardware status, which includes one or more hardware configuration values ​​acquired during the startup of the computing device.

19. One or more computer-readable hardware storage devices as claimed in claim 16, wherein, The computing device health value is based on both (1) the software state and (2) the hardware state, the software state including the state of the operating system acquired during the loading of the operating system at the computing device, and the hardware state including one or more hardware configuration values ​​acquired during the startup of the computing device.

20. One or more computer-readable hardware storage devices as claimed in claim 15, wherein, The access key is a hash of the one or more keys and the reference health value, wherein the one or more keys and the reference health value are obtained from the same remote system.

Images