[FFmpeg-devel] Would a crypto file be acceptable?

[Michael Niedermayer]

Hi

On Tue, Dec 27, 2022 at 11:46:38PM +0100, Mark Gaiser wrote:
> On Tue, Dec 27, 2022 at 10:40 PM Michael Niedermayer <michael at niedermayer.cc>
> wrote:
> 
> > On Wed, Dec 21, 2022 at 04:44:59PM +0100, Mark Gaiser wrote:
> > > Hi,
> > >
> > > The ffmpeg crypto protocol handler [1] allows one to play encrypted
> > media.
> > >
> > > The great thing here is that it allows playback of any media format that
> > > ffmpeg supports!
> > > Have a container format like mkv as an encrypted blob, no problem for the
> > > crypto plugin!
> > >
> > > I'm explicitly mentioning mkv (though there's many more) here because
> > that
> > > isn't possible in HLS/MPD. While those streaming formats handle
> > encryption
> > > too, they are very limited in terms of supported codecs and containers.
> > >
> > > Playback of encrypted data works like this:
> > > ffplay encrypted_file -decryption_key $AES_KEY -decryption_iv $AES_IV
> > >
> > > While this works just fine, it's limited in use because the cryptography
> > > details have to be passed on the command line. Applications that might
> > well
> > > support much of ffmpeg functionality can't easily hook into the crypto
> > > functionality. Take KODI for example, it allows playback of many of the
> > > formats ffmpeg supports but anything with crypto just isn't possible. In
> > > fact, anything that requires custom command line arguments isn't
> > possible.
> > > [2]
> > >
> > > My idea is to make a new file format that would be implemented and
> > specced
> > > within [1]. My proposed format would be:
> > >
> > > ---
> > > CRYPTO-VERSION:1
> > > CRYPTO-KEY:URI:.....
> > > CRYPTO-IV:URI:.....
> > > encrypted_file
> > > ---
> > >
> > > The URI would be a format type identifier where you can choose between
> > URI
> > > (to pass a URL to a key blob), BASE64URL (key encoded as base64url) or
> > HEX.
> > >
> > > The above proposed format should be stored in a file with ".crypto" as
> > > extension. The crypto plugin [1] would then handle that file. The
> > arguments
> > > would be filled based on the "properties" in the file. So for example the
> > > `decryption_key` argument would be populated with the blob returned from
> > > CRYPTO-KEY:URI:<url>. Or with one of the other types.
> > >
> > > The "encrypted_file" would just be passed through ffmpeg's
> > > "ffurl_open_whitelist" like the crypto plugin currently does. Meaning
> > that
> > > the file could be anything ffmpeg supports.
> > >
> > > Playing encrypted media would be as simple as:
> > > ffplay file.crypto
> > >
> > > With this mail I'm looking for a confirmation if the above concept would
> > be
> > > allowed as a patch for ffmpeg? And if not, how can I achieve the same
> > > results in a way that would be acceptable? [3]
> >
> > I understand what you are trying to do but not what the use case for this
> > is ?
> >
> > Encryption has the goal to let one party access data and not another.
> > Who are these 2 parties and where does the encrypted media come from?
> >
> > You mention decentralization, I see nothing related to decentralization
> > in this. Or do you suggest that, everytime someone succeeds decrypting a
> > file its key would be automatically be published in a decentralized
> > public database, so teh next user can safe herself teh troubble from
> > finding the key?
> >
> > If not iam confused why you store keys plainly in files, because this is
> > not very secure, so maybe the goal never is to keep the key safe ?
> > Or it doesnt matter that someone with physical access in the future would
> > also possibly have access to the key. Again you didnt explain the use case
> > and who the intended user and adversery is ...
> >
> 
> How do you privately want to share a video with someone else? Say A (you)
> and B (the other)
> Currently you probably use one of the following options or something
> similar:
> - A uploads it you youtube as unlisted and share that link with B
> - A adds it to google photos/drive and share that link B
> - A adds it to cloud storage and shares that link with B
> etc..

