SRTP

Secure Real-time Transport Protocol — Протокол Передачі Даних В реальному часі (або SRTP) визначає профіль RTP (Транспортний Протокол реального часу) і призначений для шифрування, встановлення автентичності повідомлення, цілісності, захисту від заміни даних RTP в unicast і multicast передачах медіа і додатках. Він був розроблений невеликою командою криптоекспертів IP протоколів компаній Cisco та Ericsson у складі David Annaba, David McGrew, Mark Baugher, Mats Naslund, Elisabetta Carrara, Karl Norman, і Rolf Blom. Був вперше опублікований в IETF у березні 2004 RFC 3711.

Опис

Оскільки RTP тісно пов'язаний з RTCP (Real-Time Control Protocol), який може використовуватися, щоб керувати сесією RTP, у SRTP також є споріднений протокол, названий Secure RTCP (або SRTCP). SRTCP забезпечує ті ж самі функції, пов'язані з безпекою в RTCP, для тієї ж функціональності SRTP RTP.

Використання SRTP або SRTCP є необов'язковим при використанні RTP або RTCP, але навіть якщо SRTP/SRTCP використовуються, всі додаткові можливості (такі як шифрування і встановлення достовірності) опціональні й можуть бути включені або виключені. Єдине виключення — функція аутентифікації повідомлень, яка обов'язкова при використанні SRTCP.

Для шифрування медіа потоку (в цілях конфіденційності голосового з'єднання), SRTP (разом з SRTCP) стандартизує використання тільки єдиного шифру, AES, який може використовуватися у двох режимах, що перетворюють спочатку блочний шифр AES в потоковий шифр:

• Сегментований цілочисельний лічильник — типовий режим, який здійснює довільний доступ до будь-яких блоків, що є істотним для трафіку RTP, що передається в мережах з непередбачуваним рівнем надійності та можливою втратою пакетів. У загальному випадку майже будь-яка функція може використовуватися в ролі «лічильника», припускаючи, що ця функція не повторюється для великого числа ітерацій. Але стандарт шифрування даних RTP — тільки звичайне цілочисельне значення лічильника. AES, що працює в цьому режимі, є алгоритмом шифрування за замовчуванням, з довжиною шифрувального ключа за замовчуванням в 128 біт і ключ сесії довжиною 112 біт.

• f8-режим — варіант режиму способу зворотного зв'язку, розширеного, щоб бути доступним зі зміненою функцією ініціалізації. Значення за замовчуванням для шифрувального ключа і ключа сесії — те ж, що і в AES в режимі, описаному вище. AES, що працює в цьому режимі, був обраний для використання в мобільних мережах 3G UMTS.

Крім шифру AES, SRTP дозволяє пряме шифрування, використовуючи так званий «порожній шифр», який може бути прийнятий як другий підтримуваний шифр (або третій режим шифрування на додаток до описаних двох вище). Фактично, порожній шифр не виконує шифрування (тобто функції алгоритму шифрування, так якби ключовий потік містив лише нулі, і копіює вхідний потік у вихідний без змін). Це обов'язково для цього способу шифрування, який повинен бути забезпечений у будь-якій SRTP-сумісній системі. Це також може використовуватися, коли конфіденційність, яку гарантує SRTP, не потрібна, однак інші можливості SRTP — автентифікація і цілісність повідомлення можуть використовуватись.

Хоча технічно у SRTP можна легко вбудовувати нові алгоритми шифрування, стандарт SRTP заявляє, що нові алгоритми шифрування, крім описаних, не можуть бути додані в реалізацію протоколу SRTP. Єдиний юридично легальний спосіб додати новий алгоритм шифрування для сумісності зі стандартом SRTP, полягає в тому, щоб опублікувати новий стандарт RFC, де повинно бути чітко визначене використання нового алгоритму.

Автентифікація, цілісність і захист від прослуховування

Перераховані вище алгоритми шифрування безпосередньо не забезпечують цілісність повідомлення, даючи можливість провести атаку типу "людина посередині" (Man-in-the-middle) і підробити вміст повідомлення, або, принаймні, прослухати раніше передані дані. Отже, стандарт SRTP повинен також забезпечувати засоби захисту цілісності даних і захисту від прослуховування.

Щоб підтвердити справжність повідомлення і захистити його цілісність, алгоритм хешування HMAC-SHA1, визначений у RFC 2104, використовується для отримання 160-бітового хеша, який потім урізається до 80 або до 32 бітів, щоб стати розпізнавальною ознакою, яку включають до пакета.

HMAC обчислюється за типом payload пакету даних в заголовку пакета, включаючи номер послідовності пакета. Щоб захистити від вбудовування повідомлень "людина посередині", приймач підтримує індекси раніше отриманих пакетів, порівнює їх з індексом кожного нового отриманого пакета і пропускає новий пакет, тільки якщо він не був посланий раніше. Такий підхід значною мірою покладається на повний захист цілісності (щоб позбавити можливості змінити індекси послідовності пакетів для обману).

Генерація ключів

Функція генерації ключів використовується для отримання сеансових ключів, використовуваних для шифрування контексту (SRTP, шифрувальні ключі контрольного протоколу SRTCP і ключі сесій, розпізнавальні ключі SRTP і SRTCP) з одного єдиного головного ключа. Таким чином, протокол обміну ключами дозволяє обмінятися тільки головними ключами, інші необхідні сеансові ключі будуть отримані використовуючи дану функцію.

Періодична зміна самої функції генерації ключів веде до додаткових заходів щодо посилення безпеки. Як правило це перешкоджає тому, щоб "людина посередині" зібрала велику кількість зашифрованого матеріалу, зашифрованого з одним єдиним сеансовим ключем. Деякі зломи легше виконати, коли є велика кількість зашифрованого матеріалу. Крім того, багаторазова зміна функції генерації ключів забезпечує пряму і зворотну безпеку в тому сенсі, що розшифрований сеансовий ключ не ставить під загрозу інші сеансові ключі, отримані з того ж самого головного ключа. Це означає, що, навіть якщо зловмиснику вдалося отримати певний сеансовий ключ, він не в змозі розшифрувати повідомлення, забезпечені з попередніми та більш пізніми сеансовими ключами, отриманими з того ж самого головного ключа. Хоча, звичайно, отриманий головний ключ дасть всі сеансові ключі, отримані з нього.

SRTP покладається на зовнішній протокол обміну ключами, щоб встановити головний початковий ключ. Розроблено два спеціальних протоколи для використання з SRTP — ZRTP і MIKEY.

Є й інші методи, щоб домовитися про ключі SRTP. Кілька різних виробників пропонують продукти, які використовують метод обміну ключів SDES.

Дивись також

• RTP/RTCP
• ZRTP

Посилання

• RFC 3711
• RFC 4771
• RFC 3551
• RFC 3550
• RFC 2104