Abstract: According to an aspect, a method for accessing a computing device includes receiving, by the computing device, an authentication credential for recovery access to the computing device, the authentication credential being different from an authentication credential used to access encrypted data on the computing device, obtaining, in response to receipt of the authentication credential for recovery access, a first key portion stored on the computing device, transmitting, over a network, a request to receive a second key portion, receiving, over the network, a response that includes the second key portion, recovering a decryption key using the first key portion and the second key portion, and decrypting the encrypted data on the computing device using the decryption key.

Abstract: According to an aspect, a method for accessing a computing device includes receiving, by the computing device, an authentication credential for recovery access to the computing device, the authentication credential being different from an authentication credential used to access encrypted data on the computing device, obtaining, in response to receipt of the authentication credential for recovery access, a first key portion stored on the computing device, transmitting, over a network, a request to receive a second key portion, receiving, over the network, a response that includes the second key portion, recovering a decryption key using the first key portion and the second key portion, and decrypting the encrypted data on the computing device using the decryption key.

Abstract: According to an aspect, a method includes receiving data loss prevention (DLP) restriction data, where the DLP restriction data defines a first DLP control. The first DLP control identifies at least one content attribute of restricted content. The first DLP control identifies a restriction to a computer function when the restricted content is rendered on a display of a computing device. The method includes storing the DLP restriction data in a memory device associated with an operating system of the computing device, detecting, by the operating system, that content rendered on the display of the computing device includes at least a portion of the restricted content as identified by the at least one content attribute, and restricting the computer function during a period of time in which the portion of the restricted content is rendered on the display.

Abstract: According to an aspect, a method for accessing a computing device includes receiving, by the computing device, an authentication credential for recovery access to the computing device, the authentication credential being different from an authentication credential used to access encrypted data on the computing device, obtaining, in response to receipt of the authentication credential for recovery access, a first key portion stored on the computing device, transmitting, over a network, a request to receive a second key portion, receiving, over the network, a response that includes the second key portion, recovering a decryption key using the first key portion and the second key portion, and decrypting the encrypted data on the computing device using the decryption key.

Abstract: Methods and devices for accessing encrypted data on a computer device may include determining that a current device state of the computer device is locked. The methods and devices may include using a level two encryption key to encrypt data associated with at least one application while the computer device is locked. The methods and devices may include using a temporary decryption key in memory of the computer device to access level two encrypted data while the computer device is locked.

Abstract: Methods and devices for accessing encrypted data on a computer device may include determining that a current device state of the computer device is locked. The methods and devices may include using a level two encryption key to encrypt data associated with at least one application while the computer device is locked. The methods and devices may include using a temporary decryption key in memory of the computer device to access level two encrypted data while the computer device is locked.

Abstract: In one embodiment, a user device may reestablish access to a user resource while forgoing use of a user credential during a system reboot. The user device may receive the user credential from a user during an initial login to access the user resource. The user device may create an ephemeral entropy to access the user resource. The user device may access the user resource using the ephemeral entropy.

Abstract: In one embodiment, a client device 110 may use an attestation service 140 to verify a secure server 120. The secure server 120 may receive a signed trusted credential 310 from an attestation service 140 validating the secure server 120 as trustworthy to a client device 110 seeking access. The secure server 120 may protect the signed trusted credential 310 in a server secure module 280.

Abstract: In one embodiment, a user device may reestablish access to a user resource while forgoing use of a user credential during a system reboot. The user device may receive the user credential from a user during an initial login to access the user resource. The user device may create an ephemeral entropy to access the user resource. The user device may access the user resource using the ephemeral entropy.

Abstract: A facility for managing the state of an electronic device is described. A facility determines a maximum-inactivity-to-lock period length and a grace period length. The facility subtracts the grace period length from the maximum-inactivity-to-lock period length to obtain an inactivity-to-disable-display period length. During a time when the device is unlocked and a visual display of the device is enabled, the facility receives one or more first user input events. At a time that is the inactivity-to-disable-display period length after the latest first user input event is received, the facility disables the visual display to begin a grace period. At a time that is less than the grace period length later than the beginning of the grace period, the facility receives a second user input event. In response, the facility enables the visual display in order to provide authenticated access to the device without imposing any further authentication process.

Abstract: The techniques discussed herein may facilitate user account management while also protecting a user's personally identifiable information (PII). The user's PII is stored in a protected area, such as a secure operating system area. The techniques may also implement a broker process to access a user's PII. The techniques display a user's accounts that are available for use with an application. The techniques further provide for passing a hint to the application upon receiving selection of an account, wherein the hint indicates which user account is selected, without divulging to the application any of the user's PII.

Abstract: In one embodiment, a client device 110 may use an attestation service 140 to verify a secure server 120. The secure server 120 may receive a signed trusted credential 310 from an attestation service 140 validating the secure server 120 as trustworthy to a client device 110 seeking access. The secure server 120 may protect the signed trusted credential 310 in a server secure module 280.

Abstract: Firmware of a system is configured to allow secondary devices, such as a smart card, to be used for authentication. In an example embodiment, the secondary device is a CCID smart card in compliance with the ISO 7816 specification. The smart card is inserted into a card reader coupled to the system prior to booting the system. The firmware comprises an emulator and driver configured to allow authentication information from the smart card to be utilized to allow execution of the boot process. In an example embodiment, the smart card comprises external keys for use with BITLOCKER™. The secondary device is compatible with systems implementing a BIOS and with systems implementing EFI. Authentication also can be accomplished via devices that do not provide data storage, such as a biometric device or the like.

Abstract: The execution of software may be controlled by a security policy expressed in a manifest. The software vendor or distributor specifies requirements for the use of software (e.g., which modules may be loaded into the software's address space, which module-signing keys are trustworthy, etc.), using a manifest specification language. A generation tool reads the specification and creates a manifest based on the specification. The tool may handle such details as retrieving keys from key files, computing software hashes, and the like. The manifest is distributed with the software and used by the environment in which the software executes to enforce the security policy.

Abstract: Firmware of a system is configured to allow secondary devices, such as a smart card, to be used for authentication. In an example embodiment, the secondary device is a CCID smart card in compliance with the ISO 7816 specification. The smart card is inserted into a card reader coupled to the system prior to booting the system. The firmware comprises an emulator and driver configured to allow authentication information from the smart card to be utilized to allow execution of the boot process. In an example embodiment, the smart card comprises external keys for use with BITLOCKER™. The secondary device is compatible with systems implementing a BIOS and with systems implementing EFI. Authentication also can be accomplished via devices that do not provide data storage, such as a biometric device or the like.

Abstract: A system debugs a computer application that employs rights-managed (RM) content. A first, non-isolated process has the application and a shell version of the trusted component, where such shell version receives each request by the application for RM services. The shell version is unconcerned whether a debugger is monitoring the first process. A second, isolated process is separate from the first process and has a debugging version of the trusted component. The shell version in the first process forwards the received request to the debugging version in the second process, and such debugging version acts upon same. The debugging version ensures that the debugger is not monitoring the second process, but is unconcerned whether the debugger is monitoring the first process.

Abstract: The execution of software may be controlled by a security policy expressed in a manifest. The software vendor or distributor specifies requirements for the use of software (e.g., which modules may be loaded into the software's address space, which module-signing keys are trustworthy, etc.), using a manifest specification language. A generation tool reads the specification and creates a manifest based on the specification. The tool may handle such details as retrieving keys from key files, computing software hashes, and the like. The manifest is distributed with the software and used by the environment in which the software executes to enforce the security policy.