Нет, мы описали атаку Timejacking. Она не была описана в статье Сатоши. Основное её отличие от атаки 51% состоит в том, что в теории для её успешного проведения требуется много меньше, чем 51% от общего хэшрейта сети.
На практике при реализации Timejacking атакующий встретится с неочевидными тонкостями, подробное описание которых вы и найдёте в нашей статье.
Модерация проходила не в ручном режиме, мы использовали специально обученную нейронную сеть, способную отличить фото/изображение кошки от любого другого. Подходили фото котов, взятые как при русскоязычном, так и при англоязычном запросе. Корректно обрабатывались даже загруженные участниками фотографии своих домашних котов, просто мы не включили их в подборку.
Вы отчасти правы. Похожую схему, хотя и без подробностей в описании реализации клиентской стороны и UI, мы описали в разделе «Схема для большинства» статьи.
Описанная вами схема действительно подходит для большинства случаев, однако она всё же оставляет окно для атаки: её всё ещё можно провести между обновлениями списка отозванных сертификатов. Это может быть неприемлемо для некоторых особо критичных к безопасности сервисов. К слову, это не обязательно могут быть веб-сервисы.
Другие возникающие вопросы — это: где хранить этот глобальный список и насколько он будет большим? Если его хранить локально, то на все ли устройства он поместится? Если хранить удалённо, то снова возвращаемся к вопросу о «человеке посередине». Если сокращать его размер, то возникает вопрос о его полноте. Но с этим, опять же, могут помочь сертификаты с коротким сроком действия.
В Google рассматривали подход, аналогичный Certificate Trancparency. Он тоже похож на обсуждаемую схему и называется «Revocation Transparency». Про него можно почитать вот тут. Насколько нам известно, его пока не планируют реализовывать.
К вопросу о «приватности», если мы вас правильно поняли, то он решается с помощью прикреплённых OCSP-ответов (OCSP stapling).
«TLS feature» и «status request» — это разные вещи. У «TLS featue» (оно же «OCSP must staple») только одна версия. Две версии у «status request» (оно же «прикреплённые OCSP-ответы», оно же «OCSP stapling», оно же «status_request» и «status_request_v2»). Но давайте по порядку.
У расширения «TLS feature» только одна версия. «TLS Feature» — это специальное поле в сертификате сервера, сообщающее клиенту о том, что сервером поддерживается определённый набор фич протокола TLS. Это поле в сертификате нужно для того, чтобы защититься от даунгрейд-атак на TLS-соединение, которые «человек посередине» может попытаться провести. Такая защита работает, поскольку «человек посередине» не может изменить сертификат сервера и удалить/модифицировать поле «TLS feature». Иначе говоря, список поддерживаемых сервером TLS-фич жестко фиксируется в сертификате сервера и с этим «человек посередине» ничего не может поделать.
У протокола TLS много необязательных фич, которые можно было бы перечислить и зафиксировать в поле «TLS feature», однако в этой статье мы рассматриваем только одну из них, а именно, так называемые прикреплённые OCSP-ответы.
Пример даунгрейд-атаки на эту фичу протокола TLS приведён в начале статьи: «человек посередине» выдаёт себя за сервер, не поддерживающий прикреплённые OCSP-ответы. Если в сертификате сервера отсутствует поле TLS feature, то у клиента нет возможности отличить «человека посередине», проводящего даунгрейд-атаку, от сервера, не поддерживающего прикреплённые OCSP-ответы.
У прикреплённых OCSP-ответов как раз две версии. Первая версия обладает значительным недостатком: она позволяет «прикрепить» (предать клиенту средствами протокола TLS) только OCSP-ответ для сертификата самого сервера. Это означает, что статус остальных сертификатов из цепочки нужно проверять иным способом. Вторая версия исправляет этот недостаток и позволяет «прикрепить» все необходимые OCSP-ответы.
Поддержка второй версии («status_request_v2») — это фича не самого веб-сервера, а используемой им библиотеки, реализующей TLS. Насколько нам известно, ни одна из популярных библиотек (Schanel, OpenSSL, GnuTLS, LibreSSL, NSS) её не поддерживает.
Прикреплённые OCSP-ответы версии 1 (как и версии 2) без «TLS feature» не позволяют защититься от атаки, описанной в данной статье, из-за возможности даунгрейда. HPKP+HSTS защитят, если клиент успел обновить pin-ы до появления «человека посередине», поскольку «человек посередине» может блокировать обновление pin-ов, вырезав необходимые заголовки из HTTP-ответа.
Это друзья Алисы и Боба, которые не столь сведущи в криптографии, поэтому пока что романтические попытки Пэта признаться в любви Джейн оканчиваются провалом из-за «человека посередине».
Пересчитали, опечатки не нашли :)
Дело в том, что в левой части формулы у нас значения HEX (0x328-0x198=0x190), а в правой части — десятичные значения!
Приведенный в статье алгоритм шифрования не использует какие-либо свойства квантовых объектов для реализации зашифрования, то есть все операции проводятся на обычном компьютере, а сама информация может находиться либо в зашифрованном состоянии, либо в незашифрованном.
Алгоритм Шора, как уже было сказано, направлен на получение данных, позволяющих найти закрытый ключ, с помощью которого и можно однозначно произвести расшифрование информации на обычном компьютере.
Однако уже существует и другое направление в криптографии под названием квантовая криптография. Ее отличие от постквантовой криптографии состоит в том, что здесь как раз для защиты информации используются принципы квантовой физики.
Если функция f(x1,x2) имеет вид: f(x1,x2)=g^(x1)y^(x2), то, сведя все к одному основанию, получаем: f(x1, x2)=g^(x1+k*x2). Алгоритм Шора находит периоды w1 и w2 этой функции, для которых значения функции начинают повторяться: f(x1,x2)=g^(x1+k*x2)=f(x1+w1, x2+w2)=g^(x1+w1+k(x2+w2)).
Это возможно, когда g^(w1+k*w2)=1 или w1+k*w2=0(mod q). Таким образом, зная значения периодов w1 и w2, можно найти k=-w1/w2.
Числа x1 и x2, таким образом, не связаны с числом k.
Алгоритм Шора позволяет решать задачи факторизации и дискретного логарифмирования (как в конечном поле, так и в группе точек эллиптической кривой) достаточно быстро на квантовом компьютере. Задача вычисления изогений обеспечивает, по крайней мере, субэкспоненциальную сложность для квантового компьютера, то есть для несуперсингулярных кривых в настоящее время существует квантовый алгоритм, позволяющий решить задачу вычисления изогений за субъэкспоненциальное время. Если же рассматривать рассматривать суперсингулярные кривые, то для них существует алгоритм, дающий лишь экспоненциальную сложность.
Очепятка, спасибо за внимательность! Должно было быть «с вечным циклом» (использовали элементарную программу с while(1) ради демонстрации эффекта Ctrl+C и Ctrl+Z)
Спасибо за замечание! Да, здесь действительно у нас неточность. Мы имели в виду функционирование X Window System вкупе с библиотекой VTE. Детальное описание оставим за кадром, т.к. в перспективе оно, возможно, станет предметом новой статьи :)
На практике при реализации Timejacking атакующий встретится с неочевидными тонкостями, подробное описание которых вы и найдёте в нашей статье.
Описанная вами схема действительно подходит для большинства случаев, однако она всё же оставляет окно для атаки: её всё ещё можно провести между обновлениями списка отозванных сертификатов. Это может быть неприемлемо для некоторых особо критичных к безопасности сервисов. К слову, это не обязательно могут быть веб-сервисы.
Другие возникающие вопросы — это: где хранить этот глобальный список и насколько он будет большим? Если его хранить локально, то на все ли устройства он поместится? Если хранить удалённо, то снова возвращаемся к вопросу о «человеке посередине». Если сокращать его размер, то возникает вопрос о его полноте. Но с этим, опять же, могут помочь сертификаты с коротким сроком действия.
В Google рассматривали подход, аналогичный Certificate Trancparency. Он тоже похож на обсуждаемую схему и называется «Revocation Transparency». Про него можно почитать вот тут. Насколько нам известно, его пока не планируют реализовывать.
К вопросу о «приватности», если мы вас правильно поняли, то он решается с помощью прикреплённых OCSP-ответов (OCSP stapling).
Благодарим за дополнение!
У расширения «TLS feature» только одна версия. «TLS Feature» — это специальное поле в сертификате сервера, сообщающее клиенту о том, что сервером поддерживается определённый набор фич протокола TLS. Это поле в сертификате нужно для того, чтобы защититься от даунгрейд-атак на TLS-соединение, которые «человек посередине» может попытаться провести. Такая защита работает, поскольку «человек посередине» не может изменить сертификат сервера и удалить/модифицировать поле «TLS feature». Иначе говоря, список поддерживаемых сервером TLS-фич жестко фиксируется в сертификате сервера и с этим «человек посередине» ничего не может поделать.
У протокола TLS много необязательных фич, которые можно было бы перечислить и зафиксировать в поле «TLS feature», однако в этой статье мы рассматриваем только одну из них, а именно, так называемые прикреплённые OCSP-ответы.
Пример даунгрейд-атаки на эту фичу протокола TLS приведён в начале статьи: «человек посередине» выдаёт себя за сервер, не поддерживающий прикреплённые OCSP-ответы. Если в сертификате сервера отсутствует поле TLS feature, то у клиента нет возможности отличить «человека посередине», проводящего даунгрейд-атаку, от сервера, не поддерживающего прикреплённые OCSP-ответы.
У прикреплённых OCSP-ответов как раз две версии. Первая версия обладает значительным недостатком: она позволяет «прикрепить» (предать клиенту средствами протокола TLS) только OCSP-ответ для сертификата самого сервера. Это означает, что статус остальных сертификатов из цепочки нужно проверять иным способом. Вторая версия исправляет этот недостаток и позволяет «прикрепить» все необходимые OCSP-ответы.
Поддержка второй версии («status_request_v2») — это фича не самого веб-сервера, а используемой им библиотеки, реализующей TLS. Насколько нам известно, ни одна из популярных библиотек (Schanel, OpenSSL, GnuTLS, LibreSSL, NSS) её не поддерживает.
Прикреплённые OCSP-ответы версии 1 (как и версии 2) без «TLS feature» не позволяют защититься от атаки, описанной в данной статье, из-за возможности даунгрейда. HPKP+HSTS защитят, если клиент успел обновить pin-ы до появления «человека посередине», поскольку «человек посередине» может блокировать обновление pin-ов, вырезав необходимые заголовки из HTTP-ответа.
Спасибо за комментарий!
habrahabr.ru/company/neobit/blog/334714
Еще, как вариант — Алиса и Боб уехали в отпуск.
Как Вам больше нравится :)
Дело в том, что в левой части формулы у нас значения HEX (0x328-0x198=0x190), а в правой части — десятичные значения!
Алгоритм Шора, как уже было сказано, направлен на получение данных, позволяющих найти закрытый ключ, с помощью которого и можно однозначно произвести расшифрование информации на обычном компьютере.
Однако уже существует и другое направление в криптографии под названием квантовая криптография. Ее отличие от постквантовой криптографии состоит в том, что здесь как раз для защиты информации используются принципы квантовой физики.
Это возможно, когда g^(w1+k*w2)=1 или w1+k*w2=0(mod q). Таким образом, зная значения периодов w1 и w2, можно найти k=-w1/w2.
Числа x1 и x2, таким образом, не связаны с числом k.