Защита информации
0,0
рейтинг
10 января 2015 в 20:00

Разработка → Padding Oracle Attack или почему криптография пугает перевод

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

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

Мой посыл не в том, что убедить вас отказаться от самостоятельного использования криптографических средств или пойти и нанять консультанта с зарплатой от $1000 в час всякий раз когда вы задумываетесь о шифровании.
Частично я веду к тому, что вам никогда не следует расслабляться, всегда нужно быть начеку, изыскивая пути, которые злоумышленник может использовать для получения дополнительной информации о вашей системе, а частично к тому, что Padding Oracle Attack является крутой демонстрацией всего этого. Итак, начнем.

Режим CBC


CBC, или режим сцепления блоков шифротекста, это один из режимов симметричного блочного шифрования с использованием механизма обратной связи. Это означает, что при шифровании очередной блок открытого текста проходит через блочный алгортим шифрования, а также дополнительно изменяется с использованием результата шифрования предыдущего блока.
Так что, если мы шифруем предложение:
This is a sentence of a carefully chosen length.

мы получим результат шифрования для каждого блока из 16 байт, причем последний блок открытого текста будет специальным образом дополнен (но об этом далее).
В CBC каждый блок открытого текста складывается побитово по модулю два (xor) с предыдущим блоком шифротекста перед тем как поступить на вход алгоритму шифрования. Данная взаимозависимость блоков означает, что каждый блок шифротекста зависит от каждого блока открытого текста, который был обработан к данному моменту. Причем изменение любого байта открытого текста приведет к изменению всех последующих байт шифротекста (лавинный эффект, ага). Согласно Википедии — CBC является «одним из двух режимов симметричного блочного шифрования, рекомендованных Нилом Фергюсоном и Брюсом Шнайером».



Как работает дополнение блоков (важно!)


