1 Reply Latest reply on Jan 9, 2013 10:58 AM by Michael Thornburgh

    Encrypted voice over RTMFP

    Rafał Olejniczak

      Hello,

       

      I'm coding encrypted voice messanger. I heard, that sound stream in NetStream is encrypted by symmetric key algorithm. Is it true? If it is, where it is generated? Is the key exchange between peers based on sth like SSL (public key algorithm safe protocol)? I want to be sure that nobody cannot access this symmetric key. I will appreciate detailed information about encrypting transmission (graphs, technical references) because I am preparing graduate work about it. Thank you in advance for your help.

        • 1. Re: Encrypted voice over RTMFP
          Michael Thornburgh Adobe Employee

          the following is information that we/i have publicly disclosed in the past. i'm not able at this time to share more.

           

          all packets are encrypted with AES-128-CBC.

           

          AES encryption keys are derived end-to-end using Diffie-Hellman with a 1024-bit prime modulus (RFC 2409 MODP group 2).

           

          all Flash client RTMFP certificates include their Diffie-Hellman public key that's used in end-to-end key agreement.  the "peer ID" (NetConnection.nearID) is the SHA-256 hash of the certificate.  the Diffie-Hellman private/public key is chosen randomly for every new NetConnection using the platform's cryptographic pseudorandom number source (such as /dev/urandom).

           

          this construction makes Flash client peer IDs unforgeable.  only one NetConnection in a normally operating Flash client can ever have a particular peer ID.  it is only possible to have a successful network connection between two client peers if those peers possess the private keys associated with their public keys.  an attacker pretending to be another peer can copy the certificate but won't have the private key, so the network connection can't succeed (since the attacker can't compute the Diffie-Hellman shared secret that goes with the connection between the two peer IDs, and therefore can't compute the AES session keys that the other end is expecting).

           

          the nearNonce and farNonce are also derived from the Diffie-Hellman shared secret, and are only known to the two endpoints.  they are secret and unforgeable.  they can be used as cryptographic challenges in application-layer handshakes.