US20170235958A1 - Methods, systems and apparatus to initialize a platform - Google Patents
Methods, systems and apparatus to initialize a platform Download PDFInfo
- Publication number
- US20170235958A1 US20170235958A1 US15/443,831 US201715443831A US2017235958A1 US 20170235958 A1 US20170235958 A1 US 20170235958A1 US 201715443831 A US201715443831 A US 201715443831A US 2017235958 A1 US2017235958 A1 US 2017235958A1
- Authority
- US
- United States
- Prior art keywords
- platform
- manager
- privilege
- context information
- state
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
- G06F21/575—Secure boot
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/4401—Bootstrapping
- G06F9/4406—Loading of operating system
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/4401—Bootstrapping
- G06F9/4406—Loading of operating system
- G06F9/441—Multiboot arrangements, i.e. selecting an operating system to be loaded
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/4401—Bootstrapping
- G06F9/4418—Suspend and resume; Hibernate and awake
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/102—Entity profiles
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/108—Network architectures or network communication protocols for network security for controlling access to devices or network resources when the policy decisions are valid for a limited amount of time
Definitions
- FIG. 1 is a schematic illustration of a system to initialize a platform.
- FIG. 2 is a schematic illustration of a privilege engine of FIG. 1 .
- FIG. 3 is an example platform profile table used by the example system of FIGS. 1 and 2 to initialize a platform.
- FIGS. 4-8 are flowcharts representative of example machine readable instructions that may be executed to initialize a platform in a manner consistent with the teachings of this disclosure.
- FIG. 9 is a schematic illustration of an example processor platform that may execute the instructions of FIGS. 4-8 to implement the example system of FIGS. 1 and 2 .
- Mobile devices enable a substantial productivity improvement for users due to advances in portable computing power, battery life and network connectivity.
- the relatively small size of such mobile devices also increases the ease at which a thief may steal the devices.
- the thief may observe the owner of a mobile device prior to stealing it so that authentication credentials may be obtained.
- the thief may observe password keyboard entry activity by the owner prior to stealing the mobile device. Accordingly, the thief may use such authentication information after stealing the mobile device so that access to privileged disk information and/or network system access may occur.
- FIG. 1 is an example system 100 to initialize a platform 102 in connection with context information and platform policy instructions.
- the example platform 102 of FIG. 1 may be a mobile computing device, such as a mobile telephone, a tablet, a laptop computer, a netbook, etc.
- the platform 102 includes platform software/firmware 104 , such as a boot loader 106 and a file system manager 108 .
- the file system manager 108 conforms to one or more specifications developed by the Trusted Computing Group (TCG) in which a storage device (e.g., a disk drive) may be divided into any number of partitions, in which each partition may be referred to as a volume having its own encrypted locking range.
- TCG Trusted Computing Group
- the example boot loader 106 of FIG. 1 is responsible for loading an example operating system (OS) 110 based on a platform policy and corresponding context information, as described in further detail below.
- OS operating system
- the example file system manager 108 is communicatively connected to storage 112 (platform storage), in which one or more volumes of the example storage 112 include a first volume 112 a, a second volume 112 b, a third volume 112 c and a fourth volume 112 d.
- Each of the volumes 112 a - 112 d are made available to the example platform 102 based on the platform policy and corresponding context information, as described in further detail below.
- the example platform 102 of FIG. 1 also includes a trusted execution environment (TEE) 114 , which includes an example privilege engine 116 and platform policy storage 118 .
- TEE 114 includes its own media access control (MAC) address and/or Internet protocol (IP) address to facilitate out-of-band (OOB) communications independent and/or otherwise separate from the example platform 102 .
- the example TEE 114 may be implemented as the Intel® Management Engine (ME), or in a manner consistent with the TCG as a trusted platform module (TPM).
- ME Intel® Management Engine
- TPM trusted platform module
- the TEE 114 includes one or more cryptographic processor(s), secured input/output (I/O), random number generator(s), key generator(s), hash generator(s), platform configuration registers (PCRs), and/or keys (e.g., storage root keys, attestation identity keys, etc.).
- the example TEE 114 of FIG. 1 operates as an authentication engine to enable one or more inputs and/or types of input to be used when attempting to gain access privileges of the example platform 102 .
- the example privilege engine 116 is communicatively connected to authentication sensors 120 .
- the example authentication sensors 120 of FIG. 1 include a near field communications (NFC) transceiver 122 , a microphone 124 , a fingerprint reader 126 , a camera 128 , a radio frequency (RF) transceiver 130 and a keyboard 132 . While six ( 6 ) sensor types are shown with the example authentication sensors 120 , additional and/or alternative sensor types may be considered, without limitation.
- NFC near field communications
- RF radio frequency
- the NFC transceiver 122 interacts with an employee identification card/badge and/or the RF transceiver 130 interacts with a network device 134 having a Wi-Fi signal, such as a network router, and/or the RF transceiver 130 interacts with a mobile device 136 having a Bluetooth signal, such as a wireless telephone.
- a network device 134 having a Wi-Fi signal such as a network router
- a Bluetooth signal such as a wireless telephone.
- FIG. 2 illustrates additional detail of the example privilege engine 116 of FIG. 1 .
- the privilege engine 116 includes a platform power change monitor 202 , a boot loader manager 204 , an authentication input manager 206 , a context manager 208 , a policy manager 210 and a disk privilege manager 212 .
- the example platform power change monitor 202 determines whether there has been a power state change of the example platform 102 . Additionally, the example platform power change monitor 202 distinguishes between one or more different types of power-on conditions, such as a cold boot power-on condition, a power-on condition from a prior sleep state, or a power-on condition from a prior hibernate state. For example, if the platform 102 is in a prior powerless state and is turned on, which is sometimes referred to as a cold boot or hard boot, the platform software/firmware 104 typically accesses a reset vector for a processor of the platform 102 to begin execution.
- POST power-on-self-test
- a proper state for operation e.g., verifying processor register states, verifying component presence and/or integrity (e.g., timers, interrupt controllers, direct memory access devices, etc.), determining system main memory location(s) and corresponding size(s), and initializing the basic input/output system (BIOS)).
- BIOS basic input/output system
- the cold boot also includes invocation of the example boot loader 106 to begin loading an OS for the example platform 102 .
- a default OS loaded by the example boot loader 106 may introduce one or more security risks to the platform 102
- example methods, apparatus, systems and/or articles of manufacture disclosed herein determine which one of any number of OSs to load based on platform policy and contextual information.
- contextual information and/or context refer to environmental conditions of the example platform 102 .
- Environmental conditions may include, but are not limited to, Wi-Fi signals proximate to the example platform 102 , Bluetooth signals proximate to the example platform 102 and/or NFC signals proximate to the example platform 102 .
- the platform policy (e.g., one or more policies stored in the example platform policy storage 118 ) instructs the example privilege engine 116 to boot a particular OS based on (a) context, (b) multi-factor inputs and/or (c) a prior operating state of the example platform 102 (e.g., a prior powerless state, a prior sleep state, a prior hibernate state, etc.).
- a prior operating state of the example platform 102 e.g., a prior powerless state, a prior sleep state, a prior hibernate state, etc.
- the example boot loader manager 204 intercepts the example boot loader 106 to prevent it from loading a default OS for the example platform 102 .
- the example authentication input manager 206 invokes the example authentication sensors 120 to retrieve authentication information from a user of the example platform 102 .
- the authentication information may include input from the example NFC transceiver 122 based on proximity to an authorized employee identification card (e.g., an employee identification card containing an NFC tag).
- the authentication information may include input from the microphone 124 to capture a voiceprint from the user to be compared against a reference voiceprint (e.g., a voiceprint reference stored in the example platform policy storage 118 of the example TEE 114 ).
- the authentication information may include input from the fingerprint reader 126 to capture a fingerprint scan of the user to be compared against an authorized reference fingerprint.
- the authentication information may include input from the camera 128 to capture an image of the user to be compared against an authorized reference image.
- the authentication information may include input from a keyboard to obtain one or more passwords to be compared against authorized passwords stored in the TEE 114 .
- one or more combinations of inputs may be retrieved and compared to identify a multi-factor authentication that, when each factor is individually authorized, permits the user to utilize one or more resources of the platform 102 .
- multi-factor authentication inputs reduce a risk of unauthorized access to the platform and/or resources available to the platform (e.g., hard drive storage information, network resource access, cloud-accessible storage access, etc.)
- some environments of the example platform 102 present greater or lesser degrees of risk.
- public locations such as coffee shops, restaurants, airports and/or libraries typically exhibit a relatively higher degree of risk due to greater numbers of unknown people having access to those locations and the ability of those people to observe and/or otherwise monitor the behaviors of the owner of the example platform 102 .
- a would-be hacker or thief may systematically observe the user to identify particular keyboard keystrokes that reflect a password. Further, in the event the thief subsequently steals the platform 102 , then the resources of the platform 102 may be available to the thief.
- the would-be thief conducts observations using a network sniffer and/or packet analyzer to capture input data associated with the multi-factor authentication.
- Such collected authentication input data may be used at a subsequent time for access to the platform 102 and/or platform resources in the event the platform 102 is stolen. While examples involving theft are described above, examples disclosed herein are not limited to such circumstances.
- sensitive data stored on the example platform 102 and/or accessible via the example platform 102 e.g., via network connections, via cloud-based services, etc.
- the example policy manager 210 accesses a platform policy from the platform policy storage 118 of the example TEE 114 and instructs the example boot loader 106 to load an OS based on context information associated with the example platform 102 . Additionally, the example disk privilege manager 212 instructs the example file system manager 108 to provide or disable one or more volumes of the storage 112 based on the context information associated with the example platform 102 .
- the platform 102 is powered-on and the context manager 208 detects a service set identifier (SSID) associated with an authorized enterprise network associated with a user of the platform 102 (e.g., an SSID known to be located in an office, laboratory, etc.), then the platform profile may indicate a particular level of access be granted to the platform 102 .
- SSID service set identifier
- the context manager 208 detects a SSID associated with an authorized network within the user's home (e.g., home office), then the platform profile may indicate an alternate (e.g., relatively lower) level of access.
- the enterprise network is a relatively highest privilege level in which the platform 102 may load an enterprise OS image and full access to all volumes of the storage 112 are available to the user when the platform 102 is near the enterprise SSID.
- the platform profile may cause the platform 102 to load an alternate OS image having fewer enterprise-level privileges when the SSID associated with the user's home is detected during boot.
- the platform profile may cause the platform 102 to load a lowest-privileged OS when the SSID is unrecognized and/or associated with known public places (e.g., airports, coffee shops, etc.).
- known public places e.g., airports, coffee shops, etc.
- FIG. 3 illustrates an example platform profile table 300 , which includes an example SSID column 302 , an OS privilege column 304 , a disk privilege column 306 , a privilege elevate column 308 and a post hibernate/sleep column 310 .
- the SSID column 302 includes known SSIDs that have a corresponding privilege configuration. For example, in the event the context manager 208 detects an SSID named “Office_1,” then the policy manager 210 retrieves the profile table 300 stored in the platform policy storage 118 to determine a corresponding OS to load from the OS privilege column 304 .
- the policy manager 210 performs one or more comparisons of retrieved context information with one or more fields of the example platform profile table 300 to determine (a) which OS to load and (b) a corresponding storage (disk) privilege condition.
- the “Office_1” SSID authorizes a highest level OS to be loaded (e.g., an Enterprise OS).
- the disk privilege column 306 authorizes full access privileges to the storage 112 when the “Office_1” SSID is detected.
- the platform 102 may be elevated to a relatively higher privilege level, thereby allowing relatively greater access to local storage 112 information and/or relatively more capable and/or functional OS images.
- the example privilege elevate column 308 identifies the necessary conditions before that may occur. Continuing with the example “Office_1” SSID of FIG. 3 , because the Enterprise OS is already authorized, no further opportunities to elevate the privilege exist. However, assuming for the sake of this example that the context manager 208 detects “Home” as the SSID, then the example privilege elevate column 308 instructs the platform to establish an authorized virtual private network (VPN) before the Enterprise OS may be loaded.
- VPN virtual private network
- the platform is in a prior sleep state or a prior hibernate state before a power-up state is invoked (e.g., a user press of the power button).
- the sleep state of a platform is an energy saving state in which on-board platform memory (e.g., random access memory (RAM)) stores user data and processor register data before shutting-down other platform components (e.g., disabling power to the hard drive to save energy otherwise spent on spinning).
- RAM random access memory
- a relatively small amount of power is used by the platform while in the sleep state to preserve platform user state information in the memory.
- the hibernate state transfers all user data and processor register data to hard disk storage rather than to memory. As such, the hibernate state of the platform does not consume energy to maintain the state.
- OS policy usually requires a minimal level of security to access platform resources after the sleep or hibernate state, such as a keyboard entry password.
- One security concern associated with the typical post-sleep or post-hibernate operation is that the OS password policy is weak and the same OS image will be available to the user (e.g., a thief) even when the post-sleep or post-hibernate state occurs in a less-secure location (e.g., a coffee shop).
- the context manager 208 is invoked to intercept any OS-based security policy, and re-acquire context information.
- the example authentication input manager 206 prompts the user of the platform 102 for authentication input credentials based on the example platform profile table 300 .
- the example post hibernate/sleep column 310 identifies the type of authentication credentials when the detected SSID is associated with “Office_1” 316 .
- the example authentication input manager 206 prompts the user for alternate input credentials 318 .
- the example policy manager 210 compares the new context information to the post hibernate/sleep column 310 corresponding to the previously detected SSID. In other words, the example policy manager 210 determines whether a prior platform state is different than a currently detected platform state. Assuming that the previously detected SSID was “Office_1” when the example platform 102 entered the sleep/hibernate mode, then the post hibernate/sleep column 310 indicates that no change to the OS needs to occur if the currently detected SSID hasn't changed 312 (i.e., the currently detected SSID is still “Office_1”).
- the previously established OS privilege and/or disk privilege status is maintained when the example platform 102 is powered on after the sleep or hibernate state.
- the example post hibernate/sleep column 310 indicates that the example platform should not re-enable the Enterprise OS, but rather change the OS to a low priority image and remove storage access privileges 314 .
- the previously established OS and/or disk privilege status is prohibited on the example platform 102 when it is powered on having a different SSID (and/or other context identifiers).
- a dynamic change in the platform 102 may occur based on a user request to elevate privileges. For example, while initial authentication procedures may restrict the platform 102 to loading a relatively lowest privileged OS when the SSID is indicative of a public place (e.g., a coffee shop), the user of the platform 102 may wish to access a relatively higher privileged state of the platform 102 . If so, the example context manager 208 may reacquire context information to confirm current environmental conditions (e.g., determine whether the platform 102 still near the same SSID), and/or require particular elevation procedures dictated by the example platform profile table 300 .
- the platform 102 is currently near and/or otherwise connected to a network associated with the SSID “MainStreetCoffee” 320 .
- the SSID “MainStreetCoffee” 320 corresponds to a relatively lowest privileged OS (see the example OS privilege column 304 ) and a relatively lowest privileged disk access configuration (see the example disk privilege column 306 ).
- the example privilege elevate column 308 identifies an opportunity to elevate the OS and the disk privileges to a full (highest) state if a VPN connection is established 322 . If those conditions are met, the example boot loader manager 204 instructs the example boot loader 106 to load an OS image for the Enterprise OS, and the example disk privilege manager 212 instructs the example file system manager 108 to allow access to all available disk volumes (e.g., the first volume 112 a, the second volume 112 b, the third volume 112 c and the fourth volume 112 d ).
- all available disk volumes e.g., the first volume 112 a, the second volume 112 b, the third volume 112 c and the fourth volume 112 d .
- the privilege engine 116 checks environmental conditions of the platform 102 on a periodic, aperiodic, scheduled and/or manual basis to determine whether a previously detected/connected SSID has changed. For example, if the platform 102 is a mobile personal computer, then it can be moved from a first location to a second location. In the event that the second location is deemed less secure, then examples disclosed herein react to the new environmental conditions to reduce the risk of unauthorized access to the platform 102 and/or resources available to the platform 102 .
- the example policy manager 210 determines that current privileges of the platform 102 should be revoked.
- the example boot loader manager 204 instructs the example boot loader 106 to load a new OS image having the relatively lower privilege level (e.g., a cloud OS), and the example disk privilege manager 212 instructs the example file system manager 108 to disable platform access to one or more volumes of the storage 112 .
- the privilege engine 116 saves the complete user state of the platform 102 in memory and/or in storage 112 before revoking the access privileges. In that way, the user of the example platform 102 may re-establish the relatively higher privileges of the platform 102 if proper authentication credentials are subsequently provided, as described above.
- FIG. 2 While an example manner of implementing the example privilege engine 116 of FIG. 1 is illustrated in FIG. 2 , one or more of the elements, processes and/or devices illustrated in FIGS. 1 and 2 may be combined, divided, re-arranged, omitted, eliminated and/or implemented in any other way. Further, the example platform power change monitor 202 , the example boot loader manager 204 , the example authentication input manager 206 , the example context manager 208 , the example policy manager 210 , the example disk privilege manager 212 , the example boot loader 106 , the example file system manager 108 , the example platform policy storage 118 and/or, more generally, the example privilege engine 116 of FIGS.
- 1 and 2 could be implemented by one or more analog or digital circuit(s), logic circuits, programmable processor(s), application specific integrated circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)) and/or field programmable logic device(s) (FPLD(s)).
- ASIC application specific integrated circuit
- PLD programmable logic device
- FPLD field programmable logic device
- At least one of the example platform power change monitor 202 , the example boot loader manager 204 , the example authentication input manager 206 , the example context manager 208 , the example policy manager 210 , the example disk privilege manager 212 , the example boot loader 106 , the example file system manager 108 , the example platform policy storage 118 and/or, more generally, the example privilege engine 116 of FIGS. 1 and 2 is/are hereby expressly defined to include a tangible computer readable storage device or storage disk such as a memory, a digital versatile disk (DVD), a compact disk (CD), a Blu-ray disk, etc. storing the software and/or firmware.
- DVD digital versatile disk
- CD compact disk
- Blu-ray disk etc.
- example privilege engine 116 of FIGS. 1 and 2 may include one or more elements, processes and/or devices in addition to, or instead of, those illustrated in FIGS. 1 and 2 , and/or may include more than one of any or all of the illustrated elements, processes and devices.
- FIGS. 4-8 Flowcharts representative of example machine readable instructions for implementing the privilege engine 116 , the boot loader 106 and/or the file system manager 108 of FIGS. 1 and 2 are shown in FIGS. 4-8 .
- the machine readable instructions comprise a program for execution by a processor such as the processor 912 shown in the example processor platform 900 discussed below in connection with FIG. 9 .
- the program may be embodied in software stored on a tangible computer readable storage medium such as a CD-ROM, a floppy disk, a hard drive, a digital versatile disk (DVD), a Blu-ray disk, or a memory associated with the processor 912 , but the entire program and/or parts thereof could alternatively be executed by a device other than the processor 912 and/or embodied in firmware or dedicated hardware.
- a tangible computer readable storage medium such as a CD-ROM, a floppy disk, a hard drive, a digital versatile disk (DVD), a Blu-ray disk, or a memory associated with the processor 912 , but the entire program and/or parts thereof could alternatively be executed by a device other than the processor 912 and/or embodied in firmware or dedicated hardware.
- FIGS. 4-8 many other methods of implementing the example privilege engine 116 , the example boot loader 106 and/or the example file system manager 108 may alternatively be used.
- the order of execution of the blocks may be changed,
- FIGS. 4-8 may be implemented using coded instructions (e.g., computer and/or machine readable instructions) stored on a tangible computer readable storage medium such as a hard disk drive, a flash memory, a read-only memory (ROM), a compact disk (CD), a digital versatile disk (DVD), a cache, a random-access memory (RAM) and/or any other storage device or storage disk in which information is stored for any duration (e.g., for extended time periods, permanently, for brief instances, for temporarily buffering, and/or for caching of the information).
- a tangible computer readable storage medium such as a hard disk drive, a flash memory, a read-only memory (ROM), a compact disk (CD), a digital versatile disk (DVD), a cache, a random-access memory (RAM) and/or any other storage device or storage disk in which information is stored for any duration (e.g., for extended time periods, permanently, for brief instances, for temporarily buffering, and/or for caching of the information).
- tangible computer readable storage medium and “tangible machine readable storage medium” are used interchangeably. Additionally or alternatively, the example processes of FIGS. 4-8 may be implemented using coded instructions (e.g., computer and/or machine readable instructions) stored on a non-transitory computer and/or machine readable medium such as a hard disk drive, a flash memory, a read-only memory, a compact disk, a digital versatile disk, a cache, a random-access memory and/or any other storage device or storage disk in which information is stored for any duration (e.g., for extended time periods, permanently, for brief instances, for temporarily buffering, and/or for caching of the information).
- coded instructions e.g., computer and/or machine readable instructions
- a non-transitory computer and/or machine readable medium such as a hard disk drive, a flash memory, a read-only memory, a compact disk, a digital versatile disk, a cache, a random-access memory and/or any other storage device or storage disk in which
- non-transitory computer readable medium is expressly defined to include any type of computer readable storage device and/or storage disk and to exclude propagating signals and to exclude transmission media.
- phrase “at least” is used as the transition term in a preamble of a claim, it is open-ended in the same manner as the term “comprising” is open ended.
- the program 400 of FIG. 4 begins at block 402 where the example platform power change monitor 202 determines whether a power change condition has occurred.
- the example platform 102 may be powered on from a prior unpowered state, in which a cold/hard boot results. In other examples, the platform 102 may be powered on from a prior sleep state or a prior hibernate state.
- the example platform power change monitor 202 distinguishes between one or more different types of power-on conditions (block 404 ), such as determining whether the power-on condition is occurring from a prior sleep or hibernate state.
- the example platform power change monitor 202 determines that the example platform 102 has been powered on from a previously unpowered state (i.e., neither a prior sleep state nor a prior hibernate state) (block 404 ), then the example boot loader manager 204 intercepts the operations of the example boot loader 106 to prevent a default OS image from being loaded on the platform 102 (block 406 ).
- typical platform operation during power-on includes the boot loader 106 loading a default OS image from storage (e.g., storage 112 ) after the POST is complete.
- examples disclosed herein do not permit a default OS image from being loaded on the example platform 102 and, instead, determine an appropriate OS image to load based on environmental conditions, platform policy, and multi-factor authentication input(s).
- the example authentication input manager 206 retrieves authentication information in a manner consistent with authentication instructions stored in the TEE 114 (block 408 ). For example, rather than rely on authentication policies associated with an OS, examples disclosed herein allow platform managers (e.g., IT personnel) to design multi-factor authentication procedure(s) stored in hardened hardware (e.g., the TEE 114 ).
- the example authentication input manager 206 is communicatively connected to the example authentication sensors 120 to retrieve one or more inputs to authenticate a user of the example platform 102 .
- the authentication input manager 206 controls one or more output devices (see FIG. 9 below) to issue one or more instructions/prompts to the user for authentication purposes. For example, the authentication input manager 206 may generate a prompt for the user of the platform 102 to apply their finger to the fingerprint reader 126 and/or to position their face in front of the camera 128 .
- the example context manager 208 collects and/or otherwise detects context information associated with the example platform 102 (block 410 ). In some examples, the context manager 208 invokes the RF transceiver 130 to determine which WiFi network(s) 134 are near the example platform 102 (block 410 ). In still other examples, the context manager 208 invokes the RF transceiver 130 to determine which Bluetooth devices are near the example platform 102 (block 410 ). In some examples, presence of a particular Bluetooth device near the platform 102 is an additional indication that the platform 102 is still under the control and/or management of an authorized user. The example policy manager 210 applies platform policy to the example platform 102 based on the collected authentication information and collected context information (block 412 ).
- FIG. 5 illustrates additional detail from the example program 400 of FIG. 4 in connection with applying platform policy (block 412 ).
- the policy manager 210 accesses the platform profile table 300 from the TEE 114 (block 502 ).
- the platform profile table 300 is stored in the example platform policy storage 118 of the TEE 114 .
- the example platform profile table 300 identifies one or more configurations of the platform 102 based on one or more environmental conditions. Based on corresponding environmental conditions detected by the example context manager 208 and successful authentication as determined by the example authentication input manager 206 , the example boot loader manager 204 instructs the example boot loader 106 to load a corresponding OS image (block 504 ).
- the example platform profile table 300 identifies one or more configurations for platform storage 112 to be applied to the example platform 102 based on the environmental context (block 506 ). For example, if the platform 102 is to be booted in the relatively lowest privileged state, the example disk privilege manager 212 limits user access of the storage 112 to the first volume 112 a. On the other hand, if the platform 102 is to be booted in the relatively highest privileged state, the example disk privilege manager 212 permits user access of the storage 112 to the all volumes (e.g., the first volume 112 a, the second volume 112 b, the third volume 112 c and the fourth volume 112 d ).
- the all volumes e.g., the first volume 112 a, the second volume 112 b, the third volume 112 c and the fourth volume 112 d .
- the example policy manager 210 boots the platform in a manner consistent with platform policy (block 414 ).
- the example platform profile table 300 includes a post hibernate/sleep column 310 to identify boot procedure when the example platform 102 exits a sleep state or a hibernate state.
- the example context manager 208 re-acquires context information (block 602 ).
- the platform 102 may have located to an alternate location from when it had entered the sleep state or hibernate state.
- the example authentication input manager 206 invokes one or more multi-factor authentication procedures (block 604 ). For example, if the example platform 102 previously entered the sleep or hibernate state when near the “Home” SSID, and subsequently awakens from sleep or hibernate when near that same SSID, then the example platform profile table 300 instructs the authentication input manager 206 to invoke facial recognition and voice recognition authentication procedures.
- the platform 102 awakens near an alternate SSID, then the platform is booted in the relatively lowest privilege state (e.g., lowest privileged OS, lowest privileged storage access).
- the example program 414 of FIG. 6 exits 605 , but additional aspects of the example program 414 of FIG. 6 will be discussed in further detail below.
- the example policy manager 210 determines whether to modify OS and/or drive access privileges (block 416 ). In some examples, the policy manager 210 determines and/or otherwise detects whether a modification request to elevate a platform 102 privilege status (e.g., from a user) has occurred. For example, while the platform 102 may initially boot in a first configuration having a first OS privilege and a first storage privilege, the user may request elevation of the privileges. In some examples, the user uses the platform 102 in a relatively lowest privilege because the platform 102 was near or connected to a public access WiFi hotspot.
- the example platform profile table 300 includes a privilege elevate column 308 to identify which conditions, if satisfied, will allow the platform to elevate to a relatively higher privilege operating state.
- the platform privilege status will be elevated if a greater number of authentication factors are used to gain access to the platform. For instance, if a first platform privilege status was established while the platform 102 was in an insecure location (e.g., airport) and required two separate authentication factors to gain a relatively low privilege status, then the example authentication input manager 206 may demand one or more additional authentication factors before allowing platform elevation to occur.
- the privilege elevate column 308 indicates that elevation to a full (e.g., relatively highest) OS image and full storage privilege may occur if connection to a VPN occurs 322 . If the user requests to modify the current OS/Storage privileges of the platform (block 416 ), then control advances to block 414 , as discussed above in connection with FIG. 6 .
- the example context manager 208 re-acquires context information (block 602 ) and the example authentication input manager 206 invokes one or more authentication types (e.g., voice recognition, facial recognition, keyboard passwords, etc.) (block 604 ), then the example policy manager 210 determines whether platform elevation is authorized (block 606 ). Assuming that the example platform 102 connects to the VPN and satisfies the condition(s) listed in the example privilege elevate column 308 (block 606 ), then the example boot loader manager 204 instructs the example boot loader 106 to load the corresponding higher-priority OS (block 608 ), and the example disk privilege manager 212 enables/updates access privileges to the storage 112 (block 610 ).
- one or more authentication types e.g., voice recognition, facial recognition, keyboard passwords, etc.
- the example context manager 208 determines whether a timer has expired (block 418 ). For example, the timer may expire after a periodic time, an aperiodic time, or after a particular time-of-day to perform a verification of the environmental conditions of the example platform 102 .
- the platform 102 may be a portable computing device, there is a possibility that the platform 102 is in-transit during usage.
- the example context manager 208 is invoked after the timer expires to re-acquire context information (block 420 ). Control advances to block 612 of FIG. 6 , where the example policy manager 210 determines whether platform privilege revocation should occur.
- the example program 414 exits, but if so (block 612 ), the example boot loader manager 204 instructs the boot loader 106 to load a relatively lower privilege OS and the example disk privilege manager 212 instructs the storage 112 to remove one or more volume access privileges (block 614 ).
- the state of the platform 102 may be saved to a secure location of the TEE 114 when the platform 102 privilege is revoked so that the user can later continue one or more activities with the example platform 102 after requesting to have privileges elevated.
- the example boot loader 106 determines whether one or more instructions have been received from the example TEE 114 (block 702 ). If not (block 702 ), then the example boot loader 106 waits for further instructions. However, upon receiving instructions from the example TEE 114 (block 702 ), such as one or more instructions from the example boot loader manager 204 , the boot loader 106 initiates loading of the OS identified by the boot loader manager 204 (block 704 ). Control then returns to block 702 to await further instructions to elevate, revoke or load a particular OS image.
- the example file system manager 108 determines whether one or more instructions have been received from the example TEE 114 (block 802 ). If not (block 802 ), then the example file system manager 108 waits for further instructions. However, upon receiving instructions from the example TEE 114 (block 802 ), such as one or more instructions from the example disk privilege manager 212 , the file system manager 108 updates access privileges associated with one or more volumes of the storage 112 (e.g., enable/disable privileges to the first volume 112 a, the second volume 112 b, the third volume 112 c and/or the fourth volume 112 d ) (block 804 ). Control then returns to block 802 to await further instructions to enable or disable one or more volumes of the storage 112 .
- access privileges associated with one or more volumes of the storage 112 e.g., enable/disable privileges to the first volume 112 a, the second volume 112 b, the third volume 112 c and/or the fourth volume 112 d
- FIG. 9 is a block diagram of an example processor platform 900 capable of executing the instructions of FIGS. 4-8 to implement the privilege engine 116 , the platform policy storage 118 , the boot loader 106 and/or the file system manager 108 of FIGS. 1 and 2 .
- the processor platform 900 can be, for example, a server, a personal computer, a mobile device (e.g., a cell phone, a smart phone, a tablet such as an iPad ⁇ ), a personal digital assistant (PDA), an Internet appliance, a gaming console, a personal video recorder, a set top box, or any other type of computing device.
- a mobile device e.g., a cell phone, a smart phone, a tablet such as an iPad ⁇
- PDA personal digital assistant
- an Internet appliance e.g., a gaming console, a personal video recorder, a set top box, or any other type of computing device.
- the processor platform 900 of the illustrated example includes a processor 912 .
- the processor 912 of the illustrated example is hardware.
- the processor 912 can be implemented by one or more integrated circuits, logic circuits, microprocessors or controllers from any desired family or manufacturer.
- the processor 912 also includes the example privilege engine 116 , which includes the example platform power change monitor 202 , the example boot loader manager 204 , the example authentication input manager 206 , the example context manager 208 , the example policy manager 210 and/or the example disk privilege manager 212 .
- the processor 912 of the illustrated example includes a local memory 913 (e.g., a cache).
- the processor 912 of the illustrated example is in communication with a main memory including a volatile memory 914 and a non-volatile memory 916 via a bus 918 .
- the volatile memory 914 may be implemented by Synchronous Dynamic Random Access Memory (SDRAM), Dynamic Random Access Memory (DRAM), RAMBUS Dynamic Random Access Memory (RDRAM) and/or any other type of random access memory device.
- the non-volatile memory 916 may be implemented by flash memory and/or any other desired type of memory device. Access to the main memory 914 , 916 is controlled by a memory controller.
- the processor platform 900 of the illustrated example also includes an interface circuit 920 .
- the interface circuit 920 may be implemented by any type of interface standard, such as an Ethernet interface, a universal serial bus (USB), and/or a PCI express interface.
- one or more input devices 922 are connected to the interface circuit 920 .
- the input device(s) 922 permit(s) a user to enter data and commands into the processor 912 .
- the input device(s) can be implemented by, for example, an audio sensor, a microphone, a camera (still or video), a keyboard, a button, a mouse, a touchscreen, a track-pad, a trackball, isopoint and/or a voice recognition system.
- the input device(s) may include any type of sensor to assist authentication of the example platform 102 , such as biometric sensor(s) to capture fingerprint information, facial features, vein detection, heartbeat detection, galvanic response(s), etc.
- One or more output devices 924 are also connected to the interface circuit 920 of the illustrated example.
- the output devices 924 can be implemented, for example, by display devices (e.g., a light emitting diode (LED), an organic light emitting diode (OLED), a liquid crystal display, a cathode ray tube display (CRT), a touchscreen, a tactile output device, a printer and/or speakers).
- the interface circuit 920 of the illustrated example thus, typically includes a graphics driver card, a graphics driver chip or a graphics driver processor.
- the interface circuit 920 of the illustrated example also includes a communication device such as a transmitter, a receiver, a transceiver, a modem and/or network interface card to facilitate exchange of data with external machines (e.g., computing devices of any kind) via a network 926 (e.g., an Ethernet connection, a digital subscriber line (DSL), a telephone line, coaxial cable, a cellular telephone system, etc.).
- a network 926 e.g., an Ethernet connection, a digital subscriber line (DSL), a telephone line, coaxial cable, a cellular telephone system, etc.
- the processor platform 900 of the illustrated example also includes one or more mass storage devices 928 for storing software and/or data.
- mass storage devices 928 include floppy disk drives, hard drive disks, compact disk drives, Blu-ray disk drives, RAID systems, and digital versatile disk (DVD) drives.
- the coded instructions 932 of FIGS. 4-8 may be stored in the mass storage device 928 , in the volatile memory 914 , in the non-volatile memory 916 , and/or on a removable tangible computer readable storage medium such as a CD or DVD.
- Example 1 is an apparatus to initialize a platform, which includes a boot loader manager to prevent operating system loading in response to detecting a power-on condition, a context manager to retrieve first context information associated with the platform, and a policy manager to identify a first operating system based on the first context information, the policy manager to authorize the boot loader manager to load the first operating system.
- Example 2 includes the subject matter of example 1, and also includes a platform power change monitor to distinguish a type of the power-on condition.
- Example 3 includes the subject matter of example 2, wherein the type of the power-on condition comprises at least one of a cold boot power-on condition, a power-on after a sleep state, or a power-on after a hibernate state.
- Example 4 includes the subject matter of example 1, wherein the policy manager is to compare the first context information to a platform profile table to identify the first operating system when a first service set identifier (SSID) is detected.
- SSID first service set identifier
- Example 5 includes the subject matter of example 4, and also includes a disk privilege manager to authorize a portion of platform storage based on the SSID.
- Example 6 includes the subject matter of example 1, and also includes a platform power change monitor to determine a prior platform state as at least one of a sleep state or a hibernate state.
- Example 7 includes the subject matter of example 6, wherein the context manager is to retrieve second context information associated with the platform when the prior platform state comprises at least one of the sleep state or the hibernate state.
- Example 8 includes the subject matter of example 7, wherein the policy manager is to determine if the first context information is different than the second context information.
- Example 9 includes the subject matter of example 8, wherein the policy manager is to permit the first operating system to be loaded on the platform when the first context information is not different than the second context information.
- Example 10 includes the subject matter of example 8, wherein the policy manager is to prohibit the first operating system from being loaded on the platform when the first context information is different than the second context information.
- Example 11 includes the subject matter of example 10, wherein the boot loader manager is to load a second operating system having a relatively lower privilege status than the first operating system.
- Example 12 includes the subject matter of example 8, and also includes a disk privilege manager to maintain a previously established disk access privilege when the first context information is not different than the second context information.
- Example 13 includes the subject matter of example 1, wherein the policy manager is to detect a request to elevate a privilege status of the platform.
- Example 14 includes the subject matter of example 13, and also includes an authentication input manager to generate a request for a set of authentication factors.
- Example 15 includes the subject matter of examples 1 and/or 2, wherein the type of the power-on condition comprises at least one of a cold boot power-on condition, a power-on after a sleep state, or a power-on after a hibernate state.
- Example 16 includes the subject matter of examples 4 and/or 5, and also includes a platform power change monitor to determine a prior platform state as at least one of a sleep state or a hibernate state, wherein the context manager is to retrieve second context information associated with the platform when the prior platform state comprises at least one of the sleep state or the hibernate state.
- Example 17 includes the subject matter of examples 13 and/or 14, and also includes a disk privilege manager to maintain a previously established disk access privilege when the first context information is not different than the second context information.
- Example 18 includes a method to initialize a platform, and also includes preventing operating system loading in response to detecting a power-on condition, retrieving first context information associated with the platform, identifying a first operating system based on the first context information, and authorizing, with the processor, loading of the first operating system.
- Example 19 includes the subject matter of example 18, and also includes distinguishing a type of the power-on condition.
- Example 20 includes the subject matter of example 19, and also includes identifying at least one of a cold boot power-on condition, a power-on after a sleep state, or a power-on after a hibernate state.
- Example 21 includes the subject matter of example 18, and also includes comparing the first context information to a platform profile table to identify the first operating system when a first service set identifier (SSID) is detected.
- SSID first service set identifier
- Example 22 includes the subject matter of example 21, and also includes authorizing a portion of platform storage based on the SSID.
- Example 23 includes the subject matter of example 18, and also includes determining a prior platform state as at least one of a sleep state or a hibernate state.
- Example 24 includes the subject matter of example 23, and also includes retrieving second context information associated with the platform when the prior platform state comprises at least one of the sleep state or the hibernate state.
- Example 25 includes the subject matter of example 24, and also includes determining if the first context information is different than the second context information.
- Example 26 includes the subject matter of example 25, and also includes permitting the first operating system to be loaded on the platform when the first context information is not different than the second context information.
- Example 27 includes the subject matter of example 25, and also includes prohibiting the first operating system from being loaded on the platform when the first context information is different than the second context information.
- Example 28 includes the subject matter of example 27, and also includes loading a second operating system having a relatively lower privilege status than the first operating system.
- Example 29 includes the subject matter of example 25, and also includes maintaining a previously established disk access privilege when the first context information is not different than the second context information.
- Example 30 includes the subject matter of example 18, and also includes detecting a request to elevate a privilege status of the platform.
- Example 31 includes the subject matter of example 30, and also includes generating a request for a set of authentication factors.
- Example 32 includes the subject matter of examples 18-20, and also includes comparing the first context information to a platform profile table to identify the first operating system when a first service set identifier (SSID) is detected, and authorizing a portion of platform storage based on the SSID.
- SSID first service set identifier
- Example 33 includes the subject matter of examples 18-20, and also includes determining a prior platform state as at least one of a sleep state or a hibernate state, retrieving second context information associated with the platform when the prior platform state comprises at least one of the sleep state or the hibernate state, and determining if the first context information is different than the second context information.
- Example 34 is a tangible machine readable storage medium comprising machine readable instructions that, when executed, cause a machine to at least prevent operating system loading in response to detecting a power-on condition, retrieve first context information associated with the platform, identify a first operating system based on the first context information, and authorize loading of the first operating system.
- Example 35 includes the subject matter of example 34, and also includes instructions to distinguish a type of the power-on condition.
- Example 36 includes the subject matter of example 35, and also includes instructions to identify at least one of a cold boot power-on condition, a power-on after a sleep state, or a power-on after a hibernate state.
- Example 37 includes the subject matter of example 34, and also includes instructions to compare the first context information to a platform profile table to identify the first operating system when a first service set identifier (SSID) is detected.
- SSID first service set identifier
- Example 38 includes the subject matter of example 37, and also includes instructions to authorize a portion of platform storage based on the SSID.
- Example 39 includes the subject matter of example 1, and also includes instructions to determine a prior platform state as at least one of a sleep state or a hibernate state.
- Example 40 includes the subject matter of example 39, and also includes instructions to retrieve second context information associated with the platform when the prior platform state comprises at least one of the sleep state or the hibernate state.
- Example 41 includes the subject matter of example 40, and also includes instructions to determine if the first context information is different than the second context information.
- Example 42 includes the subject matter of example 41, and also includes instructions to permit the first operating system to be loaded on the platform when the first context information is not different than the second context information.
- Example 43 includes the subject matter of example 41, and also includes instructions to prohibit the first operating system from being loaded on the platform when the first context information is different than the second context information.
- Example 44 includes the subject matter of example 43, and also includes instructions to load a second operating system having a relatively lower privilege status than the first operating system.
- Example 45 includes the subject matter of example 41, and also includes instructions to maintain a previously established disk access privilege when the first context information is not different than the second context information.
- Example 46 includes the subject matter of example 34, and also includes instructions to detect a request to elevate a privilege status of the platform.
- Example 47 includes the subject matter of example 46, and also includes instructions to generate a request for a set of authentication factors.
- Example 48 includes the subject matter of examples 34-36, and also includes instructions to compare the first context information to a platform profile table to identify the first operating system when a first service set identifier (SSID) is detected, and authorize a portion of platform storage based on the SSID.
- SSID first service set identifier
- Example 49 includes the subject matter of examples 34-36, and also includes instructions to determine a prior platform state as at least one of a sleep state or a hibernate state, retrieve second context information associated with the platform when the prior platform state comprises at least one of the sleep state or the hibernate state, and determine if the first context information is different than the second context information.
- Example 50 includes a system to initialize a platform, and also includes means for preventing operating system loading in response to detecting a power-on condition, means for retrieving first context information associated with the platform, means for identifying a first operating system based on the first context information, and means for authorizing loading of the first operating system.
- Example 51 includes the subject matter of example 50, and also includes means for distinguishing a type of the power-on condition.
- Example 52 includes the subject matter of example 51, and also includes means for identifying at least one of a cold boot power-on condition, a power-on after a sleep state, or a power-on after a hibernate state.
- Example 53 includes the subject matter of example 50, and also includes means for comparing the first context information to a platform profile table to identify the first operating system when a first service set identifier (SSID) is detected.
- SSID first service set identifier
- Example 54 includes the subject matter of example 53, and also includes means for authorizing a portion of platform storage based on the SSID.
- Example 55 includes the subject matter of example 50, and also includes means for determining a prior platform state as at least one of a sleep state or a hibernate state.
- Example 56 includes the subject matter of example 55, and also includes means for retrieving second context information associated with the platform when the prior platform state comprises at least one of the sleep state or the hibernate state.
- Example 57 includes the subject matter of example 56, and also includes means for determining if the first context information is different than the second context information.
- Example 58 includes the subject matter of example 57 and also includes means for permitting the first operating system to be loaded on the platform when the first context information is not different than the second context information.
- Example 59 includes the subject matter of example 57, and also includes means for prohibiting the first operating system from being loaded on the platform when the first context information is different than the second context information.
- Example 60 includes the subject matter of example 59, and also includes means for loading a second operating system having a relatively lower privilege status than the first operating system.
- Example 61 includes the subject matter of example 57, and also includes means for maintaining a previously established disk access privilege when the first context information is not different than the second context information.
- Example 62 includes the subject matter of example 50, and also includes means for detecting a request to elevate a privilege status of the platform.
- Example 63 includes the subject matter of example 62, and also includes means for generating a request for a set of authentication factors.
- Example 64 includes the subject matter of examples 50-52, and also includes means for comparing the first context information to a platform profile table to identify the first operating system when a first service set identifier (SSID) is detected, and means for authorizing a portion of platform storage based on the SSID.
- SSID first service set identifier
- Example 65 includes the subject matter of examples 50-52, and also includes means for determining a prior platform state as at least one of a sleep state or a hibernate state, means for retrieving second context information associated with the platform when the prior platform state comprises at least one of the sleep state or the hibernate state, and means for determining if the first context information is different than the second context information.
- examples disclosed herein enable a trusted execution environment to determine one or more multi-factor authentication credentials combined with one or more environmental context information associated with the platform to determine a preferred and/or otherwise appropriate privilege operating state of the platform.
- Security of the platform is enhanced with any number of different authentication requirements in view of the varying differences in safety in which the platform may be used.
Abstract
Description
- This patent arises from a continuation of U.S. patent application Ser. No. 14/581,309, filed Dec. 23, 2014, entitled “Methods, Systems and Apparatus to Initialize a Platform,” the entirety of which is hereby incorporated herein by reference.
- In recent years, security breaches have become more frequent. Users of platforms (e.g., computing devices) typically enter a password to gain access to their respective computing devices, and some users apply the same password for one or more other services (e.g., financial accounts) accessed via the computing device. In the event that the user password is revealed, stolen and/or otherwise utilized by an unauthorized person or entity, harm may result from the unauthorized access to the computing device and/or services.
-
FIG. 1 is a schematic illustration of a system to initialize a platform. -
FIG. 2 is a schematic illustration of a privilege engine ofFIG. 1 . -
FIG. 3 is an example platform profile table used by the example system ofFIGS. 1 and 2 to initialize a platform. -
FIGS. 4-8 are flowcharts representative of example machine readable instructions that may be executed to initialize a platform in a manner consistent with the teachings of this disclosure. -
FIG. 9 is a schematic illustration of an example processor platform that may execute the instructions ofFIGS. 4-8 to implement the example system ofFIGS. 1 and 2 . - Mobile devices enable a substantial productivity improvement for users due to advances in portable computing power, battery life and network connectivity. However, the relatively small size of such mobile devices also increases the ease at which a thief may steal the devices. In some cases, the thief may observe the owner of a mobile device prior to stealing it so that authentication credentials may be obtained. For example, the thief may observe password keyboard entry activity by the owner prior to stealing the mobile device. Accordingly, the thief may use such authentication information after stealing the mobile device so that access to privileged disk information and/or network system access may occur.
-
FIG. 1 is anexample system 100 to initialize aplatform 102 in connection with context information and platform policy instructions. Theexample platform 102 ofFIG. 1 may be a mobile computing device, such as a mobile telephone, a tablet, a laptop computer, a netbook, etc. In the illustrated example ofFIG. 1 , theplatform 102 includes platform software/firmware 104, such as aboot loader 106 and afile system manager 108. - In some examples, the
file system manager 108 conforms to one or more specifications developed by the Trusted Computing Group (TCG) in which a storage device (e.g., a disk drive) may be divided into any number of partitions, in which each partition may be referred to as a volume having its own encrypted locking range. Theexample boot loader 106 ofFIG. 1 is responsible for loading an example operating system (OS) 110 based on a platform policy and corresponding context information, as described in further detail below. - The example
file system manager 108 is communicatively connected to storage 112 (platform storage), in which one or more volumes of theexample storage 112 include afirst volume 112 a, asecond volume 112 b, athird volume 112 c and afourth volume 112 d. Each of thevolumes 112 a-112 d are made available to theexample platform 102 based on the platform policy and corresponding context information, as described in further detail below. - The
example platform 102 ofFIG. 1 also includes a trusted execution environment (TEE) 114, which includes anexample privilege engine 116 andplatform policy storage 118. In some examples, the TEE 114 includes its own media access control (MAC) address and/or Internet protocol (IP) address to facilitate out-of-band (OOB) communications independent and/or otherwise separate from theexample platform 102. The example TEE 114 may be implemented as the Intel® Management Engine (ME), or in a manner consistent with the TCG as a trusted platform module (TPM). In some examples, the TEE 114 includes one or more cryptographic processor(s), secured input/output (I/O), random number generator(s), key generator(s), hash generator(s), platform configuration registers (PCRs), and/or keys (e.g., storage root keys, attestation identity keys, etc.). - The example TEE 114 of
FIG. 1 operates as an authentication engine to enable one or more inputs and/or types of input to be used when attempting to gain access privileges of theexample platform 102. In particular, theexample privilege engine 116 is communicatively connected toauthentication sensors 120. Theexample authentication sensors 120 ofFIG. 1 include a near field communications (NFC)transceiver 122, amicrophone 124, afingerprint reader 126, acamera 128, a radio frequency (RF)transceiver 130 and akeyboard 132. While six (6) sensor types are shown with theexample authentication sensors 120, additional and/or alternative sensor types may be considered, without limitation. In some examples, theNFC transceiver 122 interacts with an employee identification card/badge and/or theRF transceiver 130 interacts with anetwork device 134 having a Wi-Fi signal, such as a network router, and/or theRF transceiver 130 interacts with amobile device 136 having a Bluetooth signal, such as a wireless telephone. -
FIG. 2 illustrates additional detail of theexample privilege engine 116 ofFIG. 1 . In the illustrated example ofFIG. 2 , theprivilege engine 116 includes a platform power change monitor 202, aboot loader manager 204, anauthentication input manager 206, acontext manager 208, apolicy manager 210 and a disk privilege manager 212. - In operation, the example platform power change monitor 202 determines whether there has been a power state change of the
example platform 102. Additionally, the example platform power change monitor 202 distinguishes between one or more different types of power-on conditions, such as a cold boot power-on condition, a power-on condition from a prior sleep state, or a power-on condition from a prior hibernate state. For example, if theplatform 102 is in a prior powerless state and is turned on, which is sometimes referred to as a cold boot or hard boot, the platform software/firmware 104 typically accesses a reset vector for a processor of theplatform 102 to begin execution. Additionally, when theexample platform 102 begins execution from a prior powerless state, one or more power-on-self-test (POST) operations are initiated to bring one or more portions of theexample platform 102 in a proper state for operation (e.g., verifying processor register states, verifying component presence and/or integrity (e.g., timers, interrupt controllers, direct memory access devices, etc.), determining system main memory location(s) and corresponding size(s), and initializing the basic input/output system (BIOS)). - The cold boot also includes invocation of the
example boot loader 106 to begin loading an OS for theexample platform 102. However, because a default OS loaded by theexample boot loader 106 may introduce one or more security risks to theplatform 102, example methods, apparatus, systems and/or articles of manufacture disclosed herein determine which one of any number of OSs to load based on platform policy and contextual information. As used herein, contextual information and/or context refer to environmental conditions of theexample platform 102. Environmental conditions may include, but are not limited to, Wi-Fi signals proximate to theexample platform 102, Bluetooth signals proximate to theexample platform 102 and/or NFC signals proximate to theexample platform 102. As disclosed in further detail below, the platform policy (e.g., one or more policies stored in the example platform policy storage 118) instructs theexample privilege engine 116 to boot a particular OS based on (a) context, (b) multi-factor inputs and/or (c) a prior operating state of the example platform 102 (e.g., a prior powerless state, a prior sleep state, a prior hibernate state, etc.). - Continuing with the
example privilege engine 116 in the illustrated examples ofFIGS. 1 and 2 , if the example platform power change monitor 202 determines that the platform was previously in a powerless state, thereby causing a cold boot, then the exampleboot loader manager 204 intercepts theexample boot loader 106 to prevent it from loading a default OS for theexample platform 102. The exampleauthentication input manager 206 invokes theexample authentication sensors 120 to retrieve authentication information from a user of theexample platform 102. As described above, the authentication information may include input from theexample NFC transceiver 122 based on proximity to an authorized employee identification card (e.g., an employee identification card containing an NFC tag). In other examples, the authentication information may include input from themicrophone 124 to capture a voiceprint from the user to be compared against a reference voiceprint (e.g., a voiceprint reference stored in the exampleplatform policy storage 118 of the example TEE 114). In still other examples, the authentication information may include input from thefingerprint reader 126 to capture a fingerprint scan of the user to be compared against an authorized reference fingerprint. In some examples, the authentication information may include input from thecamera 128 to capture an image of the user to be compared against an authorized reference image. In still other examples, the authentication information may include input from a keyboard to obtain one or more passwords to be compared against authorized passwords stored in theTEE 114. In still other examples, one or more combinations of inputs may be retrieved and compared to identify a multi-factor authentication that, when each factor is individually authorized, permits the user to utilize one or more resources of theplatform 102. - While multi-factor authentication inputs reduce a risk of unauthorized access to the platform and/or resources available to the platform (e.g., hard drive storage information, network resource access, cloud-accessible storage access, etc.), some environments of the
example platform 102 present greater or lesser degrees of risk. For example, public locations such as coffee shops, restaurants, airports and/or libraries typically exhibit a relatively higher degree of risk due to greater numbers of unknown people having access to those locations and the ability of those people to observe and/or otherwise monitor the behaviors of the owner of theexample platform 102. In some cases, a would-be hacker or thief may systematically observe the user to identify particular keyboard keystrokes that reflect a password. Further, in the event the thief subsequently steals theplatform 102, then the resources of theplatform 102 may be available to the thief. - In other examples, the would-be thief conducts observations using a network sniffer and/or packet analyzer to capture input data associated with the multi-factor authentication. Such collected authentication input data may be used at a subsequent time for access to the
platform 102 and/or platform resources in the event theplatform 102 is stolen. While examples involving theft are described above, examples disclosed herein are not limited to such circumstances. For instance, sensitive data stored on theexample platform 102 and/or accessible via the example platform 102 (e.g., via network connections, via cloud-based services, etc.) may be accessible to non-authorized persons and/or personnel via non-malicious and/or inadvertent activities. - To reduce the possibility of unauthorized access (either malicious or non-malicious), the
example policy manager 210 accesses a platform policy from theplatform policy storage 118 of the example TEE 114 and instructs theexample boot loader 106 to load an OS based on context information associated with theexample platform 102. Additionally, the example disk privilege manager 212 instructs the examplefile system manager 108 to provide or disable one or more volumes of thestorage 112 based on the context information associated with theexample platform 102. - For example, in the event the
platform 102 is powered-on and thecontext manager 208 detects a service set identifier (SSID) associated with an authorized enterprise network associated with a user of the platform 102 (e.g., an SSID known to be located in an office, laboratory, etc.), then the platform profile may indicate a particular level of access be granted to theplatform 102. On the other hand, in the event thecontext manager 208 detects a SSID associated with an authorized network within the user's home (e.g., home office), then the platform profile may indicate an alternate (e.g., relatively lower) level of access. In some examples, the enterprise network is a relatively highest privilege level in which theplatform 102 may load an enterprise OS image and full access to all volumes of thestorage 112 are available to the user when theplatform 102 is near the enterprise SSID. However, the platform profile may cause theplatform 102 to load an alternate OS image having fewer enterprise-level privileges when the SSID associated with the user's home is detected during boot. Moreover, the platform profile may cause theplatform 102 to load a lowest-privileged OS when the SSID is unrecognized and/or associated with known public places (e.g., airports, coffee shops, etc.). As such, as environmental risks increase, example methods, apparatus, systems and/or articles of manufacture disclosed herein adjust platform privileges to reduce unauthorized access to theexample platform 102 and/or services thereof. -
FIG. 3 illustrates an example platform profile table 300, which includes anexample SSID column 302, anOS privilege column 304, adisk privilege column 306, a privilege elevatecolumn 308 and a post hibernate/sleep column 310. In the illustrated example ofFIG. 3 , theSSID column 302 includes known SSIDs that have a corresponding privilege configuration. For example, in the event thecontext manager 208 detects an SSID named “Office_1,” then thepolicy manager 210 retrieves the profile table 300 stored in theplatform policy storage 118 to determine a corresponding OS to load from theOS privilege column 304. In some examples, thepolicy manager 210 performs one or more comparisons of retrieved context information with one or more fields of the example platform profile table 300 to determine (a) which OS to load and (b) a corresponding storage (disk) privilege condition. In the illustrated example ofFIG. 3 , the “Office_1” SSID authorizes a highest level OS to be loaded (e.g., an Enterprise OS). Additionally, thedisk privilege column 306 authorizes full access privileges to thestorage 112 when the “Office_1” SSID is detected. - In some examples, the
platform 102 may be elevated to a relatively higher privilege level, thereby allowing relatively greater access tolocal storage 112 information and/or relatively more capable and/or functional OS images. In the event a particular SSID includes an option to elevate one or more privileges of the example platform, the example privilege elevatecolumn 308 identifies the necessary conditions before that may occur. Continuing with the example “Office_1” SSID ofFIG. 3 , because the Enterprise OS is already authorized, no further opportunities to elevate the privilege exist. However, assuming for the sake of this example that thecontext manager 208 detects “Home” as the SSID, then the example privilege elevatecolumn 308 instructs the platform to establish an authorized virtual private network (VPN) before the Enterprise OS may be loaded. - While examples disclosed above include the
platform 102 in a prior powerless state, example methods, apparatus, systems and/or articles of manufacture disclosed herein are not limited thereto. In some examples, the platform is in a prior sleep state or a prior hibernate state before a power-up state is invoked (e.g., a user press of the power button). Generally speaking, the sleep state of a platform is an energy saving state in which on-board platform memory (e.g., random access memory (RAM)) stores user data and processor register data before shutting-down other platform components (e.g., disabling power to the hard drive to save energy otherwise spent on spinning). A relatively small amount of power is used by the platform while in the sleep state to preserve platform user state information in the memory. The hibernate state, on the other hand, transfers all user data and processor register data to hard disk storage rather than to memory. As such, the hibernate state of the platform does not consume energy to maintain the state. - When a typical platform comes out of a sleep or hibernate state, the boot loader of that platform is not invoked because the OS image previously loaded will again resume operation. Additionally, security measures for the typical platform when exiting the sleep or hibernate state are managed and/or otherwise controlled by OS policy. This OS policy usually requires a minimal level of security to access platform resources after the sleep or hibernate state, such as a keyboard entry password. One security concern associated with the typical post-sleep or post-hibernate operation is that the OS password policy is weak and the same OS image will be available to the user (e.g., a thief) even when the post-sleep or post-hibernate state occurs in a less-secure location (e.g., a coffee shop).
- In response to the example platform power change monitor 202 detecting that the
example platform 102 powers-up after a sleep or hibernate state (rather than from a cold/hard boot), then thecontext manager 208 is invoked to intercept any OS-based security policy, and re-acquire context information. Prior to authorizing any resources of theexample platform 102, the exampleauthentication input manager 206 prompts the user of theplatform 102 for authentication input credentials based on the example platform profile table 300. In particular, the example post hibernate/sleep column 310 identifies the type of authentication credentials when the detected SSID is associated with “Office_1” 316. On the other hand, in the event theexample platform 102 emerges from the sleep/hibernate state and is proximate to the SSID name “Home,” then the exampleauthentication input manager 206 prompts the user foralternate input credentials 318. - Returning to the illustrated example of
FIG. 3 , theexample policy manager 210 compares the new context information to the post hibernate/sleep column 310 corresponding to the previously detected SSID. In other words, theexample policy manager 210 determines whether a prior platform state is different than a currently detected platform state. Assuming that the previously detected SSID was “Office_1” when theexample platform 102 entered the sleep/hibernate mode, then the post hibernate/sleep column 310 indicates that no change to the OS needs to occur if the currently detected SSID hasn't changed 312 (i.e., the currently detected SSID is still “Office_1”). In other words, the previously established OS privilege and/or disk privilege status is maintained when theexample platform 102 is powered on after the sleep or hibernate state. On the other hand, in the event that the currently detected SSID is no longer the same SSID as it was when the sleep/hibernate state started (i.e., “Office_1,”) then the example post hibernate/sleep column 310 indicates that the example platform should not re-enable the Enterprise OS, but rather change the OS to a low priority image and removestorage access privileges 314. In other words, the previously established OS and/or disk privilege status is prohibited on theexample platform 102 when it is powered on having a different SSID (and/or other context identifiers). - In some examples, a dynamic change in the
platform 102 may occur based on a user request to elevate privileges. For example, while initial authentication procedures may restrict theplatform 102 to loading a relatively lowest privileged OS when the SSID is indicative of a public place (e.g., a coffee shop), the user of theplatform 102 may wish to access a relatively higher privileged state of theplatform 102. If so, theexample context manager 208 may reacquire context information to confirm current environmental conditions (e.g., determine whether theplatform 102 still near the same SSID), and/or require particular elevation procedures dictated by the example platform profile table 300. Assume, for the sake of this example that theplatform 102 is currently near and/or otherwise connected to a network associated with the SSID “MainStreetCoffee” 320. Additionally, the SSID “MainStreetCoffee” 320 corresponds to a relatively lowest privileged OS (see the example OS privilege column 304) and a relatively lowest privileged disk access configuration (see the example disk privilege column 306). - However, the example privilege elevate
column 308 identifies an opportunity to elevate the OS and the disk privileges to a full (highest) state if a VPN connection is established 322. If those conditions are met, the exampleboot loader manager 204 instructs theexample boot loader 106 to load an OS image for the Enterprise OS, and the example disk privilege manager 212 instructs the examplefile system manager 108 to allow access to all available disk volumes (e.g., thefirst volume 112 a, thesecond volume 112 b, thethird volume 112 c and thefourth volume 112 d). - In some examples, the
privilege engine 116 checks environmental conditions of theplatform 102 on a periodic, aperiodic, scheduled and/or manual basis to determine whether a previously detected/connected SSID has changed. For example, if theplatform 102 is a mobile personal computer, then it can be moved from a first location to a second location. In the event that the second location is deemed less secure, then examples disclosed herein react to the new environmental conditions to reduce the risk of unauthorized access to theplatform 102 and/or resources available to theplatform 102. In response to theexample context manager 208 detecting that an updated SSID proximate to theplatform 102 is associated with a relatively lower privilege (as determined by the example platform profile table 300), theexample policy manager 210 determines that current privileges of theplatform 102 should be revoked. The exampleboot loader manager 204 instructs theexample boot loader 106 to load a new OS image having the relatively lower privilege level (e.g., a cloud OS), and the example disk privilege manager 212 instructs the examplefile system manager 108 to disable platform access to one or more volumes of thestorage 112. In some examples, theprivilege engine 116 saves the complete user state of theplatform 102 in memory and/or instorage 112 before revoking the access privileges. In that way, the user of theexample platform 102 may re-establish the relatively higher privileges of theplatform 102 if proper authentication credentials are subsequently provided, as described above. - While an example manner of implementing the
example privilege engine 116 ofFIG. 1 is illustrated inFIG. 2 , one or more of the elements, processes and/or devices illustrated inFIGS. 1 and 2 may be combined, divided, re-arranged, omitted, eliminated and/or implemented in any other way. Further, the example platform power change monitor 202, the exampleboot loader manager 204, the exampleauthentication input manager 206, theexample context manager 208, theexample policy manager 210, the example disk privilege manager 212, theexample boot loader 106, the examplefile system manager 108, the exampleplatform policy storage 118 and/or, more generally, theexample privilege engine 116 ofFIGS. 1 and 2 may be implemented by hardware, software, firmware and/or any combination of hardware, software and/or firmware. Thus, for example, any of the example platform power change monitor 202, the exampleboot loader manager 204, the exampleauthentication input manager 206, theexample context manager 208, theexample policy manager 210, the example disk privilege manager 212, theexample boot loader 106, the examplefile system manager 108, the exampleplatform policy storage 118 and/or, more generally, theexample privilege engine 116 ofFIGS. 1 and 2 could be implemented by one or more analog or digital circuit(s), logic circuits, programmable processor(s), application specific integrated circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)) and/or field programmable logic device(s) (FPLD(s)). When reading any of the apparatus or system claims of this patent to cover a purely software and/or firmware implementation, at least one of the example platform power change monitor 202, the exampleboot loader manager 204, the exampleauthentication input manager 206, theexample context manager 208, theexample policy manager 210, the example disk privilege manager 212, theexample boot loader 106, the examplefile system manager 108, the exampleplatform policy storage 118 and/or, more generally, theexample privilege engine 116 ofFIGS. 1 and 2 is/are hereby expressly defined to include a tangible computer readable storage device or storage disk such as a memory, a digital versatile disk (DVD), a compact disk (CD), a Blu-ray disk, etc. storing the software and/or firmware. Further still, theexample privilege engine 116 ofFIGS. 1 and 2 may include one or more elements, processes and/or devices in addition to, or instead of, those illustrated inFIGS. 1 and 2 , and/or may include more than one of any or all of the illustrated elements, processes and devices. - Flowcharts representative of example machine readable instructions for implementing the
privilege engine 116, theboot loader 106 and/or thefile system manager 108 ofFIGS. 1 and 2 are shown inFIGS. 4-8 . In these examples, the machine readable instructions comprise a program for execution by a processor such as theprocessor 912 shown in theexample processor platform 900 discussed below in connection withFIG. 9 . The program may be embodied in software stored on a tangible computer readable storage medium such as a CD-ROM, a floppy disk, a hard drive, a digital versatile disk (DVD), a Blu-ray disk, or a memory associated with theprocessor 912, but the entire program and/or parts thereof could alternatively be executed by a device other than theprocessor 912 and/or embodied in firmware or dedicated hardware. Further, although the example program is described with reference to the flowcharts illustrated inFIGS. 4-8 , many other methods of implementing theexample privilege engine 116, theexample boot loader 106 and/or the examplefile system manager 108 may alternatively be used. For example, the order of execution of the blocks may be changed, and/or some of the blocks described may be changed, eliminated, or combined. - As mentioned above, the example processes of
FIGS. 4-8 may be implemented using coded instructions (e.g., computer and/or machine readable instructions) stored on a tangible computer readable storage medium such as a hard disk drive, a flash memory, a read-only memory (ROM), a compact disk (CD), a digital versatile disk (DVD), a cache, a random-access memory (RAM) and/or any other storage device or storage disk in which information is stored for any duration (e.g., for extended time periods, permanently, for brief instances, for temporarily buffering, and/or for caching of the information). As used herein, the term tangible computer readable storage medium is expressly defined to include any type of computer readable storage device and/or storage disk and to exclude propagating signals and to exclude transmission media. As used herein, “tangible computer readable storage medium” and “tangible machine readable storage medium” are used interchangeably. Additionally or alternatively, the example processes ofFIGS. 4-8 may be implemented using coded instructions (e.g., computer and/or machine readable instructions) stored on a non-transitory computer and/or machine readable medium such as a hard disk drive, a flash memory, a read-only memory, a compact disk, a digital versatile disk, a cache, a random-access memory and/or any other storage device or storage disk in which information is stored for any duration (e.g., for extended time periods, permanently, for brief instances, for temporarily buffering, and/or for caching of the information). As used herein, the term non-transitory computer readable medium is expressly defined to include any type of computer readable storage device and/or storage disk and to exclude propagating signals and to exclude transmission media. As used herein, when the phrase “at least” is used as the transition term in a preamble of a claim, it is open-ended in the same manner as the term “comprising” is open ended. - The
program 400 ofFIG. 4 begins atblock 402 where the example platform power change monitor 202 determines whether a power change condition has occurred. As described above, theexample platform 102 may be powered on from a prior unpowered state, in which a cold/hard boot results. In other examples, theplatform 102 may be powered on from a prior sleep state or a prior hibernate state. The example platform power change monitor 202 distinguishes between one or more different types of power-on conditions (block 404), such as determining whether the power-on condition is occurring from a prior sleep or hibernate state. - If the example platform power change monitor 202 determines that the
example platform 102 has been powered on from a previously unpowered state (i.e., neither a prior sleep state nor a prior hibernate state) (block 404), then the exampleboot loader manager 204 intercepts the operations of theexample boot loader 106 to prevent a default OS image from being loaded on the platform 102 (block 406). As described above, typical platform operation during power-on includes theboot loader 106 loading a default OS image from storage (e.g., storage 112) after the POST is complete. However, examples disclosed herein do not permit a default OS image from being loaded on theexample platform 102 and, instead, determine an appropriate OS image to load based on environmental conditions, platform policy, and multi-factor authentication input(s). - The example
authentication input manager 206 retrieves authentication information in a manner consistent with authentication instructions stored in the TEE 114 (block 408). For example, rather than rely on authentication policies associated with an OS, examples disclosed herein allow platform managers (e.g., IT personnel) to design multi-factor authentication procedure(s) stored in hardened hardware (e.g., the TEE 114). The exampleauthentication input manager 206 is communicatively connected to theexample authentication sensors 120 to retrieve one or more inputs to authenticate a user of theexample platform 102. In some examples, theauthentication input manager 206 controls one or more output devices (seeFIG. 9 below) to issue one or more instructions/prompts to the user for authentication purposes. For example, theauthentication input manager 206 may generate a prompt for the user of theplatform 102 to apply their finger to thefingerprint reader 126 and/or to position their face in front of thecamera 128. - The
example context manager 208 collects and/or otherwise detects context information associated with the example platform 102 (block 410). In some examples, thecontext manager 208 invokes theRF transceiver 130 to determine which WiFi network(s) 134 are near the example platform 102 (block 410). In still other examples, thecontext manager 208 invokes theRF transceiver 130 to determine which Bluetooth devices are near the example platform 102 (block 410). In some examples, presence of a particular Bluetooth device near theplatform 102 is an additional indication that theplatform 102 is still under the control and/or management of an authorized user. Theexample policy manager 210 applies platform policy to theexample platform 102 based on the collected authentication information and collected context information (block 412). -
FIG. 5 illustrates additional detail from theexample program 400 ofFIG. 4 in connection with applying platform policy (block 412). In the illustratedexample program 412 ofFIG. 5 , thepolicy manager 210 accesses the platform profile table 300 from the TEE 114 (block 502). In some examples, the platform profile table 300 is stored in the exampleplatform policy storage 118 of theTEE 114. As described above in connection withFIG. 3 , the example platform profile table 300 identifies one or more configurations of theplatform 102 based on one or more environmental conditions. Based on corresponding environmental conditions detected by theexample context manager 208 and successful authentication as determined by the exampleauthentication input manager 206, the exampleboot loader manager 204 instructs theexample boot loader 106 to load a corresponding OS image (block 504). Additionally, the example platform profile table 300 identifies one or more configurations forplatform storage 112 to be applied to theexample platform 102 based on the environmental context (block 506). For example, if theplatform 102 is to be booted in the relatively lowest privileged state, the example disk privilege manager 212 limits user access of thestorage 112 to thefirst volume 112 a. On the other hand, if theplatform 102 is to be booted in the relatively highest privileged state, the example disk privilege manager 212 permits user access of thestorage 112 to the all volumes (e.g., thefirst volume 112 a, thesecond volume 112 b, thethird volume 112 c and thefourth volume 112 d). - Returning to the illustrated example of
FIG. 4 , in the event theplatform 102 was in a prior sleep state or hibernate state (block 404), then theexample policy manager 210 boots the platform in a manner consistent with platform policy (block 414). As described above, the example platform profile table 300 includes a post hibernate/sleep column 310 to identify boot procedure when theexample platform 102 exits a sleep state or a hibernate state. In the illustrated example ofFIG. 6 , theexample context manager 208 re-acquires context information (block 602). For example, during the time in which theplatform 102 was in the sleep state or the hibernate state, theplatform 102 may have located to an alternate location from when it had entered the sleep state or hibernate state. Based on the instructions of the hibernate/sleep column 310, the exampleauthentication input manager 206 invokes one or more multi-factor authentication procedures (block 604). For example, if theexample platform 102 previously entered the sleep or hibernate state when near the “Home” SSID, and subsequently awakens from sleep or hibernate when near that same SSID, then the example platform profile table 300 instructs theauthentication input manager 206 to invoke facial recognition and voice recognition authentication procedures. However, in the event that theexample platform 102 awakens near an alternate SSID, then the platform is booted in the relatively lowest privilege state (e.g., lowest privileged OS, lowest privileged storage access). Theexample program 414 ofFIG. 6 exits 605, but additional aspects of theexample program 414 ofFIG. 6 will be discussed in further detail below. - Returning to
FIG. 4 , in the event that the example platform power change monitor 202 has not identified that a power change condition has occurred on the platform 102 (block 402), then theexample policy manager 210 determines whether to modify OS and/or drive access privileges (block 416). In some examples, thepolicy manager 210 determines and/or otherwise detects whether a modification request to elevate aplatform 102 privilege status (e.g., from a user) has occurred. For example, while theplatform 102 may initially boot in a first configuration having a first OS privilege and a first storage privilege, the user may request elevation of the privileges. In some examples, the user uses theplatform 102 in a relatively lowest privilege because theplatform 102 was near or connected to a public access WiFi hotspot. However, the example platform profile table 300 includes a privilege elevatecolumn 308 to identify which conditions, if satisfied, will allow the platform to elevate to a relatively higher privilege operating state. In some examples, the platform privilege status will be elevated if a greater number of authentication factors are used to gain access to the platform. For instance, if a first platform privilege status was established while theplatform 102 was in an insecure location (e.g., airport) and required two separate authentication factors to gain a relatively low privilege status, then the exampleauthentication input manager 206 may demand one or more additional authentication factors before allowing platform elevation to occur. - Assuming, for the sake of this example, that the platform is in the relatively lowest privilege operating state associated with connection to and/or proximity to the “MainStreetCoffee”
SSID 320, then the privilege elevatecolumn 308 indicates that elevation to a full (e.g., relatively highest) OS image and full storage privilege may occur if connection to a VPN occurs 322. If the user requests to modify the current OS/Storage privileges of the platform (block 416), then control advances to block 414, as discussed above in connection withFIG. 6 . After theexample context manager 208 re-acquires context information (block 602) and the exampleauthentication input manager 206 invokes one or more authentication types (e.g., voice recognition, facial recognition, keyboard passwords, etc.) (block 604), then theexample policy manager 210 determines whether platform elevation is authorized (block 606). Assuming that theexample platform 102 connects to the VPN and satisfies the condition(s) listed in the example privilege elevate column 308 (block 606), then the exampleboot loader manager 204 instructs theexample boot loader 106 to load the corresponding higher-priority OS (block 608), and the example disk privilege manager 212 enables/updates access privileges to the storage 112 (block 610). - Returning to the illustrated example of
FIG. 4 , if the platform power change monitor 202 does not identify a change in the power condition of the platform 102 (block 402), and thepolicy manager 210 does not receive a request to modify OS/Storage privileges (block 416), then theexample context manager 208 determines whether a timer has expired (block 418). For example, the timer may expire after a periodic time, an aperiodic time, or after a particular time-of-day to perform a verification of the environmental conditions of theexample platform 102. Generally speaking, because theplatform 102 may be a portable computing device, there is a possibility that theplatform 102 is in-transit during usage. In the event that the in-transit usage brings theplatform 102 from a first location having a generally trusted environment (e.g., an office location) to a second location having a generally less-trusted environment (e.g., a public access point), then theexample context manager 208 is invoked after the timer expires to re-acquire context information (block 420). Control advances to block 612 ofFIG. 6 , where theexample policy manager 210 determines whether platform privilege revocation should occur. If not (block 612), theexample program 414 exits, but if so (block 612), the exampleboot loader manager 204 instructs theboot loader 106 to load a relatively lower privilege OS and the example disk privilege manager 212 instructs thestorage 112 to remove one or more volume access privileges (block 614). As described above, the state of theplatform 102 may be saved to a secure location of theTEE 114 when theplatform 102 privilege is revoked so that the user can later continue one or more activities with theexample platform 102 after requesting to have privileges elevated. - In the illustrated example of
FIG. 7 , theexample boot loader 106 determines whether one or more instructions have been received from the example TEE 114 (block 702). If not (block 702), then theexample boot loader 106 waits for further instructions. However, upon receiving instructions from the example TEE 114 (block 702), such as one or more instructions from the exampleboot loader manager 204, theboot loader 106 initiates loading of the OS identified by the boot loader manager 204 (block 704). Control then returns to block 702 to await further instructions to elevate, revoke or load a particular OS image. - In the illustrated example of
FIG. 8 , the examplefile system manager 108 determines whether one or more instructions have been received from the example TEE 114 (block 802). If not (block 802), then the examplefile system manager 108 waits for further instructions. However, upon receiving instructions from the example TEE 114 (block 802), such as one or more instructions from the example disk privilege manager 212, thefile system manager 108 updates access privileges associated with one or more volumes of the storage 112 (e.g., enable/disable privileges to thefirst volume 112 a, thesecond volume 112 b, thethird volume 112 c and/or thefourth volume 112 d) (block 804). Control then returns to block 802 to await further instructions to enable or disable one or more volumes of thestorage 112. -
FIG. 9 is a block diagram of anexample processor platform 900 capable of executing the instructions ofFIGS. 4-8 to implement theprivilege engine 116, theplatform policy storage 118, theboot loader 106 and/or thefile system manager 108 ofFIGS. 1 and 2 . Theprocessor platform 900 can be, for example, a server, a personal computer, a mobile device (e.g., a cell phone, a smart phone, a tablet such as an iPadυ), a personal digital assistant (PDA), an Internet appliance, a gaming console, a personal video recorder, a set top box, or any other type of computing device. - The
processor platform 900 of the illustrated example includes aprocessor 912. Theprocessor 912 of the illustrated example is hardware. For example, theprocessor 912 can be implemented by one or more integrated circuits, logic circuits, microprocessors or controllers from any desired family or manufacturer. Theprocessor 912 also includes theexample privilege engine 116, which includes the example platform power change monitor 202, the exampleboot loader manager 204, the exampleauthentication input manager 206, theexample context manager 208, theexample policy manager 210 and/or the example disk privilege manager 212. - The
processor 912 of the illustrated example includes a local memory 913 (e.g., a cache). Theprocessor 912 of the illustrated example is in communication with a main memory including avolatile memory 914 and anon-volatile memory 916 via abus 918. Thevolatile memory 914 may be implemented by Synchronous Dynamic Random Access Memory (SDRAM), Dynamic Random Access Memory (DRAM), RAMBUS Dynamic Random Access Memory (RDRAM) and/or any other type of random access memory device. Thenon-volatile memory 916 may be implemented by flash memory and/or any other desired type of memory device. Access to themain memory - The
processor platform 900 of the illustrated example also includes aninterface circuit 920. Theinterface circuit 920 may be implemented by any type of interface standard, such as an Ethernet interface, a universal serial bus (USB), and/or a PCI express interface. - In the illustrated example, one or
more input devices 922 are connected to theinterface circuit 920. The input device(s) 922 permit(s) a user to enter data and commands into theprocessor 912. The input device(s) can be implemented by, for example, an audio sensor, a microphone, a camera (still or video), a keyboard, a button, a mouse, a touchscreen, a track-pad, a trackball, isopoint and/or a voice recognition system. As described above, the input device(s) may include any type of sensor to assist authentication of theexample platform 102, such as biometric sensor(s) to capture fingerprint information, facial features, vein detection, heartbeat detection, galvanic response(s), etc. - One or
more output devices 924 are also connected to theinterface circuit 920 of the illustrated example. Theoutput devices 924 can be implemented, for example, by display devices (e.g., a light emitting diode (LED), an organic light emitting diode (OLED), a liquid crystal display, a cathode ray tube display (CRT), a touchscreen, a tactile output device, a printer and/or speakers). Theinterface circuit 920 of the illustrated example, thus, typically includes a graphics driver card, a graphics driver chip or a graphics driver processor. - The
interface circuit 920 of the illustrated example also includes a communication device such as a transmitter, a receiver, a transceiver, a modem and/or network interface card to facilitate exchange of data with external machines (e.g., computing devices of any kind) via a network 926 (e.g., an Ethernet connection, a digital subscriber line (DSL), a telephone line, coaxial cable, a cellular telephone system, etc.). - The
processor platform 900 of the illustrated example also includes one or moremass storage devices 928 for storing software and/or data. Examples of suchmass storage devices 928 include floppy disk drives, hard drive disks, compact disk drives, Blu-ray disk drives, RAID systems, and digital versatile disk (DVD) drives. - The coded
instructions 932 ofFIGS. 4-8 may be stored in themass storage device 928, in thevolatile memory 914, in thenon-volatile memory 916, and/or on a removable tangible computer readable storage medium such as a CD or DVD. - The following examples, which include subject matter such as an apparatus to initialize a platform, a method to initialize a platform, at least one machine-readable medium instructions that, when performed by a machine cause the machine to perform platform initialization and/or a system to initialize a platform, are disclosed herein.
- Example 1 is an apparatus to initialize a platform, which includes a boot loader manager to prevent operating system loading in response to detecting a power-on condition, a context manager to retrieve first context information associated with the platform, and a policy manager to identify a first operating system based on the first context information, the policy manager to authorize the boot loader manager to load the first operating system.
- Example 2 includes the subject matter of example 1, and also includes a platform power change monitor to distinguish a type of the power-on condition.
- Example 3 includes the subject matter of example 2, wherein the type of the power-on condition comprises at least one of a cold boot power-on condition, a power-on after a sleep state, or a power-on after a hibernate state.
- Example 4 includes the subject matter of example 1, wherein the policy manager is to compare the first context information to a platform profile table to identify the first operating system when a first service set identifier (SSID) is detected.
- Example 5 includes the subject matter of example 4, and also includes a disk privilege manager to authorize a portion of platform storage based on the SSID.
- Example 6 includes the subject matter of example 1, and also includes a platform power change monitor to determine a prior platform state as at least one of a sleep state or a hibernate state.
- Example 7 includes the subject matter of example 6, wherein the context manager is to retrieve second context information associated with the platform when the prior platform state comprises at least one of the sleep state or the hibernate state.
- Example 8 includes the subject matter of example 7, wherein the policy manager is to determine if the first context information is different than the second context information.
- Example 9 includes the subject matter of example 8, wherein the policy manager is to permit the first operating system to be loaded on the platform when the first context information is not different than the second context information.
- Example 10 includes the subject matter of example 8, wherein the policy manager is to prohibit the first operating system from being loaded on the platform when the first context information is different than the second context information.
- Example 11 includes the subject matter of example 10, wherein the boot loader manager is to load a second operating system having a relatively lower privilege status than the first operating system.
- Example 12 includes the subject matter of example 8, and also includes a disk privilege manager to maintain a previously established disk access privilege when the first context information is not different than the second context information.
- Example 13 includes the subject matter of example 1, wherein the policy manager is to detect a request to elevate a privilege status of the platform.
- Example 14 includes the subject matter of example 13, and also includes an authentication input manager to generate a request for a set of authentication factors.
- Example 15 includes the subject matter of examples 1 and/or 2, wherein the type of the power-on condition comprises at least one of a cold boot power-on condition, a power-on after a sleep state, or a power-on after a hibernate state.
- Example 16 includes the subject matter of examples 4 and/or 5, and also includes a platform power change monitor to determine a prior platform state as at least one of a sleep state or a hibernate state, wherein the context manager is to retrieve second context information associated with the platform when the prior platform state comprises at least one of the sleep state or the hibernate state.
- Example 17 includes the subject matter of examples 13 and/or 14, and also includes a disk privilege manager to maintain a previously established disk access privilege when the first context information is not different than the second context information.
- Example 18 includes a method to initialize a platform, and also includes preventing operating system loading in response to detecting a power-on condition, retrieving first context information associated with the platform, identifying a first operating system based on the first context information, and authorizing, with the processor, loading of the first operating system.
- Example 19 includes the subject matter of example 18, and also includes distinguishing a type of the power-on condition.
- Example 20 includes the subject matter of example 19, and also includes identifying at least one of a cold boot power-on condition, a power-on after a sleep state, or a power-on after a hibernate state.
- Example 21 includes the subject matter of example 18, and also includes comparing the first context information to a platform profile table to identify the first operating system when a first service set identifier (SSID) is detected.
- Example 22 includes the subject matter of example 21, and also includes authorizing a portion of platform storage based on the SSID.
- Example 23 includes the subject matter of example 18, and also includes determining a prior platform state as at least one of a sleep state or a hibernate state.
- Example 24 includes the subject matter of example 23, and also includes retrieving second context information associated with the platform when the prior platform state comprises at least one of the sleep state or the hibernate state.
- Example 25 includes the subject matter of example 24, and also includes determining if the first context information is different than the second context information.
- Example 26 includes the subject matter of example 25, and also includes permitting the first operating system to be loaded on the platform when the first context information is not different than the second context information.
- Example 27 includes the subject matter of example 25, and also includes prohibiting the first operating system from being loaded on the platform when the first context information is different than the second context information.
- Example 28 includes the subject matter of example 27, and also includes loading a second operating system having a relatively lower privilege status than the first operating system.
- Example 29 includes the subject matter of example 25, and also includes maintaining a previously established disk access privilege when the first context information is not different than the second context information.
- Example 30 includes the subject matter of example 18, and also includes detecting a request to elevate a privilege status of the platform.
- Example 31 includes the subject matter of example 30, and also includes generating a request for a set of authentication factors.
- Example 32 includes the subject matter of examples 18-20, and also includes comparing the first context information to a platform profile table to identify the first operating system when a first service set identifier (SSID) is detected, and authorizing a portion of platform storage based on the SSID.
- Example 33 includes the subject matter of examples 18-20, and also includes determining a prior platform state as at least one of a sleep state or a hibernate state, retrieving second context information associated with the platform when the prior platform state comprises at least one of the sleep state or the hibernate state, and determining if the first context information is different than the second context information.
- Example 34 is a tangible machine readable storage medium comprising machine readable instructions that, when executed, cause a machine to at least prevent operating system loading in response to detecting a power-on condition, retrieve first context information associated with the platform, identify a first operating system based on the first context information, and authorize loading of the first operating system.
- Example 35 includes the subject matter of example 34, and also includes instructions to distinguish a type of the power-on condition.
- Example 36 includes the subject matter of example 35, and also includes instructions to identify at least one of a cold boot power-on condition, a power-on after a sleep state, or a power-on after a hibernate state.
- Example 37 includes the subject matter of example 34, and also includes instructions to compare the first context information to a platform profile table to identify the first operating system when a first service set identifier (SSID) is detected.
- Example 38 includes the subject matter of example 37, and also includes instructions to authorize a portion of platform storage based on the SSID.
- Example 39 includes the subject matter of example 1, and also includes instructions to determine a prior platform state as at least one of a sleep state or a hibernate state.
- Example 40 includes the subject matter of example 39, and also includes instructions to retrieve second context information associated with the platform when the prior platform state comprises at least one of the sleep state or the hibernate state.
- Example 41 includes the subject matter of example 40, and also includes instructions to determine if the first context information is different than the second context information.
- Example 42 includes the subject matter of example 41, and also includes instructions to permit the first operating system to be loaded on the platform when the first context information is not different than the second context information.
- Example 43 includes the subject matter of example 41, and also includes instructions to prohibit the first operating system from being loaded on the platform when the first context information is different than the second context information.
- Example 44 includes the subject matter of example 43, and also includes instructions to load a second operating system having a relatively lower privilege status than the first operating system.
- Example 45 includes the subject matter of example 41, and also includes instructions to maintain a previously established disk access privilege when the first context information is not different than the second context information.
- Example 46 includes the subject matter of example 34, and also includes instructions to detect a request to elevate a privilege status of the platform.
- Example 47 includes the subject matter of example 46, and also includes instructions to generate a request for a set of authentication factors.
- Example 48 includes the subject matter of examples 34-36, and also includes instructions to compare the first context information to a platform profile table to identify the first operating system when a first service set identifier (SSID) is detected, and authorize a portion of platform storage based on the SSID.
- Example 49 includes the subject matter of examples 34-36, and also includes instructions to determine a prior platform state as at least one of a sleep state or a hibernate state, retrieve second context information associated with the platform when the prior platform state comprises at least one of the sleep state or the hibernate state, and determine if the first context information is different than the second context information.
- Example 50 includes a system to initialize a platform, and also includes means for preventing operating system loading in response to detecting a power-on condition, means for retrieving first context information associated with the platform, means for identifying a first operating system based on the first context information, and means for authorizing loading of the first operating system.
- Example 51 includes the subject matter of example 50, and also includes means for distinguishing a type of the power-on condition.
- Example 52 includes the subject matter of example 51, and also includes means for identifying at least one of a cold boot power-on condition, a power-on after a sleep state, or a power-on after a hibernate state.
- Example 53 includes the subject matter of example 50, and also includes means for comparing the first context information to a platform profile table to identify the first operating system when a first service set identifier (SSID) is detected.
- Example 54 includes the subject matter of example 53, and also includes means for authorizing a portion of platform storage based on the SSID.
- Example 55 includes the subject matter of example 50, and also includes means for determining a prior platform state as at least one of a sleep state or a hibernate state.
- Example 56 includes the subject matter of example 55, and also includes means for retrieving second context information associated with the platform when the prior platform state comprises at least one of the sleep state or the hibernate state.
- Example 57 includes the subject matter of example 56, and also includes means for determining if the first context information is different than the second context information.
- Example 58 includes the subject matter of example 57 and also includes means for permitting the first operating system to be loaded on the platform when the first context information is not different than the second context information.
- Example 59 includes the subject matter of example 57, and also includes means for prohibiting the first operating system from being loaded on the platform when the first context information is different than the second context information.
- Example 60 includes the subject matter of example 59, and also includes means for loading a second operating system having a relatively lower privilege status than the first operating system.
- Example 61 includes the subject matter of example 57, and also includes means for maintaining a previously established disk access privilege when the first context information is not different than the second context information.
- Example 62 includes the subject matter of example 50, and also includes means for detecting a request to elevate a privilege status of the platform.
- Example 63 includes the subject matter of example 62, and also includes means for generating a request for a set of authentication factors.
- Example 64 includes the subject matter of examples 50-52, and also includes means for comparing the first context information to a platform profile table to identify the first operating system when a first service set identifier (SSID) is detected, and means for authorizing a portion of platform storage based on the SSID.
- Example 65 includes the subject matter of examples 50-52, and also includes means for determining a prior platform state as at least one of a sleep state or a hibernate state, means for retrieving second context information associated with the platform when the prior platform state comprises at least one of the sleep state or the hibernate state, and means for determining if the first context information is different than the second context information.
- From the foregoing, it will be appreciated that the above disclosed methods, apparatus, systems and/or articles of manufacture have been disclosed to initialize a platform. Rather than rely on an operating system and/or BIOS to enforce a manner of platform initialization, examples disclosed herein enable a trusted execution environment to determine one or more multi-factor authentication credentials combined with one or more environmental context information associated with the platform to determine a preferred and/or otherwise appropriate privilege operating state of the platform. Security of the platform is enhanced with any number of different authentication requirements in view of the varying differences in safety in which the platform may be used.
- Although certain example methods, apparatus and articles of manufacture have been disclosed herein, the scope of coverage of this patent is not limited thereto. On the contrary, this patent covers all methods, apparatus and articles of manufacture fairly falling within the scope of the claims of this patent.
Claims (1)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US15/443,831 US20170235958A1 (en) | 2014-12-23 | 2017-02-27 | Methods, systems and apparatus to initialize a platform |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/581,309 US9619242B2 (en) | 2014-12-23 | 2014-12-23 | Methods, systems and apparatus to initialize a platform |
US15/443,831 US20170235958A1 (en) | 2014-12-23 | 2017-02-27 | Methods, systems and apparatus to initialize a platform |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/581,309 Continuation US9619242B2 (en) | 2014-12-23 | 2014-12-23 | Methods, systems and apparatus to initialize a platform |
Publications (1)
Publication Number | Publication Date |
---|---|
US20170235958A1 true US20170235958A1 (en) | 2017-08-17 |
Family
ID=56129489
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/581,309 Active US9619242B2 (en) | 2014-12-23 | 2014-12-23 | Methods, systems and apparatus to initialize a platform |
US15/443,831 Abandoned US20170235958A1 (en) | 2014-12-23 | 2017-02-27 | Methods, systems and apparatus to initialize a platform |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/581,309 Active US9619242B2 (en) | 2014-12-23 | 2014-12-23 | Methods, systems and apparatus to initialize a platform |
Country Status (4)
Country | Link |
---|---|
US (2) | US9619242B2 (en) |
EP (1) | EP3238123B1 (en) |
CN (1) | CN107077355B (en) |
WO (1) | WO2016105692A1 (en) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10325116B2 (en) * | 2017-06-30 | 2019-06-18 | Vmware, Inc. | Dynamic privilege management in a computer system |
US11675902B2 (en) | 2018-12-05 | 2023-06-13 | Vmware, Inc. | Security detection system with privilege management |
WO2023218780A1 (en) * | 2022-05-09 | 2023-11-16 | パナソニックIpマネジメント株式会社 | Electronic device and control method |
Families Citing this family (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9674185B2 (en) * | 2015-01-29 | 2017-06-06 | International Business Machines Corporation | Authentication using individual's inherent expression as secondary signature |
US9578020B2 (en) | 2015-03-19 | 2017-02-21 | Sony Corporation | Module for controlling usability of a device |
US10120696B2 (en) * | 2015-03-19 | 2018-11-06 | Sony Corporation | Method and device for controlling usability of a communication device |
US20170039376A1 (en) | 2015-08-05 | 2017-02-09 | Dell Products L.P. | Systems and methods for providing secure data |
CN106572049B (en) | 2015-10-09 | 2019-08-27 | 腾讯科技(深圳)有限公司 | A kind of auth method and device |
US10592669B2 (en) | 2016-06-23 | 2020-03-17 | Vmware, Inc. | Secure booting of computer system |
US10242196B2 (en) * | 2016-07-29 | 2019-03-26 | Vmware, Inc. | Secure booting of computer system |
EP3451215B1 (en) * | 2017-08-28 | 2019-12-18 | Siemens Aktiengesellschaft | Hardware device and method for operating and producing a hardware device |
US10924282B2 (en) * | 2018-05-24 | 2021-02-16 | Cyber Pack Ventures, Inc. | System and method for measuring and reporting IoT boot integrity |
US11755704B2 (en) * | 2020-03-31 | 2023-09-12 | Fortinet, Inc. | Facilitating secure unlocking of a computing device |
US20220113982A1 (en) * | 2020-10-09 | 2022-04-14 | Arris Enterprises Llc | Selective switching of an active partition in an electronic device |
US20220014551A1 (en) * | 2021-09-24 | 2022-01-13 | Intel Corporation | Method and apparatus to reduce risk of denial of service resource acquisition attacks in a data center |
Citations (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5574786A (en) * | 1995-02-06 | 1996-11-12 | International Business Machines Corporation | Securing trusted personal computer system against unauthorized movement |
US5970227A (en) * | 1996-04-30 | 1999-10-19 | International Business Machines Corp. | Wireless proximity detector security feature |
US6088794A (en) * | 1997-07-31 | 2000-07-11 | Samsung Electronics Co., Ltd. | Computer system capable of selective booting from two hard disk drives |
US20020147924A1 (en) * | 1999-10-27 | 2002-10-10 | Flyntz Terence T. | Multi-level secure computer with token-based access control |
US20030159056A1 (en) * | 2002-02-15 | 2003-08-21 | International Business Machines Corporation | Method and system for securing enablement access to a data security device |
US6711688B1 (en) * | 1999-11-30 | 2004-03-23 | International Business Machines Corporation | Pre-execution logon (PEL) |
US20070005947A1 (en) * | 2005-06-30 | 2007-01-04 | Chartrand Brent D | Operating system mode transfer |
US7231665B1 (en) * | 2001-07-05 | 2007-06-12 | Mcafee, Inc. | Prevention of operating system identification through fingerprinting techniques |
US20080148387A1 (en) * | 2006-10-18 | 2008-06-19 | Madina Shab H | Trusted platform module management system and method |
US20080244292A1 (en) * | 2007-03-30 | 2008-10-02 | Alok Kumar | Method and Apparatus to Re-create trust model after sleep state |
US20090089569A1 (en) * | 2007-09-28 | 2009-04-02 | Microsoft Corporation | Multi-os (operating system) boot via mobile device |
US20090327675A1 (en) * | 2007-12-20 | 2009-12-31 | Dell Products L.P. | System and method for os boot image provisioning based on user identity to enable mobile users |
US20100153696A1 (en) * | 2008-12-12 | 2010-06-17 | Novell, Inc. | Pre-boot securing of operating system (OS) for endpoint evaluation |
US20120032945A1 (en) * | 2008-12-19 | 2012-02-09 | Openpeak Inc. | Portable computing device and method of operation of same |
US20120137049A1 (en) * | 2010-11-30 | 2012-05-31 | Micron Technology, Inc. | Code patching for non-volatile memory |
US20140115364A1 (en) * | 2012-10-24 | 2014-04-24 | Insyde Software Corp. | Method and device for advanced configuration and power interface (acpi) sleep-state support using cpu-only reset |
US20140137101A1 (en) * | 2012-10-02 | 2014-05-15 | Nextbit Systems Inc. | Automatically installing operating system specific to a detected network |
US20140215236A1 (en) * | 2013-01-29 | 2014-07-31 | Nvidia Corporation | Power-efficient inter processor communication scheduling |
US20140325197A1 (en) * | 2013-04-25 | 2014-10-30 | Insyde Software Corp. | Specialized boot path for speeding up resume from sleep state |
US20150052616A1 (en) * | 2013-08-14 | 2015-02-19 | L-3 Communications Corporation | Protected mode for securing computing devices |
US20160085963A1 (en) * | 2014-09-19 | 2016-03-24 | Intel IP Corporation | Centralized platform settings management for virtualized and multi os systems |
Family Cites Families (23)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7194764B2 (en) | 2000-07-10 | 2007-03-20 | Oracle International Corporation | User authentication |
US6928542B2 (en) | 2001-11-15 | 2005-08-09 | Inventec Corporation | Method and system for starting a multiple PDA operating system through a menu |
US9191215B2 (en) | 2003-12-30 | 2015-11-17 | Entrust, Inc. | Method and apparatus for providing authentication using policy-controlled authentication articles and techniques |
US8527752B2 (en) | 2004-06-16 | 2013-09-03 | Dormarke Assets Limited Liability | Graduated authentication in an identity management system |
US7739744B2 (en) | 2006-03-31 | 2010-06-15 | Novell, Inc. | Methods and systems for multifactor authentication |
US8671444B2 (en) | 2006-10-06 | 2014-03-11 | Fmr Llc | Single-party, secure multi-channel authentication for access to a resource |
US20080175379A1 (en) | 2007-01-23 | 2008-07-24 | Broadcom Corporation | Simple pairing to generate private keys for different protocol communications |
US9112681B2 (en) | 2007-06-22 | 2015-08-18 | Fujitsu Limited | Method and apparatus for secure information transfer to support migration |
US20090089588A1 (en) * | 2007-09-28 | 2009-04-02 | Farid Adrangi | Method and apparatus for providing anti-theft solutions to a computing system |
US20090165125A1 (en) | 2007-12-19 | 2009-06-25 | Research In Motion Limited | System and method for controlling user access to a computing device |
US8854966B2 (en) | 2008-01-10 | 2014-10-07 | Apple Inc. | Apparatus and methods for network resource allocation |
US20090187962A1 (en) | 2008-01-17 | 2009-07-23 | International Business Machines Corporation | Methods, devices, and computer program products for policy-driven adaptive multi-factor authentication |
US8769612B2 (en) | 2008-08-14 | 2014-07-01 | Microsoft Corporation | Portable device association |
KR101501167B1 (en) | 2008-10-20 | 2015-03-10 | 삼성전자주식회사 | Apparatus and method for application of multi operating systems in multi modem mobile communication terminal |
US9372711B2 (en) | 2009-07-20 | 2016-06-21 | Google Technology Holdings LLC | System and method for initiating a multi-environment operating system |
CN102004652A (en) | 2009-08-31 | 2011-04-06 | 鸿富锦精密工业(深圳)有限公司 | Electronic device and multiple start method thereof |
US8817642B2 (en) | 2010-06-25 | 2014-08-26 | Aliphcom | Efficient pairing of networked devices |
US20120079271A1 (en) | 2010-09-24 | 2012-03-29 | Carlos Cordeiro | Method and apparatus for wireless device authentication and association |
US20130055379A1 (en) | 2011-08-23 | 2013-02-28 | Research In Motion Limited | System, device and method for authentication |
CN103150209A (en) * | 2011-12-07 | 2013-06-12 | 文晔科技股份有限公司 | Portable type tablet computer with double operation systems and control method thereof |
CA2794132C (en) * | 2012-11-01 | 2020-12-08 | Ibm Canada Limited - Ibm Canada Limitee | Configuring configuration settings using a user context |
CN103838597B (en) * | 2012-11-27 | 2017-06-27 | 联想(北京)有限公司 | A kind of os starting method, device and electronic equipment |
US20160066184A1 (en) | 2014-08-29 | 2016-03-03 | Intel Corporation | Pairing Computing Devices According To A Multi-Level Security Protocol |
-
2014
- 2014-12-23 US US14/581,309 patent/US9619242B2/en active Active
-
2015
- 2015-11-16 CN CN201580062754.2A patent/CN107077355B/en active Active
- 2015-11-16 WO PCT/US2015/060883 patent/WO2016105692A1/en active Application Filing
- 2015-11-16 EP EP15873915.1A patent/EP3238123B1/en active Active
-
2017
- 2017-02-27 US US15/443,831 patent/US20170235958A1/en not_active Abandoned
Patent Citations (22)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5574786A (en) * | 1995-02-06 | 1996-11-12 | International Business Machines Corporation | Securing trusted personal computer system against unauthorized movement |
US5970227A (en) * | 1996-04-30 | 1999-10-19 | International Business Machines Corp. | Wireless proximity detector security feature |
US6088794A (en) * | 1997-07-31 | 2000-07-11 | Samsung Electronics Co., Ltd. | Computer system capable of selective booting from two hard disk drives |
US20020147924A1 (en) * | 1999-10-27 | 2002-10-10 | Flyntz Terence T. | Multi-level secure computer with token-based access control |
US6711688B1 (en) * | 1999-11-30 | 2004-03-23 | International Business Machines Corporation | Pre-execution logon (PEL) |
US7231665B1 (en) * | 2001-07-05 | 2007-06-12 | Mcafee, Inc. | Prevention of operating system identification through fingerprinting techniques |
US20030159056A1 (en) * | 2002-02-15 | 2003-08-21 | International Business Machines Corporation | Method and system for securing enablement access to a data security device |
US20070005947A1 (en) * | 2005-06-30 | 2007-01-04 | Chartrand Brent D | Operating system mode transfer |
US20080148387A1 (en) * | 2006-10-18 | 2008-06-19 | Madina Shab H | Trusted platform module management system and method |
US20080244292A1 (en) * | 2007-03-30 | 2008-10-02 | Alok Kumar | Method and Apparatus to Re-create trust model after sleep state |
US20090089569A1 (en) * | 2007-09-28 | 2009-04-02 | Microsoft Corporation | Multi-os (operating system) boot via mobile device |
US20090327675A1 (en) * | 2007-12-20 | 2009-12-31 | Dell Products L.P. | System and method for os boot image provisioning based on user identity to enable mobile users |
US20100153696A1 (en) * | 2008-12-12 | 2010-06-17 | Novell, Inc. | Pre-boot securing of operating system (OS) for endpoint evaluation |
US8566571B2 (en) * | 2008-12-12 | 2013-10-22 | Novell, Inc. | Pre-boot securing of operating system (OS) for endpoint evaluation |
US20120032945A1 (en) * | 2008-12-19 | 2012-02-09 | Openpeak Inc. | Portable computing device and method of operation of same |
US20120137049A1 (en) * | 2010-11-30 | 2012-05-31 | Micron Technology, Inc. | Code patching for non-volatile memory |
US20140137101A1 (en) * | 2012-10-02 | 2014-05-15 | Nextbit Systems Inc. | Automatically installing operating system specific to a detected network |
US20140115364A1 (en) * | 2012-10-24 | 2014-04-24 | Insyde Software Corp. | Method and device for advanced configuration and power interface (acpi) sleep-state support using cpu-only reset |
US20140215236A1 (en) * | 2013-01-29 | 2014-07-31 | Nvidia Corporation | Power-efficient inter processor communication scheduling |
US20140325197A1 (en) * | 2013-04-25 | 2014-10-30 | Insyde Software Corp. | Specialized boot path for speeding up resume from sleep state |
US20150052616A1 (en) * | 2013-08-14 | 2015-02-19 | L-3 Communications Corporation | Protected mode for securing computing devices |
US20160085963A1 (en) * | 2014-09-19 | 2016-03-24 | Intel IP Corporation | Centralized platform settings management for virtualized and multi os systems |
Non-Patent Citations (1)
Title |
---|
Dayan; Richard A; Securing trusted personal computer system against unauthorized movement; IBM 1996; page no. 1-25 * |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10325116B2 (en) * | 2017-06-30 | 2019-06-18 | Vmware, Inc. | Dynamic privilege management in a computer system |
US11675902B2 (en) | 2018-12-05 | 2023-06-13 | Vmware, Inc. | Security detection system with privilege management |
WO2023218780A1 (en) * | 2022-05-09 | 2023-11-16 | パナソニックIpマネジメント株式会社 | Electronic device and control method |
Also Published As
Publication number | Publication date |
---|---|
WO2016105692A1 (en) | 2016-06-30 |
EP3238123A4 (en) | 2018-07-11 |
CN107077355A (en) | 2017-08-18 |
US9619242B2 (en) | 2017-04-11 |
US20160179554A1 (en) | 2016-06-23 |
EP3238123A1 (en) | 2017-11-01 |
CN107077355B (en) | 2021-10-01 |
EP3238123B1 (en) | 2020-01-29 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9619242B2 (en) | Methods, systems and apparatus to initialize a platform | |
JP5350528B2 (en) | System and method for providing platform with additional security through location-based data | |
US10552590B2 (en) | System and method for providing an authentication agent in a persistent authentication framework | |
KR101654778B1 (en) | Hardware-enforced access protection | |
KR101775800B1 (en) | Anti-theft in firmware | |
US8763112B2 (en) | Systems and methods for power-on user authentication | |
US7793339B2 (en) | Devices and methods of using network information in an authorization process | |
US20140020122A1 (en) | Always-available embedded theft reaction subsystem | |
KR20160147993A (en) | Premises-aware security and policy orchestration | |
US20100083366A1 (en) | Blocking Computer System Ports on Per User Basis | |
US10586029B2 (en) | Information handling system multi-security system management | |
WO2022055802A1 (en) | Temporary removal of software programs to secure mobile device | |
US10810297B2 (en) | Information handling system multi-touch security system | |
KR100991191B1 (en) | Computer security module and computer apparatus using the same | |
TWI738014B (en) | System and device for data protection and method thereof | |
US20210126909A1 (en) | Information Handling Systems And Methods To Manage Tickets Based On User Presence, System State And Ticket Management Policy | |
TWI767548B (en) | Methods and systems for operating user devices having multiple operating systems | |
CN114840259A (en) | Method and system for operating user device with multiple operating systems |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: INTEL CORPORATION, CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:KHOSRAVI, HORMUZD M.;PEARSON, ADRIAN R.;SMITH, NEAL M.;AND OTHERS;SIGNING DATES FROM 20150318 TO 20150413;REEL/FRAME:041836/0388 |
|
AS | Assignment |
Owner name: INTEL CORPORATION, CALIFORNIA Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE SPELLING OF ASSIGNOR NAME FROM NEAL M. SMITH TO NED M. SMITH PREVIOUSLY RECORDED ON REEL 041836 FRAME 0388. ASSIGNOR(S) HEREBY CONFIRMS THE THE ASSIGNMENT;ASSIGNORS:KHOSRAVI, HORMUZD M.;PEARSON, ADRIAN R.;SMITH, NED M.;AND OTHERS;SIGNING DATES FROM 20150318 TO 20150413;REEL/FRAME:042176/0391 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |