View Single Post
  #2  
Old 06-02-2009, 06:20 AM
any ANONYMOUS forum user any ANONYMOUS forum user is offline
any user of the forum who preferred to post anonymously
 
Join Date: Aug 2011
Location: Server of stream-recorder.com
Posts: 211
any ANONYMOUS forum user is on a distinguished road
Default

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]
    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.
Reply With Quote