secure RTMPE protocol. Is it really secure???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----------------- 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]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]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]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]Packet Format ------------- The packets consist of a one byte command followed by a 1536 byte message Code:
Bytes : Description--------------------- 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 encryptedCode:
0:3 32-bit system time, network byte ordered (htonl)Code:
dhpkl = GetClientDHoffset(clientsig[1532:1535])Code:
/* Note: the SHA digest message is calculated from the bytes ofCode:
Send all 1537 bytes (command + clientsig) to the server;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 requestCode:
0:3 32-bit system time, network byte ordered (htonl)Code:
sdl = GetClientGenuineFMSKeyDigestOffset(serversig[8:11])Code:
dhpkl = GetClientDHoffset(serversig[1532:1535])Code:
0:3 32-bit system time, network byte ordered (htonl)Code:
sdl = GetServerGenuineFMSKeyDigestOffset(serversig[772:775])Code:
dhpkl = GetServerDHoffset(serversig[768:771])The key is only needed if encryption was negotiated. Code:
DHSharedSecret = DH(DHPrivateKeyC, DHPublicKeyS) |
Re: secure RTMPE protocol. Is it really secure???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]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])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)Code:
clientsig2[0:RTMP_SIG_SIZE] = Random DataWrite 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. |
Re: secure RTMPE protocol. Is it really secure???1 Attachment(s)
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 Attachment 45: Download the swf player you want to use for SWFVerification, unzip it using Code:
$ flasm -x file.swfNow generate the hash Code:
$ openssl sha -sha256 -hmac "Genuine Adobe Flash Player001" file.swfCode:
$ ./rtmpdump --swfhash "123456..." --swfsize 987...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. |
Re: secure RTMPE protocol. Is it really secure???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:
"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. |
Re: secure RTMPE protocol. Is it really secure???There are several problems with adobe's approach:
|
| All times are GMT -6. The time now is 02:59 AM. |