|
Вязмін Владислав ІвановичФакультет комп'ютерних наук та технологійКафедра програмної інженеріїСпеціальність
|
При написанні даного реферату магістерська робота ще не завершена. Остаточне завершення: Червень 2021 року. Повний текст роботи і матеріали по темі можуть бути отримані у автора або у його керівника після зазначеної дати.
Введення
Голосові месенджери [1] придбали свою популярність зовсім недавно. Розвиток даної галузі бере свій початок в момент, коли середня швидкість Інтернету по всьому світу стала досить комфортною для використання даних додатків навіть на смартфонах. Месенджер – це програма, мобільний додаток або веб-сервіс для миттєвого обміну повідомленнями, в даному випадку, голосовими. Дана галузь почала розвиватися досить бурхливо і ефективно, що призвело до створення щонайменше сотень, а то й тисячі месенджерів.
Месенджер являє собою клієнт-серверний додаток [2], яке може бути реалізовано для користувача як мобільний додаток або веб-сервіс для миттєвого обміну повідомленнями. Цей напрямок розвивається досить швидко і ефективно, що призводить до створення щонайменше сотень, а то й тисячі месенджерів різними фірмами-розробниками програмного забезпечення та окремими програмістами по всьому світу. Передача голосу з використанням Інтернету досить сильно поширена в колах як приватних користувачів, так і в державних і корпоративних установах. Для передачі медіаданих, а зокрема аудіоданих по мережі між користувачами застосовується протокол передачі реального часу RTP [3], який є небезпечним, оскільки за замовчуванням він не містить криптографічного шифрування і аутентифікації, а дані в rtp-пакеті передаються у відкритому вигляді. З цієї причини актуальною є завдання підвищення ефективності протоколів передачі голосових повідомлень.
1. Цілі і завдання дослідження, плановані результати
Метою дослідження є визначення та усунення вразливостей в протоколах передачі медіаданих, а також виявлення та усунення передбачуваних вразливостей в механізмах реєстрації та аутентифікації користувачів при розробці додатків з використанням протоколів для передачі голосових повідомлень з криптографічним захистом. Практична цінність полягає в розробці протоколу передачі голосових повідомлень з криптографічним захистом, а також модифікованого способу аутентифікації користувача за допомогою QR-коду [4] для програмних продуктів з передачі голосових повідомлень з криптографічним захистом.
Результатом даної магістерської роботи буде розроблений авторський протокол для передачі медіаданих з криптографічним захистом, а також модифікований спосіб аутентифікації користувача за допомогою QR-коду.
2. Аналіз проблем передачі мультимедійних даних по мережі
Для передачі голосових повідомлень між користувачами необхідно встановити зʼєднання. Існують два основних протоколи передачі даних, це UDP [5] та TCP [6]. ТСР є надійним протоколом для передачі даних, адже доставка гарантується, однак, для передачі потокових медіаданих він не підходить, оскільки в даному випадку необхідна швидкість, а TCP буде перевіряти, чи відправлений пакет, і якщо ні, тоді заново відправить його. У цьому випадку на допомогу приходить протокол UDP, він забезпечить необхідну швидкість, проте він не гарантує доставки пакета, що означає, що користувач може не отримати сказане слово, або ж отримати його не повністю. Отже, наступною проблемою є передача даних в повному обсязі без втрат.
3. Огляд літератури з проблеми передачі мультимедійних даних по мережі
У книзі Основи передачі голосових даних по мережах IP
автори наводять такий же приклад, який був описаний вище, а саме: по передачі голосових даних по мережах IP протокол ТСР гарантує надійність встановленого зʼєднання. Однак методи,
використовувані протоколом ТСР, не дозволяють застосувати його в якості механізму передачі власне голосових даних (RTP). При передачі голосових даних по мережах IP втрата пакета-це менше зло, в порівнянні з мережевою затримкою. В даний час
протокол H.323 використовує протокол ТСР, а протоколи SIP і MGCP-протокол ГВП (в якості транспортного механізму, протокол SIP здатний також використовувати протокол ТСР).
При передачі голосових даних по мережах IP протокол UDP використовується для передачі власне голосового трафіку (канали-носії). Протокол ТСР для цього не використовується, тому що в даному випадку управління потоком і повторна передача звукових пакетів просто не потрібні. Оскільки протокол UDP тільки передає звуковий потік, на його передачу не вплине ні 5%-ва втрата пакетів, ні 50%-ва.
Якби для передачі голосових даних по мережах IP використовувався протокол ТСР, Мережева затримка, посилена очікуванням підтверджень і повторними передачами, серйозно погіршила б якість звуку. Для передачі голосових даних по мережах IP та інших додатків реального часу контроль мережевої затримки є більш важливим завданням, ніж забезпечення надійної передачі кожного пакета.
З іншого боку, протокол ТСР використовується для встановлення зʼєднання більшістю протоколів передачі службових сигналів при передачі голосових даних по мережах IP [7].
У книзі Компʼютерні мережі. Спадний підхід
розглядається більш детальна структура протоколів, велика увага приділяється протоколам передачі медіаданих [8]. У даній книзі як приклад наводиться робота різних популярних
сервісів, таких як YouTube, Skype та ін велику увагу приділено одній з областей, що розвиваються сьогодні – мультимедійним мережевим технологіям, зокрема, специфіці передачі аудіо- та відеоданих. Книга розповідає про мультимедійні мережі.
Тепер в ній можна знайти докладне обговорення потокового відео; зокрема, адаптивне потокове мовлення. Крім того, в книзі зʼявився абсолютно новий розділ про мережі доставки контенту (CDN). Також йдеться про системи потокового відео Netflix,
YouTube і Kankan.
Передача даних, будь то текст або голос і відео, може відбуватися в реальному або модельному часу. Дані Мультимедіа можуть бути даними як реального, так і модельного часу. Реальний час – це можливість бачити і чути дані динамічно. Наприклад, відеокліп,
який переглядається, коли він завантажується на вашу мережеву станцію, класифікується як додаток реального часу. Камера, що знімає чиєсь виступ спільно з відеосерверами, що використовують протокол IP, і поширює отримані дані на тисячі робочих
станцій для перегляду в реальному часі – ще один приклад. Голос і відео вимагають дотримання спеціальних умов, а точніше, додатки реального часу предʼявляють певні вимоги до механізмів передачі даних, які розглянуті в книзі TCP/IP. Ілюстрований підручник
[9].
3.1 Огляд локальних джерел
Проблеми захищеності переданих даних в месенджерах були розглянуті в статті магістра ДонНТУ Крушанова А.І. в рамках II Міжнародної науково-практичної конференції ПІІВС-2018, где автор звертає особливу увагу на обмін ключами між користувачами і проектує для цього власний протокол, що теж вказує на актуальність проблеми [10].
Раніше, в рамках X Міжнародної науково-технічної конференції ІКСМКМ-2019, мною розглядалися існуючі протоколи для програмної реалізації голосових месенджерів і після їх розгляду я прийшов до висновку, що розробка голосового месенджера є досить трудомістким процесом, який включає в себе тісний звʼязок різних протоколів [11].
4. Анализ протоколов передачи голосовых сообщений
Кожен голосовий месенджер так чи інакше передає потокові дані по мережі, при цьому голос передається за допомогою різних транспортних протоколів. Кожен існуючий голосовий месенджер тим чи іншим чином використовує їх. Транспортні протоколи, в даному випадку, передбачені для потокової передачі медіаданих, а саме – звуку. В даний час існує два найбільш поширених протоколу для цих цілей. Це протоколи RTP і SRTP, які допомагають передавати потокові дані, однак і у них існують свої недоліки.
4.1 Аналіз протоколу RTP
Як правило, для цих цілей використовується протокол RTP (Real-time Transport Protocol) – транспортний протокол в реальному часі. Саме він забезпечує передачу даних в реальному часі. Дані RTP зазвичай доставляються по протоколу UDP, який є ненадійним транспортним протоколом. Отже, немає гарантії доставки пакетів на транспортному рівні. Пакети будуть прийматися в тому порядку, в якому вони були відправлені або пакети будуть відправлятися з постійною швидкістю. Порядковий номери пакетів і тимчасові мітки дозволяють додатку, що приймає пакети RTP, відновлювати послідовність пакетів відправника, виявляти зміни в мережі і відповідним чином коригувати. На рисунку 1 представлена схема передачі аудіоданих по мережі з використанням протоколу RTP.
Рисунок 1 – Передача аудіоданих по мережі з використанням протоколу RTP
Використання протоколу UDP для інкапсуляції пакетів RTP включає в себе певні обмеження, такі як помилки при передачі. В результаті будь-яка втрачена або пошкоджена частина просто ігнорується. Протокол rtp служить для передачі звуку і зображень, але ніяк не відстежує цілісність переданих даних. RTP не забезпечує автоматичну повторну передачу пропущених пакетів. Однак, передавати дані, використовуючи тільки RTP нерозумно з точки зору безпеки переданих даних, оскільки вони можуть бути перехоплені третіми особами. Отже, всі Месенджери, як правило, шифрують передані дані і більшість месенджерів для цих цілей використовують протокол SRTP [12].
Сьогодні більша частина трафіку VoIP відправляється без будь-якої криптографічного захисту [13] і вразлива з точки зору прослуховування і модифікації, тому використання засобів захисту є актуальним завданням.
4.2 Аналіз протоколу SRTP
SRTP (Secure Real-time Transport Protocol) являє собою розширення протоколу RTP, яке додає додаткові функції безпеки, такі як аутентифікація повідомлень, їх шифрування, перевірка цілісності і захист від заміни даних, в основному призначений для VoIP-комунікацій. SRTP є одним з протоколів безпеки, що використовуються для технології WebRTC. Як правило, в SRTP за замовчуванням для шифрування використовується AES-CM [14]. Основною причиною вибору AES-CM була відсутність розширення корисного навантаження (зашифрована корисне навантаження має ту ж довжину, що і вихідна). Інша особливість AES-CM дозволяє обробляти пакети не по порядку, що має на увазі можливість обробляти пакети паралельно. Під корисним навантаженням мається на увазі частина переданого пакета, в якій знаходиться фактичне повідомлення. Отже, можна зробити висновок, що всі голосові месенджери для передачі потокових даних використовують протокол RTP, поверх якого використовують різні алгоритми шифрування.
Інформація про криптографічний стан, повʼязана з кожним потоком SRTP, називається криптографічним контекстом. Воно (стан) має підтримуватися як відправником, так і одержувачем. Якщо в даному сеансі FTP присутній кілька потоків SRTP, для кожного повинен підтримуватися окремий криптографічний контекст (припустимо відправляємо одночасно звук і відео, але в різних потоках).
Криптографічний контекст включає в себе будь-який сеансовий ключ (ключ безпосередньо в шифруванні / аутентифікації повідомлення) і головний ключ (випадкова бітова рядок, яка використовується для отримання сеансових ключів), а також інші параметри робочого сеансу.
Хоча SRTP не визначає точний механізм для реалізації обміну ключами, він забезпечує кілька функцій, які спрощують управління ключами і підвищують загальну безпеку. Головний ключ використовується для надання ключового матеріалу для ключа функції виводу.
Завдяки цьому можуть генеруватися початкові сеансові Ключі [15], а також, цей механізм періодично надає нові ключі сеансу, щоб гарантувати обмежену довжину шифротексту, отриманого будь-яким заданим ключем шифрування. Сеансові ключі використовуються для забезпечення захисту від різних впливів, таких як попереднє обчислення і атаки з використанням памʼяті в часі.
Періодична зміна самої функції генерації ключів веде до додаткових заходів щодо посилення безпеки. Як правило це перешкоджає тому, щоб людина посередині зібрав велику кількість зашифрованого матеріалу, зашифрованого з одним єдиним сеансовим ключем. Деякі зломи легше виконати, коли є велика кількість зашифрованого матеріалу. Крім того, багаторазова зміна функції генерації ключів забезпечує пряму і зворотну безпеку в тому сенсі, що розшифрований сеансовий ключ не ставить під загрозу інші сеансові Ключі, отримані з того ж самого головного ключа. Це означає, що, навіть якщо зломщику вдалося отримати певний сеансовий ключ, він не в змозі розшифрувати повідомлення, забезпечені з попередніми і пізнішими сеансовими ключами, отриманими з того ж самого головного ключа (хоча, звичайно, отриманий головний ключ дасть всі сеансові Ключі, отримані з нього).
SRTP покладається на зовнішній протокол обміну ключами, щоб встановити головний початковий ключ. SRTP для цих цілей використовує такі протоколи як ZRTP [16] та MIKEY [17]. Є й інші методи, щоб домовитися про ключі SRTP. Кілька різних виробників пропонують продукти, які використовують метод обміну ключів SDES.
5. Модифікований спосіб аутентифікації користувача за допомогою QR-коду
На момент роботи над авторефератом був спроектований модифікований спосіб аутентифікації користувача за допомогою QR-коду для додатків з передачі голосових повідомлень з криптографічним захистом [18].
Перед входом в кожну систему користувачеві спочатку необхідно зареєструватися в ній, а потім при кожному вході здійснювати аутентифікацію. Однак, якщо при аутентифікації користувач буде використовувати тільки свій пароль, то існує ризик того, що зловмисник зможе отримати доступ до пароля користувача. Для забезпечення більшої безпеки даних користувача було вирішено доповнити парольну аутентифікацію користувача для програмного забезпечення типу месенджер використанням QR-коду. Передбачається, що клієнтський додаток буде використовуватися на персональних компʼютерах. Аутентифікація в даному додатку проводиться з використанням логіна, пароля, QR-коду та електронної пошти. Як тільки користувач запустить клієнтську частину програми, буде згенерована пара ключів RSA (приватний і публічний ключ) [19], потім, з сервером буде здійснено обмін публічними ключами. Кожен раз при аутентифікації буде здійснюватися генерація нових ключів. На стороні сервера користувач буде ідентифікований як незареєстрований користувач, йому буде присвоєно свій унікальний ідентифікатор і пара ключів, згенерованих алгоритмом RSA для цього користувача. Після обміну відкритими ключами між клієнтом і сервером, самі ключі будуть занесені в базу даних на стороні сервера, в якій будуть зберігатися дані про всіх підключеннях в поточний момент часу. Етап запуску Користувачем Програми продемонстрований на рисунку 2.
Рисунок 2 – Дії, що відбуваються на етапі запуску Користувачем Програми
Далі розглянемо сценарій, коли Користувач не зареєстрований в системі, і збирається пройти етап реєстрації з подальшою роботою в додатку. На самому початку, після того як був здійснений обмін ключами з сервером, користувач вибрав етап реєстрації. Під час реєстрації користувач ввів свій логін, пароль та адресу електронної пошти. Після цього від пароля користувача береться хеш, потім всі введені користувачем дані обʼєднуються в один рядок, після чого отримана рядок переводиться в base64 [20], шифрується за допомогою приватного RSA ключа користувача і відправляється на сервер. Сервер в свою чергу, отримує ці дані, розшифровує публічним ключем користувача, перетворює дані в зрозумілий вигляд і перевірять на достовірність (чи існує користувач з такою електронною адресою або логіном), і в разі, якщо валідація була пройдена, ці дані заносяться в базу даних. Дана процедура показана на рисунку 3.
Рисунок 3 – Процедура реєстрації та аутентифікації користувача
Потім, користувач вирішує зайти в систему як зареєстрований користувач. Після того, як користувач ввів свої дані, і вони пройшли перевірку на сервері (вірний пароль від аккаунта), сервер відповідає на це, і потім клієнтська частина програми просить ввести QR-код, який був згенерований сервером і відправлений по електронній пошті користувачеві. Після чого користувач заходить в свою електронну пошту, завантажує висланий сервером QR-код, вставляє його в потрібне поле в клієнтській частині, де цей QR-код розшифровується, виходить рядок в base64, потім шифрується алгоритмом RSA і відправляється на сервер для звірки. Якщо все пройде успішно, то користувач може працювати з клієнтською частиною програмної системи. Орієнтовна схема представлена на рисунку 4.
Рисунок 4 – Двофакторна аутентифікація користувача
Запропонований алгоритм генерації QR-коду на серверній частині програми показаний на рисунку 5.
Рисунок 5 – Генерація QR-коду на серверній частині програми
Висновок
В ході дослідження було виявлено, що для потокової передачі даних в більшості відомих месенджерів служить протокол RTP. Для забезпечення захисту переданої інформації поверх протоколу RTP використовуються відомі криптографічні алгоритми шифрування. Результатом написання магістерської дисертації будуть розроблені протоколи які теоретично зможуть прийти на заміну SRTP і стандартним методам аутентифікації. В ході аналізу існуючих протоколів було виявлено, що протоколи передачі аудіоданих досить сильно схильні до прослуховування і підміни трафіку.
Подальші дослідження з цієї теми будуть спрямовані на наступні аспекти:
Список джерел
Э, 2016. – 912 с.
Crypto Messenger/ А.И. Крушанов, А.В. Чернышова // Программная инженерия: методы и технологии разработки информационно-вычислительных систем (ПИИВС–2018): сборник научных трудов II научно-практической конференции (студенческая секция), том 2 / Донец.национал.техн.ун-т; — Донецк, 2017. — С. 116-120.
