secure RTMPE protocol. Is it really secure???

any ANONYMOUS forum user · #1 06-02-2009, 07:18 AM

RTMPE
-----
RTMPE is an extension to RTMP to include encryption of content. Adobe uses industry standard crypto primitives for RTMPE although it calls this protocol "proprietary".

This document is a clean-room specification of the RTMP "Encryption" scheme called RTMPE. It contains industry-standard crypto primitives, ARC4, HMACSHA256 and Diffie-Hellman. The specification was created by reviewing the source code of rtmpdump v1.6.

Academic and other discussion is invited. Distribution of this document is unlimited and encouraged. Implementations even more so.

More info: http://lkcl.net/rtmp
Revisions: http://rab.zapto.org/RTMPE/
RTMPE recording: stream-recorder.com: RTMPE stream recording/downloading/capturing/ripping/saving

Conventions
-----------

data[x:y] means "bytes x through y, inclusive" - like in python
x+y on bytes means "append the two byte streams, consecutively"
data[x] means "the byte offset by x" - like in python.
/* ... */ means comments
bigendian32(x) means create 4 bytes in big-endian order, from a 32-bit integer.

Constants
---------

Code:

RTMP_SIG_SIZE = 1536
SHA256DL = 32 /* SHA 256-byte Digest Length */

RandomCrud = {
    0xf0, 0xee, 0xc2, 0x4a,
    0x80, 0x68, 0xbe, 0xe8, 0x2e, 0x00, 0xd0, 0xd1,
    0x02, 0x9e, 0x7e, 0x57, 0x6e, 0xec, 0x5d, 0x2d,
    0x29, 0x80, 0x6f, 0xab, 0x93, 0xb8, 0xe6, 0x36,
    0xcf, 0xeb, 0x31, 0xae
}

SWFVerifySig = { 0x1, 0x1 }

/* data in quotes does not include quotes as part of data */
GenuineFMSKey = "Genuine Adobe Flash Media Server 001" 
GenuineFPKey = "Genuine Adobe Flash Player 001" 

GenuineFMSKeyCrud = GenuineFMSKey + RandomCrud
GenuineFPKeyCrud = GenuineFPKey + RandomCrud

GetServerDHOffset
-----------------

The purpose of this function is to calculate the offset of the Server's Diffie-Hellmann key.

Its input is 4 consecutive bytes.

Code:

    offset = byte[0] + byte[1] + byte[2] + byte[3]
    offset = modulo(offset,632)
    offset = offset + 8

For sanity, the offset should be no bigger than (767-128)

GetServerGenuineFMSKeyDigestOffset
----------------------------------

The purpose of this function is to calculate the offset of the Server's Digest.

Input data is 4 consecutive bytes.

Code:

offset = byte[0] + byte[1] + byte[2] + byte[3]
    offset = modulo(offset,728)
    offset = offset + 776

For sanity, the offset should be no bigger than (1535-32)

GetClientDHOffset
-----------------

The purpose of this function is to calculate the offset of the client's Diffie-Hellmann key.

Input data is 4 consecutive bytes.

Code:

offset = byte[0] + byte[1] + byte[2] + byte[3]
    offset = modulo(offset,632)
    offset = offset + 772

For sanity, the offset should be no bigger than (RTMP_SIG_SIZE-128-4)

GetClientGenuineFPKeyDigestOffset
---------------------------------

The purpose of this function is to calculate the offset of the client's Digest.

Input data is 4 consecutive bytes.

Code:

offset = byte[0] + byte[1] + byte[2] + byte[3]
    offset = modulo(offset,728)
    offset = offset + 12

For sanity, the offset should be no bigger than (771-32)

Packet Format
-------------

The packets consist of a one byte command followed by a 1536 byte message

Code:

    Bytes    : Description
    -------    -----------
    0          Command
    1:1536     message of RTMP_SIG_SIZE bytes

Client First Exchange
---------------------

This is the first packet to be generated.
clientsig and clientsig2 are RTMP_SIG_SIZE bytes.
serversig and serversig2 are RTMP_SIG_SIZE bytes.

Note: Encryption is only supported on versions at least 9.0.115.0

Note: The 0x08 command-byte is not yet known. It is understood to involve further obfuscation of the Client and Server Digests,
and is understood to be implemented in Flash 10.

Command byte:

Code:

    0x06 if encrypted
    0x08 if further encrypted (undocumented)
    0x03 if unencrypted

Message:

