Mit openssl-Verschlüsselung für Apple HTTP Live Streaming

Hat jemand hatte kein Glück, immer verschlüsselt streaming-arbeiten mit Apple HTTP Live Streaming mit openssl? Es scheint, ich bin fast da, aber mein video nicht spielen, aber ich bekomme keine Fehler in Safari entweder (wie "Video ist nicht abspielbar" oder "Sie besitzen nicht die Berechtigung, um das video zu" wenn ich den Schlüssel falsch).

#bash script:
keyFile="key.txt"
openssl rand 16 > $keyFile
hexKey=$(cat key.txt | hexdump -e '"%x"')
hexIV='0'
openssl aes-128-cbc -e -in $fileName -out $encryptedFileName -p -nosalt -iv ${hexIV}  -K ${hexKey}


#my playlist file:
#EXTM3U
#EXT-X-TARGETDURATION:000020
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-KEY:METHOD=AES-128,URI="key.txt"
#EXTINF:20, no desc
test.ts.enc
#EXT-X-ENDLIST

War ich mit diesen docs als Leitfaden:

http://tools.ietf.org/html/draft-pantos-http-live-streaming

Sie haben verschlüsselt die Datei. Warum würden Sie erwarten, dass Safari in der Lage sein zu "spielen" ciphertext?
Für mehr Kontext zu dieser Frage: developer.apple.com/iphone/library/documentation/... tools.ietf.org/html/draft-pantos-http-live-streaming
danke für die links.
Hmmm... sieht aus wie Sie hat alles richtig gemacht. Die Skillung gar nicht angeben, die Polsterung, aber das sollte nicht Schaden, Sie erst ganz am Schluss, wenn überhaupt.

InformationsquelleAutor Rob | 2010-06-09

  1. 10

    Okay, ich habe es herausgefunden... Mein hexdump-Befehl falsch war. Es sollte sein:

    hexKey=$(cat key.txt | hexdump -e '16/1 "%02x"')

    InformationsquelleAutor

  2. 7

    Beachten Sie auch die folgenden, wenn Sie mehr als 1 TS "chunk", und Sie sind auf der Suche für eine bit-genaue Ersatz für die Apple Verschlüsselung pipeline. Standardmäßig wird das Apple-tool zum verschlüsseln von updates der IV (Initialisierungsvektor) parameter für jedes der Stücke, bei denen "erhöht die Stärke der Chiffre", so die Pantos spec.

    Umsetzung bedeutet dies einfach, dass die Sequenznummer, die codiert werden müssen in hex übergeben und als -iv-parameter zu openssl:

    #!/bin/bash
keyFile="key.txt"
openssl rand 16 > $keyFile
hexKey=$(cat key.txt | hexdump -e '"%x"')
# hexIV='0'
for i in {0..number_of_TS_chunks}
do
    hexIV=`printf '%032x' $i`
    openssl aes-128-cbc -e -in $fileName -out $encryptedFileName -p -nosalt -iv ${hexIV} -K ${hexKey}
done

    InformationsquelleAutor

  3. 4

    Kombination der Informationen aus den drei genannten (die OP, die fix für den hexdump und der IV (Informationen) lieferte eine funktionierende Lösung für uns. Nämlich:

    openssl rand 16 > static.key

key_as_hex=$(cat static.key | hexdump -e '16/1 "%02x"')

for i in {0..9}; do
    init_vector=`printf '%032x' $i`
    openssl aes-128-cbc -e -in video_low_$(($i+1)).ts -out video_low_enc_$(($i+1)).ts -p -nosalt -iv $init_vector -K $key_as_hex
done

    InformationsquelleAutor

  4. 0

    Leider habe ich nicht die Werkzeuge, um mit diesem experiment. Es sieht aus wie Sie vorsichtig folgte der spec. Eine Sache, die ich tun würde, ist das schnüffeln das Netzwerk, stellen Sie sicher, das key.txt - Datei wird immer heruntergeladen, um Safari. Ich würde auch versuchen explizit die Kommissionierung der IV über die IV-Attribut des EXT-X-TASTE-tag, z.B. 

    #EXT-X-KEY:METHOD=AES-128,URI="key.txt",IV=0x00000000000000000000000000000000
    Ja, ich habe versucht, die IV ausdrücklich, aber ich bekam das gleiche Ergebnis. Ich kann bestätigen, dass die key.txt wird geholt, und ich habe auch echte Fehler aus dem video-element, indem Sie einige bytes in key.txt ("Sie sind nicht autorisiert, diese Datei zu öffnen").

    InformationsquelleAutor

Schreibe einen Kommentar