Patent Application
20100023782
Data protection is becoming a very important feature on computing platforms such as laptops, desktops etc. The primary methods used to protect data are based on encryption. Various platform features are being added to create, store, use, and protect these keys. However, most of existing key-management technologies that are used in those solutions only allow the keys to be statically protected by using some shared secrets or using some measurement of secure platform state without enforcing any specific policies for the keys.
The claimed subject matter will be understood more fully from the detailed description given below and from the accompanying drawings of disclosed embodiments which, however, should not be taken to limit the claimed subject matter to the specific embodiment(s) described, but are for explanation and understanding only.
Referring to
CIM 12 includes a secure storage service 14, secure non-volatile storage 16, CIM interface driver 18, secure policy enforcement engine 20, and system interface module 22. System components and their functionality are briefly described and the method below may provide additional details.
The secure storage service 14 may be a point of contact for receiving a key-blob from an application. A key-blob is a collection of key data generated by the application that is stored as a single entity. Secure storage service 14 may also perform other tasks such as parsing a key-blob, working with secure policy enforcement engine 20 in verifying that a policy provided by the application is enforceable within the current system capabilities, deriving a key using a key hierarchy, retrieving the key from secure non-volatile storage 16, verifying credentials, etc.
The secure non-volatile storage 16 may be non-volatile protected random access memory (NVRAM) for secure storage of keys. Having secure memory internal to the CIM may help protect against snooping and modification through software or hardware attacks on the system.
CIM 12 is coupled to the platform via a connection 24 which allows communication between applications running on the platform and the CIM through the CIM interface driver 18 on the CIM. Connection 24 may be a hardware bus or other secure channel.
The secure policy enforcement engine 20 may determine whether a policy provided by the application is enforceable with current system capabilities and verify policy status upon a request by the application for a key. For information to make these determinations, the secure policy enforcement engine may communicate with a system interface module 22 to obtain information via a system bus 26 or other secure channel. The system interface module 22 may communicate with a clock 28, network interface card (NIC) 30, global positioning system (GPS) 32, and other platform components 34 independent of the CPU to obtain necessary policy information. In addition, this communication link to platform components allows new types of policy associations.
System 10 may further include applications running on the platform. Applications may communicate with the CIM using communication components 36, which may include a CIM interface driver 38, a secure storage communication module 40, and a cryptographic token interface 42 such as Public Key Cryptography Standards #11 (PKCS #11) or a Trusted Computing Group (TCG) interface. Communication components may include different components depending on the implementation.
As an example, an application such as a full disk encryption (FDE) bootloader 44 typically runs on a main CPU (not shown). The FDE may include a pre-boot authentication module 46 providing password protection, a full disk encryption module 48, and FDE key storage services 50. Communication components 36 may exist as a plugin 52 that is supported by the application.
In another exemplary application, a host operating system (OS) is shown at 54. The host OS includes a file/folder encryption 56 and communication components 36. It should be noted that applications located externally to the platform may be used in the system if they are configured to communicate with the CIM.
Using these components and interfaces, applications in the system can securely store keys and policies into secure storage in the CIM.
Referring to
Method 100 further includes having the secure storage service parse the key-blob and verify with the secure policy enforcement engine that the policy is enforceable with the current system capabilities at step 104. If the verification succeeds (policy is enforceable), method 100 includes, at step 106, wrapping the key-blob with a key derived from hardware, which only the CIM can access. The key may be derived according to a specific key hierarchy. One example of a key hierarchy is shown in
At a later time, the application may request access to the secure key. The request may include credentials such as a username/password, biometric signatures, or any identifier which an application may use as credentials. The request may further include a key ID as an index in the CIM. At step 108, the method includes receiving a request to access the secure key.
At step 110, the method includes having the secure storage service retrieve the secure key. At step 112, method 100 further includes determining whether the application is allowed access to the secure key. In making this determination, step 112 includes verifying credentials at sub-step 114, and verifying policy status at sub-step 116. If the credentials are correct at sub-step 114, then policy status is verified by the secure policy enforcement engine.
As an example based on the key-to-policy association storage in
If it is determined that the application is allowed to access the secure key, method 100 includes, at step 118, returning the key(s). It is noted that the secure key and other key material such as the key-blob may be returned. The number of keys may be determined by the specific implementation.
Referring to
Below the hardware key in the key hierarchy is the core storage key 74, referred to as “platform encryption key (PEK)”. PEK 74 is cryptographically derived from the hardware key 72. The PEK is dynamically derived from the hardware value on each platform boot.
Below the PEK in the key hierarchy is storage root key (SRK) 76 which is derived from a combination of the parent key PEK and an SRK secret. SRK 76 is derived from PEK on host application-initiation of secure storage services (referred to as “initiation”) when an SRK secret is established. An SRK secret may be any information that a platform owner wants to keep secret from others. In general, a secret is a key. A new SRK is generated at initiation and the SRK is deleted during retirement. The SRK is stored by wrapping with the PEK.
Below the SRK in the key hierarchy is application storage key (AppSK) 78 which is derived from a combination of SRK and application SRK secret. AppSK is derived from SRK when a new application initiates. The application SRK secret is given by whichever host application initiates and is needed for AppSK creation. AppSK is stored by wrapping with the SRK. Multiple AppSKs may exist at the same time for each application.
Keys below the AppSK level are not supported and thus cannot be used by the secure storage service. The non-storage keys (such as secrets using AppSK) are stored using the AppSK by the application.
It is appreciated that key-to-policy association and enforcement for secure key-management and policy execution has been explained with reference to one general exemplary embodiment, and that the disclosed subject matter is not limited to the specific details given above. References in the specification made to other embodiments fall within the scope of the claimed subject matter.
Reference in the specification to “an embodiment,” “one embodiment,” “some embodiments,” or “other embodiments” means that a particular feature, structure, or characteristic described in connection with the embodiments is included in at least some embodiments, but not necessarily all embodiments, of the claimed subject matter. The various appearances of “an embodiment,” “one embodiment,” or “some embodiments” are not necessarily all referring to the same embodiments.
If the specification states a component, feature, structure, or characteristic “may”, “might”, or “could” be included, that particular component, feature, structure, or characteristic is not required to be included. If the specification or claim refers to “a” or “an” element, that does not mean there is only one of the element. If the specification or claims refer to “an additional” element, that does not preclude there being more than one of the additional element.
Those skilled in the art having the benefit of this disclosure will appreciate that many other variations from the foregoing description and drawings may be made within the scope of the claimed subject matter. Indeed, the invention is not limited to the details described above. Rather, it is the following claims including any amendments thereto that define such scope and variations.
