Impacts of Security Protocols on Real-time Multimedia Communications

1. Impacts of Security Protocols on Real-time Multimedia Communications Kihun Hong1, Souhwan Jung1, Luigi Lo Iacono2, Christoph Ruland2 1 School of Electronic Engineering, Soongsil University, 1-1, Sangdo-dong, Dongjak-ku, Seoul 156-743, KOREA {kihun@cns., souhwanj@}ssu.ac.kr 2 Institute for Data Communications Systems, University of Siegen, Germany {lo_iacono, ruland}@nue.et-inf.uni-siegen.de

2. Outline • Motivation for the study • Main contributions of the paper • Security Standards for Multimedia Communication • Comparing Criteria • Implementation • Conclusion kihun@cns.ssu.ac.kr

3. Motivation for the study • Which security protocol will you use for real-time multimedia communication ? • We have many security protocols as IPsec, TLS, H.235, SRTP, and so on. • Media stream has real-time properties. • Delay, packet loss, jitter etc. • Security service can degrade the quality of real-time multimedia services. kihun@cns.ssu.ac.kr

4. Main contributions of the paper • We investigated the existing security protocols for real-time multimedia communication. • We analyzed the details of the security functions for real-time multimedia communication. • Optimized security function for real-time multimedia communication. • Protection bound, Encryption algorithm and operation mode, computational delay etc. • This work is helpful to choose and design the security protocol for real-time multimedia communication. kihun@cns.ssu.ac.kr

5. Security Standards for Multimedia Communication • IPsec • Security services for the Internet Protocol • It is mandatory for IPv6 and optional for IPv4. • Encapsulating Security Payload (ESP) • Authentication Header (AH) • H.235 • H.235 standard describes security services for H.323. • Baseline Security Profile • Message authentication/integrity for the signaling path. • Voice encryption profile • Signature Security Profile • Authentication, integrity, and non-repudiation for the signaling messages by using digital signatures. • SRTP • The Secure RTP (SRTP) provides confidentiality and authentication for RTP and RTCP. • The encryption of SRTP or SRTCP packets is optional whereas the authentication for RTCP is mandatory but optional for RTP. kihun@cns.ssu.ac.kr

6. Comparing Criteria • Confidentiality • Data Integrity and Message Authentication • Packet Source Authentication and User Authentication • Replay Protection • Dos Protection • Key Management • Data Expansion • Error Propagation • Computational Delay kihun@cns.ssu.ac.kr

7. Confidentiality • IPsec • IP payload (protection bound) • DES CBC-Mode • H.235 • RTP payload (protection bound) • RC2, DES, and 3DES, CBC-Mode • SRTP • RTP, RTCP payload (protection bound) • AES in Segmented Integer Counter (SIC) mode • Keystream is XORed with the payload. kihun@cns.ssu.ac.kr

8. Data Integrity and Message Authentication • IPsec • IP packet (AH) • H.235 • The anti-spamming mechanism provides a light-weighted RTP packet authentication. • A part of the RTP header. • An attacker can modify RTP payloads. • SRTP • RTP, RTCP header and the (encrypted) payload • MAC is truncated to the leftmost 32 bit. • A truncation to less than the half of the generated output of the HMAC increases the possibility to attack the MAC because of the birthday-attack-bound. kihun@cns.ssu.ac.kr

9. Packet Source Authentication and User Authentication • All of the schemes don’t provide a method for packet source authentication. • IPsec • User authentication relies on the main mode of the IKE protocol using digital signatures. • H.235 • Authentication is accomplished by the utilization of pre-shared secrets. (a static password or some other a priori piece of information) • The usage of digital certificates is possible. • SRTP • SRTP depends on a separate protocol for user authentication. kihun@cns.ssu.ac.kr

10. RTP Header encrypted …P… SEQ# timestamp …… Media data padding AUTH padlen MACK(…SEQ#, timestamp) Replay Protection and Dos Protection • Replay Protection • IPsec • The AH guards against replay attacks. • Sliding window approach • This is realized by maintaining a replay list on the receiver-side. • H.235 • Replay protection is for further study. • SRTP • It indirectly provides replay protection by authenticating the sequence number. • Dos Protection • IPsec and SRTP have no countermeasure against message flooding. • H.235 • A media anti-spamming mechanism kihun@cns.ssu.ac.kr

11. Key Management • IPsec • Internet Key Exchange (IKE) protocol • Main Mode and Quick Mode • H.235 • The master chooses a random session key. • The shared secret is used to encrypt the session key material. • SRTP • SRTP does not define any key establishment protocol. • It just describes how to derive the necessary session keys for encryption and authentication from the master keys. kihun@cns.ssu.ac.kr

12. Data Expansion • IPsec : ESP (or AH) header, pad, auth. field • H.235 : pad, auth. field • SRTP : auth. tag kihun@cns.ssu.ac.kr

13. Error Propagation • IPsec and H.235 • In case of CBC, a transmission error affects two plaintext blocks. • SRTP • No error propagation • The process of encrypting a packet • XORing with the keystream kihun@cns.ssu.ac.kr

14. Computational Delay • Sender-side • IPsec computation delay = Enc(UDP header||RTP header||RTP payload) + GenMAC(ESP header||UDP header||RTP header||RTP payload) • H.235 computation delay = Enc(RTP payload) + GenMAC(RTP header) • SRTP computation delay = Enc(RTP payload) + GenMAC(RTP header || RTP payload) * • Receiver-side • IPsec Computation delay = Dec(UDP header||RTP header||RTP payload) + VerMAC(ESP header||UDP header||RTP header||RTP payload) • H.235 computation delay = Dec(RTP payload) + VerMAC(RTP header) • SRTP computation delay = Dec(RTP payload) + VerMAC(RTP header || RTP payload) * * : XOR operation. kihun@cns.ssu.ac.kr

15. Summary of Properties kihun@cns.ssu.ac.kr

16. Implementation • H.235 • OpenH323 supports H.235 for securing RAS messages but doesn’t support security functions for H.225.0, H.245, and RTP. • We extended the H.225.0 and H.245 signaling implementations and added the missing security fields and structures such as CryptoToken, ClearToken, and H.235Key. • All encryption algorithms as stated in H.235 Annex D were integrated. • SRTP • The SRTP framework is considered as a bump in the stack implementation between the RTP application and the transport layer. • We integrated our SRTP framework into the openH323 project and extended the OpenPhone application. kihun@cns.ssu.ac.kr

17. Communication overheads versus payload size • IPsec : ESP (or AH) header, pad, auth. field • H.235 : pad, auth. field • SRTP : auth. tag kihun@cns.ssu.ac.kr

18. Corrupt frames versus Packet error probability • We use a 40 bytes payload consisting of 2 frame of G.723.1. • The block size of encryption algorithm is 8 bytes. • The error position of packet is random. • IPsec and H.235 make more corrupted frames. kihun@cns.ssu.ac.kr

19. Conclusions • IPsec is a general security protocol for IP datagram and is easy to apply to applications. • But IPsec has a high comm. overhead and end-to-end delay. • In case of H.235 the offered security for the media stream is incomplete. • Furthermore the protection of RTCP is left out completely. • That makes H.235 very vulnerable to a variety of attacks. • Protection bound, pre-computation, error propagation, data size expansion • SRTP defines optimized security functions as integrity of RTP payload, RTCP protection, pre-computation, and low comm. overhead for real-time multimedia application using RTP. kihun@cns.ssu.ac.kr