โปรโตคอลการขนส่งแบบเรียลไทม์ที่ปลอดภัย (Secure Real-time Transport ProtocolหรือSRTP ) เป็นโปรไฟล์สำหรับโปรโตคอลการขนส่งแบบเรียลไทม์ (Real-time Transport Protocolหรือ RTP) ที่ออกแบบมาเพื่อการเข้ารหัส การตรวจสอบความถูก ต้องและความสมบูรณ์ ของข้อความ และ การป้องกัน การโจมตีแบบเล่นซ้ำสำหรับข้อมูล RTP ทั้งใน แอปพลิเคชัน แบบยูนิคาสต์และมัลติคาสต์โปรโตคอลนี้ได้รับการพัฒนาโดยทีมเล็กๆ ของ ผู้เชี่ยวชาญ ด้านโปรโตคอลอินเทอร์เน็ตและการเข้ารหัสจากซิสโก้และอีริคสันและ ได้รับการเผยแพร่ครั้งแรกโดยIETFในเดือนมีนาคม 2547 ในชื่อRFC  3711

เนื่องจาก RTP มาพร้อมกับโปรโตคอลควบคุม RTP (RTCP) ซึ่งใช้ในการควบคุมเซสชัน RTP ดังนั้น SRTP จึงมีโปรโตคอลคู่ขนานที่เรียกว่าSecure RTCP ( SRTCP ) ซึ่งให้ฟังก์ชันเดียวกันกับที่ RTCP ให้กับ RTP อย่างปลอดภัย

การใช้งาน SRTP หรือ SRTCP เป็นทางเลือกในแอปพลิเคชัน RTP หรือ RTCP แต่ถึงแม้จะใช้ SRTP หรือ SRTCP คุณสมบัติทั้งหมดที่ให้มา (เช่น การเข้ารหัสและการตรวจสอบความถูกต้อง) ก็เป็นทางเลือกและสามารถเปิดหรือปิดใช้งานแยกต่างหากได้ ข้อยกเว้นเพียงอย่างเดียวคือคุณสมบัติการตรวจสอบความถูกต้องของข้อความ ซึ่งเป็นสิ่งจำเป็นและขาดไม่ได้เมื่อใช้ SRTCP

SRTP และ SRTCP ใช้มาตรฐานการเข้ารหัสขั้นสูง (AES) เป็นการเข้ารหัส เริ่มต้น มี การกำหนด โหมดการเข้ารหัส สองโหมดที่อนุญาต ให้ใช้การเข้ารหัสแบบบล็อก AES เป็นการ เข้ารหัสแบบสตรีมได้ :

โหมดตัวนับจำนวนเต็มแบบแบ่งส่วน

โหมดตัวนับทั่วไปซึ่งอนุญาตให้เข้าถึงบล็อกใดๆ ก็ได้แบบสุ่ม ซึ่งจำเป็นอย่างยิ่งสำหรับทราฟฟิก RTP ที่ทำงานบนเครือข่ายที่ไม่น่าเชื่อถือและอาจเกิดการสูญหายของแพ็กเก็ตได้ โดยทั่วไปแล้ว ฟังก์ชันเกือบทุกชนิดสามารถใช้แทนตัวนับได้โดยสมมติว่าฟังก์ชันนั้นไม่ทำงานซ้ำเป็นจำนวนมาก แต่มาตรฐานสำหรับการเข้ารหัสข้อมูล RTP คือตัวนับแบบเพิ่มค่าจำนวนเต็มทั่วไป อัลกอริทึมการเข้ารหัส AES ที่ทำงานในโหมดนี้เป็นค่าเริ่มต้น โดยมีขนาดคีย์ เริ่มต้น 128 บิต และ ความยาว คีย์เกลือ เซสชันเริ่มต้น 112 บิต

โหมด f8

รูปแบบหนึ่งของการป้อนกลับเอาต์พุตที่ได้รับการปรับปรุงให้สามารถค้นหาได้และมีฟังก์ชันการเริ่มต้นที่เปลี่ยนแปลงไป ค่าเริ่มต้นของคีย์การเข้ารหัสและคีย์เกลือจะเหมือนกับ AES ในโหมดตัวนับ (AES ที่ทำงานในโหมดนี้ได้รับการเลือกใช้ใน เครือข่าย มือถือ 3G )

