HTTPS clone URL
Subversion checkout URL
Clone this wiki locally
Across the RedPhone architecture, there are three places where data is transmitted, and thus needs to be encrypted:
- The standard signaling protocol. All signal-based communication with
relayswitches needs to be encrypted.
- The compressed signaling protocol. Signals transmitted over SMS, C2DM, and GCM need to be encrypted.
- The call content itself. Naturally, the actual call audio needs to be encrypted as well.
All communication between RedPhone clients and servers is encrypted using TLS. We do not use certificates signed by CAs, however. Instead, we have our own "CA certificate" that is distributed with the RedPhone client. Individual RedPhone servers have certificates that are signed by and validated against this "CA certificate," eliminating any requirement to trust CAs.
These messages are encrypted using a very simple protocol:
Version [1 Byte] : A one byte version number. IV (Random) [16 Bytes] : A random 16-byte IV Ciphertext [Variable] : AES-128 in CBC mode MAC [10 Bytes] : Hmac-SHA1 over the preceding bytes (encrypt-then-authenticate), truncated to 80 bits.
The AES and MAC keys are chosen by the client and transmitted to the server at registration time. These keys are static, do not provide forward security, and might be better implemented using a counter with keys that roll forward.