![]() ![]() Prior to initiating the call, you’ll want to fire up Wireshark to capture the necessary packets.Ī configuration of Linphone and packet capturing is beyond the scope of this article. Otherwise, you won’t be able to decode the audio in Wireshark. You’ll also want to make sure that the two Linphone endpoints are using G.711 (PCMU or PCMA). The easiest way to obtain the necessary packets is to simply set up two PCs with Linphone, configure Linphone to do SRTP (you do NOT want ZRTP for this tutorial), and make a call between the two Linphone clients. It won’t pay any mind (or throw any sort of warning) that the master keys are transported across an insecure medium. ![]() When configured to use SRTP, Linphone is quite happy to send the keys in plaintext within SDP. (Un)Luckily, Linphone doesn’t seem to be very concerned about the safety of SRTP keys. To do this, we need two SIP endpoints that don’t really care about that quoted passage from RFC 4568 and are quite happy to send plaintext keys across insecure SIP. To complete this proof of concept, we need to capture the initial SIP handshake and some SRTP data. ![]() Hopefully, things will start to make sense once we begin to look at the packets involved. But you should still be using a key management protocol.” This is extremely frustrating and very confusing. Actually, it will help you do the exact opposite: send a key without using a key management protocol. But this RFC won’t actually help you with that. The SDES RFC more or less says “You should use a key management protocol. It’s a complete mess of RFCs that, truth be told, feel very half-baked. Replay the decrypted RTP data in WiresharkĬonfused yet? The technology surrounding SDES, SRTP, and key exchange seems like black magic.Grab the key and filter out a single SRTP stream in Wireshark.Obtain a complete call, including SIP exchange and RTP data, between two endpoints. ![]() If the SIP signaling protocol isn’t transported over a secure medium (such as TLS), then decrypting the “secure” RTP is trivial once the encryption key is obtained from the plaintext SIP exchange. SDES just allows for the master key to be exchanged within a new SDP field. That is the place of RFC 4567, which provides additional SDP fields for exchanging key management protocol information. SDES does not actually provide any methods to utilize key management or agreement protocols within SDP. Of the security session to gain unauthorized access to session. Key over a medium where an attacker can snoop the key, alter theĭefinition of the key to render it useless, or change the parameters Parameters at least as well as the data are secured.ĪKE is needed because it is pointless to provide a It would be self-defeating not to secure cryptographic keys and other Indeed, RFC 4568 for SDES specifically mentions this reality: Therefore, we need to be using SIP over TLS, so that transportation of the key within SDP is secure. Also remember that SIP is usually unencrypted by default. Remember that SDP provides parameters, such as media encoding, for a connection. Essentially, SDES allows for key exchange within the SDP portion of a SIP packet. The Session Description Protocol Security Descriptions (SDES) provide one method for exchanging the keys that are used to encrypt RTP media. VoIP security is a fairly complex topic, rife with acronyms, competing solutions, and enough implementation challenges to make any administrator pull their hair out. Hacking VoIP: Decrypting SDES Protected SRTP Phone Calls ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |