Прошу прощения за желтый заголовок, но думаю, это действительно стоит обсудить.
Итак, по словам автора приложения APRSdroid, начиная с Android 2.3 при установке SSL-соединения вместо использовавшейся ранее комбинации алгоритмов шифрования и хэширования AES256 и SHA1 первой стала предлагаться значительно более слабая комбинация из RC4 и MD5.
Почитать пост с описанием этого открытия вы можете по ссылке.
Оставляя за скобками мотивы разработчиков android установить приоритет именно для этих алгоритмов, я хочу рассказать чем плох RC4 в качестве основного метода шифрования и чем это чревато для SSL.
Уязвимость шифра RC4
RC4 является потоковым шифром, с внутренним состоянием состоящим из 256 элементов. Фактически, RC4 состоит из двух частей:
- Алгоритм инициализации — на вход алгоритма подается ключ шифрования. Алгоритм заполняет внутреннее состояние шифра и производит перемешивание путем перестановок, определяемых ключем.
- Генератор псевдослучайных чисел — производит перемешивание внутреннего состояния и возвращает псевдослучайную последовательность байтов.
В дальнейшем сгенерированная гамма суммируется по модулю два с открытыми данными и получается шифротекст.
Важнейшим условием предъявляемым к потоковым шифрам является абсолютная неотличимость производимой ГПСЧ гаммы от случайной последовательности байт.
Проблема в том, что RC4 не соответствует этому условию.
Было установленно, что каждый из первых 256 байт выходной последовательности RC4 имеет отличную от 1/256 вероятность оказаться равным нулю.
Это означает следующее. Предположим злоумышленник смог собрать достаточно большое количество одного и того же сообщения длиной 256 байт, зашифрованного различными ключами. Т.к. вероятность того, что каждый из 256 байт гаммы, используемой для шифрования, равен нулю выше среднего показателя 1/256, атакующий может проверить каждый байт всех имеющихся шифротекстов и с большой долей успеха предположить, что наиболее часто встречающийся байт и является исходным. Раскрывая байт за байтом атакующий сможет раскрыть все сообщение целиком.
Протокол записи SSL
Теперь поговорим о том насколько это все применимо к SSL.
Итак, после того как в результате протокола рукопожатия будет сформирован сеансовый ключ весь дальнейший трафик будет шифроваться с помощью RC4.
Первым шифруемым RC4 сообщением является блок данных называемый Finished. Finished служит для подтверждения установления связи. Он состоит из 36 байт, генерируемых каждый раз по новому. Соответственно для атакующего расшифровка этого блока не представляется возможной.
В итоге остается 220 байт полезной информации, которую можно раскрыть с помощью данной атаки. И это плохая новость, т.к. этого вполне достаточно чтобы восстановить ваш пароль или cookies.
К с частью, есть и хорошая. На сегодняшний день атака трудно реализуема на практике. Как я уже писал для вскрытия нужно собрать большое количество одного и того же зашифрованного текста. Создатели атаки утверждают, что для восстановления 80 байт из 256 необходимо 226 шифротекстов. Для вскрытия всего блока длиной 256 байт, понадобится 232.
Впервые успешную атаку на эту уязвимость удалось осуществить в марте 2013 года. Поэтому, можно сказать, что это очень новый и весьма перспективный тип атак, который весьма вероятно уже скоро будет усовершенствован.
В заключение я бы хотел вставить несколько слов обо всей этой ситуации которая сложилась вокруг протокола SSL в последнее время. Честно говоря, меня это все несколько удивляет. Криптография за последние годы очень сильно продвинулась вперед. Новый стандарт SHA-3 неотличим от случайного оракула. Разрабатываются асимметричные криптосистемы стойкие к атакам на квантовых компьютерах. Появляются режимы шифрования гарантирующие как аутентификацию так и конфиденциальность сообщения. Но при всем при этом мы до сих пор пользуемся протоколом 14 летней давности. Может быть пришло время попробовать что-нибудь поновее? В противном случае нас все чаще будут «радовать» заголовки о том, что кто-то, где-то использует ослабленный вариант SSL.
Ссылки
Краткое описание атаки.
Брюс Шнайер об атаке.
Подробное описание(pdf)
Автор: NeverWalkAloner
