Bug: 151896491
Test: local build
Exempt-From-Owner-Approval: This CL update suite name vts-core to vts as
the suite name is updated. This CL won't change test logic or behavior.
Change-Id: I562b4dc50765e953800a814a8fd84a01c1b9352b
Merged-In: I562b4dc50765e953800a814a8fd84a01c1b9352b
Although no real devices should have a software implementation,
emulator and cloud devices do, and it's useful to be able to use them
as a development platform, which is facilitated by having useful VTS
tests.
This is in preparation for Keymaster 4.1 implementation and VTS work.
Bug: 140193672
Bug: 140192237
Bug: 140824829
Test: VtsHalKeymaster4.0TargetTest
Change-Id: Idc5de13c342ef1ac62d3131a1a2185d5e78a0d45
This is part of a refactor to facilitate reuse in Keymaster 4.1 VTS
tests.
Bug: 140193672
Bug: 140192237
Test: VtsHalKeymasterV4_0TargetTest
Change-Id: I9310a851648c028850f9795d303419c6a7e29a11
We should not be relying on the HAL service to add CREATION_TIME to
keys. It was always intended to be an optional tag that could be
added by keystore, or maybe the caller of keystore. One widespread
Keymaster implementation started adding it (somewhat erroneously) if
it wasn't provided, and it appears that this implementation's behavior
became assumed to be the required behavior.
Test: VtsHalKeymasterV4_0TargetTest
Change-Id: I34267c4e1f59fd8ee5f898f8c746a7b49f4d74a5
Without the setting of TAG_MAC_LENGTH, the test fails due to
MISSING_MAC_PURPOSE.
Bug: 145626599
Test: VtsHalKeymasterV4_0TargetTest
Change-Id: Ic58411b86e07dfeeb78211abf9271ee995beabc9
This is updating the public exponent being checked from 3 to 65537. The
test was updated to use the latter public exponent without the check
also being updated
Test: atest VtsHalKeymasterV4_0TargetTest
Change-Id: I55fa2e67c94f0c52a1d65644f16b5f703a661e00
This test should will flag builds running as eng or userdebug that
report back the device is locked during development. This will also
catch the case where the device is a user build but reporting that it
isn't locked. This should help to avoid instances in the future where
userdebug builds report a locked device in the VBMeta information.
This patch also does a little bit of cleanup of the surrounding VBMeta
checking code.
Test: atest VtsHalKeymasterV4_0TargetTest
Change-Id: I3b387ade5eeee6a68b9ff307e503417d264ecbfe
The Keymaster 4.0 HAL specifies that the public exponent for RSA is F4
(2^16+1). There were a few tests still using 3 as the exponent. This
patch updates those incorrect exponents accordingly.
Bug: 143404829
Test: atest VtsHalKeymasterV4_0TargetTest
Change-Id: Ibc82a8a912bc5926bcdd544e0370e4185a888c0d
This tests passing a large input to finish. This should either succeed
or fail with the right error code.
Test: Run new VTS test
Change-Id: Ic4ef90adc6274317796bbe752f95fc9efa5fdb07
This test will check that the length of the attestation application id
field will be properly encoded in valid DER ASN.1 in cases where the
length is long enough to require extra bytes to encode. In those cases,
the encoding of that field should include:
-A byte to specify how many bytes are required to enumerate the length
-The bytes required to enumerate the length
-The actual data that follows
Bug: 142674020
Test: atest keymaster_hidl_hal_test
Change-Id: I6d162efa4c8c6e0922989e234d0377caf3c1758e
Per Keymaster 4.0 spec, TEE and StrongBox implementations are only
required to support HMAC keys between 64 and 512 bits in length.
StrongBox implementations additionally must not support anything larger
than 512 bits. The tests removed in this CL specified key sizes larger
than 512 bits.
Bug: 143404829
Test: m VtsHalKeymasterV4_0TargetTest && adb sync data && \
adb shell data/nativetest64/VtsHalKeymasterV4_0TargetTest/VtsHalKeymasterV4_0TargetTest
Change-Id: I96ee3a20b981c288d88366f536b9924f907268f3
This test checks that length metadata for the ASN.1 encoding of
attestation application ids are correct. It generates an app id that
will have a length between 127 and 256, which should create an encoding
that requires two bytes of length metadata - one byte to specify how many
bytes are needed for the length, and one byte for the length.
Some implementations of keymaster only use one byte in this case, which
will fail on strict ASN.1 parsers.
Bug: 142674020
Test: m VtsHalKeymasterV4_0TargetTest && adb sync data \
&& adb shell data/nativetest64/VtsHalKeymasterV4_0TargetTest/VtsHalKeymasterV4_0TargetTest
Change-Id: I7dfc38a09247eb3cb237f33a202044668d15cbca
1. AES operation attempted with unauthorized purpose.
2. AES-GCM encryption performed with different nonces, should
generate different ciphertexts.
3. AES-GCM encryption decryption round trip with delays between
begin and update and finish.
Bug: 133258003
Test: VtsHalKeymasterV4_0TargetTest
Change-Id: Ia8b4b4b317ecff51b18e64dfa3b84bf77475812d
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
BUG: b/139689895
TEST: Added VTS tests to keymaster_hidl_hal_test.cpp
TEST: Ran on emulator against soft keymaster::v4_0::ng
Change-Id: I6c682cafee65cf7ea426bd03865bf868586efc62
Due to changes in implementation between keymaster 3.0 and 4.0, rollback
resistance is now specified by the caller. This patch addresses that
inconsistency to make sure rollback resistance is properly tested. If
rollback resistance is supported by the hardware, then it will now be
tested.
Test: atest VtsHalKeymasterV4_0TargetTest
Change-Id: I21e8d1e66932ddfad2d42ce8a43591431f3ff284
GSI images do not have AVB verification enabled and therefore lack
several properties the keymaster HAL test depended on. Selectively
disable those parts of the test that would fail with AVB verification
disabled. Also disable date format checks under GSI. When invoked from
GSI the TEE-backed keymaster doesn't use the correct date format.
Bug: 130843899
Test: VtsHalKeymasterV4_0TargetTest
Exempt-From-Owner-Approval: change only affects VTS-on-GSI behavior
Change-Id: Idaafb7b515c41290c766a8132f35d498ca15f48a
The TEE keymaster has been seen to be almost a minute out of sync with
the host clock during attestation. Increase the leniency window to two
minutes.
Bug: 134408892
Bug: 134408367
Test: VtsHalKeymasterV4_0TargetTest
Change-Id: Ic256a939dcd7e7b108099cfcf237cacde8dde059
In Keymaster 3, both INVALID_INPUT_LENGTH and INVALID_ARGUMENT were
acceptable for oversized messages. Keymaster 4 VTS requires that
INVALID_ARGUMENT be returned, but the spec has no such restriction. This
loosens VTS to allow either INVALID_INPUT_LENGTH or INVALID_ARGUMENT in
this case.
Bug: 129297054
Test: atest VtsHalKeymasterV4_0TargetTest Pixel 3, Trusty tests
The spec requires that SHA1 not be allowed for wrapped keys and that
only SHA_2_256 be used. Unfortunately, the previous VTS required SHA1
support. This patch takes the middle ground by requiring SHA_2_256 be
supported for importWrappedKey, but not disallowing it from supporting
SHA1.
This makes it possible for a spec compliant keymaster to pass VTS
while not disqualifying shipped devices.
Bug: 129291873
Test: atest VtsHalKeymasterV4_0TargetTest:ImportWrappedKeyTest, Trusty
Change-Id: I6c3a9182b51f2e7a46173d5bfc34d3c3264d954f
This test verifies that verification tokens with different time stamps do
not have the same MAC. This may not guarantee that the MAC is computed
correctly but it catches implementation that do not include the time
stamp in the mac.
It also checks that the MAC changes when both time stamp and challenge
changes.
Test: yes it is
Bug: 131859731
Bug: 132288466
Bug: 132287277
Change-Id: I85aa1d873eff46df7a66fc69bd61a031e6e6fbe0
The BOOT_PATCHLEVEL value is allowed to have 00 in the days position
according to the keymaster specification. This test's comment already
suggests that it's allowed, so update the expectation to match.
Test: VtsHalKeymasterV4_0TargetTest
Bug: 130843899
Change-Id: Ib43da43b2e0398b48fb59710bf4066f2641de2eb
The verified boot hash in the attestation record is a binary blob, while
the property read from the system is a hex-encoded value. Convert the
boot hash from the attestation record into hex before comparing.
Test: VtsHalKeymasterV4_0TargetTest
Bug: 130843899
Change-Id: I6f6e0da71501d741dd8b27d0778e1854af17ace6
