Этот мессенджер безопасен? (Часть 3)
BespalePhone
Содержание (ч.3)
Часть 2 (...2.2.7.2. нейтрализуем человека-посередине SHA (1995), Poly1305 (2005))
2.2.7.3. правдоподобно отрицаем
2.2.8. циферки
2.2.9. типы данных
2.2.9.1. файлы
2.2.9.2. звонки SRTP (2004) + DTLS (2012), WebRTC (2011)
2.2.10. промежуточный итог 2
2.2.7.3. правдоподобно отрицаем
Ключи распределили, целостность/аутентичность подтвердили, но..
Представим:
1️⃣мусора знают, кто такие a и b
2️⃣пасут их, следовательно, пасут все пакеты
3️⃣пасут и копят
4️⃣не ломают, не брутят, не mitm'ят
5️⃣тупо складывают в свою мусорскую сорм-коробочку, лишь индексируя маршруты: a->b|b->a
6️⃣и вдруг, один день, 5 утра, сразу по двум адресам: здрааасьте, а вам тут крипто-ректалочка подъехала, не желаете? тогда может пин от телефончика?
7️⃣а вот и ключики
8️⃣где там наши пакетики?
Представили?
Рассуждения о "правдоподобном отрицании" в подобной ситуации выглядят комично (но только не для a и b).
Поэтому данная проблема должна решаться сугубо в технической плоскости, исключив человеческий (крипто-ректальный) фактор из схемы.
Как этого добиться?
Да очень просто: доходим до пункта с ключиками(7️⃣), и делаем так, чтобы они были бесполезны для всего того, что накопили эти проклятые коррупционеры.
Как?
Одноразовые ключи:
1 пакет(текст/файл/звонок) - 1 ключ
новый пакет - новый ключ
новый ключ перезаписывается поверх старого
нет старых ключей -> нет физической возможности расшифровать -> нечего и отрицать -> bingo
2.2.8. циферки
Итак, мы рассмотрели наиболее базовые вещи (протоколы/алгоритмы)
Я не зря так подробно останавливался на aes, chacha, rsa, dh и его ec, sha, poly.
Все это - базовые вещи, базовые алгоритмы/протоколы.
Именно они (или их менее именитые аналоги) и лежат в основе любого современного е2е, что мы скоро наглядно и увидим.
Но перед тем как уже перейти к столь разным и столь одинаковым современным протоколам е2е, надо еще упомянуть пару вводных моментов.
Момент первый (совсем простой):
🔢цифры
ко всем указанным ранее протоколам/алгоритмам, как правило прилепляют в конце какую-то цифру, например: aes128/rsa4096/dh2048/sha256 итд.
Буквы мы теперь хорошо понимаем что означают (ну +-😁), а вот что значат эти цифры.. о чем они нам говорят?
Все довольно просто:
цифры - это всего-навсего физический размер (ключа/серта/хеша)
Этот размер исчисляется в битах (единица создания информации)
Именно поэтому эти странные цифры всегда (почти) делятся на 8 - чтобы из битов получить байты (единица хранения/пересылки информации)
Т.е. aes256 - означает, что для шифрования создан и применен 256-битный ключ, rsa2048 - 2048-битные ключи (🗝🔑), и так далее по аналогии.
Как это трактовать применительно к обеспечению безопасности?
Можно сказать так:
чем больше цифра, тем физически больше ключ/хеш (т.е. ключ rsa4096 прям ровно в 2 раза больше ключа rsa2048), тем лучше
Но
Так это работает строго в рамках одного протокола/алгоритма, т.е.:
rsa4096 лучше чем rsa2048, а aes256 лучше чем aes128 (хотя идут споры), а sha512 лучше чем sha256
но
sha512 НЕ лучше чем aes256, а rsa4096 - НЕ лучше их обоих, только лишь потому что циферки больше
Это так не сравнивается, каждый протокол имеет свою реализацию, свои ключи, и размер играет роль сугубо в рамках одного конкретного протокола.
Ну и кроме того
Бывают и исключения в этой стройной теории о циферках (биты/байты/8):
уже многократно упомянутый Бернште(а)йн, с его Salsa20/ChaCha20, poly1305 и эллиптическими кривыми (ec), где цифры вообще очень странные и разные😁🤷♂️. Что он там хотел своими цифрами сказать, уже рассуждать не возьмусь, но полагаю тоже что-то связанное с математикой.
Как бы там ни было, на наши рассуждения это уже никак не влияет, так что будем считать по 🔢цифрам разобрались.
2.2.9. типы данных
Теперь момент второй:
🔣типы данных (типы пакетов)
Условно говоря, всю нашу интернет коммуникацию можно разделить на три типа:
1. текст
2. файлы
3. звонки
С текстом все понятно, это в первую очередь сообщения, а также ключи/серты/хеши - все это тоже текст.
И все описанные ранее протоколы/алгоритмы в первую очередь относятся именно к тексту.
Но вы скажете: текст - это пакет - это же файл, и будете правы.
Но текст - это физически очень маленький файл. И этот факт самой своей природой обеспечивает скорость: маленький файл в любом случае быстро шифровать/дешифровать.
2.2.9.1. файлы
Чего не скажешь о хотя бы даже картинке, которая весит как несколько десятков, а то и сотен сообщений, соответственно делим скорость на 10-100. А теперь представьте видео.
Поэтому файлы вынесены в отдельную дисциплину. И это не я так решил, а протоколы так реализованы😁
Файлы МОЖНО надежно е2е-зашифровать и отправить (a<->b), порешав даже все 3 уебищных проблемы по дороге.
Не бином Ньютона, человечество уже давно на это способно.
Но далеко не всегда это делается, далеко не каждый мессенджер так щепетилен с файлами в рамках своего комплексного е2е-решения.
Зачастую, файлы если и шифруются, то сервер-бейсд (tls), что, как мы хорошо понимаем, никакого е2е между a и b не обеспечивает: сервер-то видит наши пип-фотки, какое ж это е2е.
Поэтому
Мухи отдельно, котлеты отдельно:
смотрим отдельно что там с е2е по тексту
и
смотрим отдельно что там с е2е по файлам
2.2.9.2. звонки SRTP (2004) + DTLS (2012), WebRTC (2011)
Ну и совсем отдельно стоят звонки.
И в данном случае выделяются они не размером пакетов, а типом соединения:
звонок [только не смейтесь] - это всегда сугубо и исключительно p2p
Да-да, всегда, когда мы звоним - мы общаемся p2p, напрямую, пакеты с данными (голосом) - летят сугубо между a и b, не заходя на центральный сервер вообще.
И хотя мы уже взрослые и прекрасно понимаем, что сервер все равно должен присутствовать (чтобы сконнектить a и b, создать саму сессию), но сам звонок - всегда p2p, и это дает некие бонусы по безопасности.
При этом, если по тексту/файлам мы имеем хоть какие-то вариации/адаптации/аналоги/развитие.. То, взглянув на звонки, мы в 99% случаев упремся в комбинацию:
srtp+dtls
Что такое srtp?
[следим за руками]:
📍aes128 (*модернизированный из блочного в поточный) - само шифрование
📍dh + серверная асимметрия - распределение ключей
📍sha1 - целостность/mitm
📍одноразовые ключи (1 звонок - 1 ключ) - отрицание
Лица все знакомые, но не все приятные, в частности sha первой версии явно хромает.
Но главное, что смущает - сервер-based ключи, пусть и через диффи. "Надежность" сертов/центров мы уже наглядно разобрали, поэтому и назвать srtp надежным можно разве что с натяжкой.
Конечно, в отличии от классического "скопить пакеты+паяльник в жопу", в данном случае мусорам придется внатуре поработать:
1️⃣захватить srtp-сервер ЗАРАНЕЕ
2️⃣понять, подчинить, видоизменить и online-контролировать распределение ключей
3️⃣засесть где-то-посередине, при том что это "где-то" может легко меняться от звонка к звонку, а инфраструктуру там развернуть придется совсем нехилую
И это еще лишь пол-мусорской-беды, т.к. есть же еще "+ dtls", который при звонках как раз и используется для доп. защиты от человека-посередине.
Но, к сожалению уже для нас, dtls - опять же серверный протокол.
Что такое dtls?
[следим за наперстками]:
📍aes128 - шифр
📍ecdh - ключи
📍sha256 - mitm
📍[и зачем-то, полагаю, как серт-центр] tls
Ну что можно сказать.. dtls был бы неплох, если б не tls😁
Что можно сказать, возвращаясь к реальности/мусорам?
Если мессенджеру хватило мозгов (привет владельцу/разработчику) разнести подальше друг от друга srtp- и dtls-сервера, желательно по разным юрисдикциям и собственникам (как это делаем мы со своими BespaleVPN-серверами, например), тогда мусорам ЕЩЕ придется:
1️⃣.1️⃣захватить dtls-сервер ЗАРАНЕЕ
2️⃣.1️⃣понять, подчинить, видоизменить и online-контролировать dtls-ключи/серты/хеши
3️⃣ -//-
4️⃣поддерживать всю эту конструкцию в боевой готовности 24/7, при том что "где-то-посередине" все время плавает и легко может быть/стать недоступным, непригодным по тех.условиям, а то и вовсе - неизвестным
5️⃣всем этим должен управлять большой международный штат высококвалифицированных специалистов, выполняя большую часть работы вручную, причем в спешке, т.к. звонок происходит здесь и сейчас
6️⃣и все это, весьма вероятно, лишь ради: "Привет, как ты? - Занят, перезвоню"
Как видно, нормально реализованные звонки (srtp+dtls) разломать не так уж и просто, если вообще возможно.
Конечно, в реальности никто подобной хуйней заниматься не станет. Имея такие ресурсы, гораздо проще обратиться в гугл/эпл и вежливо попросить удаленный доступ прямо к телефонам a/b, откуда удобненько подснять не какой-то там рандомный звонок, а СРАЗУ ВСЕ, по всем мессенджерам, в расшифрованном виде и с удобным интерфейсом. От подобного развития событий ни один мессенджер защитить, естественно, не в состоянии, но сейчас это выходит за рамки обсуждения.
Завершая тему звонков, стоит также упомянуть webrtc, который порой заявлен как протокол шифрования звонков. Но в действительности, шифрование звонков внутри webrtc всегда реализовано..? правильно - srtp+dtls. Справедливости ради, надо сказать, что webrtc - это далеко не только звонки, и далеко не только шифрование. Это довольно обширная веб-технология, обсуждать которую мы опять же сейчас не будем.
Итого по звонкам:
srtp+dtls - хоть и 2 раза server-based, хоть и теоретически уязвим, но в реальной жизни он будет надежен в 99.9% случаев
А если с обеих сторон - a и b - еще и по даблвпну натянуть (bespale, например😁)
При реализации звонков, протокол dtls используется исключительно для обеспечения целостности и защиты от mitm, сами же данные (разговор) шифруются по протоколу srtp
Также, вы можете встретить громкое заявление о том, что звонки у нас, мол, шифруются по новой webrtc-технологии
Но ковырнув пальцем буквально на пару ссылок дальше википедии, мы легко можем обнаружить, что шифрование в этой новой технологии реализовано (ну надо же) по протоколу srtp+dtls (бывает же)
Но, надо признать, что webrtc - это не только звонки, технология довольно обширная, в частности позволяет обмениваться файлами, правда какие протоколы применяется в этом случае - редакция сказать затрудняется, может кто подскажет, предположительно все те же srtp+dtls..
_
Итого по е2е для звонков: это всегда srtp+dtls
И это значит - 2 раза server-based
Звонки - единственный тип соединения, где основные пакеты с данными (разговорами) летят строго p2p, минуя сервер мессенджера
Но при этом тухлый золотой и единственный стандарт е2е-шифрования звонков - делает доверие к серверу (привет владельцу/разработчику) - КЛЮЧЕВЫМ параметром безопасности при совершении звонка
Какая ирония, вы не находите?😁
2.2.10. промежуточный итог 2
Ну вот мы и готовы уже, наконец, погрузиться в реальность, в то что применимо прямо вот сейчас.
Но сначала резюмируем и зафиксируем всю изложенную выше е2е-теорию, сформировав таким образом понятную модель (механизм) оценки этого параметра.
Итак.
#1️⃣
Надежно зашифровать sодержание можно с помощью следующих симметричных алгоритмов:
📍aes (128/256)
и/или
📍Salsa/ChaCha
#2️⃣
Надежно распределить ключи можно с помощью:
#3️⃣
Надежно защититься от человека-посередине можно с помощью:
#4️⃣
Правдоподобно отрицать поможет:
📍протокол 1 ключ - 1 пакет
#5️⃣
Ну и все коммуникации делятся на 3 типа данных:
Ну воооот
Если по всем пунктам - все хорошо, то только тогда это будет надежное е2е-шифрование (т.е. всего лишь 1 параметр оценки).
А еще ведь был владелец/разработчик😁