- The docs said that IdentityCredential.createEphemeralKey() returned
data encoded PKCS#8 which is wrong. It's supposed to be in DER format
which is also what the VTS tests and credstore expects.
- Clarify that createEphemeralKeyPair(), setReaderEphemeralPublicKey(),
and createAuthChallenge() are all optional.
- Avoid passing an invalid profile ID in the IdentityCredentialTests.
verifyOneProfileAndEntryPass test.
- Update requirements for which tags must be present in the attestation
for CredentialKey as well as the requirements on expiration date and
the issuer name. Update default implementation to satisfy these
requirements. Update VTS tests to carefully verify these requrements
are met.
- Clarify requirements for X.509 cert for AuthenticationKey. Add VTS
test to verify.
- Mandate that TAG_IDENTITY_CREDENTIAL_KEY must not be set for test
credentials. Add VTS test to verify this.
- Make default implementation pretend to be implemented in a trusted
environment and streamline VTS tests to not special-case for the
default implementation.
- Switch to using the attestation extension parser from the KM 4.1
support library instead of the one from system/keymaster. The latter
one did not support the latest attestation extension and thus would
fail for pretty much anything that wasn't the default HAL impl.
- Fix a couple of bugs in keymaster::V4_1::parse_attestation_record():
- Report root_of_trust.security_level
- Add support for Tag::IDENTITY_CREDENTIAL_KEY
- Fix how EMacKey is calculated.
- Add test vectors to verify how EMacKey and DeviceMac is calculated.
Test: atest VtsHalIdentityTargetTest
Test: atest android.security.identity.cts
Bug: 171745570
Change-Id: I2f8bd772de078556733f769cec2021918d1d7de6
The GSI patch level might be greater than the vbmeta SPL, because
GSI system.img might be updated via the DSU flow, where vbmeta.img won't
be updated in this scenario.
https://developer.android.com/topic/dsu
Allowing GSI patch level to be greater than or equal to the vbmeta SPL,
since Treble allows new system.img works on old vendor images.
Bug: 145377203
Test: atest VtsHalKeymasterV4_0TargetTest
Change-Id: Ib761d80c88695eb2db08b0dc00e30fcdc2788865
The keymaster function affects the performance of secure os. When considering the swtiching time of the normal world < - > Secure world and the processing delay of the SecureOS by the scheduling policy of the normal world, it is necessary to increase the time.
Even though Secure world is no problem, Sometimes there is a possibility of that the test will fail because it is a limited resource normal world.
On average, it is performed in a very fast time, but sometimes it takes a lot of time. After many tests, the safe time was measured.
Bug: 162115135
Change-Id: I55862204ef71f69bc88c79fe2259f7cb8365699a
Signed-off-by: kh0705 <kh0705.park@samsung.com>
The test fails on devices because an unknown
client starts a keymaster BEGIN operation during
bootup but does not finish it. This affects the
keymaster hardware implementation's capability
to support the maximum possible operations while
running this test.
Bug: 154801042
Change-Id: Ib6adc6c28ebe76ddfdc2c66cd17cf78c04e5b468
HIDL libs are not necessarily part of VNDK now. Because some are
used by VNDK libs, they are still VNDK. But rest are now just
vendor-available.
.hidl_for_test files are also removed because they are used to exclude
test-purpose hidl libs from VNDK libs.
Instead, .hidl_for_system_ext files are added to tests/lazy to
distinguish them from others which are installed /system.
Bug: 143933769
Test: update-makefiles.sh && m com.android.vndk.current
Merged-In: Ia81312dda340b6b5cbdd7a3c21e1d323bda39a4a
Change-Id: Ia81312dda340b6b5cbdd7a3c21e1d323bda39a4a
(cherry picked from commit b0907a6bb8)
In deserializeVerificationToken(), we use extractUint64() to extract
VerificationToken.challenge. A potential bug was found in
extractUint64() that will cause VerificationToken.challenge()
incorrect.
Bug: 160198696
Merged-In: Ie0d2c0127cc34f1bb90455e4f7869e15e5542173
Change-Id: Ie0d2c0127cc34f1bb90455e4f7869e15e5542173
In deserializeVerificationToken(), we use extractUint64() to extract
VerificationToken.challenge. A potential bug was found in
extractUint64() that will cause VerificationToken.challenge()
incorrect.
Bug: 160198696
Change-Id: Ie0d2c0127cc34f1bb90455e4f7869e15e5542173
HIDL libs are not necessarily part of VNDK now. Because some are
used by VNDK libs, they are still VNDK. But rest are now just
vendor-available.
.hidl_for_test files are also removed because they are used to exclude
test-purpose hidl libs from VNDK libs.
Instead, .hidl_for_system_ext files are added to tests/lazy to
distinguish them from others which are installed /system.
Bug: 143933769
Test: update-makefiles.sh && m com.android.vndk.current
Merged-In: Ia81312dda340b6b5cbdd7a3c21e1d323bda39a4a
Change-Id: Ia81312dda340b6b5cbdd7a3c21e1d323bda39a4a
(cherry picked from commit b0907a6bb8)
Bug: 152932559
Test: Boot and observe that Strongbox gets the message
Merged-In: I752b44f5cc20d85bf819188ccaaf0813a5607ba5
Change-Id: I752b44f5cc20d85bf819188ccaaf0813a5607ba5
VTS was running on a userdebug build GSI before Android 10.
Starting from Android 10, VTS is switched to running on top of a
user build GSI image, plus the device-specific boot-debug.img to
allow adb root.
https://source.android.com/compatibility/vts/vts-on-gsi
So 'ro.build.type' will be 'user' because the value comes from
/system/build.prop. Switching to using 'ro.debuggable' to decide
whether we should check the device is locked or not. Note that
'ro.debuggable' will be '1' for userdebug/eng images or when a
boot-debug.img is used.
Bug: 154449286
Test: atest VtsHalKeymasterV4_0TargetTest
Change-Id: If5a90d62f77489aa58f96e908553a052cf6d1e18
Merged-In: If5a90d62f77489aa58f96e908553a052cf6d1e18
(cherry picked from commit 43dd6e34bd)
VTS was running on a userdebug build GSI before Android 10.
Starting from Android 10, VTS is switched to running on top of a
user build GSI image, plus the device-specific boot-debug.img to
allow adb root.
https://source.android.com/compatibility/vts/vts-on-gsi
So 'ro.build.type' will be 'user' because the value comes from
/system/build.prop. Switching to using 'ro.debuggable' to decide
whether we should check the device is locked or not. Note that
'ro.debuggable' will be '1' for userdebug/eng images or when a
boot-debug.img is used.
Bug: 154449286
Test: atest VtsHalKeymasterV4_0TargetTest
Change-Id: If5a90d62f77489aa58f96e908553a052cf6d1e18
This is to facilitate HAL implementations using a TA existing in a
different environment than where auth tokens are minted. This method
will be used by credstore in a companion CL.
This modifies version 2 of the Identity Credential API (which was
never been released) to add a new method and creates version 2 of the
Keymaster types-only AIDL API to include the new VerificationToken
parcelable and SecurityLevel enum.
Bug: 156076333
Test: atest VtsHalIdentityTargetTest
Test: atest android.security.identity.cts
Merged-In: I7d05413a9ec70225ce419079f3cc9daf026cf744
Change-Id: Idd7ab041d87617556ed840403033b642f8c2ab86
This is to facilitate HAL implementations using a TA existing in a
different environment than where auth tokens are minted. This method
will be used by credstore in a companion CL.
This modifies version 2 of the Identity Credential API (which was
never been released) to add a new method and creates version 2 of the
Keymaster types-only AIDL API to include the new VerificationToken
parcelable and SecurityLevel enum.
Bug: 156076333
Test: atest VtsHalIdentityTargetTest
Test: atest android.security.identity.cts
Change-Id: I7d05413a9ec70225ce419079f3cc9daf026cf744
This CL needs some polish. Changes
herein are somewhat brute-force to
make things work, particularly with
authorization-list parsing and validation.
This CL also copies over support for
dumping attestation records.
Bug: 129282228
Test: VtsHalKeymasterV4_1TargetTest
Change-Id: I4fc0183dc0b8a76e84d14054b38ad7c1540a1897
This test is expected to be run
on non-StrongBox instances.
Bug: 129282228
Test: StrongBoxOnly passes on TZ
Change-Id: Ia6b274d097b4c698904d1c51daed821188a50510
AIDL interfaces which are vintf-stable have to be frozen in release.
But these interfaces have been never frozen, so freeze them.
- android.hardware.power
- android.hardware.identity
- android.hardware.keymaster
- android.hardware.vibrator
- android.hardware.light
- android.hardware.tests.extension.vibrator
Bug: 153500421
Bug: 153500550
Bug: 153511407
Bug: 153500549
Bug: 153501107
Bug: 153501202
Test: m
Change-Id: I643c25fc695f9d1e874dcceb327d465c49e9cab6
Merged-In: I643c25fc695f9d1e874dcceb327d465c49e9cab6
AIDL interfaces which are vintf-stable have to be frozen in release.
But these interfaces have been never frozen, so freeze them.
- android.hardware.power
- android.hardware.identity
- android.hardware.keymaster
- android.hardware.vibrator
- android.hardware.light
- android.hardware.tests.extension.vibrator
Bug: 153500421
Bug: 153500550
Bug: 153511407
Bug: 153500549
Bug: 153501107
Bug: 153501202
Test: m
Change-Id: I643c25fc695f9d1e874dcceb327d465c49e9cab6
All aidl_interface modules should by default considered as stable, in
case it is used across system and vendor partitions, or across modules.
Like other API surfaces, we need to have a dump for the current
(yet-to-be-released) version and update it when there is an API change.
This is done via .
Then the owner of the interface can freeze the current version as a
numbered version via .
This change shal be rejected only when the owner is certain that the
interface is not used across the updatable boundaries.
Bug: 152655547
Test: m
Change-Id: Id167905590c0a596b0ed470ef668c47810966836
Merged-In: Id167905590c0a596b0ed470ef668c47810966836
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
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
The way I planned for this to work doesn't work. We'll revisit in
Keymaster5. For now, removing IOperation and beginOp.
Test: Build & boot
Merged-In: I017d17079380cc3bacc6f05b2486e1b6e6c3f675
Change-Id: I017d17079380cc3bacc6f05b2486e1b6e6c3f675
The attestation code used boringssl's ASN.1 encoding tools
incorrectly, causing it to encode incorrect values in device_locked.
Bug: b/152503089
Test: Build & boot
Change-Id: I3c5352523b2db37d539ad353ac8c48c1585eb08d
HMAC key was created with Digest(Digest::SHA_2_256) which is missing in
the UseHmacKey function
Bug: 152932473
Test: VtsHalKeymasterV4_1TargetTest
Change-Id: If63dd197fe12172e14be9890ab07a00c3eef4a4c
All aidl_interface modules should by default considered as stable, in
case it is used across system and vendor partitions, or across modules.
Like other API surfaces, we need to have a dump for the current
(yet-to-be-released) version and update it when there is an API change.
This is done via .
Then the owner of the interface can freeze the current version as a
numbered version via .
This change shal be rejected only when the owner is certain that the
interface is not used across the updatable boundaries.
Bug: 152655547
Test: m
Change-Id: Id167905590c0a596b0ed470ef668c47810966836
The way I planned for this to work doesn't work. We'll revisit in
Keymaster5. For now, removing IOperation and beginOp.
Bug: 152536287
Test: Build & boot
Change-Id: I017d17079380cc3bacc6f05b2486e1b6e6c3f675
This includes add a partial types-only HAL for KeyMaster for
HardwareAuthToken.
Bug: 111446262
Test: atest android.security.identity.cts
Test: VtsHalIdentityTargetTest
Test: android.hardware.identity-support-lib-test
Change-Id: I7a6254d33200bfd62269aed1957cbb2a84b16272
These are keymaster keys used specifically for storage
encryption. This provides the ability for keymaster implementations to
securely protect storage encryption keys.
Test: VtsHalKeymasterV4_1TargetTest
Bug: 147733587
Change-Id: I5f7f83755fcbed96d8f38fa51812aa6d2eb0927b
Merged-In: I5f7f83755fcbed96d8f38fa51812aa6d2eb0927b
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
Merged-In: Idc5de13c342ef1ac62d3131a1a2185d5e78a0d45
We'll add a large-size test to the Keymaster 4.1 VTS tests.
Test: VtsHalKeymasterV4_0TargetTest
Change-Id: I2460106cf918e44ea5eeac5c518a89c311756eb3
Merged-In: I2460106cf918e44ea5eeac5c518a89c311756eb3
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
Merged-In: I9310a851648c028850f9795d303419c6a7e29a11
These are keymaster keys used specifically for storage
encryption. This provides the ability for keymaster implementations to
securely protect storage encryption keys.
Test: VtsHalKeymasterV4_1TargetTest
Bug: 147733587
Change-Id: I5f7f83755fcbed96d8f38fa51812aa6d2eb0927b
* changes:
Keymaster 4.1 VTS tests
Update KM4 VTS tests to allow s/w implementation to pass.
Remove service death test.
Change finish input test to avoid large sizes.
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
This CL adds:
- The IDENTITY_CREDENTIAL_KEY tag. This new tag is not actually used
by Keymaster at all. It's used by the new Identity Credential HAL in
its key attestations, which use the Keymaster format and the Keymaster
attestation key.
- A VerificationToken argument to deviceLocked, used for StrongBox
implementations.
- Some error codes, including one to diagnose unprovisioned
attestation keys/ids.
- Clarifications in the documentation.
Test: VtsHalKeymasterV41TargetTest
Change-Id: Iae7151e2d9b328dd73e5cd78e59687ef29bab4f0
Merged-In: Iae7151e2d9b328dd73e5cd78e59687ef29bab4f0
This CL adds:
- The IDENTITY_CREDENTIAL_KEY tag. This new tag is not actually used
by Keymaster at all. It's used by the new Identity Credential HAL in
its key attestations, which use the Keymaster format and the Keymaster
attestation key.
- A VerificationToken argument to deviceLocked, used for StrongBox
implementations.
- Some error codes, including one to diagnose unprovisioned
attestation keys/ids.
- Clarifications in the documentation.
Test: VtsHalKeymasterV41TargetTest
Change-Id: Iae7151e2d9b328dd73e5cd78e59687ef29bab4f0
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
Note that CL is missing complete tests (what's included is just a
stub, really) and support library code. All of that will come in
near-future CLs. This CL omits them because they'll take time and
there's a need to unblock Keymaster 4.1 implementers now.
Bug: 140193672
Bug: 140192237
Bug: 140824829
Test: Will be in a future CL
Change-Id: I0e6e3a38356f0517158a10604b549415641ad1b9
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
NullOr now stores the references a pointers internally. This fixes UB
where the internal reference was initalized by dereferencing nullptr.
Test: Compiles
Bug: 121390225
Change-Id: I2073e5aeac401309aa63b08e05db3c467fab6b69
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
Since these were combined into libhidlbase.
Bug: 135686713
Test: build only (libhwbinder/libhidltransport are empty)
Change-Id: I075670b64eebbbbd6a6ae0e84ad51bf1c6f5ba36
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
Object derived from RefBase must be owned by sp rather then other smart
pointer implementations.
Bug: 79474587
Change-Id: I866f67e1cb091efb3026450d50a410b5985539b6