Code:

    0:3        32-bit system time, network byte ordered (htonl)
    4:7        Client Version.  e.g. 0x09 0x0 0x7c 0x2 is 9.0.124.2
    8:11       Obfuscated pointer to "Genuine FP" key 
    12:1531    Random Data, 128-bit Diffie-Hellmann key and "Genuine FP" key.
    1532:1535  Obfuscated pointer to 128-bit Diffie-Hellmann key

Calculate location of Diffie Hellmann Public Key and create it:

Code:

dhpkl = GetClientDHoffset(clientsig[1532:1535])
    DHPrivateKeyC, DHPublicKeyC = DHKeyGenerate(128) /* 128-bit */
    clientsig[dhpkl:dhpkl+127] = DHPublicKeyC

Calculate location of Client Digest and create it:

Code:

/* Note: the SHA digest message is calculated from the bytes of
      the message, excluding the 32-bytes where the digest itself goes.
    */

    cdl = GetClientGenuineFPKeyDigestOffset(clientsig[8:11])
    msg = clientsig[0:cdl-1] + clientsig[cdl+SHA256DL:RTMP_SIG_SIZE-1]
    clientsig[cdl:cdl+SHA256DL-1] = HMACsha256(msg, GenuineFPKey)

First Exchange:

Code:

Send all 1537 bytes (command + clientsig) to the server;
    Read 1537 bytes (command + serversig) from the server.

Note that the exact circumstances under which "Message Format 1"
or "Message Format 2" are utilised is unknown. It is therefore necessary for clients to utilise the SHA verification to determine which of the two message formats is being received (!)

Command byte:

Code:

    0x06 if encrypted - same as client request
    0x03 if unencrypted - same as client request

Message Format 1:

Code:

    0:3        32-bit system time, network byte ordered (htonl)
    4:7        Server Version.  e.g. 0x09 0x0 0x7c 0x2 is 9.0.124.2
    8:11       Obfuscated pointer to "Genuine FMS" key 
    12:1531    Random Data, 128-bit Diffie-Hellmann key and "Genuine FMS" key.
    1532:1535  Obfuscated pointer to 128-bit Diffie-Hellmann key

Calculate location of Server Digest and compare it:

Code:

    sdl = GetClientGenuineFMSKeyDigestOffset(serversig[8:11])
    msg = serversig[0:sdl-1] + serversig[sdl+SHA256DL:RTMP_SIG_SIZE-1]
    Compare(serversig[sdl:sdl+SHA256DL-1], HMACsha256(msg, GenuineFMSKey))

Calculate location of Server Diffie Hellmann Public Key and get it:

Code:

   dhpkl = GetClientDHoffset(serversig[1532:1535])
    DHPublicKeyS = serversig[dhpkl:dhpkl+127]

Message Format 2:

Code:

    0:3        32-bit system time, network byte ordered (htonl)
    4:7        Server Version.  e.g. 0x09 0x0 0x7c 0x2 is 9.0.124.2
    8:767      Random Data and 128-bit Diffie-Hellmann key 
    768:771    Obfuscated pointer to 128-bit Diffie-Hellmann key 
    772:775    Obfuscated pointer to "Genuine FMS" key 
    776:1535   Random Data and "Genuine FMS" key.

Calculate location of Server Digest and compare it:

Code:

    sdl = GetServerGenuineFMSKeyDigestOffset(serversig[772:775])
    msg = serversig[0:sdl-1] + serversig[sdl+SHA256DL:RTMP_SIG_SIZE-1]
    Compare(serversig[sdl:sdl+SHA256DL-1], HMACsha256(msg, GenuineFMSKey))

Calculate location of Server Diffie Hellmann Public Key and get it:

Code:

    dhpkl = GetServerDHoffset(serversig[768:771])
    DHPublicKeyS = serversig[dhpkl:dhpkl+127]

Compute Diffie-Hellmann Shared Secret:

The key is only needed if encryption was negotiated.

Code:

    DHSharedSecret = DH(DHPrivateKeyC, DHPublicKeyS)

any ANONYMOUS forum user · #2 06-02-2009, 07:20 AM

Compute SWFVerification token:

If a SWFHash is used, a SWFVerification response will need to be calculated, and returned on-demand to a "ping" request.
SWFsize is the size of the SWF file.

Note: It is assumed that the reader is familiar enough with RTMP to know what a "ping" is. Where the ordinary ping type is 0x0006, and the pong response is of type 0x0007, an SWF verification ping is of type 0x001a and the SWF verification pong is of type 0x001b.
Packet sizes of type 0x001b are 44 bytes: 2 bytes for the type itself and 42 bytes for the SWF verification response.

