Abstract: Attestation by a self-regulating attestation client. The attestation client requests a credential of health from an attestation service, which includes an ordered attestation log and proof of integrity and freshness of the log. The attestation client receives the requested credential of health, which certifies the attestation client was healthy when it requested the credential of health and that the attestation service trusts the attestation client to be healthy each time the attestation client authenticates using the credential of health. The attestation client receives a request to authenticate that it is healthy using the credential of health, verifies that it is currently healthy, and performs the requested authentication.

Abstract: A system that includes an account management module configured to maintain protected accounts. For instance, a particular protected account includes a protected data set that is not readable outside of the system, and perhaps not even readable outside of the account. The particular data set corresponds to a particular entity assigned to the particular account and that includes keys corresponding to the particular entity. A security processor uses at least some of the plurality of keys to perform cryptographic processes in response to one or more trusted execution environment commands received from the particular entity.

Abstract: Embodiments for performing service binding between a client and a target server are disclosed. In accordance with one embodiment, a clear text client service binding value is received from a client at the target server, the client service binding value is compared to a server service binding value, and a communication channel is formed between the client and the target server when the client service binding value matches the server service binding value.

Abstract: A policy that governs access to a resource may be tested against real-world access requests before being used to control access to the resource. In one example, access to a resource is governed by a policy, referred to as an effective policy. When the policy is to be modified or replaced, the modification or replacement may become a test policy. When a request is made to access the resource, the request may be evaluated under both the effective policy and the test policy. Whether access is granted is determined under the effective policy, but the decision that would be made under the test policy is noted, and may be logged. If the test policy is determined to behave acceptably when confronted with real-world access requests, then the current effective policy may be replaced with the test policy.

Abstract: A system that includes an account management module configured to maintain protected accounts. For instance, a particular protected account includes a protected data set that is not readable outside of the system, and perhaps not even readable outside of the account. The particular data set corresponds to a particular entity assigned to the particular account and that includes keys corresponding to the particular entity. A security processor uses at least some of the plurality of keys to perform cryptographic processes in response to one or more trusted execution environment commands received from the particular entity.

Abstract: Input challenge based authentication techniques are described in which data regarding a user's input signature is employed for authentication of the user to access resources. Different users have distinct input signatures that are indicative of the manner in which each individual user provides input including at least typing characteristics and timing data. Data regarding input signatures may be captured from user interaction with computing devices and associated with user accounts. Once sufficient data regarding a user's input signature is captured, access to a user account may be controlled at least in part based on the input signature. To do so, an input challenge that indicates a non-secret pattern of input is presented to the user in connection with an authentication sequence. The user reproduces the non-secret pattern of input and selective access to the user account is granted depending upon whether or not the reproduction matches the input signature.

Abstract: Cloning of a virtual machine having a trusted executed environment such as a software-based trusted platform module. In order to clone the virtual machine, the virtual machine state of the source virtual machine is copied to formulate a target virtual machine state that is to be associated with a target virtual machine. The target virtual machine is a clone of the source virtual machine state, and thus the storage hierarchy of the trusted execution environment may be the same for the trusted execution environment in the source and target virtual machine states. However, because the identity of the target virtual machine is different than that of the source virtual machine, the endorsement hierarchy of the target virtual machine state is altered such that it is based on the identity of the target virtual machine, rather than the source virtual machine.

Abstract: Embodiments for providing differentiated access based on authentication input attributes are disclosed. In accordance with one embodiment, a method includes receiving an authentication input at an authentication authority using an authentication protocol. The authentication input being associated with a client. The method also includes providing one or more representations for the authentication input, wherein each of the representations represents an attribute of the authentication input.

Abstract: A system that includes an account management module configured to maintain protected accounts. For instance, a particular protected account includes a protected data set that is not readable outside of the system, and perhaps not even readable outside of the account. The particular data set corresponds to a particular entity assigned to the particular account and that includes keys corresponding to the particular entity. A security processor uses at least some of the plurality of keys to perform cryptographic processes in response to one or more trusted execution environment commands received from the particular entity.

Abstract: A context of a principal is built, at a target system controlling access to a resource, independently of the principal requesting access to the resource. An authorization policy is applied, at the target system, to the context to determine whether the principal is permitted to access the resource, and an indication of whether the principal is permitted to access the resource is provided (e.g., to an administrator). Modifications can be made to the context and the authorization re-applied to determine whether a principal having the modified context is permitted to access the resource.

