Self-described security model for resource access

Patent metadata

Field	Value
Publication number	US-10192067-B2
Application number	US-201615165783-A
Country	US
Kind code	B2
Filing date	May 26, 2016
Priority date	May 26, 2016
Publication date	Jan 29, 2019
Grant date	Jan 29, 2019

Abstract

Various embodiments provide techniques and devices for implementing a self-described security model for sharing secure resources between secure applications. In some examples, a trustlet can include a self-described policy defining capabilities of the trustlet and/or membership in a scenario group managed by a signing authority. Further, the trustlet can include a code signature signed by the signing authority. Additionally, a proxy kernel can allow the trustlet to share application data with other trustlets in the scenario group based on the policy and the code signature without exposing the application data to compromised system software and/or unauthorized applications.

First claim

What is claimed is:

1. A method, comprising:
managing an operating system execution environment comprising a normal user mode and a first kernel mode;
managing a secure execution environment comprising a secure user mode and a second kernel mode;
receiving, from a first trustlet executing in the secure user mode of the secure execution environment, a first request to create a secure object within a scenario group, wherein the scenario group is managed by a signer authority;
determining that the first trustlet is a member of the scenario group;
creating the secure object within the scenario group based at least in part on the first request;
denying a process executing within the first kernel mode of the operating system execution environment access to the secure object;
receiving, from a second trustlet executing in the secure user mode of the secure execution environment, a second request to access the secure object;
determining that the second trustlet is a member of the scenario group;
providing the second trustlet access to the secure object;
identifying a code signature associated with the first trustlet;
determining that the signer authority associated with the code signature is permitted to provide a capability to create the secure object; and
wherein the creating is further based at least in part on the determining that the signer authority associated with the code signature is permitted to provide the capability.

2. A method as claim 1 recites, further comprising:
determining that a policy included in the first trustlet grants the first trustlet the capability.

3. A method as claim 1 recites, further comprising:
determining that a policy included in the second trustlet grants the second trustlet a second capability to open the secure object;
identifying a second code signature associated with the second trustlet;
determining that the signer authority associated with the second code signature is permitted to provide the second capability to open the secure object; and
wherein the creating is further based at least in part on the determining that the signer authority associated with the second code signature is permitted to provide the second capability.

4. A method as claim 1 recites, further comprising notifying a trustlet agent executing in the operating system execution environment of the creation of the secure object.

5. A method as claim 4 recites, further comprising sending a notification from the trustlet agent to the second trustlet, the notification indicating creation of the secure object.

6. A method as claim 1 recites, further comprising:
receiving, from a third trustlet executing in the secure user mode of the secure execution environment, a third request to access the secure object;
determining that the third trustlet is not a member of the scenario group; and
denying the third trustlet access to the secure object.

7. A method as claim 1 recites, wherein receiving the first request, comprises: receiving a system call to create the secure object from the first trustlet, the system call including a first identifier of the secure object, and a second identifier of the scenario group.

8. A method as claim 1 recites, wherein receiving the second request, comprises receiving a system call to access the secure object from the second trustlet, the system call including a first identifier of the secure object, and a second identifier of the scenario group.

9. A method as claim 1 recites, wherein the denying a process executing within the first kernel mode access to the secure object, further comprises disabling access by a kernel service to a memory associated with the secure object.

10. A method as claim 1 recites, wherein the secure object includes at least one of a decryption key, a secret, a semaphore, a secure memory object, a mutex, an event, and/or a waitable timers.

11. A method as claim 1 recites, wherein at least one of the first trustlet or second trustlet is associated with a biometric process.

12. A system, comprising;
one or more processors;
a memory;
a kernel executing on the one or more processors in a first trust level;
a proxy kernel executing on the one or more processors in a second trust level;
one or more modules maintained on the memory and executed by the one or more processors to perform acts comprising:
receiving, via the proxy kernel, from a trustlet executing in the second trust level, a system call including a scenario group identifier and a secure object identifier, wherein a scenario group corresponding to the scenario group identifier is managed by a signer authority;
determining, via the proxy kernel, that a policy of the trustlet grants the trustlet a capability to perform the system call, wherein the capability includes the capability to create a secure object;
identifying, via the proxy kernel, the signer authority as associated with a code signature of the trustlet;
determining, via the proxy kernel, that the signer authority is permitted to grant the capability; and
executing, via the proxy kernel, the system call at least to create the secure object based at least in part on the determining that the signer authority associated with the code signature is permitted to provide the capability to create the secure object.

13. A system as claim 12 recites, further comprising a capability database that indicates one or more capabilities assignable by the signer authority; and wherein the determining, via the proxy kernel, that the signer authority associated with the code signature of the trustlet is permitted to grant the capability is based at least in part on the capability database.

14. A system as claim 12 recites, wherein the capability includes a privilege to create a secure memory section within the memory.

15. A system as claim 14 recites, wherein the acts further comprise disabling access by the kernel to a memory address associated with the secure memory section.

16. A system as claim 12 recites, wherein the secure object identifier identifies at least one of an encryption key, a secret, a semaphore, a secure memory object, a mutex, an event, and/or a waitable timer.

17. One or more non-transitory computer-readable media storing computer-executable instructions that, when executed on one or more processors, configure a computer to perform acts comprising:
receiving, from a secure process, a request to create a secure object within a scenario group, wherein the scenario group is managed by a signer authority;
determining that a policy associated with the secure process grants the secure process a capability to create a secure object;
creating a secure object associated with the scenario group, the secure object stored in a memory address space;
disabling access by a kernel executing in normal execution environment to the memory address space, wherein access to the memory address space is disabled by modifying memory access attributes of the memory address space;
identifying a code signature associated with the secure process; and
determining that the signer authority associated with the code signature is permitted to provide the capability to create the secure object,
wherein the creating is further based at least in part on the determining that the signer authority associated with the code signature is permitted to provide the capability.

18. One or more non-transitory computer-readable media as claim 17 recites, wherein the secure process represents a first secure process, the request represents a first request, the policy represents a fi

Assignees

• Microsoft Technology Licensing Llc

Inventors

• Gefflaut Alain F
• Harper Andrew W

Classifications

• G06F21/6218 Primary

  to a system of files or objects, e.g. local or distributed file system or database · CPC title

• G06F21/44

  Program or device authentication · CPC title