นอกจากรหัส AES แล้ว SRTP ยังอนุญาตให้ปิดการเข้ารหัสโดยสิ้นเชิงได้ โดยใช้ รหัส การเข้ารหัสแบบว่าง เปล่า (null encryption cipher) ซึ่งอาจถือได้ว่าเป็นรหัสทางเลือกที่รองรับได้ ที่จริงแล้ว รหัสการเข้ารหัสแบบว่างเปล่าจะไม่ทำการเข้ารหัสใดๆ อัลกอริทึมการเข้ารหัสจะทำหน้าที่เป็นฟังก์ชันเอกลักษณ์ (identity function ) และคัดลอกสตรีมอินพุตไปยังสตรีมเอาต์พุตโดยไม่มีการเปลี่ยนแปลงใดๆ การใช้งานโหมดการเข้ารหัสนี้เป็นข้อบังคับในระบบที่เข้ากันได้กับ SRTP ทุกระบบ ดังนั้นจึงสามารถใช้ได้เมื่อไม่ต้องการการรับประกันความลับที่รับรองโดย SRTP ในขณะที่สามารถใช้คุณสมบัติอื่นๆ ของ SRTP เช่น การตรวจสอบสิทธิ์และความสมบูรณ์ของข้อความได้

แม้ว่า SRTP จะสามารถรองรับอัลกอริธึมการเข้ารหัสใหม่ๆ ได้อย่างง่ายดาย แต่มาตรฐาน SRTP ระบุว่าอัลกอริธึมการเข้ารหัสใหม่ๆ จะสามารถนำมาใช้ได้ก็ต่อเมื่อมีการเผยแพร่RFC มาตรฐาน ที่เกี่ยวข้องฉบับใหม่ ซึ่งต้องกำหนดรายละเอียดของอัลกอริธึมใหม่นั้นอย่างชัดเจน

อัลกอริทึมการเข้ารหัสที่กล่าวมาข้างต้นเพียงอย่างเดียวไม่สามารถรับประกันความสมบูรณ์ของข้อความได้ ผู้โจมตีจะไม่สามารถถอดรหัสข้อมูลได้ แต่อาจสามารถปลอมแปลงหรือเล่นซ้ำข้อมูลที่ส่งไปก่อนหน้านี้ได้ ดังนั้น มาตรฐาน SRTP จึงมีวิธีการเพิ่มเติมเพื่อรักษาความสมบูรณ์ของข้อมูลและความปลอดภัยจากการเล่นซ้ำด้วย

เพื่อตรวจสอบความถูกต้องของข้อความและปกป้องความสมบูรณ์ของข้อความจะใช้อัลกอริธึมHMAC-SHA1 ^{[ 1 ]} ซึ่งจะสร้างผลลัพธ์ 160 บิต จากนั้นจะถูกตัดให้เหลือ 80 หรือ 32 บิตเพื่อใช้เป็น แท็กการตรวจสอบความถูกต้องที่แนบมากับแต่ละแพ็กเก็ต HMAC จะถูกคำนวณจากเพย์โหลดของแพ็กเก็ตและข้อมูลจากส่วนหัวของแพ็กเก็ต รวมถึงหมายเลขลำดับของแพ็กเก็ต เพื่อป้องกันการโจมตีแบบเล่นซ้ำผู้รับจะเก็บรักษาหมายเลขลำดับของข้อความที่ได้รับก่อนหน้านี้ เปรียบเทียบกับหมายเลขลำดับในแต่ละข้อความใหม่ที่ได้รับ และยอมรับข้อความใหม่ก็ต่อเมื่อยังไม่เคยได้รับมาก่อน วิธีการนี้อาศัยการป้องกันความสมบูรณ์เพื่อทำให้ไม่สามารถแก้ไขหมายเลขลำดับได้โดยไม่ถูกตรวจจับ

ฟังก์ชัน การสร้างคีย์ ( Key Derivation Function)ใช้ในการสร้างคีย์ต่างๆ ที่ใช้ในบริบทการเข้ารหัส (คีย์การเข้ารหัส SRTP และ SRTCP และค่าเกลือ (salt) คีย์การตรวจสอบความถูกต้อง SRTP และ SRTCP) จากคีย์หลัก เพียงคีย์เดียว ในลักษณะที่ปลอดภัยทางด้านการเข้ารหัส ดังนั้น โปรโตคอล การจัดการคีย์จึงจำเป็นต้องแลกเปลี่ยนคีย์หลักเพียงคีย์เดียวเท่านั้น คีย์เซสชันที่จำเป็นทั้งหมดจะถูกสร้างขึ้นโดยการใช้ฟังก์ชันการสร้างคีย์

