La diffusion HTTP en direct avec le chiffrement

Je suis en train d'essayer de comprendre comment le HTTP Live Streaming protocol que Apple prend en charge sur leurs appareils iOS ainsi que sur Safari protège la clé qui déverrouille le contenu.

La façon dont je le comprends, l' .m3u8 fichier contenant le tout ensemble et les références de contenu (en MPEG2 TS, conteneurs, AES 128 chiffré) et la clé pour le fichier TS.

Comme dans cet exemple:

   #EXTM3U
   #EXT-X-MEDIA-SEQUENCE:7794
   #EXT-X-TARGETDURATION:15

   #EXT-X-KEY:METHOD=AES-128,URI="https://priv.example.com/key.php?r=52"

   #EXTINF:15,
   http://media.example.com/fileSequence52-1.ts
   #EXTINF:15,
   http://media.example.com/fileSequence52-2.ts
   #EXTINF:15,
   http://media.example.com/fileSequence52-3.ts

   #EXT-X-KEY:METHOD=AES-128,URI="https://priv.example.com/key.php?r=53"

   #EXTINF:15,
   http://media.example.com/fileSequence53-1.ts

En supposant un navigateur de base de la lecture où l' <video> élément est nourri d'un fichier m3u8 dans l'attribut "src". Dans ce cas, même si la clé est livrée via https, comment puis-je m'assurer que l'utilisateur ne se contente pas de saisir l'URL https dans son navigateur et enregistre la clé de son disque dur? La façon dont je comprends le mécanisme, la clé de téléchargement est effectué par le <video> balise, car elle joue les m3u8 source à l'aide du navigateur https pile-comment est la légitime client à l'intérieur du navigateur distingue de l'utilisateur, juste en tapant dans la barre d'adresse? Ce doit être vraiment évident, mais je ne vois pas...

Tout le meilleur,

dansch

Excellente question, d'autant plus que dans la plupart des cas, HTTPS juste se révèle être un serveur de confiance basée sur la mise en œuvre plutôt que sur le client de confiance. Sur le Web, c'est compréhensible, utile, puisque les données de l'utilisateur est transmis aux serveurs plutôt que l'inverse.De sorte que les utilisateurs doivent être assurés qu'ils envoient leurs données à un site de confiance. Toutefois, dans le cas de la vidéo, le contenu est assez bien compte tenu de l'écart, et il y a un plus grand besoin pour le serveur à faire confiance à l'utilisateur que vice-versa. Cependant, côté client auth n'est pas viable depuis des milliers d'utilisateurs à être servi. En fin de compte, je suis juste dans un cornichon

OriginalL'auteur dansch | 2010-12-20

3

comment puis-je m'assurer que l'utilisateur ne se contente pas de saisir l'URL https dans son
navigateur et enregistre la clé de son disque dur?

Vous pouvez avoir un client SSL certificat dans l'application, et ainsi d'authentifier l'app" pour la lecture du contenu. Vous devez alors éviter les fuites de votre contenu avec d'autres appareils de votre application.

Mais cela signifierait que vous auriez besoin de cacher quelque sorte votre ssl-clé/phrase à l'intérieur de l'app. Et il y a malheureusement aussi des problèmes pour obtenir le lecteur vidéo sur iOS pour utiliser le protocole ssl, l'authentification par clé...

OriginalL'auteur
2

D'Apple de mise en œuvre de la diffusion HTTP en direct ne prend pas en charge les DRM.

Voir FAQ numéro 16 sur http://developer.apple.com/library/ios/#documentation/networkinginternet/conceptual/streamingmediaguide/FrequentlyAskedQuestions/FrequentlyAskedQuestions.html

La question de la demande spécifiquement sur le chiffrement, et la FAQ #16 dit: "les médias peuvent être cryptées, et la clé d'accès peut être limité par l'nécessitant une authentification lorsque le client récupère la clé de votre serveur HTTPS." Cette réponse n'est pas la question complètement.
Quel est donc le point de chiffré segments?!

OriginalL'auteur
2

La réponse n'est pas évidente à tous. Vous êtes essentiellement nécessaire d'inventer votre propre clé de livraison si vous voulez qu'il soit sécurisé. Une option est de définir un cookie pour les utilisateurs autorisés, et à vérifier le cookie dans le serveur de clés. Cela permet de garder quelqu'un en mesure de simplement utiliser la touche url de contourner la sécurité de votre.

Garder à l'esprit qu'il prend toujours uniquement une légitime client de fuite de la clé de votre sécurité afin d'être invalidée.

Par la suite, Apple a introduit une clé sécurisée mécanisme de livraison pour plusieurs des derniers appareils iOS. Ils l'appellent le FairPlay en Streaming. Vous pouvez lire à ce sujet sur le site web d'Apple: developer.apple.com/streaming/fps

