Подробности криптографии Bitmask

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

Аутентификация – парольная аутентификация (SRP)

Bitmask использует парольную аутентификацию (Secure Remote Password, SRP) для проверки подлинности сервис-провайдера. SRP – это вид доказательства с нулевым разглашением для аутентификации посредством имени пользователя и пароля, которая не дает серверу копию действительного пароля. Как правило, системы паролей работают путем отправки копии пароля в незашифрованном виде серверу, который затем хеширует этот пароль и сохраняет хеш. Благодаря SRP, клиент и сервер договариваются о “верификаторе пароля” после нескольких проходов “туда-обратно”. У сервера никогда нет доступа к незашифрованному паролю.

Одним из дополнительных преимуществ SRP является то, что обе стороны аутентифицируют друг друга. Для традиционных захешированных паролей сервер может сказать, что пароль правильный, даже если он не имеет ни малейшего понятия какой настоящий пароль. Благодаря SRP, пользователь аутентифицируется сервером, но сервер также аутентифицируется пользователем.

В настоящее время мы используем 1024-битные параметры дискретного логарифма. Мы изучаем их увеличение до 2048-битных.

Для SRP существуют некоторые ограничения. Скомпрометированный или бесчестный провайдер может попытаться грубой силой взломать пароль, пробуя миллионы комбинаций, точно так же как с обычными захешированными паролями. По этой причине, по-прежнему важно выбирать надежный пароль. На практике, однако, пользователи ужасно выбирают надежные пароли.

Второе ограничение связано с веб-приложением. Оно также использует SRP, но javascript-код SRP загружается от провайдера. Если провайдер скомпрометированный или бесчестный, он может загрузить некоторый javascript-код, чтобы захватить пароль пользователя.

У нас есть три плана на будущее, чтобы преодолеть эти потенциальные проблемы:

1. Разрешить использование дополнительного длительного случайного ключа, который используется как часть процесса аутентификации (необязательно). Например, каждое устройство, на котором установлен Bitmask, могло бы иметь “ключ устройства”, и пользователь должен был бы авторизовать эти ключи устройства, прежде чем они могли бы запускать Bitmask на этом новом устройстве.
2. Мы также планируем включить в Bitmask фильтр Блума 10,000 наиболее часто используемых паролей. По некоторым данным, 98,8% всех пользователей выбирают пароль из этих 10,000. Фильтр Блума этих паролей является относительно небольшим, и мы можем просто запретить пользователю выбирать любой из них (хотя и с некоторыми ложными срабатываниями).
3. Разрешить провайдерам запрещать аутентификацию через веб-приложения. Аутентификация будет происходить посредством приложения Bitmask, которое затем загрузило бы на веб-сайт с помощью сеансового токена, который оно получило. Таким образом, критический код аутентификации SRP никогда не будет загружаться от провайдера.

Для получения дополнительной информации смотрите:

• srp.stanford.edu
• en.wikipedia.org/wiki/Secure_Remote_Password_protocol
• xato.net/passwords/more-top-worst-passwords

Транспорт – TLS

Клиент Bitmask часто делает различные соединения с провайдером, используя TLS. Например, чтобы проверить есть ли обновление списка VPN-шлюзов.

Когда сервис-провайдер впервые добавляется Bitmask, сертификат центра сертификации от провайдера загружается с помощью обычного TLS-соединения, аутентифицированного с помощью существующей системы сертификации X.509. Это единственный момент, когда Bitmask полагается на систему сертификации.

Все последующие соединения с тем провайдером используют центр сертификации конкретно для этого провайдера для проверки подлинности TLS-соединения. По сути, это форма пиннинга сертификатов и TOFU. Для того, чтобы внешнему злоумышленнику выдать себя за провайдера, он должен предоставить ложный сертификата сервера X.509, аутентифицированный центром сертификации, а затем перехватить и переписать весь последующий трафик между клиентом Bitmask и провайдером.

Если провайдер был предварительно установлен приложением Bitmask, то отпечаток сертификата центра сертификации для этого провайдера известен заранее. В подобных случаях нет нужды когда-либо полагаться на систему сертификации X.509.