การใช้ฟังก์ชันการสร้างคีย์ซ้ำเป็นระยะๆ จะช่วยป้องกันผู้โจมตีจากการรวบรวมข้อความเข้ารหัสจำนวนมากที่เข้ารหัสด้วยคีย์เซสชัน เดียว ซึ่งเป็นการป้องกันการโจมตีบางประเภทที่ทำได้ง่ายขึ้นเมื่อมีข้อความเข้ารหัสจำนวนมาก นอกจากนี้ การใช้ฟังก์ชันการสร้างคีย์ซ้ำหลายครั้งยังให้ความปลอดภัยทั้งแบบย้อนหลังและแบบไปข้างหน้า กล่าวคือ คีย์เซสชันที่ถูกบุกรุกจะไม่ส่งผลกระทบต่อคีย์เซสชันอื่นๆ ที่สร้างจากคีย์หลักเดียวกัน หมายความว่า แม้ว่าผู้โจมตีจะสามารถกู้คืนคีย์เซสชันได้ เขาก็ไม่สามารถถอดรหัสข้อความที่ได้รับการรักษาความปลอดภัยด้วยคีย์เซสชันก่อนหน้าและคีย์เซสชันถัดไปที่สร้างจากคีย์หลักเดียวกันได้ (โปรดทราบว่า หากคีย์หลักรั่วไหล จะเปิดเผยคีย์เซสชันทั้งหมดที่สร้างจากคีย์นั้น)

SRTP อาศัยโปรโตคอลการจัดการคีย์ภายนอกในการตั้งค่ามาสเตอร์คีย์เริ่มต้น โปรโตคอลสองตัวที่ออกแบบมาโดยเฉพาะสำหรับใช้กับ SRTP คือZRTPและMIKEYนอกจากนี้ยังมีวิธีการอื่นๆ ในการเจรจาคีย์ SRTP อีกด้วย มีผู้จำหน่ายหลายรายที่นำเสนอผลิตภัณฑ์ที่ใช้วิธีการแลกเปลี่ยนคีย์ SDES

• RFC  5764ได้กำหนดนิยามของDTLS-SRTPไว้ DTLS-SRTP ใช้ โปรโตคอล DTLSในการส่งคีย์หลัก และอนุญาตให้ตรวจสอบความถูกต้องด้วยคีย์สาธารณะได้

ดูการเปรียบเทียบซอฟต์แวร์ VoIP § ซอฟต์แวร์ VoIP ที่ปลอดภัยสำหรับโทรศัพท์ เซิร์ฟเวอร์ และแอปพลิเคชันที่รองรับ SRTP

• แอสเตอริสก์ (PBX) ^{[ 2 ] [ 3 ]}

เว็บเบราว์เซอร์ที่รู้จักกันดีซึ่งรองรับ SRTP ในรูปแบบใดรูปแบบหนึ่ง

• ตระกูลBlink (เอนจินเบราว์เซอร์)
• เบราว์เซอร์ Chromiumรองรับ (แต่ไม่ใช่ทุกเบราว์เซอร์) SRTP ในเชิงทดลองมาตั้งแต่ปี 2016
• โอเปอเร (เว็บเบราว์เซอร์)
• วิวัลดี (เว็บเบราว์เซอร์)

ตระกูลเว็บเบราว์เซอร์ที่มี SRTP ในระดับหนึ่งในสายหลักจะได้รับการอัปเดตจากระบบแสดงผลหลัก

• เก็กโก้ (ซอฟต์แวร์)
• MSHTML (ถูกแทนที่แล้ว แต่ยังคงมีการสนับสนุนขั้นพื้นฐานอยู่บ้างในขณะที่หมดอายุ)
• เว็บคิท

จนถึงปัจจุบัน ยังไม่มีเว็บเบราว์เซอร์แบบข้อความใดที่รองรับโปรโตคอล SRTP

• RFC  3711มาตรฐานที่เสนอ โปรโตคอลการขนส่งแบบเรียลไทม์ที่ปลอดภัย (SRTP)
• RFC  4771มาตรฐานที่เสนอ การแปลงความสมบูรณ์พร้อมตัวนับการวนซ้ำสำหรับโปรโตคอลการขนส่งแบบเรียลไทม์ที่ปลอดภัย (SRTP)
• RFC  3551มาตรฐาน 65 โปรไฟล์ RTP สำหรับการประชุมทางเสียงและวิดีโอที่มีการควบคุมน้อยที่สุด
• RFC  3550 , มาตรฐาน 64, RTP: โปรโตคอลการขนส่งสำหรับแอปพลิเคชันแบบเรียลไทม์
• RFC  2104 , ข้อมูล, HMAC: การแฮชแบบใช้คีย์สำหรับการตรวจสอบความถูกต้องของข้อความ
• RFC  7714 มาตรฐานที่เสนอ การเข้ารหัสแบบตรวจสอบความถูกต้อง AES-GCM ในโปรโตคอลการขนส่งแบบเรียลไทม์ที่ปลอดภัย (SRTP)