Предпочтительным методом дополнения блоков шифротекста, является PKCS7. В нем значение каждого дополняемого байта устанавливается равным количеству дополняемых байт. Так если мы имеем блок из 12 символов, он будет дополнен четырьмя байтами [04, 04, 04, 04] до стандартного размера блока в 16 байт. Если блок имеет размер в 15 байт, он будет дополнен одним байтом [01]. Если блок имеет размер ровно в 16 байт, мы добавляем новый блок состоящий из [16]*16. (подробнее — https://en.wikipedia.org/wiki/Padding_(cryptography)#PKCS7)

Солгасно данному методу, последний блок расшифрованного открытого текста не может заканчиваться, например, на [..., 13, 06, 05]. А значит, что и оригинальный шифротекст является неверным, потому как не существует допустимых открытых текстов, которые могли бы быть преобразованы в такой шифротекст.

The Padding Oracle Attack


Оказывается, что знания факта, получается ли при расшифровке шифротекста открытый текст с корректным дополнением, достаточно атакующему для проведения успешной атаки на шифрование в режиме CBC. Если мы можем подавать какому-то сервису шифротексты, а он будет возвращать нам информацию, корректно ли дополнение — мы сможем вскрыть ЛЮБОЙ шифротекст.

Так что ошибкой, которой достаточно, чтобы обрушить ваше шифрование, может являться некоторый API, который будет возвращать код 200, если поданный нами шифротекст расшифровывается во что-то с корректным дополнением, и код 500, если нет.
Это не маловероятная ситуация. Например, Ruby OpenSSL подвержен данной проблеме. Достаточно использовать пример кода из официальной документации (http://www.ruby-doc.org/stdlib-1.9.3/libdoc/openssl/rdoc/OpenSSL/Cipher.html#documentation):
decipher = OpenSSL::Cipher::AES.new(128, :CBC)
decipher.decrypt
decipher.key = "the most secret!"
decipher.iv = "also very secret"

plain = decipher.update("thewrongpadding!") + decipher.final

Данный код выдает OpenSSL::Cipher::CipherError: bad decrypt, который, если его не перехватить, вернет ответ с ошибкой 500.

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

Промежуточное состояние (The intermediate state)


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

Атака работает через вычисление «промежуточного состояния» процедуры расшифрования (смотри схему) для каждого блока шифротекста. Это состояние блока шифротекста после расшифрования блочным алгоритмом, но ДО процедуры XOR с предыдущим блоком шифротекста. Мы будем находить это состояние, поднимаясь снизу от открытого текста, вместо того, чтобы спускаться вниз через блочный шифр. Также мы вообще не будем волноваться на счет ключа шифрования или алгоритма блочного шифрования.

Почему же данное промежуточное состояние так важно? Заметим:
I2 = C1 ^ P2
и
P2 = C1 ^ I2

Мы уже знаем C1 т.к. это часть шифротекста, который мы имеем. Так что если мы найдем I2, мы можем легко найти P2 и расшифровать сообщение.


Манипулирование шифротекстами


Вспомним, что мы можем подавать на вход системе любой шифротекст, и сервер ответит нам корректное ли дополнение получается после расшифрования. Мы используем данный факт, подавая на вход C1' + C2, где C1' — специальным образом сформированный нами блок шифротекста, а C2 — это блок, который мы хотим расшифровать. Под обозначением C1' + C2 мы понимаем простую конкатенацию (то-есть, «склеивание» блоков). Обозначим результат расшифрования как P'2.

Начнем с того, что мы заполним C1'[1..15] случайными байтами, а C1'[16] заполним нулем (0x00). Теперь подадим C1' + C2 серверу. Если сервер ответит, что дополнение получилось корректное, то мы можем быть уверены (с большой вероятностью), что P2'[16] равно 0x01 (т.к. дополнение корректно). Если сервер отвечает ошибкой — посылаем сообщение с C1'[16], установленным в 0x01, затем в 0x02 и.т.д. пока не получим нужный нам ответ.

(примечание переводчика. Конечно же возможна ситуация, когда мы получим два верных ответа:
1) для дополнения 01
2) для дополнения 02,02 или 03,03,03…

Если произошла такая ситуация — просто меняем предпоследний байт C1' и повторяем операцию заново.
В самом крайнем случае, нам понадобится три попытки, но это маловероятно.
)


Теперь положим, что сервер вернул ответ 200 при C1'[16] = 94.
I2     = C1'     ^ P2'
I2[16] = C1'[16] ^ P2'[16]
       = 94      ^ 01
       = 95

Ура! Мы получили финальный байт промежуточного состояния. Т.к. C2 взят из реального шифротекста, то I2 тоже идентичен реальному. Поэтому, мы можем расшифровать последний байт настоящего открытого текста:
P2[16] = C1[16] ^ I2[16]
       = C1[16] ^ 95

Мы подаем на вход C1'[16] = C1[16] и получаем последний байт реального открытого текста. На этом этапе, мы нашли всего-лишь заполнитель, так что придется проделать еще несколько итераций данного процесса, пока мы не обнаружим что-нибудь интересное.

Продолжаем


Мы нашли последний байт прокручиванием C1' до получения корректного дополнения. При этом мы можем сделать заключение, что последний байт P'2 равен 0x01. Затем используя P2'[16] и C1'[16], находим I2[16]. Продолжая этот процесс, находим оставшиеся байты I2 и расшифровываем весь блок шифротекста.

Заполняем C1'[1..14] случайными байтами, C1'[15] устанавливаем в 0x00, а C1'[16] таким, чтобы получить P2'[16] == 0x02:
C'1[16] = P'2[16] ^ I2[16]
        = 02      ^ 95
        = 93

Теперь мы можем быть уверены, что P2' будет заканчиваться на 0x02, и поэтому единственный вариант, при котором P2' будет иметь корректное дополнение — если P2[16] == 0x02. Мы будем прокручивать C1'[15], пока сервер не выдаст нам код 200. Предположим, что это случилось при C1'[15] == 106. Проделываем опять то, что мы уже умеем:
I2     = C1'     ^ P2' 
I2[15] = C1'[15] ^ P2'[15]
       = 106     ^ 02
       = 104