Code:

    swfvk = serversig[RTMP_SIG_SIZE-SHA256DL:RTMP_SIG_SIZE-1]
    SWFDigest = SWFVerifySig + bigendian32(SWFsize) + bigendian32(SWFsize) + 
                HMACsha256(SWFHash, swfvk)

Initialise ARC4 Send / Receive Keys:

The ARC4 keys KeyIn and KeyOut are used to decrypt and encrypt incoming and outgoing data, respectively.

Code:

    KeyIn  = ARC4Key(HMACsha256(DHPublicKeyS, DHSharedSecret)[0:15])
    KeyOut = ARC4Key(HMACsha256(DHPublicKeyC, DHSharedSecret)[0:15])

Explanation in words:

To calculate the ARC4 key for the data received by the client (KeyIn), take the Server's initial 128-bit Diffie-Hellmann Secret (from which the DH Shared Secret was calculated) and calculate the HMACsha256 digest of that server's secret, using the DH Shared Secret as the HMACsha256 key.

To calculate the ARC4 key for the data sent by the client (KeyOut), take the Client's initial 128-bit Diffie-Hellmann Secret (from which the DH Shared Secret was calculated) and calculate the HMACsha256 digest of the client's secret, using the DH Shared Secret as the HMACsha256 key.

Read Second Exchange:

Note: the second response appears to be read directly after the first response, rather than the normal client-server arrangement of interleaving client writes with server sends.

Read 1536 bytes (serversig2) from the server.

Validate Second Response:

If Flash Player version 9 Hand-shaking is not being utilised, then the server will have simply sent a copy of the client's own previous packet back to it. Otherwise, the client verifies the response (the first four bytes of which are likely to be zero if there was a validation error), as follows:

Code:

    digest = HMACsha256(DHPublicKeyC, GenuineFMSKeyCrud)
    signature = HMACsha256(serversig2[0:RTMP_SIG_SIZE-SHA256DL-1], digest)
    Compare(signature, serversig2[RTMP_SIG_SIZE-SHA256DL:RTMP_SIG_SIZE-1])

Generate Second Response:

Code:

    clientsig2[0:RTMP_SIG_SIZE] = Random Data
    digest = HMACsha256(DHPublicKeyS, GenuineFPKeyCrud)
    signature = HMACsha256(clientsig2[0:RTMP_SIG_SIZE-SHA256DL-1], digest)

Send Second Response:

Write 1536 bytes (clientsig2) to server.

Update ARC4 Keys:

If encryption is enabled, then ONLY after the handshaking is completed is the ARC4 keys applied to future communication.

any ANONYMOUS forum user · #3 06-02-2009, 07:21 AM

Analysis
--------

The creation of the ARC4 encryption keys are created ultimately from nothing more than a Diffie-Hellmann key exchange, excluding constants and publicly-transferred information that is passed through hashing algorithms. There is no input into the algorithm from a secret key, password or passphrase. The same effect as this algorithm could therefore be achieved with a well-known industry standard algorithm such as SSL.

The "verification" process involves nothing more than publicly-obtainable information (the 32-byte SWFHash and the SWF size) and publicly-exchanged data (the last 32 bytes of the first server response).

According to readme_rtmpdump1.6.txt:

Download the swf player you want to use for SWFVerification, unzip it using

Code:

$ flasm -x file.swf

It will show the decompressed filesize, use it for --swfsize

Now generate the hash

Code:

$ openssl sha -sha256 -hmac "Genuine Adobe Flash Player001" file.swf

and use the --swfhash "01234..." option to pass it. e.g.

Code:

$ ./rtmpdump --swfhash "123456..." --swfsize 987...

In other words, the "verification" algorithm basically links the SWF file with the content that is being accessed through it. The SWF file unfortunately has to be made publicly available via web sites, and so
can be easily obtained.

Thus, the only "security" is given by linking the last 32 bytes of the first server response in to the "verification" algorithm. Unfortunately, this information was also generated with no passwords or secret keys, and is transmitted in-the-clear.

Overall, then, the Adobe RTMPE algorithm provides end-to-end secrecy in exactly the same way that SSL provides end-to-end secrecy, but provides no security and uses no authentication of any kind.

any ANONYMOUS forum user · #4 06-02-2009, 08:01 AM

RTMPE is definitely not a "Copyright Protection" mechanism.

