[ Merge of http://go/wvgerrit/154593 ]
This CL updates the initial time used for reboot tests to be
within the valid range used by OPK. Also, the fake clock is
now synced with every use of the TestHost's clock function.
Also, the OPK's system clock is no longer initialized to 0
because this caused some tests to set initial playback time
to 0. That broke code that assumed a time of 0 mean "never".
I also removed some log spam in the WTPI code.
Bug: 222353528
Bug: 236317198
Change-Id: Ibdbdb2440454b9cf561cd9ec65ca3e40cf5a8d93
After a successful extraction, the vector of BCC should be resized to
the correct value.
Test: build and run extraction tool
Bug: 237029566
Change-Id: I41f39cb72bb1dc27d6d40f3c5ace5265271aab0e
(This is a merge of http://go/wvgerrit/153552.)
The correct way to create a FileSystem object for testing CdmEngine
depends on the platform. However, our code has historically just
instantiated a new FileSystem object using the default constructor. This
works fine for Android and has historically worked fine for the CE CDM
tests because they did not implement storage correctly. However, an
upcoming commit will fix the implementation of storage in the CE CDM
TestHost, causing tests that use a default FileSystem constructor to
fail. This patch adds a new platform-defined function that instantiates
per-origin test storage in a platform-correct way. For Android, it
continues to use the default constructor, while for CE CDM, it uses the
TestHost.
Bug: 193060708
Test: x86-64 w/ storage separated
Test: build_and_run_all_unit_tests.sh
Change-Id: I0a9b6a4d3943e053d51d6018e392b7f215f50642
(This is a merge of http://go/wvgerrit/153551.)
On CE CDM, storage is split between global and per-origin storage, and
one type of storage cannot be used to access the other. (Though, until
an upcoming commit lands, the tests will allow it.) On Android, both
types of storage access the same filesystem. This means that code may
run fine on Android but fail on CE CDM.
The Usage Table Header code normally, explicitly accesses the header
file via global storage. However, a few code paths would try to access
it inconsistently via per-origin storage. This patch updates
StoreTable() to always use the global storage, similar to how
RestoreTable() already functions.
Test: x86-64 w/ storage separated
Test: build_and_run_all_unit_tests.sh
Bug: 236400786
Bug: 192297621
Change-Id: Ie84cef43a7ad169ca8ab701d73c087294ee29705
(This is a merge of http://go/wvgerrit/153550.)
On CE CDM, storage is split between global and per-origin storage, and
one type of storage cannot be used to access the other. (Though, until
an upcoming commit lands, the tests will allow it.) On Android, both
types of storage access the same filesystem. This means that code may
run fine on Android but fail on CE CDM.
The OEM Cert in Provisioning 4.0 is a global file that should only
exist once, but it was being accessed through the per-origin storage,
which would result in a separate OEM Cert being provisioned for each app
& origin on CE CDM. This patch changes the Prov 4.0 code to access it
through the global storage, using techniques similar to how the Usage
Table Header code does this.
Test: x86-64 w/ storage separated
Test: build_and_run_all_unit_tests.sh
Bug: 236400627
Change-Id: I301d250fc9543e62949a4d9fdcbdd109bd941384
[ Merge of http://go/wvgerrit/153589 ]
Some unit tests call InstallTestRSAKey() a few times. In current
provision 2 with Keybox, the test RSA DRM key is hard coded. But for
provision 4, it will be generated by OEMCrypto.
When a test calls multiple times of InstallTestRSAKey(), we don't want
the key to be generated during each call, and we want to use the same
key in order for the decrytion to work.
The fix to cache the drm key once it is created for prov 4 tests.
Bug: 180530495
Bug: 236317198
Test: oemcrypto_test
Change-Id: I1b2d96a89e0619861492e6d9bc56862e2c440c86
[ Merge of http://go/wvgerrit/150349 ]
The device id for prov4 is hash of the encoded device public key
(COSE_key).
Also replaced a few bug numbers if it is prov3 specific (not related to prov4).
Bug: 225216277
Bug: 236317198
Test: oemcrypto_test
Change-Id: Ica1c8579c0a3ef83c70f331283c9cce629c6bb3f
[ Merge of http://go/wvgerrit/149849 ]
With ECC based DRM cert, the session key is expected to be 32, as
compared to 16 bytes in RSA case. This CL adds supports for 32 bytes
session key.
Bug: 236317198
Test: oemcrypto_test
Change-Id: I657fdd92d17736a23375ddcd457f83efa6ca6d1f
[ Merge of http://go/wvgerrit/151311 ]
Missing a check for provision 4.0.
Note: This CL is merged out of sequence with the CDM repo, resulting
in a slightly different CL.
[ Conflicting CL http://ag/18244016 ]
Test: Native test crypto_session_unittest
Bug: 180530495
Bug: 236317198
Change-Id: I79f753ba43098e1a3422c39b9903f57e5df03af2
[ Merge of http://go/wvgerrit/150810 ]
This CL changes the call "Provision()" in some tests to use
"EnsureProvisioned()". The latter can actually call "Provision()" twice
in case of Prov 4 being used: first call to get oemcert.bin and second
call to get drm cert.bin.
Also added a file clean up during test tear-down.
Test: opk_ta with prov2 and prov4
Bug: 180530495
Bug: 236317198
Change-Id: I37c8708ead7f18e8b4d619bf6a080424e45406ee
[ Merge of http://go/wvgerrit/153290 ]
Currently OEMCrypto_Close will be called for entitled key sessions as
well upon destroying, while only OEMCrypto sessions should be called.
This CL adds a session type to the oemcrypto adaptor.
Bug: 232225911
Bug: 236317198
Test: request_license_test
Change-Id: I323fff80139ce949f801cf0df5aa2bd3171dfb51
The CL http://ag/16988980 introduced new Adnroid property queries to
the CDM; however, the file was not of the correct format for the CDM
repo. This CL simply ran clang-format on the file.
Bug: 197771575
Bug: 236317198
Test: none
Change-Id: I5293864f84d1297efb7aef2a96a71794217c5203
[ Merge of http://go/wvgerrit/152650 ]
There are two LOGEs in device_files.cpp that would frequently trigger
during testing despite the condition they were logging being totally
normal. The files were not present because the device had never had to
write them yet. This patch downgrades these bengin errors to warnings
to reduce log spam.
Test: build_and_run_all_unit_tests.sh
Bug: 236317198
Change-Id: I56f9d477f8a6b26635f0eb4a6b7c636e866381d3
[ Merge of http://go/wvgerrit/148729 ]
A recent merge from google3 of the ODK code broke builds on the
oemcrypto-v17 branch because it depended on a license_protocol.proto
change that had not been brought over yet. This patch brings over the
missing line to fix the build.
Test: build_and_run_all_unit_tests.sh
Bug: 236317198
Change-Id: Ia8133696f3156c16ef4bd1382358be5da6159820
(This is a merge of http://go/wvgerrit/152969.)
C++ makes absolutely no guarantees about the order of initialization of
global variables in different compilation units. The class-scope static
WvCdmTestBase::default_config_ in test_base.cpp invokes the
ConfigTestEnv constructor on creation, which depends on the prior
initialization of several file-scope static variables in
config_test_env.cpp. Since those are different compilation units, there
is no guarantee that they will initialize in the correct order to avoid
referencing uninitialized memory. This is one of the reasons Google
Style really encourages people not to have global-scope variables with
complex types.
As it happens, on all our internal platforms, these files get linked in
such a way that the variables get initialized in the right order and
there is no crash. But that's not guaranteed, and some partners have
reported crashes here. In at least one case, the "right" linker order
was platform-dependent, and the partner ended up having to maintain
separate linker orders for separate platforms.
This patch defers default_config_ initialization until
WvCdmTestBase::Initialize() is called. By that time, all static
variables will be initialized, so it will be safe to reference them.
Bug: 173252165
Test: x86-64
Test: build_and_run_all_unit_tests.sh
Change-Id: If31128a999c7d6945f47293ca57f08e43d8274de
This is a merge from:
https://widevine-internal-review.googlesource.com/c/cdm/+/152897
and http://go/wvgerrit/153709
Adding a new OEMCrypto unit test will allow partners to correct a
problem earlier in their integration.
Verifies current oemcrypto implementation handles clear KCB in a
mocked 16.4 license response.
Unit test release date updated to 2022-06-17.
Test: run_x86_64_tests; opk_ta
Bug: 235870170
Bug: 234645065
Change-Id: I59fef2c25f5c007624447d4f46147d96adeddad9
[ Merge of http://go/wvgerrit/147275 ]
Swapped out use of OpenSSL/BoringSSL RSA and EC_KEY to use OEMCrypto
reference utility classes RsaPublicKey/EccPublicKey. This enables
further test development with ECC keys, and removes duplicate OpenSSL/
BoringSSL code.
For Android makefiles, only the minimally required files have been
added.
Bug: 205902021
Bug: 236317198
Test: run_prov30_test run_prov40_test oemcrypto_test
Change-Id: I64491018e8ffb69bf986083e3aae446eb9e5cf39
[ Merge of http://go/wvgerrit/150789 ]
We had two copies of the wvcrc32.h and wvcrc.cpp files: One in
oemcrypto/util/ and one in oemcrypto/test/. The two were identical
except for the namespaces used. However, this setup created confusion if
the compiler could see both files, as the wrong one could get included.
This patch removes the set from test/ in favor of the more-widely-used
set from util/ and updates the one piece of code using the old
namespace.
Update Android oemcrypto_test makefile for wvcrc32.
[ Merge of http://go/wvgerrit/153657 ]
Duplicated wvcrc files were removed in http://go/wvgerrit/150632,
however, the Android-specific makefile for oemcrypto_test was not
updated with the new source and include directory. This CL makes
the necessary changes to the makefile to build with the OEC ref util
version of wvcrc32.
Bug: 229160397
Bug: 236317198
Test: oemcrypto_test
Change-Id: I0b53255122172fb514e7e0602b59f3ab704e52da
[ Merge of http://go/wvgerrit/152950 ]
This CL introduces several functions for computing a HMAC-SHA256
signature. The functions wrap the OpenSSL/BoringSSL implementation
of HMAC(), allowing for common C++ types to be passed in. Several
of the functions follow several OEMCrypto conventions for generating
signatures (ex. returning OEMCrypto_ERROR_SHORT_BUFFER if signature
buffer is too small).
Also provided limited wrappers for HMAC-SHA-1, which are used for
a limited number of operations within OEMCrypto.
Bug: 154055871
Bug: 145026434
Bug: 236317198
Test: hmac_unittest
Change-Id: I4a9e56066a7c3f14c7159270503225cd794c1bb6
[ Merge of http://go/wvgerrit/153489 ]
OEMCrypto does not provide an API for retrieving the system ID when
the TEE uses a built-in DRM certificate (provisioning 1.0). New OEMs
and Android devices do not use prov 1.0; however, the Zimperium CDM
(at least the tests) use a built-in certificate and are failing
certain tests because of the missing system ID. To address this
failure; the CDM SystemIdExtractor has been updated to return a null
system ID.
Bug: 235879962
Test: system_id_extractor_unittest
Change-Id: Ib4c2bd75a7825967b0aa9e31e144184ae18fe8fb
In CreateCoreLicenseResponse(), there seems to be an out of bounds
potential error due to a missing check that the index used for
license_response.parsed_license->key_array is valid. Adding a check
for this here.
Bug: 217677571
Test: fuzz tests
Change-Id: I37f7228f87992ba5284c553d7b07ef97d6a66ab3
[ Merged from http://go/wvgerrit/152493 ]
Replace struct with class for WVDrmFactory, WVCryptoPlugin
and WVDrmPlugin.
Also fix build_all_unit_tests.sh, hidl_metrics_adapter_unittest
has been renamed to hal_metrics_adapter_unittest.
Test: unit tests
Test: Google TV and Netflix
Test: atest GtsMediaTestCases
Bug: 216717460
Change-Id: I92b15510267e8f37058845be760a6ec6241bc5d7
[ Merge of http://go/wvgerrit/152674 ]
This allows an app to query the provisioning model. Possible
values are { "DrmCertificate", "Keybox", "OEMCertificate",
"BootCertificateChain" }
An app can use these to disntinguish between provisioning models.
Provisioning 4.0 (boot certificate chain) requires a double provisioning
step.
Bug: 234057551
Test: WV unit/integration tests, libwvdrmdrmplugin_hal_test
Change-Id: I1611488ec632a0e5a9e1d106b7475e8f5a2a5a13
This is a merge from:
https://widevine-internal-review.googlesource.com/c/cdm/+/152372
The L3 source change which produced these libraries is:
https://widevine-internal-review.googlesource.com/c/cdm/+/152371/
Original commit message:
To address the bug with certain 16.4.x SDK versions returning a
clear key control block (KCB) for clients newer than 16.5, the
exact version check to determine whether key control blocks are
clear or not has been loosened.
Original behavior:
- ODK version >= 16.5.x --> Assume clear
- ODK version <= 16.4.x --> Assume encrypted
New behavior:
- No KCB IV --> Assume clear
- Otherwise --> Assume encrypted
This CL also includes a change to oemcrypto/include/OEMCryptoCENC.h
The changes to OEMCryptoCENC.h in the CL are comments or variable name
change. So it should be safe.
This change was merged to wv tm-dev here:
https://widevine-internal-review.googlesource.com/c/cdm/+/148411
So, adding it to Android tm-dev.
Test: run_level3_static_tests, CdmDecryptTest/CdmTestWithDecryptParam.* against LS SDK 16.4.2 & 17.0
Bug: 232557453
Change-Id: I2bbb5ab3ea33a16bd6c198077e5aefe960737ea0
(This is a merge of http://go/wvgerrit/151930.)
While grepping the code to respond to some CR feedback, I noticed a few
places where we had sprinkled some unnecessary "const" specifiers
amongst constexpr declarations. This patch cleans them up. There should
be little semantic difference in the code after this patch, as it only
removes specifiers that were redundant. The only exception is where
"constexpr const char* X" was converted to "constexpr char X[]", which
has slightly different semantics in edge cases we don't use.
Test: x86-64
Bug: 231439638
Change-Id: I0b33777f8d3b718a3410f6d802c51b1220508d34
(This is a merge of http://go/wvgerrit/151891.)
A previous patch changed how we skip padding when extracting keys from
key containers in license.cpp. Unfortunately, this broke generic
signing when an ODK core message is not in use:
1) "Content" keys for signing are 32 bytes long, but content keys were
assumed to be 16 bytes long.
2) When an ODK core message IS in use, the result of the extraction in
license.cpp is ignored.
The only way to know the correct length of a content key container in
License Protocol 2.1 is to leverage the knowledge that it will always be
padded by exactly 16 bytes. This will have to change if we ever
implement support for License Protocol 2.2, as all key containers are
unpadded in that version.
Bug: 231439638
Bug: 114159862
Test: oemcrypto_dynamic_v15
Change-Id: I1d6c24b3a922247b970fd1517c6f23aded570adf