I would encrypt it with gpg with Bs public key then send it to B by a
secure way, the way depends on what i know of from B
* physically give him a usb stick or send that by snail mail
* upload it somewhere through tor browser, B then could download it too
  using tor browser.
  
If the material is of value to some state actor (hello CIA/NSA/FSB/Mosad)
then additional precautions are probably a good idea. (seperate computers, use of
internet connections not associated with either A or B and so forth) ive not yet
had the need to do this so i have not really thought about it

I somewhat avoid all these "paid by giving your data away to advertisers"
companies even for things 100% intended to be public. At least when its
easy to avoid them.
But i dont want to slide too far off topic here, just replying ...


> 
> The common denominator in all those examples is where and how it's stored.
> The data is stored in supposedly private storage.
> You trust that storage to be private and trust the link to be between you
> and the intended target.tended party.
> 
> In this setup your video, that is not intended to be public, is shared.
> This works and is the "web2" way of doing things.
> 
> Now enter web3.
> Storage now is publicly available to everyone in the distributed world of
> web3.
> I know, or can know, what you host and vice versa.
> If I were to follow the above sharing model the video - which you had
> intended to be private - is now very publicly available.
> 
> That's what I'm trying to fix (and am nearly there)!
> How I'm fixing this is as follows (this is a bit outside the scope of the
> initial question but its context might help you frame the question
> properly):
> - A has a public and private key pair. So does B.
> - A knows the public key of B and vice versa.
> - Both A and B have data which is encrypted on their end with keys
> unrelated to their own public and private keys
> - (this is the important bit!) Wrapped around their private data is a
> "metadata" file where their own private key serves to encrypt/decrypt that
> file
> - A can now re-encrypt the metadata to the public key of B and share that
> metadata with B.
> - B can now play the file backed by the metadata that A intended to share.
> - The result being file sharing where you can access it if:
>  -- you have access to the distributed storage
>  -- you have the keys to decrypt the metadata
> ---- This all works already, right here and now on my pc! ----
> 
> The tricky part here is for anyone using this scheme to play this file.
> Right now i'm doing this with a command line like:
> ffplay crypto://encrypted_file -decryption_key $AES_KEY -decryption_iv
> $AES_IV
> 
> For brevity's sake, consider the "metadata" file named above to be the
> _encrypted_ version of the ".crypto" file i'm proposing.
> For B to play it, B must decrypt that file (now it's like the proposed
> .crypto file) and can now happily play this file in ffmpeg-backed players
> that allow the proposed crypto file.

iam not against the idea in principle. 
Some maybe technical detail here is that the unencrypted  .crypto file
should never be stored on disk. Because its leaking the AES key and anyone
with physical access to the machine later could potentially obtain that key.
A better solution may be to only store the .crypto file encrypted with gpg
so when libavformat accesses it, gpg (agent) would look in it and check if 
it has a matching private key. if so it would decrypt it in accordance to
its configuration. 
From the user side the user could get a popup asking if the file should be
decrypted and if needed for the users password protecting the private key.
This is the same you would get today when you use gpg and have it configured
accordingly.
The main goal here is to never have the decrypted .crypto file on disk, just
to pass the encrypted one through gpg and use that to then decrypt teh main
multimedia material.

of course something else than gpg can be used but iam thinking that it
wouldnt hurt if more people had gpg setup properly and knew how to use
it in this world of mass surveliance. So having gpg as an option could be
interresting.

About URLs in the .crypto file
full URLs always pose some risk for privacy. There is some risk for
tracking here if its a remote destination.
This is something that should probably be thought through carefully.

example: if one use case is to have the crypto file in the same place
as the multimedia. Example:

someplace/zksnark-lecture5.mp3.encrypted
someplace/zksnark-lecture5.mp3.crypto.gpg

then maybe that could be handled different from a case like
zksnark-lecture5.mp3.crypto.gpg
    Which then points to https://clicktracker-redirector.evil/someplace/zksnark-lecture5.mp3.encrypted

Because teh first can be done more privately then if a different remote
location is needed and allowed
    
thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20221228/56ca8cc5/attachment.sig>