Abstract: Protecting user credentials from a computing device includes establishing a secure session between a computing device and an identity provider (e.g., a Web service). Parameters of the secure session are communicated to a credential service, which renegotiates or resumes the secure session to establish a new secure session between the credential service and the identity provider. User credentials are passed from the credential service to the identity provider via the new secure session, but the computing device does not have the parameters of the new secure session and thus does not have access to the passed user credentials. The credential service then renegotiates or resumes the secure session again to establish an additional secure session between the credential service and the identity provider. Parameters of the additional secure session are communicated to the computing device to allow the computing device to continue communicating securely with the identity provider.

Abstract: A policy that governs access to a resource may be tested against real-world access requests before being used to control access to the resource. In one example, access to a resource is governed by a policy, referred to as an effective policy. When the policy is to be modified or replaced, the modification or replacement may become a test policy. When a request is made to access the resource, the request may be evaluated under both the effective policy and the test policy. Whether access is granted is determined under the effective policy, but the decision that would be made under the test policy is noted, and may be logged. If the test policy is determined to behave acceptably when confronted with real-world access requests, then the current effective policy may be replaced with the test policy.

Abstract: Booting a computing device includes executing one or more firmware components followed by a boot loader component. A protection component for the computing device, such as an anti-malware program, is identified and executed as an initial component after executing the boot loader component. One or more boot components are also executed, these one or more boot components including only boot components that have been approved by the protection component. A list of boot components that have been previously approved by the protection component can also be maintained in a tamper-proof manner.

Abstract: A password may be provided along with a validation code, which can help prevent the password from being sent to the wrong recipient. When a password is created, a validation code may be created based on (a) the password, and (b) the identity of the target of authentication (TA) to which the password is intended to be sent. When a user is requested to provide a password, validation component intercepts the request and asks the user to enter both the password and validation code. The validation component then re-calculates the validation code based on the entered password and on the TA that is requesting the password. If the re-calculated validation code matches the validation code entered by the user, then the password is released to the user agent that the user uses to communicate with the TA, and the user agent sends the password to the requesting TA.

Abstract: A context of a principal is built, at a target system controlling access to a resource, independently of the principal requesting access to the resource. An authorization policy is applied, at the target system, to the context to determine whether the principal is permitted to access the resource, and an indication of whether the principal is permitted to access the resource is provided (e.g., to an administrator). Modifications can be made to the context and the authorization re-applied to determine whether a principal having the modified context is permitted to access the resource.

Abstract: Attestation by a self-regulating attestation client. The attestation client requests a credential of health from an attestation service, which includes an ordered attestation log and proof of integrity and freshness of the log. The attestation client receives the requested credential of health, which certifies the attestation client was healthy when it requested the credential of health and that the attestation service trusts the attestation client to be healthy each time the attestation client authenticates using the credential of health. The attestation client receives a request to authenticate that it is healthy using the credential of health, verifies that it is currently healthy, and performs the requested authentication.

Abstract: Booting a computing device includes executing one or more firmware components followed by a boot loader component. A protection component for the computing device, such as an anti-malware program, is identified and executed as an initial component after executing the boot loader component. One or more boot components are also executed, these one or more boot components including only boot components that have been approved by the protection component. A list of boot components that have been previously approved by the protection component can also be maintained in a tamper-proof manner.

Abstract: A password may be provided along with a validation code, which can help prevent the password from being sent to the wrong recipient. When a password is created, a validation code may be created based on (a) the password, and (b) the identity of the target of authentication (TA) to which the password is intended to be sent. When a user is requested to provide a password, validation component intercepts the request and asks the user to enter both the password and validation code. The validation component then re-calculates the validation code based on the entered password and on the TA that is requesting the password. If the re-calculated validation code matches the validation code entered by the user, then the password is released to the user agent that the user uses to communicate with the TA, and the user agent sends the password to the requesting TA.

Abstract: Embodiments for performing service binding between a client and a target server are disclosed. In accordance with one embodiment, a clear text client service binding value is received from a client at the target server, the client service binding value is compared to a server service binding value, and a communication channel is formed between the client and the target server when the client service binding value matches the server service binding value.

Abstract: Embodiments for providing differentiated access based on authentication input attributes are disclosed. In accordance with one embodiment, a method includes receiving an authentication input at an authentication authority using an authentication protocol. The authentication input being associated with a client. The method also includes providing one or more representations for the authentication input, wherein each of the representations represents an attribute of the authentication input.