По умолчанию сертификат центра сертификации для конкретного провайдера использует 4096-битный RSA и SHA256, сертификаты сервера используют 4096-битный RSA и SHA256. Эти значения по умолчанию можно легко изменить.

Все TLS-соединения используют шифры PFS.

Зашифрованный туннель – OpenVPN

OpenVPN имеет три параметра, которые управляют тем, какие шифры он использует (есть и четвертый, --tls-auth, но мы не можем его использовать в публичном многопользовательском окружении). Каждый провайдер может легко выбрать любые опции по своему желанию. Ниже приведены текущие значения по умолчанию, которые идут с leap_platform.

tls-cipher

Параметр --tls-cipher определяет процесс аутентификации сеанса OpenVPN. Если он будет скомпрометирован, то вашу коммуникацию сможет прослушивать злоумышленник с помощью атаки посредника. TLS часть OpenVPN аутентифицирует сервер и клиент друг с другом, и согласовывает случайное значение, используемое в значении пакетной аутентификации и пакетном шифровании.

Вместо того, чтобы позволять множество вариантов, Bitmask поддерживает только один шифр (для предотвращения атаки отката).

На данный момент, мы выбрали DHE-RSA-AES128-SHA. Самое главное заключается в выборе шифра, который поддерживает PFS, как это делают все шифры DHE.

Мы выбрали AES-128 потому что известны слабости алгоритмов смены ключей AES-192 и AES-256. Неизвестны слабости к атакам прямого перебора на полный 14-раундный AES-256, однако слабости AES-256, использующего другие числа раундов, достаточно, чтобы рекомендовать AES-128 вместо AES-256 в целом. Для получения более подробной информации смотрите статью Брюса Шнайера Еще одна новая атака на AES.

Мы бы предпочли использовать ECC вместо RSA, и в конце концов планируем это сделать. Это немного сложнее и включает в себя изменения в нашем коде TLS во многих местах (перекомпиляции OpenVPN и изменение библиотек генерации сертификатов, используемых системными администраторами и API провайдеров).

Текущий стандарт для клиентских и серверных сертификатов x.509, используемых OpenVPN, является 2048-битный RSA и 4096-битный RSA (соответственно) с SHA256. Они также легко настраиваются провайдером (чтобы увидеть все варианты, запустите leap inspect provider.json).

auth

Параметр --auth определяет какое хеш-значение используется для аутентификации каждого пакета трафика с помощью HMAC.

Мы решили оставить по умолчанию SHA1 вместо SHA256. Если злоумышленник может нарушать SHA1 HMAC на каждом пакете в режиме реального времени, у вас проблемы больше, нежели только с VPN.

cipher

Параметр --cipher определяет как шифруются действительные пакеты трафика. Мы выбрали AES-128-CBC.

Значение этого параметра OpenVPN по умолчанию, вероятно, на самом деле лучше, чем AES-128, так как это Blowfish. Мы выбрали AES-128, потому что шифр TLS уже полагается на AES-128. Мы, как правило, предпочитаем режим шифра OFB вместо CBC, однако в руководстве по OpenVPN говорится, что “рекомендуется CBC, а CFB и OFB следует рассматривать как расширенные режимы”.

obfsproxy

Obfsproxy опционально использоется так, чтобы VPN-трафик не распознавался как VPN-трафик для кого-либо, кто осуществляет мониторинг сети. Obfsproxy использует модули, называемые встраиваемыми транспортами, чтобы скрыть основной трафик. Различные транспорты могут использовать или не использовать шифрование и иметь различные реализации и выбор схем шифрования.

Мы выбрали подключаемый транспорт Scramblesuit, который использует унифицированный Диффи-Хеллмана для начального рукопожатия и AES-CTR 256 для данных приложения.

Зашифрованная электронная почта – OpenPGP

Автоматически генерируемая пара ключей пользователя использует 4096-битный RSA для главного подписывающего ключа.

Bitmask откажется шифровать открытым ключом получателя, если его длина составляет 1024 бита или менее.

Все ключи хранятся в Soledad.

Bitmask пока не поддерживает ECC ключи.

Bitmask использует GnuPG. Библиотекой python, которую мы используем, является форк Айсис python-gnupg.

Разное

OpenSSH

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