An analysis of RTMPE (see "Analysis" section) shows that RTMPE does nothing more than what SSL already does (provide end-to-end secrecy, except without the protection against man-in-the-middle attacks - RSALabs on DH, para 5) and simply mathematically links a publicly-downloadable and publicly-obtainable SWF file to the connection.

Bottom line: All the information required to obtain the content is publicly available. There is no "security".

If the information isn't publicly available (such as the SWF file to be executed in the web browser) then the content cannot be obtained, either.

Adobe claims that SWF verification is somehow "secure". Anyone reading this who has bought into Adobe Technology on the basis of "security" or "protection" is advised to initiate legal action against Adobe,seeking compensation and damages for deceiving them about the level of "protection" of their Copyright material.

From Adobe's Web Site:

Quote:

Originally Posted by adobe.com

'(swf verification) ensures that only your SWF or AIR files can connect to your application or content on Flash Media Server'.

This is false. The correct interpretation is:

"if anyone can obtain the publicly-available SWF or AIR file (or a hash of it, and knows the SWF or AIR file's size) they can also connect to your application or content".

Are there any 'encryption' keys in RTMPE?

No, there are no encryption keys in RTMPE. There are however three magic constants which are used as input. And, remember, also, the publicly accessible SWF file - the one which you put on the web site to view the content - is used as input to the algorithm as well (or, at least, its hash and its size).

So if you want to get genuinely stupid, and consider the sentence "Genuine Adobe Flash Player 001" to be a quotes key quotes, then by that definition, so is the publicly accessible SWF file also a quotes encryption key quotes.

This raises some hilarious implications:

How can you claim that a key is secret, yet make it publicly available on the internet? If you want to keep this "key" secret, surely you should go after all web browser distributors, and everyone who has HTTP cacheing technology, DEMANDING that they "protect" - remove - SWF files from caches.

This latter is quite easily achieved. You just block *.swf files. Actually, all Free Software HTTP Proxy and Web Browser projects should not risk being subjected to DMCA takedown notices and should block all swf files, just to be on the safe side.

... after all, it's not like they can analyse the content being streamed by the SWF file, because that would require either reverse-engineering
the SWF file on-the-fly in order to find out if it uses RTMPE, or setting up a complex system of analysing network traffic (again, which would
be, like, illegal, like, cos you'd have to, like actually identify RTMPE and would need to, y'know, know the algorithm?).

Presumably, though, on detection of RTMPE, then, well, by that time, it's too late: the browser will have already received and be executing the SWF file. So, presumably, right, like that joke computing language which had a "GO FROM" statement and an "IF THEN ELSE UNLESS" construct, you'd have to somehow undo the past, and, presumably, if that wasn't possible, try to hide the fact that you were unable to predict the future, by deleting incriminating evidence from the user's machine and then crashing it.

any ANONYMOUS forum user · #5 06-18-2009, 11:20 PM

There are several problems with adobe's approach:

there is no "encryption key" in RTMPE.
there is, however, a magic constant (actually, three). the first is "Genuine Adobe Flash Player 001"; the second is "Genuine Adobe Flash Media Server 001" and the third is some unpronounceable random crud which you can get by looking at the first post
there is no "protection" in RTMPE.
RTMPE is an algorithm that uses industry-standard crypto primitives, magic constants and publicly-available information (the SWF file) to do two things:

a) provide end-to-end secrecy, just like SSL

b) link knowledge of the size and a hash of the SWF file to the connection.

adobe claim [translation: lie to their customers, thus exposing themselves to lawsuits] that this "validation" process _guarantees_ that only someone with the SWF file (that was publicly accessible and publicly downloadable from a web site) can download the content. what they imply from that is that only someone who _executes_ the SWF file can download the content, which is blatantly false.

from the algorithm: if anyone knows the SWF file's hash and its size, they can use the algorithm to access the content. executing the SWF file or even having it _at all_ is irrelevant.
if you want to get arsey about it, and say that the words "Genuine Adobe Flash Player 001" are an "encryption key", then you have a problem, because there is further input into the "validation" algorithm: the SWF file itself.

that makes the SWF file also an "encryption key".

... whoops.

you can immediately work out the implications, here, for yourself, but here's some of the more hilarious ones:

* how can you claim that a key is secret, yet make it publicly available on the internet?

* if you want to keep this "key" secret, surely you should go after all web browser distributors, and everyone who has HTTP cacheing technology, DEMANDING that they "protect" - remove - SWF files from caches.

this latter is quite easily achieved. you just block *.swf files.