| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Inheritance of HAL object is performed by composing a child structure of a
single parent structure located at offset 0 followed by new data members
and function pointers in the child structure.
For example,
struct child {
struct parent common;
int a_data_member;
void (*a_method)(struct child *c, int v);
};
HAL code assumes this layout when accessing child structures given a pointer
to a parent structure such that users write code like the following...
void child_method(struct *parent, int v) {
struct child * c = (struct child*)parent;
// do stuff with c
}
Code above will break if a member is added before "common" in "struct child".
This change adds comments that describe the restriction on the location of
parent HAL objects within a derived HAL object. HAL objects that already
have comments that describe the required location of parent objects are not
modified.
Change-Id: Ibe4300275286ef275b2097534c84f1029d761d87
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For wrapping the disk encryption secret, we add a flag that indicates it
can be done without having to start some storage daemon which the
trusted OS will query to get data needed to load up the keys. This
usually means that the "key blob" we store is actually just the RSA key
encrypted with the device's KEK and not a reference to an encrypted
filesystem stored on /data
Also to allow other providers to upgrade to V3 of the header, we add
flags to show whether the keymaster supports different key types. This
allows keymaster HALs to support the whole device encryption secret
wrapping without needing to implement DSA and EC key handling. The V2
header made support implicit.
(cherry picked from commit 8a3849e26f9c64314edb69586819250e8f95c1eb)
Change-Id: I49be8403faf9f4c3888c84848b3009b44ab6d183
|
| |
|
|
|
|
|
|
|
|
| |
The original version of this HAL used a field in keymaster_module to
represent the module's version number, but a later revision of the HAL
interface added a distinguisher between HAL module and device versions.
This is needed to support upgrade code in keystore.
Bug: 10600582
Change-Id: Ied34cf382e2b7725e648faada00df2dee993e6c5
|
| |
|
|
|
|
|
| |
(cherry picked from commit 6e1683f5d508a4c1ff761a9a3508619ac5ac6ed7)
Bug: 10600582
Change-Id: I8e5b66baa70b37031198260853bb5355df75e23d
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
The first flag is something for the default implementation to use to
indicate that its keys are importable to hardware keymasters. This
allows easy migration from the default software implementation to
hardware implementations as they become available.
Change-Id: Ideb26a4b1ac91ca8c330a4fe4df323f028b2f855
|
| |/
|
|
|
|
|
|
| |
In order to aid keymasters erase their memory efficiently, introduce new
delete_all API to tell keymasters to forget everything. This will be
triggered when keystore itself is told to reset.
Change-Id: I730375f1f32cd1ea0bf1fa38d5b1bec2f81ba492
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Switch from unspecified encoding for import of keys to PKCS#8 (Java
standard encoding).
Add function for obtaining the public key from a keypair.
Add fields for RSA key generation that indicate modulus size and desired
public exponent.
Add in placeholder fields for possible digest and padding types for
signatures. Currently the only thing supported is "none" and "none"
respectively.
Change-Id: I19ee02cf35321aee859e2460a963c7213791414b
|
|
|
Add a hardware API for key handling from "keystore"
Change-Id: I5fd192cc212dbb057ee2a7003d602382ee2cd2c0
|
