Abstract: Resource authorization policies and resource scopes may be defined separately, thereby decoupling a set of authorization rules from the scope of resources to which those rules apply. In one example, a resource includes anything that can be used in a computing environment (e.g., a file, a device, etc.). A scope describes a set of resources (e.g., all files in folder X, all files labeled “Y”, etc.). Policies describe what can be done with a resource (e.g., “read-only,” “read/write,” “delete, if requestor is a member of the admin group,” etc.). When scopes and policies have been defined, they may be linked, thereby indicating that the policy applies to any resource within the scope. When a request for the resource is made, the request is evaluated against all policies associated with scopes that contain the resource. If the conditions specified in the policies apply, then the request may be granted.

Abstract: Managing encrypted datasets is illustrated. A method includes obtaining a first decryption key. The first decryption key is configured to be used to decrypt an encrypted dataset that has been encrypted using a first encryption mechanism. The first encryption mechanism is associated with the first decryption key that can be used to decrypt the dataset. The method further includes encrypting the first decryption key with a second encryption mechanism. The method further includes encrypting the first decryption key with a third encryption mechanism. The method further includes creating a package including at least the first decryption key encrypted with the second encryption method and the first decryption key encrypted with the third encryption method. The method further includes signing the package with a guardian signature and signing the package with a signature created from the first decryption key.

Abstract: Deploying an encrypted entity on a trusted entity is illustrated herein. A method includes, at a trusted entity, wherein the trusted entity is trusted by an authority as a result of providing a verifiable indication of certain characteristics of the trusted entity meeting certain requirements, receiving an encrypted entity from an untrusted entity. The untrusted entity is not trusted by the authority. At the trusted entity, a trust credential from the authority is used to obtain a key from a key distribution service. The key distribution service is trusted by the authority. The key is used to decrypt the encrypted entity to allow the encrypted entity to be deployed at the trusted entity.

Abstract: A client can communicate with a middle tier, which can then, in turn, communicate with a back end tier to access information and resources on behalf of the client within the context of a system that can scale well. Each individual back end can establish a policy that defines which computing device can delegate to that back end. That policy can be enforced by a domain controller within the same administrative domain as the particular back end. When a middle tier requests to delegate to a back end, the domain controller to which that request was directed can either apply the policy, or, if the domain controller is in a different domain than the targeted back end, it can direct the middle tier to a domain controller in a different domain and can sign relevant information that the middle tier can utilize when communicating with that different domain controller.

Abstract: A security processing unit is configured to manage cryptographic keys. In some instances, the security processing unit may comprise a co-processing unit that includes memory, one or more processors, and other components to perform operations in a secure environment. A component that is external to the security processing unit may communicate with the security processing unit to generate a cryptographic key, manage access to a cryptographic key, encrypt/decrypt data with a cryptographic key, or otherwise utilize a cryptographic key. The external component may comprise a central processing unit, an application, and/or any other hardware or software component that is located outside the security processing unit.

Abstract: A keying infrastructure may generate and/or manage cryptographic keys. The cryptographic keys may include identity keys, encryption keys, and a variety of other types of keys. The cryptographic keys may be derived or created with a key derivation function (KDF) or other one-way function. The cryptographic keys may include keys that are accessible to a boot loader, keys that are accessible to particular components of a Trusted Execution Environment (TrEE), and so on. In some examples, a key may be derived from a preceding key in a sequence of keys. The preceding key may be deleted when the key is derived.

Abstract: An event log can comprise, not only entries associated with components instantiated since a most recent power on of a computing device, but also entries of components instantiated prior to that power on, such as components that were instantiated, and represent, a state of the computing device prior to hibernation that has now been resumed. Upon hibernation, the current values of the Platform Configuration Registers (PCRs) of a Trusted Platform Module (trusted execution environment), as well as a quote of those current values, and a current value of a monotonic counter of the trusted execution environment can be logged. The monotonic counter can be incremented at each power on to track successive generations of the computing device and to guard against an intervening, not-logged generation. A subsequent parsing of the event log can verify the prior generational entries with reference to the PCR values in the log that are associated with those generations.

Abstract: Sharing security claims across different security contexts. A method includes, for a first security context, identifying a first set of security claims. The method further includes for the first security context identifying a second set of security claims from the first set of security claims that is allowed to be sent from the first security context. The first set of security claims is modified to create the second set of security claims. For a second security context, security claim requirements are identified. The second set of security claims is modified to satisfy the security claim requirements for the second security context.

Abstract: Resource authorization policies and resource scopes may be defined separately, thereby decoupling a set of authorization rules from the scope of resources to which those rules apply. In one example, a resource includes anything that can be used in a computing environment (e.g., a file, a device, etc.). A scope describes a set of resources (e.g., all files in folder X, all files labeled “Y”, etc.). Policies describe what can be done with a resource (e.g., “read-only,” “read/write,” “delete, if requestor is a member of the admin group,” etc.). When scopes and policies have been defined, they may be linked, thereby indicating that the policy applies to any resource within the scope. When a request for the resource is made, the request is evaluated against all policies associated with scopes that contain the resource. If the conditions specified in the policies apply, then the request may be granted.

Abstract: A client can communicate with a middle tier, which can then, in turn, communicate with a back end tier to access information and resources on behalf of the client within the context of a system that can scale well. Each individual back end can establish a policy that defines which computing device can delegate to that back end. That policy can be enforced by a domain controller within the same administrative domain as the particular back end. When a middle tier requests to delegate to a back end, the domain controller to which that request was directed can either apply the policy, or, if the domain controller is in a different domain than the targeted back end, it can direct the middle tier to a domain controller in a different domain and can sign relevant information that the middle tier can utilize when communicating with that different domain controller.

Abstract: An event log can comprise, not only entries associated with components instantiated since a most recent power on of a computing device, but also entries of components instantiated prior to that power on, such as components that were instantiated, and represent, a state of the computing device prior to hibernation that has now been resumed. Upon hibernation, the current values of the Platform Configuration Registers (PCRs) of a Trusted Platform Module (trusted execution environment), as well as a quote of those current values, and a current value of a monotonic counter of the trusted execution environment can be logged. The monotonic counter can be incremented at each power on to track successive generations of the computing device and to guard against an intervening, not-logged generation. A subsequent parsing of the event log can verify the prior generational entries with reference to the PCR values in the log that are associated with those generations.