Can Widevine DRM client player maintain a log of the keys that have been used for content decryption? The logs could be useful to derive certain statistics, such as to identify till where the content was viewed.
Also, are the keys that are received in 'pssh' data blogs also encrypted with certain token or session key?
pssh contains only KIDs (key ids) or in general protection headers, not the real decryption keys. The application needs to use those KIDs / protection headers to request the license from the license server. The license contains decryption keys but those are never exposed to your application. Keys in the license are encrypted. The only information you have are KIDs.
Widevine client should have some kind of map showing which status of known KIDs and event to notify you when the map changes. For example:
EME: keyStatuses and onkeystatuseschange on MediaKeySession
Android: queryKeyStatus and OnKeyStatusChangeListener in Media DRM
You can use those to monitor usage of keys in your app.
I assume by Widevine DRM you mean Widevine CDM.
Once key is expired (duration of key as per license policy), it is replaced by renewed keys corresponding to KIDs (KeyIDs). So "no" it does not maintain a log of used keys
Pssh box does not have Keys.
It has KeyIds and Init Data from which license request can be prepared by CDM, using which application can fetch license from license Server
Related
I have created service to offer the brands to create appointment passes and send via email, brands can create passes and send notification using my service.
This service allows them to send push notifications and using their brand name Can someone suggest as per attached image it’s in conflict or not
.
This clause authorizes your customers to send you their certificates for your service to manage on their behalf. This is a good thing and what you want them to do.
If I read between the lines, I believe you are asking if your service can your own single certificate to send to multiple brands. Attachment 5 to the Developer Agreement states:
You may use the Pass Type ID only for purposes of digitally signing
Your Pass for use with Wallet and/or for purposes of using the APN
service with Your Pass. You may distribute Your Pass Type ID as
incorporated into Your Pass in accordance with Section 2 below only so
long as such distribution is under Your own trademark or brand. To the
extent that You reference a third party’s trademark or brand within
Your Pass (e.g., a store coupon for a particular good), You represent
and warrant that You have any necessary rights. You agree not to
share, provide or transfer Your Pass Type ID to any third party
(except for a Service Provider and only to the limited extent
permitted herein), nor use Your Pass Type ID to sign a third party's
pass.
This strongly suggests you should only use your certificate for passes bearing your own trademark or brand.
It's a grey area. Only you can really decide whether or not you want to risk having your certificate revoked.
Does the Gmail API use encryption when sending emails?
Is there a better SO board to post this question on? I will move it if so.
(1) All requests between your client and the Gmail API are over HTTPS, which is encrypted.
(2) For calls like message.send() that generate an email to leave Google and go to another recipient, Google will do the same logic of attempting to send using encryption as when the user sends an email through web or mobile client. However unless your user is a GSuite user that has the "only send encrypted" policy enabled, the email sending may fallback to unencrypted if the remote side does not support encryption. For normal Gmail users if the remote side doesn't support encryption it may be delivered over plain text.
(3) If you want end-to-end encryption something like S/MIME or PGP is best.
(4) There's a new "STS" email standard that came out that Google supports that is a way for email providers to publish whether they require encryption to receive the email, which Gmail supports. When other providers also start publishing their STS records Gmail will respect it (and require encrypted transit to deliver those messages) Gmail STS
In the EMV protocol the IMK(ac) is used to generate the session key, which is used to generate an ARQC. The IMK(ac) is exclusive to the chip and the card issuer host
As far as I understand, the card issuers do not share those keys with the card brand (i.e. Visa cannot validate your ARQC, only "The Bank of Peoria" who issued the card can).
When an EMV Apple Pay transaction occurs in which the phone generates the ARQC, which IMK(ac) key is it using? Presumably it can't be the IMK(ac) from the original card, and thus the card issuer cannot validate the ARQC.
If it's an Apple IMK(ac) being used, then does this mean that it is Apple validating that ARQC?
If this is the case, what's the transaction flow that gives Apple the opportunity to validate the ARQC?
[Edited for clarity]
Mobile wallets like Apple/Google Pay don't use the card's PAN, so they don't need to provide the same ARQC that the card would have generated.
Instead, they use network tokens which are then mapped back to the PAN by the scheme.
Before the transaction
the Token Requestor (e.g. Apple) sends its IMKac to the Token Service Provider (e.g. Visa) as part of the onboarding
the Device (i.e. individual phone) is provisioned with a Token that can be mapped back to the PAN by the Token Service Provider as part of adding the card to Apple Pay
During the transaction
the Device:
generates an ARQC, which it includes in the transaction
sends its Token in the place that the PAN would go
the Token Requestor:
swaps out the Token for the PAN, which the issuer can recognise
validates the ARQC using the Token Requestor's IMKac, and forwards the result of this validation to the issuer
Encryption will always use Session keys derived from an IMKac for Cryptogram generation. However the IMK need not be the same as what your physical card uses( you can manage this using a different CVN as host).
The same key will be available with the payment schemes(Visa, MasterCard etc.) who will validate the cryptogram during the transaction and send you the results of verification.
Wallet CVNs are different. If you as a card issuer host wants to verify the cryptogram, then you should have the IMKac for the CVN and your HSM should support the CVN. Ideally you can rely on the verification results code (in 44 for Visa and 48 SE71 for MC) to decide whether it can be approved or no.
In case if you have more documentations from Apple you can share, I would love to go through those :-) .
I had ported Widevine CDM to cobalt RELEASE_9 branch. Playback of purchased video very well in beginning of 5 minutes. After 5 minutes, decrypt failed, the reason is key expiration.
After review DRM related API in starboard, I have two questions:
1.How to handle "renewal" message from CDM? how to inform upper layer when such message existed?
2.If key/license expired, how to reflect such status to upper layer?
Thanks
You can call SbDrmSessionUpdateRequestFunc with kSbDrmTicketInvalid if the update request was generated by the DRM system (Widevine CDM in this case).
Cobalt will pass these messages to server to get new license.
Check the comment in Drm.h and you also need SB_API_VERSION >= 4 in your platform.
I was wondering how the new google reCAPTCHA could verify the user is not a bot, just by clicking a button?!
See link here:https://developers.google.com/recaptcha/intro
I explain little on the new google behaviour captcha, but you might find the richer explanation in here.
The supplied JavaScript captcha api code accumulates the cues of human activities (or its absence) on a web page even before a user (client) approaches the reCaptcha itself.
When a user moves to and ticks the “I’m not a robot” checkbox, that behaviour drives even more browser events. These are caught by the same script and a request with encoded payload is sent to the Google server, the user’s fingerprints are recorded and his cookies stored.
The behaviour analysis system on the Google server analyses the data provided and returns an encoded value to the client page. This value is user and time dependent.
In case of confusion (or bot-like behavior) Google’s server will ask the client to complete an additional image-check CAPTCHA (see picture below) to further verify if the user is a bot or not.
The encoded value bears the hidden info if user is verified or not. But then you need to know whether Google has verified that user or not on that page. To check it, you send a POST (ajax) request with the following parameters: the returned encoded value, the secret key and end user ip (the last one is optional). Read the details on how to fetch and verify the user’s response.