И вуаля! Мы знаем предпоследний байт I2. Поэтому можем найти предпоследний байт P2, как мы это уже проделывали ранее:
P2[15] = C1[15] ^ I2[15]
       = C1[15] ^ 104

И так далее для всех 16 байтов C2.

Остальные блоки


Форма блоков шифротекста зависит только от них самих и предшествующих блоков. Так что мы можем применить вышеприведенный алгоритм к каждому блоку шифротекста (отдельно от первого). Первый блок будет зашифрован с использованием вектора инициализации (IV), а сам IV выбран случайно при процедуре зашифрования. До тех пор, пока мы не узнаем IV, мы не сможем расшифровать первый блок, и нет ничего, что тут можно придумать, кроме глупого перебора очевидных значений [0,0,0,...] для IV и просмотра, получается ли какой-нибудь разумный открытый текст. И делать так в надежде, что первые 16 байт будут чем-нибудь вроде "Дорогой Евгений!".

Это все и есть Padding Oracle Attack.

Вот почему все, что связано с криптографией пугает.

Мы знаем, что не следует самостоятельно реализовывать криптографические примитивы, и что мы строим систему на чем-то уже изобретенном. Легко почувствовать себя расслабленно, когда мы прячемся за стойким шифром, разработанным специалистами. И пока мы держим наши ключи в секрете и не храним нигде открытые тексты, мы чувствуем себя неуязвимыми.

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

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

Спасибо.

