Avoiding fabrication of contents

Add new RTCP packets containing signed hashes over blocks of (S)RTP packets or (S)RTCP packets. Sign with private key. Verify with public key! This signed hash need not immediately follow the block of packets it is computed over.

Slide Notes

Md. Sakhawat Hossen A Session Initiation Protocol User Agent with Key Escrow: Providing authenticity for recordings of secure sessions, Master’s thesis, KTH Royal Institute of Technology, TRITA-ICT-EX-2010:1, January 2010 http://urn.kb.se/resolve?urn=urn:nbn:se:kth:diva-12143 Links to an external site.

Muhammad Sarwar Jahan Morshed, Voice over IP and Lawful Intercept: God cop/Bad cop, Master’s thesis, KTH Royal Institute of Technology, TRITA-ICT-EX-2010:28, February 2010 http://urn.kb.se/resolve?urn=urn:nbn:se:kth:diva-24260 Links to an external site.

Transcript

[slide413] So how do we avoid the fabrication of contents? Well, what do we do? We use our SRTP with our keys as before, but now over blocks of our traffic, we compute a hash. And we now, yes, sign that hash using our private key. And we send that hash as part of our SRTP traffic. So now what happens? Well, if someone should tamper with that traffic, later anyone can use my public key, decrypted, see, nope, someone tampered with these blocks because the hash doesn't match. And what I can also do is, I can escrow the last hash that I computed. So now the result is that I can show when the call ended, so no one can fabricate anything beyond that. But to do that, we need to add a new RTCP packet to put the signed hashes into. The good feature is we don't have to compute those signed hashes right away. This is an interesting area.