[FFmpeg-devel] [PATCH] avformat/utils: Don't parse encrypted packets.

[Jacob Trimble]

On Wed, Aug 29, 2018 at 4:37 PM Michael Niedermayer
<michael at niedermayer.cc> wrote:
>
> On Wed, Aug 29, 2018 at 03:30:39PM -0700, Jacob Trimble wrote:
> > On Wed, Aug 29, 2018 at 3:20 PM James Almer <jamrial at gmail.com> wrote:
> > >
> > > On 8/29/2018 7:07 PM, Michael Niedermayer wrote:
> > > > On Tue, Aug 28, 2018 at 10:58:43AM -0700, Jacob Trimble wrote:
> > > >> If a packet is full-sample encrypted, then packet data can't be parsed
> > > >> without decrypting it.  So this skips the packet parsing for those
> > > >> packets.  If the packet has sub-sample encryption, it is assumed that
> > > >> the headers are in the clear and the parser will only need that info.
> > > >>
> > > >> Signed-off-by: Jacob Trimble <modmaker at google.com>
> > > >> ---
> > > >>  libavformat/utils.c | 21 ++++++++++++++++++++-
> > > >>  1 file changed, 20 insertions(+), 1 deletion(-)
> > > >
> > > > Hmm, please correct me if iam wrong but IIUC
> > > > 1. The demuxer has set need_parsing, indicating that it _requires_ a parser
> >
> > There isn't a flag for "try parsing and ignore errors".  So my choice
> > (from an app) is to either require parsing or don't do parsing at all
> > (which can result in incorrect timestamps).
> >
> > > > 2. Parsing cannot be done before decrypting
> > > >
> > > > If all this and the set values are correct, logically, the fix would be
> > > > to decrypt the packet before the parser not to skip the parser.
> >
>
> > There are cases where the packet can't be decrypted before getting to
> > this point.
>
> Can you elaborate on these cases ? I dont think its obvious what these
> cases are, at least its not obvious to me what exactly you are thinking
> of here. And i think its not helpfull if i guess what you mean and then
> argue/comment on that because maybe you meant something entirely different ...

Fair warning, I am working on a DRM solution.  I know many of you may
not agree with DRM, but it is a requirement imposed by content
creators.  FFmpeg doesn't have to support DRM itself, but you should
still consider its usages.

At that point in the code, the packet can only be decrypted by the
demuxer.  For example, in MP4 this can be done by passing the
-decryption_key parameter.  But that requires that FFmpeg handle the
decryption.  In my case, we are passing the packet to a CDM (content
decryption module) to handle the decryption and that might be a
hardware-secure decryptor.  In most DRM situations, we can't get the
raw key at all, all we can do is say "decrypt this block of memory".
So the only way to have the packet decrypted before this point would
be to introduce a callback to the app to decrypt the packet.

This is why I have been working on exposing the encryption info.  My
app (or more correctly the CDM) needs to handle the decryption and we
can't just give the key to libavformat so the demuxer can decrypt the
packet.

>
>
> > This point is between the demuxer creating the packet and
> > giving to the app.  So the only way to decrypt the frame (as of now)
> > is for the demuxer to do this.  There is no way for the app to handle
> > the decryption before this point.
> >
>
> > From the app's perspective, I would expect the packet to remain
> > encrypted for as long as possible.
>
> why ?

Because the point of encryption is to ensure that nefarious parties
don't get access to the data.  Even though the packet data is stored
in memory, it could still be retrieved by a malicious user.  Usually
for protected media, the frames are only decrypted when needed and in
some cases are decrypted in a secure CPU and isn't even accessible to
the app.  There are platforms that support what is called "direct
render" where the app gives the platform the encrypted packets and a
discrete hardware unit will decrypt the packet, decode it, and render
it directly; this happens on some smart TVs.  There are also cases
which require decrypt-decode where we give the platform an encrypted
packet and it will decrypt and decode the packet, ensuring the
decrypted packet data is never in main memory.  So there are cases
where we can't even see the encoded packet and decoding is handled by
the platform.

>
>
> > My app will store the packet for a
> > while, then decrypt it right before passing it to the decoder and
> > drawing the frame.  So requiring the packet to be decrypted at this
> > point is not ideal.
> >
> > >
> > > And if that can't be done, then the demuxer could perhaps set
> > > st->need_parsing to 0 and skip parsing altogether?
> >
> > I would want to still have parsing if possible. For example, a lot of
> > content has a clear lead where the first few seconds are clear.  So
> > they could be used to adjust the starting timestamps (and whatever
> > parsing needs) and the encrypted content later can be deduced based on
> > that.
> >
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Modern terrorism, a quick summary: Need oil, start war with country that
> has oil, kill hundread thousand in war. Let country fall into chaos,
> be surprised about raise of fundamantalists. Drop more bombs, kill more
> people, be surprised about them taking revenge and drop even more bombs
> and strip your own citizens of their rights and freedoms. to be continued
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel