Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.comp.os.windows-10 > #181186

Re: OT: Streaming

Show all headers | View raw

On Wed, 1/8/2025 12:14 PM, Newyana2 wrote:
>   Another clue here that I'm hoping might mean something.
> I looked it up and so far haven't found anything useful.
> 
>   Chromium on Windows at Kanopy shows the mysterious
> message "Unsupported keySystem or supportedConfigurations".
> I tried it on my Raspberry Pi, which also runs Netflix fine,
> and I get a different message in Chromium when I try to start
> the video. It says the video is encrypted and it doesn't have the
> decryption keys.
> 
>   How could all the latest browsers be missing the keys
> for streaming at some sites? Kanopy claims to still support
> browsers. I've never heard of updating decryption keys.
> Any idea how that works?
> 

   "You have a media file or a media stream, which is encrypted with
    a symmetric key (almost always an AES-128 variant)."

   "Now let's go back to how the content key is delivered to a user's device.
    This is usually via some sort of cryptographic challenge/response mechanism,
    which means there is PKI involved. In other words, the key request is signed
    (to prove the device's identity) and the key response is encrypted with the
    device's public key.

    The goal of this is to ensure that, even if the user were to take hold of
    the file where the key is eventually stored, they would not be able to
    distribute it to other devices, which are supposed to have different PKI
    unique material.
   "

The ideal case (from a Hollywood perspective), is when a PVP
exists, a Protected Video Path, where the application of the key
is done inside a part of the video card that cannot be copied.

Like, in each machine case, no need to have a private place to work,
to protect against a "debug mode" being used to copy the decrypted data.

The media streamed to you, is scrambled with the AES encryption method,
but the key exchange is only between trusted endpoints (because only they
will be able to successfully use Public Key Infrastructure to pass the
Content Decryption Method to the recipient.

Not telling the public what the method is, does not improve the security.
An expert can recognize a method, on sight. I got an example of that
when researching install.esd and reading about it on MDL posts. A guy
pops in, takes one look at the presumed key length and a few other
things, and says it is "this particular flavor of CBC". I tried my hand
at recognizing the key length, and it was nothing I'd seen before. But
there are people out there, who don't even need to run any cracking tools.
They know the method and tell you, "you're looking for a hex string
with this many digits". And in the case of install.esd , the string is
carried plaintext in the payload (they had to change that). For that one,
you just have to know where to look, and the experts hint, he left them to it,
he didn't hack it or anything. Considering the remaining task trivial,
he just... walked away. That's what a real expert looks like. It would
be pretty hard to charge him under the DMCA, because he really didn't
do anything. Nothing physical was done.

Normally, with good crypto, you reveal PKI is used, you can reveal
the "strength" of the method, and the actual security comes from the
known strength of that method (how long it would take John the Ripper
to break it, which would be centuries).

Look at the individual who figured out the protection on Default Program
selection in Windows. Microsoft protected it with a particular method,
which included encrypting a time stamp (which seems like a circular process).
The gentleman figured it all out and made a tool to mimic the process and
make valid registry entries. He did not reveal the entire method to the public,
so the "secret" was safe, but he did make software to deal with it, and
another expert reverse engineering that code, might figure it out. Depending
on what methods the reverse engineer used to obfuscate what he'd done.

For Secure Enclaves, there is nothing consistently available on computers.
Some machines have a TPM, some don't. The 10900K has a Secure Enclave (which
may have been breached or can be taken over), the 14900K has it pinned off,
and you can't play 4K BluRay movies on the 14900K because the flavor of
enclave is missing. It's because of minor details like that, that if you
rely on such hardware, you're going to need a hell of a lot of drivers loaded
and if-then-else sequence, to carry out a transaction. It's possible some
of the AMD x86 processors, have a single ARM core inside, which is a place
to do such things. Microsoft wrote the Pluton spec, and at least one AMD
laptop has a Pluton, but we don't know whether Pluton even works and
has security still.

Obviously, not all Widevine usage uses the same assurances. When my TV station
uses it, it's to ensure the content is not tampered with. So "the advertising
is delivered". The payload after that section is basically worthless. In such
a case, the PKI doesn't really seek to identify me.

In the case of your Kanopy, you do have an ID, backed by your library card identifier.
The PKI could prepare a key exchange sequence that can only be read as
plaintext, if "Mayayana" receives it. There may have been some preparation
procedure that works with this.

Someone suggested using an older version of the DLL, and seeing if the WideVine
decode works with an older DLL, which implies a change in some of the details
of the PKI for delivering the decode key. The library could be told to update
the server with a new version of the procedure. In which case, there should be
some means of telling the user they need to update something on their end.

It could even be, that the key the library has, has been "revoked" and
the latest WideVine at the client end, is refusing to acknowledge PKI signed with it.
PKI has a private key (the librarian must never give that to anyone) and a
public key component. And there could well be a revocation method for
disabling a particular library branch. Since the payment of fees is involved,
you have to assume there is a method for that.

Summary: Contact the library and ask whether anything has changed recently
         for Kanopy delivery, such as minimum browser version, minimum DLL version
         or any of those sorts of hints. I know libraries just love all this
         tech bullshit when all they ever wanted to do is the Dewey Decimal system :-)
         I know the librarian at my branch is the "printer repair person", actual
         library type activity is a lesser percentage of the time.

   Paul

Back to alt.comp.os.windows-10 | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

OT: Streaming Newyana2 <newyana@invalid.nospam> - 2025-01-05 23:21 -0500
  Re: OT: Streaming Paul <nospam@needed.invalid> - 2025-01-06 08:36 -0500
    Re: OT: Streaming Newyana2 <newyana@invalid.nospam> - 2025-01-06 10:45 -0500
      Re: OT: Streaming Paul <nospam@needed.invalid> - 2025-01-06 18:38 -0500
        Re: OT: Streaming Newyana2 <newyana@invalid.nospam> - 2025-01-06 19:33 -0500
        Re: OT: Streaming Newyana2 <newyana@invalid.nospam> - 2025-01-08 12:14 -0500
          Re: OT: Streaming Paul <nospam@needed.invalid> - 2025-01-08 13:58 -0500
          Re: OT: Streaming Paul <nospam@needed.invalid> - 2025-01-08 14:02 -0500
            Re: OT: Streaming Newyana2 <newyana@invalid.nospam> - 2025-01-08 14:51 -0500
              Re: OT: Streaming Paul <nospam@needed.invalid> - 2025-01-08 18:16 -0500
              Re: OT: Streaming Chris <ithinkiam@gmail.com> - 2025-01-09 22:27 +0000
                Re: OT: Streaming Newyana2 <newyana@invalid.nospam> - 2025-01-09 22:12 -0500
                Re: OT: Streaming Chris <ithinkiam@gmail.com> - 2025-01-10 16:23 +0000
                Re: OT: Streaming Newyana2 <newyana@invalid.nospam> - 2025-01-10 11:57 -0500
                Re: OT: Streaming Chris <ithinkiam@gmail.com> - 2025-01-10 17:12 +0000
              Re: OT: Streaming Paul <nospam@needed.invalid> - 2025-01-09 19:37 -0500
                Re: OT: Streaming Newyana2 <newyana@invalid.nospam> - 2025-01-09 22:18 -0500
                Re: OT: Streaming Paul <nospam@needed.invalid> - 2025-01-09 23:12 -0500
                Re: OT: Streaming Newyana2 <newyana@invalid.nospam> - 2025-01-10 09:17 -0500

csiph-web