Данный пост является вольным пересказом-переводом статьи, опубликованной недавно в New York Observer. Помимо упоминаний некоего стартапа, о котором я тактично умолчу, дабы не быть заподозренным в рекламе, в статье содержится ряд интересных мыслей по поводу светлого будущего end-to-end шифрования. Признаюсь честно, меня эта тема сильно интересует и хотелось бы узнать мнение сообщества по этому вопросу. Итак, под катом частичный перевод статьи с незначительными авторскими добавлениями.
В марте 2014 года Google убрал возможность использовать Gmail по незашифрованному соединению. В этом году компания повысила уровень безопасности, добавив специальные иконки, сигнализирующие о том, что email-провайдер корреспондента не поддерживает HTTPS.
Компания из Маунтин-Вью делает очень многое (хотя не факт, что достаточное) для защиты информации своих пользователей от третьей стороны. Тем не менее, вопрос защищенности данных пользователей от самой компании по прежнему остается открытым.
До разоблачений Сноудена, говорится в статье, не было никаких доказательств того, что третья сторона действительно существует. Кое-кто возможно и был слегка обеспокоен способностью облачных сервисов просматривать персональные данные пользователей, но мало кто верил, что эти данные действительно просматриваются. Сейчас же практически всем стало понятно, что как минимум правительство совершенно не прочь заглянуть в ваши личные файлы.
Это понимание послужило толчком к смене общественного сознания. От сомнений в обоснованности end-to-end шифрования многие пришли к выводу о его абсолютной необходимости.
End-to-end означает, что ключи, необходимые для шифрования и расшифровки передаваемых сообщений, хранятся исключительно у участников переписки. Другими словами, email и все вложенные файлы могут проходить через дюжину сторонних серверов, и при этом иметь совершенно нечитаемый вид, до тех пор, пока не достигнут указанного получателя. И только последний сможет расшифровать и прочитать сообщение.
Полноценного end-to-end шифрования можно добиться, используя такие программы как PGP. С помощью PGP пользователи могут сгенерировать пары открытых/закрытых ключей и использовать их для end-to-end соединения. Способ этот однако требует от пользователей достаточно широкой технической осведомленности. При этом не стоит забывать, что зашифрованное по умолчанию PGP сообщение содержит информацию об id ключа получателя сильно снижая тем самым уровень анонимности.
Рассматривая ситуацию с точки зрения компаний, следует принять во внимание цену, которую они вынуждены платить за использование end-to-end шифрования. Цена эта заключается в невозможности сбора данных о своих пользователях. Microsoft ведет активную борьбу с правительством Соединенных Штатов за право уведомлять своих пользователей о случаях, когда спецслужбы получают доступ к персональным данным. Но такой доступ был бы невозможен, если бы Microsoft внедрил end-to-end шифрование для своих сервисов.
С другой стороны end-to-end шифрование может стать чрезвычайно важным требованием в набирающем популярность Интернете вещей. В мире, где каждый светофор и каждый автомобиль подключены к сети Интернет, а смартфоны знают все о своих владельцах, аутентификация и шифрование становятся жизненно необходимыми.
Последние новости из стана мессенджеров позволяют оптимистично смотреть на перспективы повсеместного внедрения функции end-to-end шифрования. WhatsApp недавно добавил такую возможность к своему мессенджеру. Viber и Google похоже движутся в том же направлении. Все это указывает на то, что крупные компании приняли новые условия игры.
И быть может совсем скоро пользователи перестанут надеяться, что сервисы не просматривают их персональные данные. Сервисы просто не смогут просматривать эти данные.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Комментарии (40)
FirExpl
26.04.2016 10:04+1Мне интересно вот что: а каким образом такие мессенджеры защищены от MITM-атаки на этапе обмена ключами шифрования? Или опять нужно надеяться на добропорядочность разработчиков сервиса?
NeverWalkAloner
26.04.2016 10:16В Telegram, к примеру, есть возможность сверки ключей. Т.е. пользователи могут проверить, что они используют один и тот же ключ для шифрования. При этом, если существовует MITM, то ключи у пользователей будут отличаться.
FirExpl
26.04.2016 11:23Я не знаком с протоколом работы телеграмма, а потому уточню: т.е. Алиса может определить, что между ней и Бобом есть Чак, который представился для Алисы Бобом, а для Боба Алисой?
NeverWalkAloner
26.04.2016 11:26Да, именно так. Для этого правда необходимо сверить отпечатки ключей, что может потребовать либо личной встречи, либо установления дополнительного защищенного канала.
FirExpl
26.04.2016 11:38+1В том то и проблема, что если есть другой защищённый канал, то зачем нужна возня с ключами для этого?) Ну а про личную встречу я думаю понятно, что это не всегда возможно, а в целом сводит на нет всю удобность технологии.
fRoStBiT
26.04.2016 13:28+1Без возни с ключами никуда.
Я вижу только такие варианты:
— сгенерить общий ключ, используя DH, и проверить его (что мы и видим)
— заранее обменяться открытыми ключами (через тот самый «другой канал» или при личной встрече)
— использовать удостоверяющий центр (но мы же не доверяем никому, да?)
Как ещё два человека могут создать надёжно защищённый канал связи?NeverWalkAloner
26.04.2016 13:32+1Есть еще вариант наподобие «blockchain», ключи могут быть подписаны другими пользователями. Ключ с наибольшим количеством подписей принимается в качестве валидного. Но тоже вариант, скажем так, на любителя.
FirExpl
26.04.2016 13:54+2Я к тому и клоню, что проблема присущая обмену ключами по Диффи-Хеллману в этих мессенджерах так и не решена(да она нигде не решена, в общем-то), а потому совсем уж радоваться безопасности не стоит. Стало безопаснее, да, но если кому-то сильно понадобится, то МИТМ по прежнему актуален.
lockywolf
26.04.2016 17:26+2Вы качаете открытый ключ с публичного сервера ключей, куда он залит пользователем.
Открытый ключ подписан закрытыми ключами кучи народу, с которой ты повстречался раньше. Значит ключу можно верить. Итого, личная встреча не обязательна.
Концепция называется «Web of Trust».
На самом деле, можно установить не защищённый канал, а просто позвонить другу по скайпу и попросить продиктовать фингерпринт. Технологий, позволяющих в режиме реального времени подменять голос так, чтобы он выглядел достоверно — не существует.
ivlad
27.04.2016 16:51> Как ещё два человека могут создать надёжно защищённый канал связи?
web of trust
deniskreshikhin
26.04.2016 11:39+1А разве ключи можно сверить побуквенно?
По-моему там какая-то картинка, аля найди 10 отличий.NeverWalkAloner
26.04.2016 11:42Если не ошибаюсь, то под картинкой сам отпечаток тоже написан.
deniskreshikhin
26.04.2016 11:49Насколько мне известно, нет:
Скрытый текст
darthslider
26.04.2016 12:34Думаю картинка — некий аналог хеша. Малейшее изменение ключа меняет картинку полностью и подобрать ключ с похожей на нужную картинку проблематично.
Kondra007
26.04.2016 13:12+1У Вас старый секретный чат или старая версия клиента. Начиная с 3.6 или 3.7 показывается ещё и отпечаток.
Пруф: https://habrastorage.org/files/4ba/291/5b5/4ba2915b57734c5bab4918f065e16366.png.
Более того, в одной из тех версий был осуществлен переход на более сильное шифрование (увеличили длину ключа), поэтому «квадратиков» стало больше. Прошу прощения за возможные некорректные определения «силы» шифрования, давно не брал в руки книг по криптографии.
denis_g
26.04.2016 17:55+1Та тут все просто, звонишь другу и диктуешь: #ffffff, #d4e6f2, #2f99c9, #2e5775… Только надо про систему координат заранее договориться ;)
Ivan_83
26.04.2016 15:36+3Не готов.
1. Только полностью ПО, желательно несколько реализаций на разных языках.
2. Полностью без серверов, те p2p.
3. Использование каскадов из разных криптоалгоритмов, чтобы иметь запас прочности на будущее.
4. Пользователи бестолковы (да и многие программисты) в вопросах крипты, а красного и зелёного не достаточно для объяснения происходящего.
Всякие телеграмы и прочие со своим открытым АПИ и серверами могут идти в лес, никаких гарантий они не дают, только обещания и PR.
Lockal
26.04.2016 19:05+15. DPI bypass (meek, obfs3 и пр.).
6. Инфраструктура не должна зависеть от Google Play и Apple Store (см. недавнюю историю с угрозами в сторону Telegram)
vsb
26.04.2016 16:40+1Основная проблема E2E шифрования это пользователи. E2E шифрование требует большой технической культуры: нужно уметь управлять своими ключами; нужно уметь сверять ключи с ключами своих собеседников и т.д. и т.п. Без этого это всё профанация.
Кстати вопрос в тему. Вот стоит у меня Whatsapp, я сижу в групповом чате, общаюсь. Купил себе новый телефон, старый вайпнул, соответственно новый ключ. Как он обрабатывает такую ситуацию? Меня выбросит из всех старых чатов и мне будет недоступна вся предыдущая история?shaukote
26.04.2016 17:38+3Это было бы странно, да и пользователи вряд ли оценят потерю всей истории переписки при смене аппарата.
Думается мне, там всё же что-то вроде end-to-end шифрования с резервным копированием приватного ключа в облако. :D
VolCh
26.04.2016 19:11+31. Не должны. По крайней мере в обязательном порядке, не оставляя пользователю выбора. Использование шифрования на клиентской стороне без возможности доступа к оригинальному контенту со стороны сервиса накладывает много рисков и ограничений. От невозможности доступа к своей информации при утрате ключа до невозможности проводить операции типа поиска на сервере.
Komei
27.04.2016 18:57+1>От невозможности доступа к своей информации при утрате ключа
Так в этом весь и смысл. Это не проблема, это сама цель. Нет ключа — нет доступа. Если это не так, то надобности в ключе ровно НОЛЬ.Komei
27.04.2016 23:57+1Может быть тот, кто пошёл и по тихому поставил мне минус в карму всё-таки попробует высказать тут свою позицию? Ибо я верю что аргументированная дискуссия будет более плодотворной чем слив кармы, ведь во время дискуссии можно переубедить своего визави, а сливом — нет.
VolCh
28.04.2016 19:39Для кого цель? Обычному пользователю вряд ли понравится всеобщее «нет ключа — нет доступа», хотя потребность в шифровании может и испытывать, но с возможностью восстановления ключа и(или) своих данных после подтверждения личности. Грубо говоря, ему всё равно, что его данные может прочитать сервис-провайдер или спецслужбы, обладающие «универсальным» ключом, но не всё равно, что это может сделать жена или начальник.
Komei
29.04.2016 00:34+1>Для кого цель?
Цель шифрования. Иначе вообще можно ничего не шифровать.
>с возможностью восстановления ключа и(или) своих данных после подтверждения личности
В цифровом мире подтверждением личности является именно обладание ключом. А как вы представляете себе эту процедуру? По паспорту (и прощай анонимность)? А вдруг он поддельный? Или по хешу сознания? :)
P.S. Бекапить свой ключ само собой не только можно, но и нужно.
>Грубо говоря, ему всё равно, что его данные может прочитать сервис-провайдер или спецслужбы, обладающие «универсальным» ключом, но не всё равно, что это может сделать жена или начальник.
Вот только универсальный ключ утечёт и его с радостью продадут жене и начальнику. У нас в стране продаются все базы всех силовых структур. Вы реально думаете что за деньги нельзя будет попросить «продажных ментов» чтобы они вам расшифровали (это если ключ не сопрут)?
Вообще пора уже просто принять правила цифрового мира (например о том, что защита или есть или нет, среднего состояния нет). Да, он забрал у нас ряд вещей, но он и дал ряд других. Что-то станет удобнее, а что-то наоборот будет требовать повышенного внимания. Один из величайших даров цифровой эпохи это именно шифрование и децентрализация (привет биткойну и т.п.) и не стоит отказываться от них хотябы потому, что то, что у вас забрали вам никто не вернёт.
P.S. К сожалению я сильно заматался сегодня и очень сумбурно написал, но добавлю ещё одну мысль: почему вы думаете частная компания (или отдельные её сотрудники) не продаст ваши ключи вашей жене и начальнику? Ваша судьба интересна только вам, для остальных вы лишь источник прибыли.VolCh
01.05.2016 23:41Цель шифрования. Иначе вообще можно ничего не шифровать.
Не утрируйте. Каждый конкретный вид шифрование — способ защиты информации с конкретной моделью доступа и угроз. Виды шифрования с моделью типа «получить доступ может обладатель одного из двух секретных ключей, не имея возможности вычислить другой ключ» вполне имеют право на жизнь.
В цифровом мире подтверждением личности является именно обладание ключом.
Большинство людей живут в обычном мире и в цифровом они подтверждают свою реальную личность.
По паспорту (и прощай анонимность)?
Типа того. А обычному пользователю для чего-то важного типа управления банковским счетом как раз не анонимность нужна, а подтверждение своей реальной личности.
А вдруг он поддельный?
Во-первых, это и так существующие риски. Во-вторых, вполне реально оспорить в суде и признанать все действия ничтожными.
почему вы думаете частная компания (или отдельные её сотрудники) не продаст ваши ключи вашей жене и начальнику?
Мой начальник и моя жена не заплатят столько за мои тайны, чтобы компания или сотрудники шли на репутационные риски.Komei
02.05.2016 00:38+1> Мой начальник и моя жена не заплатят столько за мои тайны, чтобы компания или сотрудники шли на репутационные риски.
О каких ещё репутационных рисках идёт речь? Посмотрите кругом. Если раньше сбор всяких телеметрий и т.д. считался беспределом и если кого и ловили, это и правда было какимито потерями. Сейчас это преподносится как норма. Посмотрите на последнее шоу от M$ с запретом на выбор кастомного поискового движка (а то вдруг M$ не сможет шпионить за вами или фильтровать вашу поисковую выдачу как её хочется). Вы и правда верите что кого-то в корпорациях волнует их репутация у простых людей? К сожалению вынужден вас огорчить — по всей видимости от считают людей за БЫДЛО (именно так выглядит их отношение, хотя на словах они конечно всё отрицают). Для сравнения с нормальным отношением я приведу цитату отсюда https://habrahabr.ru/company/croc/blog/280135/
> Естественно, не надо забывать, что штатный режим подразумевает отправку подозрительного трафика в их центры анализа, но ни веднор, ни интегратор не имеют права включать эту опцию без прямого согласования с вами, если не хотите делиться своим SSL-содержимым.
Т.е. по отношению к корпорациям репутации ещё придаётся какое-то значение. С обычным сервисом будет так: есть левая компания которая предлагает вам услуги чтения чужой почты, официально корпорация не при делах и как «хакеры» это делают не знает и т.д. Вы поймите, вы имеете дело с теми у кого заведомо нет совести, а на вас и ваше мнение о них им плевать.
> Типа того. А обычному пользователю для чего-то важного типа управления банковским счетом как раз не анонимность нужна, а подтверждение своей реальной личности.
Зачем вводить дополнительный узел на котором возможен отказ? Я уже молчу о том, что серьёзное подтверждение реальной личности процесс довольно длительный: нужно проверить документы (и не просто посмотреть на них, а провести их анализ), проверить что тот кто их предъявляет именно тот на кого они выданы (а как это сделать? анализ ДНК? Опрос соседей, друзей, родственников?). Вы посмотрите сколько занимает времени восстановление документов если человек лишился их всех. Да, конечно в реальности обычно просто смотрят на паспорт (и плевать подделан он или нет) и на то, похож ли предъявитель на фото. Т.е. защита от честных людей и не более. Цифровая эпоха как раз и дала нам возможность надёжной «проверки документов». Считайте что ваш ключ это ваш паспорт (только в отличии от бумажного его легко забекапить, хотя нельзя восстановить в милиции — т.е. одних способ защиты заменили другим). Я вообще думаю что пора уже бумажные документы заменить на цифровые — надёжнее. А от кражи цифрового документа защита такая же как и от кражи бумажного.
P.S. Я тут подумал и пришел к мнению что решать нужно именно проблему бекапа ключей, чтобы их не теряли:
1) На диске ассиметричный ключ всегда хранится в зашифрованном виде по такой схеме. Passphrase пользователя (обязательно проверяем надёжность) пропускается через KDF на основе SHA512. Из получившихся 512-бит ключа используем 384 (256 как ключ для AES и ещё 128 бит как начальное значение для CTR режима).
2) Приложение имеет опцию (возможно даже автоматически вызываемую) забекапить ключ в облако с тем условием что для бекапа в облаке используется другая passphrase (всё шифрование естественно производится на устройстве пользователя).
3) Приложение имеет опцию экспорта ключа для его помещения в произвольное резервное хранилище
4) ОЧЕНЬ ВАЖНО. При бекапе в облако большими буквами написано предупреждение что бекап ТОЛЬКО в облако это очень очень не надёжно, т.к. облако может сдохнуть.
Как вам такой вариант? И ключ не потеряешь и никто твою переписку читать не будет.
AndrewFoma
А где еще вариант вопроса: «Верите ли вы, что крупные компании при любом уровне шифрования для клиентов, не будут смотреть и собирать о вас данные?»
NeverWalkAloner
Просто суть end-to-end шифрования в том, что ключи будут хранится исключительно у пользователей. Т.е. компания при всем желании не сможет получить доступ к зашифрованным данным.
Все вышесказанное разумеется справедливо, только в случае абсолютно прозрачной реализации шифрования, с открытыми исходными кодами. Некий черный ящик, который якобы что-то там шифрует никакой безопасности, на мой взгляд, не добавляет.
lostpassword
Жжжесть какая-то, честно. Если только сделают единую стандартную библиотеку с открытым кодом и API, через который смогут работать приложения…
Но всё равно сомнительные какие-то конструкции, ИМХО.
Tdr
Такая библиотека есть – openssl. Мы применяем ее в нашем приложении для End-to-end шифрования переписки пользователя. Только мы мы делаем иначе – не канал шифруем, а контент. В зашифрованном виде он и на серверах хранится, и передается, и у получателей находится.
ivlad
В мобильном приложении применяете openssl?
Tdr
да
DeadKnight
Вообще-то открытый исходный код не требует билдить программы при выходе обновления. Хочешь, пользуйся собранными бинарниками.
Все что при этом требуется, чтобы бинарные файлы собранные в таком же окружении при тех же настройках совпадали с распространяемыми файлами.
Nikelandjelo
Так а кто будет это проверять? Получается всё равно надо локально собрать и сравнить.
DeadKnight
Ну, во-первых, существуют различные сертифицирующие организации.
Во вторых, сообщество.
Ну и в конце концов, достаточно чтобы это сделал кто-нибудь один, кому доверяют.
Nikelandjelo
Тут большая проблема в доверии. Получается, что гуглу, майкрософту не доверяют их закрытому коду, а организации сторонней доверяют. А что если эту организацию подкупили? Или человека, которому доверяют.
Lure_of_Chaos
При закрытых исходниках, есть вариант бэкдора, а также не забывайте про Heartbleed и пр.
y2k
Вряд ли это помешает приложению параллельно отправить «данные для улучшения сервиса» на свои сервера. А учитывая что объём этих данных ничем не ограничен… Вообще, мне иногда кажется, что мир уже смирился с отсутствием приватности в сети, и остаётся только надеяться, что он ещё не готов расстаться с ней в оффлайне…