[ Merge of http://go/wvgerrit/120123 ]
DRM certificate creation and expiration times are now validated.
* New DRM (default) certificates will have an expiration time specified
by the provisioning service.
When stored, the client will include the time the certificate was
received. This allows for expiration calculation to occur when client
and provisioning service clocks are out of sync.
When read out, creation, expiration and acquisition times are
validated. The certificate is checked for expiry by making sure
that the time at the client since the license was acquired is not
greater than the expiration period. The time information stored at the
client may be tampered with. The license service will perform an
expiration check and reject the license request if tampered with.
The expiration time may be set to never expires/unlimited. This is not
a valid value for creation or acquisition time.
* Pre-existing (legacy) certificates from upgrading devices will not
have an expiration time set by the provisioning service. Instead
the client will calculate an expiration time 6 months with + or -
a random two month period in the future. This is stored along with the
certificate.
When read out, if no expiration time has been set by the client, one
will be calculated and written out. The certificate will be declared as
valid. If a client calculated expiration time is present, the
certificate will be validated. In case of tampering, the license service
can reject license requests and force reprovisioning when appropriate.
* ATSC certificates will continue to not have an expiration time.
No additional validation is required.
Other changes for non-ATSC licenses involve managing both default and
legacy certificate co-existance. When checking for DRM certificates,
the default certificate is attempted first. This is followed by a check
for the legacy certificate, if the default certificate is not present.
Bug: 169740403
Test: WV unit/integration tests
DeviceFilesTest.StoreCertificateInvalidParams
DeviceFilesTest.RetrieveAtscCertificate
DeviceFilesTest.RetrieveAtscCertificateNotFound
DeviceFilesTest.RetrieveCertificateInvalidParams
DeviceFilesTest.RetrieveLegacyCertificateWithoutExpirationTime
DeviceFilesTest.RetrieveLegacyCertificateWithClientExpirationTime
DeviceFilesTest.RetrieveLegacyExpiredCertificateByClientExpirationTime
DeviceFilesTest.RetrieveLegacyCertificateInvalidClientExpirationTime
DeviceFilesTest.RetrieveCertificateWithoutKeyType
DeviceFilesTest.RetrieveDefaultCertificate
DeviceFilesTest.RetrieveDefaultCertificateNeverExpires
DeviceFilesTest.HasCertificateAtsc
DeviceFilesTest.HasCertificateDefault
DeviceFilesTest.HasCertificateLegacy
DeviceFilesTest.HasCertificateNone
CertificateTest.StoreCertificateTest.DefaultAndLegacy/*
CertificateTest.RetrieveLegacyCertificateTest.ErrorScenarios/*
CertificateTest.RetrieveDefaultCertificateTest.ErrorScenarios/*
Change-Id: I7dbec7555fbd493c1ec61c6bb5d9428a2405b1fd
[ Merge of http://go/wvgerrit/119843 ]
Creation and expiration times are extracted from the device DRM
certificate. They are reported as
* -1 if not set in the proto
* 0 if unlimited
* positive number otherwise
Bug: 169740403
Test: WV unit, integraiton tests
Change-Id: I9463954dfeb82b6a88ff5d608ed74d20f2424e83
[ Merge of http://go/wvgerrit/119684 ]
This allows for a default DRM certificate that includes an expiration
time and a legacy one without for each app+origin specific identifier.
Existing offline licenses/secure stops are not associated with a
certificate, and so we cannot delete legacy certificates even after
fetching a new one. New offline licenses/secure stops will be associated
with certificate information, so we will not have this problem going
forward.
Bug: 169740403
Test: WV unit/integration tests
Change-Id: I0f08f6bf98775fd43927243dc4a9f75f21bfbbcc
[ Merge of http://go/wvgerrit/119644 ]
This change includes additional fields in DeviceCertificate, License and
UsageInfo.
New DRM certificate will include a creation and expiration time.
In addition acquisition_time_seconds will allow the client to calulate
expiration time even when client and provisioning service clocks
are not in sync.
expiration_time_seconds will allow clients to expire DRM certificates
that do include an expiration time. A random value within a window
(4-8 months after update) will be calculated to avoid
a provisioning storm.
Drm certificate will be added to offline licenses. In a future release,
licenses will be removed on expiry and the certification information
that needs to be sent to the license service will be reduced.
This should reduce space overhead.
UsageInfo will use a certificate cache in case multiple usage info
entries use the same DRM certificate.
Bug: 169740403
Test: WV unit/integration tests
Change-Id: I2f34a1df526fa8168162a1b1ea930a2f257b87cd
[ Merge of http://go/wvgerrit/119804 ]
The coverage framework used by Android requires the process to call
exit() for coverage information to be dumped after the tests.
Android unit tests have been adapted to use the a new main module.
The core test_main.cpp used by integration tests has been updated to
call exit().
Bug: 138941105
Test: Linux and Android unittests
Change-Id: Ifffc7b8290c50dffe527738a36547c1d2fb90bd3
[ Merge of http://go/wvgerrit/119230 ]
This patch adds an annotation to the one place in the codebase where we
intentionally fall through between switch statement cases, in order to
appease stricter compilers.
Bug: 182058081
Test: compile, WV unit/integration tests
Change-Id: I004a6a6e61681fcf22c6bf25d9b0284b8b64e776
[ Merge of http://go/wvgerrit/119564 ]
This closes a crypto session when the provisioning request fails. We
cannot be as eager when handling the response as the app may have
multiple simultaneous provisioning attempts in flight. In this case
all provisioning responses except the one associated with the last
request will fail. If we close the session on error, even the one
associated with the last request may fail.
Bug: 180986725
Test: WV unit/integration tests
Change-Id: Ic3d33a374e442b5bf040e345bed829d91c4ef1dc
[ Merge of http://go/wvgerrit/119563 ]
This also increases the max log size from 1024 to 5120
Bug: 181642154
Test: WV unit/integration tests
Change-Id: Ifae90354dad1165f4d9fa3c9fe33a4dc14df1270