OriginalL'auteur
2

Le meilleur moyen est d'utiliser Apple HLS de chiffrement pris en charge.HLS 128 bits de cryptage AES et le client, le joueur a besoin pour décoder le flux de données.

OriginalL'auteur
2

Certains des indices intéressants peuvent être trouvés ici: https://developer.apple.com/library/content/documentation/AudioVideo/Conceptual/AirPlayGuide/EncryptionandAuthentication/EncryptionandAuthentication.html

Cela nécessitera un travail personnalisé dans iOS, mais aussi sur Android et web joueurs.
- Servir de clés à partir d'un protégé HTTPS royaume. Avant que la lecture commence, votre application peut utiliser NSURLConnection pour authentifier lui-même, de fournir des informations d'identification qui sont cachées.
- L'utilisation des cookies sur HTTPS. Votre application peut établir une connexion à un serveur HTTPS et authentifier l'application dans une application défini. Votre serveur peut alors émettre un cookie qui s'applique à la clé Url. Vous devez définir l'expiration du cookie longtemps après la lecture. Le serveur doit alors exiger la présence d'un cookie de session valide à l'avenir des demandes pour les clés.
  Pour un maximum de fiabilité, si la date d'expiration est dans un avenir proche, le serveur doit mettre à jour la date d'expiration du cookie dans sa réponse à de futures demandes.
- Spécifier les clés dans la .m3u8 des fichiers à l'aide d'une application définie schéma d'URL. L'application doit s'inscrire personnalisé NSURLProtocol traiter les demandes de ces Url. Le joueur puis appelle de nouveau dans votre application lorsqu'il doit charger une clé d'URL; votre application peut alors obtenir la clé à l'aide d'un coté sécurisé canal et peut fournir au joueur.
Si vous êtes seulement de ciblage iOS, alors vous devriez utiliser Apple Fairplay DRM, qui s'occupe de l'authentification des clés.

OriginalL'auteur
1

comment est la légitime client à l'intérieur du navigateur distingue de l'utilisateur, juste en tapant dans la barre d'adresse?

Distinction intéressante, la suggestion est le navigateur de l'utilisateur est légitime lors de la lecture de la vidéo dans la page web, et illégitime en cas d'accès via la barre d'adresse.

Mais il n'y a pas de réelle distinction il y a, je ne pense pas que vous manque quoi que ce soit.

Comment voulez-vous donner les droits à un navigateur et non pas un utilisateur? Ne peut pas d'un utilisateur, il suffit d'écrire leur propre navigateur?

Je sais, il semble peu probable qu'un utilisateur puisse écrire un navigateur, mais ces types de discussions sont toujours à propos de l'improbable des scénarios de toute façon. Un peu de chances que l'utilisateur pourrait trouver un moyen pour afficher les m3u8 en tant que texte brut, ils peuvent télécharger les touches directement, ils peuvent utiliser ces clés pour décrypter et de l'éventuelle pièce de l'ensemble des segments vidéo.

Ou, de quelque chose qui est beaucoup plus probable - utilisation de logiciel d'enregistrement d'écran pour copier les vidéos qu'ils peuvent jouer dans le navigateur.

À mon avis, si un utilisateur est autorisé à lire la vidéo, ils peuvent, malheureusement, également copier la vidéo car il n'y a aucun moyen pour empêcher l'affichage de la vidéo est redirigé vers quelque chose qui n'est plus crypté - au moins dans l'environnement d'un ordinateur de bureau qui est la lecture d'une vidéo dans un navigateur.

De toute façon, ma compréhension est que vous pouvez protéger les touches en demandant l'autorisation à la remise des clés, mais si l'utilisateur dispose de l'autorisation, puis - eh bien, ils peuvent obtenir les clés.

OriginalL'auteur
1

Jetez un oeil ici
https://tools.ietf.org/html/draft-pantos-http-live-streaming-13#section-6.3.6

la liste de lecture est nécessaire de spécifier une clé pour chaque segment. ainsi, un joueur sera en mesure d'identifier une clé pour déchiffrer un segment.

Les navigateurs ne prennent pas en charge les DRM de la boîte. HTML5 préciser que cela peut être fait via EME (Encrypted media extensions) celui qui pas mis en œuvre un guichet automatique.

afin que vos options sont les suivantes:
1. utilisation de flash et de récupérer les clés par l'intermédiaire de votre propre algorithme
2. écrire vos propres plugins(extension)
3. être grand comme Netflix et d'accord avec le navigateur
  les vendeurs à l'appui de votre DRM, aka la protection du contenu et de la clé
  distribution.
OriginalL'auteur

Vous devez vous connecter pour publier un commentaire.