The Matasano Crypto Challenges (http://matasano.com/articles/crypto-challenges/), благодаря которым я заинтересовался криптографией. Очень рекомендую!

_____

Перевод сделан с разрешения автора статьи Robert Heaton.
Источник: http://robertheaton.com/2013/07/29/padding-oracle-attack/
Еще интересные ссылки по теме:
https://class.coursera.org/crypto-preview/lecture/38
Перевод: Robert Heaton
Александр @Nostr
карма
29,0
рейтинг 0,0
Защита информации
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (60)

  • +10
    Спасибо за статью. Всем заинтересовавшимся хабравчанам рекомендую курс Cryptography I, который начался неделю назад.
    • +4
      Замечательный курс. Очень жаль, что его продолжение уже два года задерживают.
      • 0
        Да нет. Уже есть и Cryptography II
        • +5
          Я про него и говорю. На coursera сейчас стоит сессия с 6 апреля по 22 мая. До этого стояло начало января, до этого ноябрь, до этого сентябрь, до этого июнь и.т.п.
          Переносят уже года два.
          • 0
            Он как бы есть, но его нету :) Первый курс — отличный, я с удовольствием его закончил. Жду вторую часть уже год
        • 0
          А где есть-то? Насколько я вижу, январский запуск опять отложили. На этот раз на апрель.
  • +2
    Если мы можем подавать какому-то сервису шифротексты, а он будет возвращать нам информацию, корректно ли дополнение — мы сможем вскрыть ЛЮБОЙ шифротекст.

    Так по этим дополнениям и выясняют, нормально ли расшифровалось или нет. Ну и вообще CBC такая штука, что даже если в какой то блок внесут изменения, то уже через 1 блок всё нивелируется, толку от него немного. Давно пора использовать более совершенные режимы
    • +2
      Плюс ко всему — CBC не распараллеливается. Имхо в современном мире, CTR куда более актуален.
      • +1
        Этих режимов огромное множество. Я выделил бы GCM или OCB (но на него вроде патент есть).
      • +1
        Как раз CTR один из самых уязвимых режимов работы, google в помощь ctr cipher mode vulnerability.

        И если говорить формально, то распараллеливаются не режимы работы, а базовые циклы конкретного симметричного шифра.
        • +2
          Почему это CTR стал одним из самых уязвимых? И вообще, что такое «самый уязвимый»? Режим или фундаментально уязвимый, как ECB, или неуязвимый, при правильном использовании.
          • +2
            Школота минусует, я смотрю, ну вперед, продолжайте в том же духе.

            Как вы правильно подметили, при «правильном» использовании. Вот пример tools.ietf.org/html/draft-ietf-ipsec-ciph-aes-ctr-00. Опять же сам факт неправильного использования сводит на нет все преимущества использования такого режима. Найдите в рекомендуемых параметрах SSL например вот здесь wiki.mozilla.org/Security/Server_Side_TLS хоть один CTR режим.

            + вот еще ссылка www.nsa.gov/ia/programs/suiteb_cryptography/
            The Galois/Counter Mode (GCM) is the preferred AES mode.

            Для общего развития можно почитать habrahabr.ru/post/120096/
            • +1
              Спасибо за ссылку на tools.ietf.org. Но Вам не кажется, что «волков бояться — в лес не ходить?». Например для шифрования сессии с одноразовым ключём, переданным асимметрично, и для счётчика, инициализированным для этой же самой сессии — велик ли риск повтора значений?
              А по-поводу TLS, вот хорошее описание ситуации: crypto.stackexchange.com/questions/11307/what-is-wrong-with-aes-ctr-hmac-sha256-or-why-is-it-not-in-tls
            • +2
              Любое шифрование и любой режим работы шифра использовать бессмысленно, если оно применяется неправильно.
              По вашим ссылкам нет CTR просто потому что CBC — более старый и «проверенный» режим. Зато там есть такие шифры, как RC4 и 3DES.
              И CBC, и CTR подвержены элементарным атакам на целостность данных, поэтому в чистом виде не используются. Но если добавить код проверки аутентичности сообщения GMAC к режиму работы блочного шифра CTR, получится… режим GCM, который рекламируется самим NSA и вами.
              • –1
                Чувствуется, что беседа заходит в тупик, и пропадает всякое желание тратить свое время на ни к чему не ведущую полемику. Где вы нашли RC4 и 3DES? На всякий случай, восклицательный знак стоит трактовать как «кроме». Я ничего никому не рекламирую, но призываю думать, и разумеется, без фанатизма.

                P.S.
                “Just because you're paranoid doesn't mean they aren't after you”
                • +4
                  Здесь написано, что RC4 использовался раньше, но сейчас удален, а 3DES оставлен для обратной совместимости т.е. где-то в глубинах интернета применяется.
                  Вы утверждали, что CTR — «самый уязвимый режим работы», при этом, цитировали NSA, которая рекомендует везде использовать GCM. В GCM непосредственно для шифрования используется чистый режим CTR. GMAC, превращающий CTR в GCM, напомню, предоставляет защиту только от фальсификации данных и на другие криптографические свойства режима не влияет.
                  Можете посмотреть схему работы GCM, чтобы в этом убедиться.
        • +2
          Проверил, какой режим используется у меня в SSH (две машинки со стабильным дебианом) и нашёл aes128-ctr. Неужели в одной из ключевых программ в стабильном дебиане используют один из самых уязвимых режимов?
        • +2
          Позвольте не согласиться по поводу уязвимости. CTR ничем не хуже других, если его правильно использовать — не повторять значения счётчика для сообщений зашифрованных одним и тем же ключём (ага, для 128битного ключа это делает ~ 10^38 уникальных значений).
        • +1
          В CTR, в отличие от CBC, на вход шифра подается счетчик, содержимое которого достаточно строго детерменировано. В CBC на вход шифра подается непосредственно ciphertext, что требует от шифра правильной работы при любых входных данных. Это свойство malleability шифров достаточно часто использовалось для атак на шифры в режиме CBC, но абсолютно не затрагивало CTR. Из конкретных примеров: www.jakoblell.com/blog/2013/12/22/practical-malleability-attack-against-cbc-encrypted-luks-partitions/

          Насчет параллелизации, я не знаю, что вы пытались сказать словом «формально», но как раз параллелизация шифрации блоков данных — это как раз очень важное свойство CTR режима, а не конкретных PRF, используемых в этом режиме. В CBC параллелизуется только дешифрация блоков.
    • 0
      CBC такая штука, что даже если в какой то блок внесут изменения, то уже через 1 блок всё нивелируется, толку от него немного. Давно пора использовать более совершенные режимы

      Разобраться в трёх режимах (CBC, OFB, CFB) мне помогла статья на opennet.ru.
      В итоге в Пандоре я перешёл с CBC на CFB.
  • 0
    С практической точки зрения я чувствую достаточную уверенность пересылая зашифрованный gpg файл (gpg -c) через ssh-соединение внутри vpn-туннеля, работающего на pki-ssl.

    • +2
      С практической точки зрения возможно будет проще взломать ваш ПК, с которого вы всё это проделываете. Софта много, багов много.
      • 0
        Для этого надо иметь доступ к софту.

        Тройное шифрование — это не защита от targeted атаки, а от сниффинга трафика с последующим «ой, есть эксплоит, позволяющий расковырять трафик». То есть защита против чего-то уровня xkeycode, а не directed attack.
        • 0
          Если атака не targeted и нет доступа к софту, достаточно пользоваться чем-то экзотическим + пароль 30 знаков.
          openssl des3 -in file.txt -out encrypted.txt
          Файл можно просто по HTTP лить. Ну, есть какой-то поток байт. Ни заголовка, ни подсказок. Без инсайдерской информации не подберёшься
          • 0
            scp эргономичнее. А дыры обнаруживают в чём попало, так что наложить слоями — вполне себе стратегия. 2 из 3 будут дырявыми, один, в этом конкретном случае, нет.
    • 0
      А вы знаете, какой алгоритм используется по умолчанию для шифрования в GPG?
      • 0
        The default symmetric cipher used is CAST5, but may be chosen with the --cipher-algo option.

        А так, да, крипто-карго-культ. Сырцы gpg я не читал, в ssh только заглядывал (не в криптосекцию), openvpn тоже не читал.
        • 0
          А зачем используете -c? Почему не ключи?
          • 0
            Чтобы потом расшифровать можно было «из головы». Это очень полезно, когда хоть что-то не хранится в машиночитаемом виде.
            • 0
              -----BEGIN PGP SIGNED MESSAGE-----
              Hash: SHA256
              
              А как вы говорите красным тогда? Или это только для шифрования файлов?
              
              -----BEGIN PGP SIGNATURE-----
              Version: GnuPG v2
              Comment: https://keybase.io/valdikss
              
              iQIcBAEBCAAGBQJUs6l/AAoJEFzXIC7viPdyFMIP/0U5EkPxuB7irQUvBi//4inA
              CmRCzmFrNPswHK+SFTm5IuU2Or8y9DZkr6BGY/qr+9zXikkA2fHQvKH+Ai5SAxUs
              dilz1i2ZW3W+x8m2GH1I7ahYvB6oYsmPPph7O7SoRUbIW6/NtHYi0R5/MYP8FPKB
              a1H8jkNglE2HPwJNErKH8P3I0cACXaN991sXCFFldm8lE0fLkFfAUgVQJNsvDrcS
              Bj8Boc1x7GtGHZPyqXFPI0+1faqfD+6tWD9E7A9H5ck2DOoLYFg04aU7FLHZWC1e
              brZJj9oHRe+v87ImBieN1YIGi2kzqHsqej59lJ+HJ0r5r7wKxUktj+Q6GkBb2BrB
              PpbWcQeST9E6Hdf1mKWM1OG+gG0E4KlK7gAYPzGdYjwGTBy/PxEO4GMpt1nlGHHV
              B/v4Om7HdlF2IzUxmz6knTs2bgJuX2LGYUyVUHwO+SZPBrnXLD03uWUGZQEfV+91
              3wRSd/9+TZcYMTAQ/VimFAl51rlfUA0krLXx/DqRyO6QERvB4WRNkX7UhgMiL+sb
              QZ2GRmLv0CixdYTOmMTrsPhEhP6iMBKBCBSGqI2vTxRL+GEZPKyS95ze55COS97L
              Gd7zJpL46HO1m90CGrkP+CKvXltGMQ4+luR7xuQgSIUf09nB8yu/aZr4mh13Vqon
              4w/XdsgDO9XyBVWiR7d0
              =7FaC
              -----END PGP SIGNATURE-----
              • 0
                Да, речь про «передачу зашифрованного файла через ssh внутри vpn». Шифрование — gpg -c.
      • 0
        У меня (arch, gnupg 2.1.1, libgcrypt 1.6.2, gnutls 3.3.11) в мане пишут "-с Encrypt with a symmetric cipher using a passphrase. The default symmetric cipher used is AES128, but may be chosen with the --cipher-algo option." Параметры сборки gnupg, libgcrypt и gnutls обычные, ничего специфичного по симметричному шифру по умолчанию не видно на первый взгляд.

        Видимо, настройка по умолчанию менялась, т. к. сейчас в www.gnupg.org/documentation/manuals/gnupg/Operational-GPG-Commands.html указан aes128, а в 2011 году в рассылке говорилось, что там cast5 (см lists.gnupg.org/pipermail/gnupg-users/2011-January/040276.html)
        • 0
          Ого, неожиданно. Я думал, что там до сих пор cast5.
    • +7
      image
      • +1
        Предлагаю такое решение: ноут шифруется паролем и ключом (для расшифрования нужны оба). Пароль человек хранит в голове, ключ автоматически подцепляется с удалённого сервера во время загрузки. (На хабре была статья, в которой предлагалась практическая реализация такой схемы, но не могу её найти.) На удалённом сервере в cron установлен скрипт, который ежедневно удаляет ключ, если человек не отменил это действие явно. (Примерно таким же способом L сделал оповещение о своей смерти.) Если человека хватают, то его задача продержаться первые сутки, а потом уже никто не сможет восстановить информацию.
        • +5
          От кого вы защищаетесь? Модель атаки какая?
          • 0
            Это попытка защититься от правой части комикса: есть данные, которые допустимо потерять, но абсолютно недопустимо, чтобы они попали в чужие руки (вариант задачи: чтобы нельзя доказать наличие этих данных у пользователя). При этом пользователь допускает, что атакующий может применять жесткие методы, включая те же наркотики, но сначала будет пытаться получить данные по-хорошему (за это время ключ и испарится). Важный момент: удалённый сервер не делает бекапов, а ещё лучше, чтобы был устойчив перед всеми возможными атакующими.
            • +2
              Во-первых, люди, готовые использовать наркотики и насилие — не будут ждать сутки.
              Во-вторых, ничего вы никому не объясните — вас будут продолжать колоть и бить, бить и колоть.
              В-третьих, когда вы наконец объясните свою супер-хитрую схему — ну, забьют вас окончательно и всё на этом.

              Повторим вопрос: от кого вы защищаетесь?
              • 0
                Повторю ответ: защита от получения противником доступа к данным, любой ценой.

                Объяснять схему насильникам как раз не нужно, так как они успеют добраться до сервера до того, как он сотрёт ключ. Задача спасти данные, а не себя (тем более, всё равно могут убить, как вы отметили).

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

                Похожая схема может применяться политическими активистами и разведчиками.
                • 0
                  А кто сотрет данные из головы сотрудника филиала?
                  • –1
                    Из данных, представляющих интерес для неприятеля, у него в голове есть только пароль, ставший бесполезным. Данные как таковые содержатся на этом зашифрованном сервере филиала и понемногу в головах остальных сотрудников. Их всех отлавливать и пытать — не вариант, тем более неизвестно, кто что знает. А вот сразу все данные с сервера были бы ценной добычей. Кстати, если многие будут применять такую схему, то и захваты сотрудников прекратятся — зачем захватывать, если до данных всё равно не добраться.
                    • +1
                      Из данных, представляющих интерес для неприятеля, у него в голове есть только пароль, ставший бесполезным


                      Такое может быть только в том случае, когда с данными никто не работает. В выбранном государстве, по крайней мере. Но раз данные есть и есть задача их защитить, значит с ними работают.

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


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

                      Кстати, если многие будут применять такую схему, то и захваты сотрудников прекратятся — зачем захватывать, если до данных всё равно не добраться.


                      Типичная попытка решить нетехническую проблему исключительно техническими методами. Можно уничтожить криптографический ключ, можно уничтожить компьютерную информацию, но заставить человека не раскрывать информацию можно лишь одним способом. Пока с данными будут работать люди, именно эти люди и будут одним из самых слабых звеньев, вне зависимости от применяемых технических средств. Разумеется, можно каким-то способом подставить под удар сотрудника, который только вводит пароль, а с данными не работает, но такая попытка решения поставленной задачи носит сугубо организационный характер (основная проблема – как организовать работу с данными и людьми, а не какое шифровальное средство выбрать и в каком режиме его использовать).
                      • 0
                        Чтобы данные были в безопасности, надо прокачать и людей, и технику. Мне кажется более важной техническая сторона, а вам, судя по всему, человеческая, но они обе обязательны в нормальной схеме. Согласитесь, что грош цена любой схеме, в которой данные хранят и передают в незашифрованном виде, даже если сотрудники строго следуют уставу и устойчивы к пыткам.

                        Чтобы не ходить далеко за примером, рассмотрим известный Силк Роад, в гибели которого виновата именно техническая сторона, а не социальная. Ни один из «сотрудников» (кроме владельца) не знал слишком много, но на сервере хранилось всё. Подкачала техническая реализация, из-за чего неприятель и добрался до сервера, а потом и до владельца и его биткоинов а теперь продаёт их оптом.
                • 0
                  Что это за «юридическая фирма с филиалами по всему миру», ради данных которой сотрудникам предлагается аж жизнью жертвовать? Это вообще глупо предполагать, что кто-то (а хоть бы и ты сам) отдаст жизнь или здоровье ради каких-то там данных. Реализовывать такую схему — опасно и глупо.
                  • 0
                    глупо предполагать, что кто-то (а хоть бы и ты сам) отдаст жизнь или здоровье ради каких-то там данных
                    Поэтому у сотрудников и не должно быть возможности слить данные.
                    Что хуже: если все сядут или если одного подвергнут пыткам?
            • 0
              «Абсолютно» не бывает, и в простейшем случае я оцениваю ценность всех моих данных, включая те, которые я старательно скрываю, в пару фингалов. Ну ладно, в одну сломанную кость, если включить сюда все пароли от всех аккаунтов.
              • 0
                Для меня это тоже было бы весомым аргументом. Поэтому и придумали анонимность — чтобы не было ясно, кому ставить фингал. Мало кто способен противостоять пыткам, вот мне и захотелось придумать схему, устойчивую к таким ситуациям. Выше я привёл примерный сценарий использования. В общем случае это можно свести к ситуациям, когда вам дают доступ к чужим важным данным и хотят защитить данные от того, что кто-то выпытает у вас пароль.

                Обидно, что человека в итоге могут запытать до смерти, но какие ещё варианты решения можно предложить, когда преступники ловят сотрудника и ставят выбор данные или жизнь, а данные организация отдать никак не может. Допустимо ли рисковать жизнью одного сотрудника ради сохранности данных компании?
                • +1
                  Отдать данные и не париться. Под шумок можно набрать что-нибудь аварийное на телефоне с выключенным звуком.

                  Вообще, я не понимаю, каким образом криптографические воздушные замки могут помочь, когда «пришли». Меньше рыпаешься — больше шансов, что обойдётся.
                  • 0
                    Если я правильно понял, вы предлагаете набрать на телефоне команду аварийного уничтожения данных. Это и есть «рыпаться» и не всегда возможно, а если заметят, то костей сломают больше. По-моему, надежнее, если данные будут уничтожены сами собой при полном бездействии как пользователя, так и захваченного оборудования (допустим, пользователя неожиданно схватили и отобрали телефон, а компьютер вынесли). Такая схема напоминает свидетельство канарейки тем, что действие вызвано бездействием.

                    Про «отдать данные и не париться» я уже писал. Если для отдельного человека это выглядит самым логичным вариантом, если он не маньяк, то в компании могут предпочесть спасти данные, а не захваченного сотрудника. Сделать так, чтобы с момента похищения сотрудник не мог предать компанию, даже если его будут пытать.
                    • +2
                      Нет, я предлагаю набрать 112, выключить звук и оставить «как есть».

                      Насчёт «страдать для компании» — извините, в условиях силовой конфронтации я отдам все пароли без дополнительного стресса. А в компании, «в которой предпочтут спасти данные» я предпочту не работать.
                      • –1
                        Нет, я предлагаю набрать 112, выключить звук и оставить «как есть».
                        Хороший вариант, но что если напавшие сами работают в правоохранительных органах?
                        А в компании, «в которой предпочтут спасти данные» я предпочту не работать.
                        А другой согласится. Люди соглашаются и в боевых действиях участвовать, была бы достойная оплата и склад характера. Предложенная схема не является серебряной пулей, но некоторым, без сомнения, может пригодиться. Разумеется, большинство компаний готовы отдать все данные человеку с автоматом и им такая схема не нужна.
                        • –1
                          Ок, ок, проблемы ополченцев, сражающихся за федерализацию очередной несчастной страны, возможно, отличаются от потребностей мирных жителей, которые не хотят, чтобы их опОлчивали.
      • +1
        Этот комикс был нарисован в эпоху воображения криптоманьяков. После Сноудена это не воображение, а суровая реальность — если мой трафик идёт в США, то с высокой вероятностью он пишется на жёсткие диски NSA. И мне не хочется, чтобы они из-за нелепой дырке в протоколе могли эти файлы прочитать.
        • +1
          Я ж всячески за многослойное шифрование для важных данных. Просто напомнило) кстати, спасибо за iperf. Случайно наткнулся на твой пост.
    • 0
      … используя всезде один и тот же ключ.
      • 0
        Низзя и не получится. У ssh свои ключи, у PKI-SSL свои. На это и рассчёт.
  • 0
    Начнем с того, что мы заполним C1'[1..15] случайными байтами, а C1'[16] заполним нулем (0x00). Теперь подадим C1' + C2 серверу. Если сервер ответит, что дополнение получилось корректное, то мы можем быть уверены (с большой вероятностью), что P2'[16] равно 0x01 (т.к. дополнение корректно). Если сервер отвечает ошибкой — посылаем сообщение с C1'[16], установленным в 0x01, затем в 0x02 и.т.д. пока не получим нужный нам ответ.

    нипонятно, почему p2[16] должен быть равен 0x01
    • 0
      Мы пытаемся подобрать такой искусственный C1', что результат I2[16] ^ C1'[16] будет равен 0x01. ( ^ — это XOR)
      • 0
        Результат i2[16] и c1'[16] это p2'[16]. Почему p2'[16] должен быть равен 0x01?
        • 0
          Перебирая все 256 вариантов C1'[16], мы натолкнемся гарантированно на такое значение, что P2'[16] будет равно 0x01.
          Т.к. любой текст, заканчивающийся 0x01 является корректным — нам придет ответ 200.
          Мы это детектируем и найдем I2[16]. Все это для того, чтобы I2 восстановить.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.