If odsign is marked as oneshot, and it crashes (eg due to a coding
error), the device will not boot completely, because init keeps waiting
for the odsign.key.done / odsign.verification.done properties. So
instead, we don't mark it as oneshot, but stop the service manually in
the exit paths of the code. This ensures that if a bad OTA / module
update causes odsign to crash, we will automatically start it again; if
it crashes repeatedly, apexd will detect this, and roll back any module
update.
In the good path, there's no difference - odsign will run just once and
be stopped.
Bug: 194334176
Test: manually make odsign crash; inspect output
Change-Id: I7015f291888d6b8066e4c526a7e8cf3c9c7ea618
When using the rkp_factory_extraction_tool in test mode, a fake device
key is generated on the fly. This makes verifying the output difficult
as the key is permanently lost.
In test mode, print out the generated keys so that we can test if the
output data is good or not.
Test: Manually tested against backend service tooling not in AOSP
Change-Id: Ibc30044c03f5107990da6d3a03b17aa652d4b1bc
The number of times I've said "Oh yeah, I'll put a change in later to
add myself to OWNERS" has become embarassing.
Test: I can give OWNERS +2
Change-Id: If24b192fe0f2ca65f6cac58602c0b2b63f2df094
1. The MAC tag value was not being included in the uploaded data, so
it was previosly impossible to verify the keys to sign mac.
2. The device info is supposed to be an array with [Verified,
Unverified] info. It was previously just the verified info.
Test: Manual. Uploaded sample data to device info service.
Change-Id: I096bc5ded0b38fc56864e75c5e06dfbef62e9a74
Bug: 194492359
Version binding of storage keys was broken in that the old keyblob was
passed to the KM backed instead of the upgraded key blob when an upgrade
was required.
Bug: 194444841
Bug: 187304488
Test: N/A
Change-Id: Iad3e9d4c0de2f8c7121147c81590e56663fe596f
This CL updates files used in the keystore2 tests to address new linter
warnings from the 1.52.1 compiler.
Bug: 194309655
Test: m keystore2_tests
Change-Id: Ibfa7c20ddaecbe70c7e62f8a01d93bf7d6aecee0
This CL replaces an if-statement with a call to the Option::map
function. Having manual implementations of Option::map became a warning
with the 1.52.1 compiler update, and this was promoted to an error by
the build system.
Test: TH
Change-Id: I13e4adfbc84fbe855fd7d573e43e65bf602e0a5b
This is purely a port: it does not add or change any functionality
(other than renaming the library).
Bug: 182498247
Test: Use library.
Change-Id: Ice0c07d5afcbdd2029775fd61eb04a6f7058fdcf
When CompOS generates new artifacts it may also need to generate a new
keypair. Modify odsign to account for this. It needs to start up
CompOS to find out if the pending key is now the correct one; if so it
replaces the existing key, otherwise we keep the current key (if there
is one).
The pending keys are stored in /data/misc/apexdata/com.android.compos
since they are created & written by CompOS.
Fixed another RsaPublicKey bug.
Bug: 190166662
Test: Manual: No keys at all, no pending key, valid pending key, invalid pending key.
Change-Id: I17871b1e59380d037d71e8065f4cad699374ecaf
This change cuts off the error propagation from attempting to assign or
fetch a remotely provisioned key for a given app. Instead of passing the
error back out to the framework, the error will be logged and KM will
instead use the factory provisioned key.
Bug:190645703
Test: Key generation never fails due to presence/lack of an attestation
key
Change-Id: I5234baf4649f40832798b25d3204a9a7397e457e
This change replaces getSecurityLevels() with getImplementationInfo().
Instead of returning an array of integers that only indicates which
security levels the underlying implementations are running as, the new
method returns a parcelable with additional info. Specifically, the
supported EC curve is now sent back to the caller in this Parcelable as
well as the security level.
This change is part of the alterations necessary to support P256 EEKs.
The component sitting between the provisioning server and keystore2 will
need to know which signed EEK certificate chain to pass down to keystore
for a given security level.
Bug: 189018262
Test: atest RemoteProvisionerUnitTests
Change-Id: I416922edad6e0d0245b65fb02983210e790c1221
Ignore-AOSP-First: Merge conflict resolution of a CL in the topic.
Bug: 188590587
Test: statsd TestDrive script.
Merged-In: I0ad7c94187060dca28469ba262e1e4d93fe3df83
Change-Id: I0ad7c94187060dca28469ba262e1e4d93fe3df83
Grant the CompOS APEX access to the signature proto. Switch to
protobuf-lite, since it is more generally available in APEX.
Modify the signature proto (and related code) to store the signature
of the fsverity_formatted_digest, not the raw digest.
Fix dozens of places where raw public key (modulus) and RsaPublicKey
were confused. (Who knew that having 2 different representations with
the same underlying type would cause bugs?)
Fix error in PKCS#7 generation.
All still behind if (false).
Bug: 190166662
Test: Manual: Valid pending artifacts are accepted & added to fs-v as needed.
Change-Id: I115a1e4d2267ca01887ba693e8e02a0bb7c9141a
This CL adds metrics related to attestation pool status and out of key
error, from keystore side.
Ignore-AOSP-First: No mergepath to AOSP.
Bug: 184301651
Test: Statsd test drive script.
Merged-In: I7025c897449e050dda42e2b290dea336c5ad0d52
Change-Id: I7025c897449e050dda42e2b290dea336c5ad0d52
Test: m legacy_blob_fuzzer & adb sync data & adb shell
legacy_blob_fuzzer
The edge coverage after running for few minutes was about 15 percent.
Change-Id: I8a8a535319c6146c67980e6c31e5c85c420e40e7
Keystore2 atoms need to be routed to statsd via a proxy.
The proxy needs to call this API in order to pull metrics from
keystore.
Bug: 188590587
Test: Statsd Testdrive script
Merged-In: I28f8675fe5467b0760418c4d2d87808e45657be1
Change-Id: I28f8675fe5467b0760418c4d2d87808e45657be1
This is to avoid errors being printed at keystore2 startup due to
statsd not being available.
(refer b/185844285#comment13 for other options for avoiding this)
Also, removed watch dog watch point in async_task since waiting for
boot completion takes a lot of time, triggering watch dog.
Also changed register_pull_metrics_callbacks to use
wait_for_boot_completed and be called in async_task.
Bug: 188441750
Test: statsd Test Drive script for all three types of atoms.
keystore2 startup logs.
Merged-In: I41b48526aad9702dd29f93d139e5f2afba89be3a
Change-Id: I41b48526aad9702dd29f93d139e5f2afba89be3a
It's OK to just do an FS_IOC_MEASURE_VERITY on a file even if we don't
know it's in fs-verity; it returns an appropriate error code.
Bug: 190166662
Test: Create a spurious non-verity file, see it is detected.
Change-Id: I392289b11b674b760d9217258ca01b5305b0eee4
We have been storing the CompOS public key as the raw modulus. But on
the CompOS side we actually need it as a DER-encodedn RSAPublicKey
(which encodes both modulus and exponent).
Bug: 190166662
Test: Use compos_key_cmd to generate a key, odsign accepts it.
Test: Use FakeCompOs to generate a key, compos_key_cmd accepts it.
Change-Id: Ifdc9dc236d2b41ba2ee6a1a04cd7fd6dc4b1a241
If the current artifacts are missing or invalid, and if we have
pending CompOs artifacts, then attempt to use them. This includes
verifying the signatures and adding them to fs-verity if need be.
This is largely a proposal in the form of a CL. Note specifically the
definition of what a signature file looks like
(compos_signature.proto, VerityUtils.cpp).
I rationalised the way we handle multiple certificate subjects because
it was starting to get messy & confusing.
Apart from various refactorings, the significant changes remain behind
an if (false). It is currently largely untestable (we don't have
anything to produce signatures) and there's a couple more CLs to come,
but I think this is a big enough CL as it stands.
Bug: 190166662
Test: Create pending directory, see it deleted.
Test: Create valid pending directory, it gets renamed, fails verification
Test: Invalid signature file is rejected
Test: Presubmit
Change-Id: I20ef65f3c382bcfd5db8747e73fc0148a4b978e9
