Replace libcrypto with libcrypto_static, which can be protected through
visibility to ensure only modules that don't affect FIPS certification
can use it.
Bug: 141248879
Test: m checkbuild
Change-Id: I8685cb06d15f3425eeb96d998ffda54c82dcd387
Since these were combined into libhidlbase.
Bug: 135686713
Test: build only (libhwbinder/libhidltransport are empty)
Change-Id: I075670b64eebbbbd6a6ae0e84ad51bf1c6f5ba36
hidl-generated makefiles are now generated such that bpfmt(file) == file.
Bug: 67417008
Test: enable bpfmt hook
Change-Id: I1f69d292bc23a7cc293a66110cb02d597e1019ad
Due to an unclear API, wireless_charger accidentally started
two threads.
Bug: 80102279
Test: use lshal to verify that the service only has one thread
Change-Id: Ic6bdb6ef0025173f4388f0550e00a6b4fc2e21df
With the last patch I exposed the auth token key to users of the
GenericOperation. But because the auth token key is never used in the
default implementation it did not show that the setHmacKey method did
not actually work. This patch fixes it.
Bug: 78456249
Test: Compile trusted app based on the GenericOperation
Change-Id: I25a80f985ce500e3658421cac62421133cc5b788
According to spec the test key has 32 bytes set to TextKeyBits::BYTE.
The VTS test and default implmementation only set the first 16 bytes and
left the remaining 16 bytes zero.
This bug fixes both, the VTS test and the default implementation.
Also some long overdue changes to how the auth token key is handled
by the generic operation.
Bug: 78456249
Test: VtsHalConfirmationUIV1_0TargetTest
Change-Id: I509f2c2a99704ee00625e6f6169479771a3bc17a
This is not a HAL change. It just adds a command to msg_formatting.h as
a service to vendors who have to augment the protocol between the HAL
service and the TA or other implementation with janitorial commands that
don't effect the HAL interface.
Bug: 76152930
Test: No functional change
Change-Id: I5d4e5dadea29d4c7d51753939eda6c3f3571fae1
The confirmationui HAL does not need to run as user system.
Bug: 63928580
Test: All required services boot and can access what they need
Change-Id: Ic2d6edabf8cca8384a7e0ce49dfc5445a6ec1658
These changes accumulated during the integration with the Pixel specific
impelemtation. The make it easiser to integrate an GUI renderer with the
core logic.
Bug: 63928580
Test: VTS tests and manual tests
Change-Id: I7001f60709ce806a16f098492bdb71eb05e6ca9a
This reference implementation implements the core
logic of the confirmation provider including the
cryptographic operations. For a full implementation
a user interface and a few policy checks are missing.
Bug: 63928580
Test: VtsHalConfirmationUIV1_0TargetTest
Change-Id: I22ca138ed612979223f8e83792b525a31709e0fe
Includes:
A light weight CBOR generator
This patch adds a header only CBOR generator and unit tests.
It allows expressing CBOR datastructures in C++ for subsequent
serialization. The implementation performs no memory allocation
and only depends on stdint.h (for (u)intx_t) and stddefs.h (for size_t).
It is tailored for use in constrained environments such as TEEs.
Convenience method for generating a SHA256 HMAC
Bug: 63928580
Test: android.hardware.confirmationui@support-lib-tests
Change-Id: I1d93a85503f861281e71e09b1ede5cbb74219694
HAL definition for high assurance confirmation providers.
High assurance confirmation providers allow relying parties
to prompt the user for confirming a short piece of information.
If the user confirms, the result is a signed message indicating
that the user has seen the message. For a high assurance confirmation
provider this must also be true if Android and the Linux kernel
are compromised.
Bug: 63928580
Test: VTS tests in the following commit
Change-Id: I72017b39c01b4333d0146c648637a19fafcb7278
