Security for all - #37 - 11 мая 2020

Это я, почтальон Печкин - Proton Mail

Сегодня

Сегодня я расскажу про почтовый сервис ProtonMail. Он предоставляет возможность шифрования почты для своих пользователей. А также позволяет послать зашифрованное письмо внешнему адресату, который использует почтовый сервис без поддержки шифрования. Давайте разбираться, как это реализовано в ProtonMail.

Картинка недели

https://turnoff.us/geek/the-depressed-developer-54/

Введение

ProtonMail - почтовый сервис, который позиционируется себя, как сервис предоставляющий надежное шифрование электронной почты. В 2016 году компания выпустила документ, в котором говорится следующее:

“ProtonMail conservatively assumes that all mailservers may eventually be compromised. Thus, ProtonMail uses end-to-end encryption to ensure that plaintext email data is never sent to the server. If a server only contains encrypted messages, then the risks of a central server breach are mitigated.” ProtonMail Security Features and Architecture Specification, 2016 (https://protonmail.com/docs/business-whitepaper.pdf)

“ProtonMail консервативно предполагает, что все почтовые сервера в конце концов могут быть скомпрометированы. Поэтому ProtonMail использует шифрование точка-точка для того, чтобы сообщения электронной почты никогда не попадали на сервер в открытом виде. Если на сервере содержатся только зашифрованные сообщения, то угроза компрометации основного сервера уменьшена.” Особенности безопасности и спецификация архитектуры ProtonMail, 2016 (https://protonmail.com/docs/business-whitepaper.pdf)

Разработчики ProtonMail создавали свой сервис с учетом возможных угроз. Первая угроза - это компрометация сервера. Основной целью сервиса является защита переписки. В случае компрометации сервера атакующие получают доступ к хранящимся на нем данным. Поэтому переписка не попадает на сервер в открытом виде. Вместо этого клиенты шифруют переписку и отправляют на сервер уже зашифрованные данные.

Расшифровать данные можно с помощью пароля. Поэтому сервер не должен знать этот пароль. При этом сервер должен проверить, что клиент знает пароль, и отдавать зашифрованные данные только в этом случае.

Давайте разбираться, как удалось обеспечить такую функциональность и остались ли какие-нибудь проблемы.

Пароль и аутентификация

Обычно пароль посылается серверу в открытом виде. Если сервер каким-либо образом будет скомпрометирован, также будет скомпрометирован пароль или его эквивалент. Чтобы избежать компрометации пароля, в Proton Mail используется протокол Secure Remote Password, который предполагает проверку пароля пользователя без передачи этого пароля по сети. Алгоритм работы этого протокола похож на алгоритм Диффи-Хелмана. Но в отличие от последнего для генерации общей части используется пароль клиента и верификатор, сохраненный на сервере в момент регистрации. Также этот протокол позволяет обеим сторонам убедиться, что другая сторона знает пароль или верификатор.

PGP

Для защиты переписки в Proton Mail используется старый добрый PGP. Кратко напомню суть. Каждый пользователь имеет свою пару приватного и публичного ключа асимметричного шифрования. Для шифрования каждого сообщения генерируется симметричный ключ. Затем сообщение шифруется этим ключем. А сам ключ шифруется публичным ключом получателя. Опционально автор сообщения подписывает его цифровой подписью.

Одна из проблем PGP - управление ключами асимметричного шифрования. Первый вариант - носить приватный ключ с собой, чтобы использовать на разных устройствах. Второй вариант - хранить ключ онлайн и получать при входе на сервер. В сервисе Proton Mail выбран второй вариант. Он удобнее и проще для пользователей.

Приватный ключ генерируется на основе идентификатора пользователя (то есть его почтового адреса) и пароля. Публичный ключ в открытом виде и зашифрованный на пароле пользователя приватный ключ передаются на сервер. При успешном входе север возвращает зашифрованный приватный ключ и клиент может его расшифровать с помощью своего пароля.

Зашифрованные письма могут быть отправлены любому пользователю, у которого есть публичный PGP ключ. Если у получателя есть аккаунт Proton Mail, то публичный ключ автоматически получается с сервера и используется для шифрования сообщения. Если аккаунта нет, то нужно вручную добавить его публичный ключ.

EO (Encrypt-to-Outside)

Но что делать, если у получателя нет публичного ключа? Как безопасно отправить сообщение? У сервиса Proton Mail есть опция Encrypt-to-Outside. Как следует из названия, данная функция позволяет зашифровать сообщение для внешнего получателя. Для шифрования необходим будет пароль, который обе стороны согласуют по какому-нибудь каналу, например, посредством звонка.

Пароль используется для шифрования самого сообщения и случайно сгенерированного токена. Затем зашифрованное сообщение, зашифрованный и открытый токен отправляются серверу Proton Mail. После этого сервер отсылает письмо с приглашением получателю.

При переходе по ссылке из письма браузер получателя должен будет расшифровать зашифрованный токен с помощью пароля и отослать серверу. Если токен от пользователя совпадает с тем, что хранится на сервере, значит пароль верный и сервер может отдать зашифрованное сообщение.

Угрозы

В конце документа, опубликованного командой Proton Mail, рассмотрены некоторые угрозы. В основном речь про защиту данных при передаче, надежность инфраструктуры, отказоустойчивость и защиту от DoS атак. Но ни слова об анализе угрозы компрометации сервера, о которой речь шла в самом начале документа.

Представим, что сервер был скомпрометирован. Какие возможности появляются у атакующего?

Во-первых появляется возможность оффлайн перебора пароля. На сервере хранится зашифрованный приватный ключ. Злоумышленник может пытаться его расшифровать разными паролями, например из словарей или утечек паролей, и сопоставлять расшифрованный приватный ключ и публичный ключ аккаунта. Если они сойдутся, значит пароль найден.

Во-вторых у атакующего будет возможность заполучить пароль пользователя. Но не во всех случаях. Сам протокол проверки пароля достаточно надежен. Если пользоваться проверенным приложением, то проблем не видно. Но если использовать web интерфейс почты, то в этом случае скомпрометированный сервер может отправить браузеру любой код и браузер должен будет доверять этому коду. У него нет причин не доверять. И вот этот подмененный код может, например, в дополнение к основной функциональности сервиса банально отправить введенный пользователем пароль на сервер злоумышленника. Тем самым злоумышленник получит пароль и доступ к ящику.

Проблема с подменой кода, который будет выполнять браузер актуальна как для основного функционала сервиса, так и для функции encrypt-to-outside.

Послесловие

Получается, что сервис не идеален и у него есть проблемы. Но знают ли об этом разработчики? Конечно, знают. У них даже есть специальная страница (https://protonmail.com/blog/protonmail-threat-model/), на которой они поясняют, что ни одна система не безопасна на 100%. Все зависит от модели угроз. От каких-то угроз система защищена, от каких-то нет.

В частности разработчики описывают угрозу “Unauthorized backdoor” (“неавторизованный бэкдор”). Это именно та угроза, о которой мы говорили. Разработчики утверждают, что они реализовали различные механизмы защиты, которые усложнят исполнение этой угрозы. Но полной гарантии защиты от нее нет.

Ссылки по теме

https://eprint.iacr.org/2018/1121.pdf

https://protonmail.com/docs/business-whitepaper.pdf

https://protonmail.com/blog/protonmail-threat-model/

В следующем выпуске я расскажу про цикл безопасной разработки ПО - SDL. Что это такое, кто придумал, для чего и почему при существовании цикла безопасной разработки в софте все еще остается много дыр.

На этом на сегодня все. До следующего выпуска.