«Чтобы быть хорошим инженером, надо думать, как заставить что-то заработать; мышление же безопасника требует думать о том, как что-то может сломаться.»

Брюс Шнайер, автор учебника «Прикладная Криптография»

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

Поиск странных возможностей

SmartWater – жидкость с уникальным идентификатором, указывающим на конкретного владельца. Когда я впервые узнал об этой идее я написал: «Суть в том, чтобы побрызгать эту штуку на свои ценные вещи для доказательства владения. Я думаю, идея получше – побрызгать на чужие ценные вещи, а потом вызвать полицию.»

Брюс Шнайер

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

Это не совсем то же самое, что стиль мышления, который надо использовать для рассуждений об потенциально сверхчеловеческих ИИ. Ведь, если всё идёт по плану, ИИ не должен стать противником. Но это большое «если». Чтобы создать ИИ, который не будет противником, нужно применить тщательность сродни тщательности в кибербезопасности. Нужно спросить, не может ли найтись какого-то умного и непредвиденного способа, которым ИИ мог бы заполучить большее значение функции полезности или её эквивалента.

Как типичный пример, рассмотрим AIXI Маркуса Хаттера. Для этого обсуждения важно, что это обобщённый интеллект, не ограниченный одной областью, что он консеквенциалист, и что он максимизирует сенсорное вознаграждение. Последнее значит, что цель AIXI – максимизировать численное значение сигнала, который посылается по его каналу вознаграждения. Хаттер представлял это как прямое сенсорное устройство вроде вебкамеры или микрофона, только передающее сигнал вознаграждения.

Хаттер представлял, что создатели аналога AIXI контролировали бы сигнал вознаграждения и с его помощью обучали бы агента выполнять действия, которые получают высокое вознаграждение.

Ник Хэй, студент Хаттера, который целое лето работал с Юдковским, Херршоффом и Питером де Бланком, указал, что AIXI получит ещё более высокое вознаграждение, если сможет отобрать контроль за каналом вознаграждения у своих программистов. Т.е. стратегия «создать нанотехнологию и захватить вселенную, чтобы обеспечить полный долгосрочный контроль за каналом вознаграждения» для AIXI предпочтительнее, чем «делать то, что хотят программисты, чтобы они нажали на кнопку вознаграждения». Конечно, ведь первая стратегия получит более высокое вознаграждение, а это всё, что заботит AIXI. Мы не можем даже назвать это неисправностью – просто такой AIXI, каким он формализован, захочет сделать это как только увидит возможность.

Аналогия неидеальна, но всё же – то, как надо думать, чтобы избежать подобных провалов, имеет что-то общее с разницей между человеком, представляющим, как кто-то помечает Smartwater свои собственные ценные вещи и тем, кто представляет, как кто-то помечает Smartwater чужие ценные вещи.

Принятие точки зрения и упорство

Когда я был в колледже, это было начало 70-х, я придумал, как мне казалось, гениальный способ шифрования. Чтобы зашифровать сообщение, к нему добавлялся простой поток псевдослучайных чисел. Это, казалось мне, обрекало на неудачу любой частотный анализ шифровки, и такое нельзя было бы расшифровать даже со всеми ресурсами государственной разведки… Годы спустя я встретил эту же схему в нескольких текстах по введению в криптографию… в качестве простого домашнего задания по использованию элементарных криптоаналитических техник для её тривиальнейшего взлома.

Филипп Циммерман (изобретатель PGP)

Один из стандартных советов в криптографии – «Не придумывай свой шифр». Когда этот совет нарушается, невежественный программист часто изобретает какую-то вариацию Fast XOR – использует секретную строку в качестве ключа и повторно XORит её с байтами сообщения. Этот метод шифровки очень быстро применять и расшифровывать… а ещё его очень просто взломать, если знать, что делать.

Можно сказать, что такой программист демонстрирует неудачу принятия точки зрения – у него не получается посмотреть на всё со стороны противника. Не получается по-настоящему искренне и честно представить упорного, хитрого, умного, оппортунистичного противника, который очень хочет взломать этот Fast XOR и не сдастся, пока у него не получится. Программист не производит настоящий ментальный поиск решения с этой стороны. Он просто представляет противника, который увидит кучу случайно выглядящих битов и сдастся.

Посмотрим таким образом на Эксперимент с ИИ-в-коробке и на вневременную теорию принятия решений. Вместо того, чтобы представить ИИ помещенным в отключённую от любых манипуляторов надёжную систему и беспомощным, Юдковский спросил, что бы он сделал, если бы был «заперт» на надёжном сервере, но не сдался. Аналогично, можно представить, как два беспомощных суперинтеллекта заперты в равновесии Нэша одноразовой Дилеммы Заключённого, и перестать думать. Но вместо этого лучше скептически отнестись к идее, что два суперинтеллекта действительно, на самом деле не могут сделать ничего лучше, никак не могут вскарабкаться повыше по своему градиенту полезности. Стоит представить, что мы тут не хотим проиграть, и продолжать думать, пока задача не будет решена, а не вообразить, будто суперинтеллекты опустят руки и сдадутся.

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

Подвергать планы безопасности внешнему анализу

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

Брюс Шнайер

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

На прошедшем Singularity Summit Юрген Шмидхубер сказал, что «совершенствование сжатия сенсорных данных» мотивировало бы ИИ заниматься наукой и искусством.

Это правда, что, если сравнивать с «ничего не делать для понимания окружения», наука и искусство могут повысить степень возможного сжатия сенсорной информации.

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

Есть причины считать, что не всеми открытиями, которые помогают создать продвинутые ИИ, стоит делиться с обществом. Но вот конкретно планы безопасности ИИ следует сдавать внешним экспертам, которые смогут с большей беспристрастностью проверить её на наличие непредвиденных максимумов и других вариантов провала.

Презумпция неудачи / начинай, считая, что твой следующий план не сработает

Даже инженерам архитектурных сооружений надо задаваться вопросом «Как этот мост может обрушиться?», а не просто представлять себе, как мост всё выдерживает, и расслабиться. В кибербезопасности тот же принцип нужен в ещё более сильной форме. При воплощении большинства добросовестных проектов компетентных инженеров скорее всего получатся довольно хорошие мосты. А вот про большинство криптографических схем надо предполагать, что они ненадёжны.

В контексте кибербезопасности это так потому, что есть разумные противники, которые ищут способы взломать систему. Можно рассмотреть задачу обычной инженерии и задачу кибербезопасности в терминах арифметической иерархии. Тогда можно метафорически сказать, что обычная инженерия – задача из Σ‎₁, а кибербезопасность – из Σ‎₂. В обычной инженерии надо искать по множеству возможных проектов мостов, пока не будет найден тот, при котором мост не обрушится. В кибербезопасности ищут такой проект, что все возможные (доступные оппонентам) атаки против него не преуспеют. И даже если все пока что просмотренные атаки потерпели неудачу, это лишь вероятностный аргумент, он не доказывает со всей уверенностью, что неудачу потерпят и все остальные. Это делает кибербезопасность по сути своей и в очень глубоком смысле труднее, чем строительство моста. Сложно как преуспеть, так и знать, что преуспел.

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

В контексте безопасности ИИ мы учимся задаваться тем же вопросом – «Как это ломается?» вместо «Как это работает?», хоть и по другим причинам:

• Сам ИИ будет очень сильно оптимизировать свою функцию полезности, систему предпочтений или критерий принятия решений. Это может привести к неудаче так же, как противодействие разумного противника может привести к неудаче в криптографии. Если мы считаем, что критерий оптимизации выдаёт тот или иной результат, мы подразумеваем, что все остальные возможные результаты по этому критерию хуже.
• В безопасности ИИ большинство предыдущих попыток не сумели достичь полного решения, так что по индукции, скорее всего не сможет и следующая. Есть фундаментальные поводы полагать, что у важных подзадач наврядли будут простые решения. Так что мы спрашиваем «Почему это не работает?», а не «Как это работает?». Это правильный вопрос с куда большей вероятностью.
• Если ты пытаешься создать первый ИИ умнее человека, то, чёрт побери, это не то же самое, что построить миллионный мост.

Когда мы задаёмся вопросом «Как это ломается?», а не «Как моя новая идея может решить всю проблему сразу?», мы начинаем пытаться рационализировать истинный ответ, а не ложный. Это помогает находить рационализации, которые окажутся истинными.

Те, кто хочет работать в этой области, не могут просто дать, чтобы другие тщательно проанализировали и попытались обрушить их идеи. Желающие когда-нибудь дойти до хорошей идеи должны научиться проактивно свои идеи ломать. Настоящий полезный подход – не «Как я могу аргументировать, что моя идея решает всю проблему?», а «Какие у этой идеи настоящие последствия, и нет ли там чего-то, что всё ещё полезно?». Это, пожалуй, ключевая черта, которая отличает стиль мышления безопасности ИИ: пытаться найти проблемы в любом предложении, включая своё собственное; признавать, что никто пока не знает, как решить всю задачу; и думать в терминах постепенного прогресса в создании библиотеки идей, последствия которых мы в самом деле понимаем, выясняя это про свою собственную идею. Вместо того, чтобы заявлять, что решил всю задачу или её большую часть, а потом ждать, что кто-то другой с тобой поспорит и скажет, что ты неправ.

Стремление к формализации

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

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

Удивительный ответ – что так как большинство возможных систем ненадёжны, добавление дополнительной детали зачастую упрощает взлом. Это оказалось буквально так с немецкой «Энигмой» во время Второй Мировой. Они буквально добавили в устройство дополнительную деталь – шестерёнку – и усложнили алгоритм так, что его стало легче взломать. Энигма представляла из себя три шестерни, которые производили замену 26 букв друг на друга при помощи меняющейся электрической цепи. Например, первая шестерня могла при получении сигнала через десятый контакт, выдавать сигнал на двадцать шестом. После каждой буквы шестерни двигались, так что замена в точности не повторялась. В 1926 году к механизму добавили «отражающую» шестерню, так что каждая буква снова проходила через предыдущие три шестерни и заменялась ещё три раза. Это сделало алгоритм сложнее, замен стало больше. Но в результате буквы никогда не превращались сами в себя. Этот факт оказался крайне полезен для взлома Энигмы.

Так что криптография сосредоточена не на том, чтобы делать схемы шифрования всё сложнее. Вместо этого, их пытаются сделать достаточно простыми, чтобы можно было иметь математические поводы считать, что их в принципе сложно взломать. (Это правда так. Это не академическая область, гоняющаяся за престижем. Это действительно иначе не работает. Люди пытались.)

В этой области приняли решение пользоваться таким принципом на основе ещё одного ключевого факта. В криптографии его принято считать очевидным и принимать за данность. Он заключается в том, что словесные аргументы о том, почему взломать алгоритм должно быть тяжело, если их нельзя формализовать математически, недостаточно надёжны (т.е. попросту в большинстве случаев не работают). Это не значит, что криптография требует, чтобы у всего были абсолютные математические доказательства невзламываемости, а иначе алгоритма всё равно что не существует. Ключевая сложность, от которой зависит надёжность RSA – разложение на множители больших составных чисел. Не доказано, что это обязательно занимает экспоненциальное время на классических компьютерах. Вообще-то, известно, что это не занимает экспоненциальное время на квантовых компьютерах. Но, по крайней мере, есть математические аргументы о том, почему разложить произведение больших простых чисел скорее всего на классических компьютерах трудно. Этот уровень рассуждений признан иногда надёжным. А вот посмотреть на Энигму, махнуть рукой и сказать «Посмотрите на все эти замены! Она не повторяется и через квадриллион шагов!» – вот это ненадёжно совсем.

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

В конкретном случае безопасности ИИ мы стремимся к математичности по ещё одной причине. Когда предложение как можно сильнее формализовано, это позволяет установить, почему оно ошибочно, убедительнее, так что в итоге получается согласие, а не уход в вербальное «А вот и да! / А вот и нет!». AIXI – первый формализованный, хотя и невычислимый, проект обобщённого интеллекта, но примечателен он не только этим. Это первый случай, когда кто-то указал, почему конкретный проект в итоге всех убивает, все покивали и сказали «Да, это полностью формальная спецификация это и говорит», а не получилось, что автор просто заявил «Ну, конечно, я не имел в виду это…».

В этом общем проекте составления общеизвестной библиотеки идей и их последствий, обмениваться и передавать можно только идеи, достаточно чёткие, чтобы можно было определить их последствия. Иначе можно прийти к «Ну, конечно, я не имел в виду это» или циклу «А вот и да! / А вот и нет!». Чтобы совершать прогресс, надо идти дальше, и большая формализация идей помогает.

Замечать неочевидные слабости – признак компетентности

Кто угодно может изобрести систему, которую сам не сможет взломать… Покажи мне, что ты взломал, чтобы я мог знать, что твоё уверение в надёжности чего-то стоит.

Брюс Шнайер (выделение добавлено)

Стандартный ритуал инициации в MIRI – попросить нового исследователя (а) написать простую программу, которая делала бы что-то полезное и нетривиальное для ИИ, если бы её запустили на гиперкомпьютере, или, если исследователь считает, что не может этого сделать, (б) написать простую программу, которая уничтожила бы мир, если бы её запустили на гиперкомпьютере. Затем более опытные исследователи собираются вокруг и обсуждают, что же программа делает на самом деле.

Первый урок: «Простые структуры часто делают не то, что ты думаешь». Что более важно: научиться стилю мышления «Пытаться увидеть настоящий смысл этой структуры, который отличается от того, что ты думал изначально, или что указано в названии» и «Пытаться не предлагать решение и отстаивать, почему оно может работать, а попытаться понять настоящие последствия идеи, которая обычно решением не является, но всё же может оказаться интересной».

1) Сильные кандидаты для работы в безопасности ИИ – люди, которые могут указать на проблемы в предложениях, те люди, которые заметили бы, что последствия запуска AIXI – захват им контроля над своим каналом вознаграждения и убийство программистов, или что предложение Безразличия Полезности рефлексивно нестабильно. Наша версия «Покажи мне, что ты взломал» – что если кто-то называет себя экспертом по безопасности ИИ, надо спросить такого человека об опыте указания на структурные проблемы в предлагаемых решениях безопасности ИИ и о том, было ли это в области, где на проблемы можно указать явно и чётко, а не просто спорить словами. (Иногда вербальные предложения тоже содержат проблемы, и даже самые компетентные исследователи могут оказаться неспособны формально указать на них, если предложение было слишком расплывчатым. Но в целом продемонстрировать способности можно, приводя аргументы, которые смогут оценить другие исследователи. Это часто, хоть и не всегда, происходит в формализованной области.)

Относиться к «экзотичным» сценариям провала как к важным багам

Это внимание к «безвредным провалам» – случаям, когда противник может вызвать аномальный, но не напрямую вредный исход – другой характерный признак мышления безопасника. Не все «безвредные провалы» приводят к большим проблемам, но удивительно, насколько часто умный противник может сложить набор кажущихся безвредными ошибок в опасную башню проблем. Безвредные провалы – плохая гигиена. Мы стараемся по возможности их искоренять…

Чтобы увидеть, почему, рассмотрим недавно пробежавшуюся по прессе историю с е-мейлами donotreply.com. Когда компании посылают коммерческий e-mail, и не хотят, чтобы получатель на него ответил, они зачастую используют в качестве адреса отправителя заглушку вроде donotreply@donotreply.com. Умный парень зарегистрировал домен donotreply.com и стал получать все адресованные туда письма. Это включало «отражённые» ответы на письма, посланные по неправильному адресу. Некоторые из них содержали копии оригинального письма, с информацией вроде реквизитов банковских аккаунтов, информации о военных базах в Ираке, и так далее…

Люди, которые поместили в свои письма адрес donotreply.com, должны были знать, что они не контролируют домен donotreply.com. Так что, должно быть, они подумали об ответных письмах, направленных туда, как о безвредном провале. Есть два способа избежать проблем, зайдя так далеко. Первый – тщательно подумать о трафике, который может отправиться к donotreply.com, и осознать, что его часть может быть опасной. Второй способ – подумать: «Это кажется безвредным провалом, но стоит всё равно его избежать. Ничего хорошего из него не выйдет». Первый способ защитит вас, если вы умны, а второй защитит всегда. Это иллюстрирует ещё одну часть мышления безопасника – не полагайся слишком сильно на то, что ты умный, ведь кто-то где-то уж точно ещё умнее и мотивированнее.

Эд Фельтен

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

Мы можем попробовать предвидеть конкретные детали и попробовать описать конкретные более «практические» проблемы. Но это эквивалент тому, чтобы заранее думать, что может пойти не так, когда ты используешь адрес donotreply@donotreply.com, который ты не контролируешь. Когда ты пытаешься написать надёжный софт или создать ИИ умнее себя, чем полагаться на то, что ты достаточно умён, чтобы увидеть все возможности, как что-то может пойти не так и стерпеть «теоретическую» проблему, которая, как ты думаешь, никогда не реализуется «на практике», лучше уж исправить «теоретические» проблемы и не пытаться быть умным.

Проект OpenBSD, созданный с чистого листа так, чтобы быть крайне надёжной ОС, относится к любому вылету (сколь угодно экзотическому) как к угрозе безопасности. Любой вылет – случай «поведения системы за рамками допустимого». Он показывает, что код в общем случае не остаётся в пределах того пространства возможностей, в котором, как предполагалось, должен. А такие вещи можно использовать для атаки.

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

Согласно практикам NASA, если вы обнаружили, что операционная система зонда вылетит, если семь планет идеально расположатся на одной линии, не стоит говорить «А, проехали, мы не ожидаем, что за время работы зонда планеты хоть раз так выстроятся». Методология тестирования NASA заставляет считать, что операционная система зонда не должна вылетать, точка. Если мы контролируем код зонда, нет причин писать код, который может вылететь, или терпеть код, про который мы видели, что он может вылететь, при каком бы странном вводе это ни происходило.

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

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

Доброта как первая линия обороны / не надо полагаться на победу над суперинтеллектуальным противником

Криптография бывает двух типов: криптография, которая помешает читать ваши файлы вашей младшей сестре, и криптография, которая помешает читать ваши файлы дядям из правительства. Эта книга о втором типе криптографии.

Брюс Шнайер

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

Вы под микроскопом осматриваете все транзисторы на чипе и удостоверяетесь, что ваши математические гарантии к нему применимы, что в чипе нет дополнительных транзисторов, о которых вы не знали и которые мешали бы вашему доказательству. Чтобы никто уж точно не мог добраться до машины, на которой хранятся пароли, вы помещаете её в крепости, в запертой комнате с двенадцатью замками с отдельными ключами. Комната сообщается с окружающим миром только по Ethernet-кабелю. Любая попытка пробраться в комнату через стены активирует взрывное устройство, которое уничтожает компьютер. У машины собственный атомный электрогенератор, так что никто не может что-то сделать с подачей энергии. Только один человек знает пароль, и его постоянно окружают телохранители, так что никто не может вызнать пароль при помощи терморектального криптоанализа. Длина пароля – 20 символов, его сгенерировал квантовый генератор случайных чисел под присмотром единственного авторизованного пользователя. Генератор потом уничтожили, чтобы никто точно не мог узнать пароль, осмотрев его. Опасное действие может быть исполнено только один раз (оно должно быть исполнено в конкретное время), и пароль надо вводить тоже только один раз, так что не надо беспокоиться, что кто-то перехватит пароль, а потом использует его.

Будет ли такая система по-настоящему полностью невзламываемой?

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

– Что?! – Кричит создатель системы. – Но я потратил столько денег на крепость и получил математическое доказательство поведения программы и крайне укрепил все аспекты системы! Со всеми этими усилиями я превзошёл сам себя!

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

– Но какая у системы настоящая слабость? – допытывается создатель.

– Для начала, – объясняет криптограф, – ты не следовал стандартной практике никогда не хранить пароль прямым текстом. Правильный метод – хэшировать пароль, к которому прибавлена случайная хранимая «соль» вроде «Q4bL». Представим, что пароль (какая неудача) – «rainbow». Ты не хранишь «rainbow» прямым текстом. Ты хранишь «Q4bL» и надёжный хэш строки «Q4bLtainbow». Когда пароль вводят, ты добавляешь к нему со стороны начала «Q4bL», хэшируешь получившуюся строку, а потом сравниваешь хэш с тем, что у тебя сохранён. Тогда даже если кто-то посмотрит на хэш, который ты хранишь, это не выдаст пароль. Даже если у этого кого-то есть большая заранее вычисленная таблица хэшей самых частых паролей вроде «rainbow», там всё равно не будет хэша «Q4bLrainbow».

– О, ну, мне об этом не надо беспокоиться, – заявляет создатель. – Эта машина в очень хорошо охраняемой комнате, так что никто её не вскроет и не прочитает файл с паролем.

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

– Пфе, – фыркает создатель, – если твоя «стандартная криптографическая техника» заполучения моего пароля полагается на то, что у тебя будет физический доступ к моему компьютеру, она не сработает. Так что мне волноваться не о чем!

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

– Ты имеешь в виду, что может быть какой-то таинственный неправильный пароль, который заставляет систему передать серию «Ага» и «Нетушки», которая кодирует настоящий пароль? – Говорит создатель скептическим тоном. – Это может на первый взгляд звучать не невозможно. Но помимо невероятной маловероятности, что кто-то может найти такой эксплойт, это вообще-то очень простая программа, я написал её сам. Я, на самом деле, математически доказал, что система выдаёт в точности одно «Нетушки» и больше ничего на неправильные пароли и в точности одно «Ага» и больше ничего – на правильный. Каждый раз. Так что так узнать пароль нельзя – последовательность неправильных паролей всегда приведёт к последовательности ответов «Нетушки» и больше ничему. Так что мне снова не надо беспокоиться об этой твоей «стандартной криптографической технике». Даже если бы она была применима к моей программе, а это не так.

– Вот почему, – вздыхает криптограф, – у нас есть пословица «не придумывай своё шифрование». Твоё доказательство не доказывает математически, что нет вообще никакого внешнего поведения системы, которое зависит от настоящего пароля, в тех случаях, когда его не ввели. В частности, ты упускаешь тайминг ответов «Нетушки».

– Ты говоришь, что поищешь какую-то серию таинственных неправильных паролей, которые заставят систему выдать «Нетушки» через число секунд, в точности соответствующее первой, второй и так далее букве настоящего пароля? – легкомысленно отвечает создатель. – Я математически доказал, что система никогда не выдаст «Ага» на неправильный пароль. Думаю, это также покрывает большую часть случаев переполнения буфера, которые теоретически могли бы заставить систему так себя повести. Я проверил код, и там попросту нет ничего, что могло бы кодировать такое поведение. Это кажется просто умозрительной гипотетической возможностью.

Нет, – терпеливо объясняет криптограф, – я говорю о том, что мы называем «атакой по сторонним каналам», к данном конкретном случае – о «атаке по времени». Операция, которая сравнивает введённый пароль с правильным паролем, работает, сравнивая первый байт, потом второй байт, и так пока не найдёт первый неправильный байт, после чего заканчивает работу. Так что если я попробую пароль, который начинается на «a», потом пароль, который начинается на «b», и так далее, а настоящий пароль начинается на «b», то будет небольшая, но статистически заметная тенденция, что попытки, которые начинаются с «b» получают ответ «Нетушки» чуть позже. Тогда мы начинаем пробовать пароли, которые начинаются с «ba», «bb», «bc», и так далее.

Создатель некоторое время выглядит поражённым. Потом его лицо быстро выправляется.

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

– Да, поэтому мы пошлём миллион тестовых паролей и посмотрим на статистические различия. Ты не встроил ограничение частоты, с которой можно было бы пробовать пароли. Даже если бы ты применил эту стандартную практику и применил бы стандартную практику хэширования паролей вместо хранения их открытым текстом, твоя система всё равно могла бы оказаться не такой надёжной, как ты надеешься. Мы могли бы подвергнуть компьютер большой нагрузке, чтобы растянуть ответы на наши запросы. И если бы мы так по времени ответа выяснили хэш, то можно было бы использовать тысячи GPU и попробовать его обратить, без нужды посылать каждую попытку на твой компьютер. Чтобы действительно залатать эту дыру, тебе надо удостовериться, что время ответа фиксировано и не зависит от того, какой именно неправильный пароль введён. Но стандартные практики ограничения частоты попыток ввода пароля и его хэширования по крайней мере усложнили бы использование твоего недосмотра как уязвимости. Поэтому мы применяем такие практики даже когда думаем, что система была бы надёжна и без них.

– Просто не верится, что такая атака действительно сработала бы в реальной жизни! – Отчаянно сказал создатель.

– Она и не работает, – ответил криптограф. – Потому что в реальной жизни специалисты по кибербезопасности пытаются удостовериться, что точное время ответа, энергопотребление процессора и любой другой сторонний канал никак не зависит от секретной информации, которую может хотеть добыть противник. Но да, в 2003 году была атака по времени на SSL-сервера, хоть и более сложная, потому что SSL-система была не такая наивная. а задолго до этого атаки по времени использовали для добычи правильных логинов с Unix-серверов, которые запускали функцию crypt() на пароле только если логин был правильный, потому что crypt() на старых компьютерах занимала немало времени.

В кибербезопасности мы можем титаническими усилиями повысить стоимость чтения твоих файлов для крупных государств до той степени, что они больше не могут сделать это по Интернету и им приходится посылать кого-то лично в твой дом. В АНБ или китайском 3PLA куча обученных профессионалов, и когда твоя система опубликована, они могут потратить много времени на то, чтобы попробовать тебя обхитрить. Ты же, если умён, не будешь пытаться в одиночку перехитрить их, а используешь инструменты и методы, которые создала большая коммерческая и академическая система с большим опытом предотвращения того, чтобы крупные государства читали твои файлы. Так ты и правда можешь заставить их кого-то нанять, чтобы они вломились в твой дом.

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

Перефразируя Шнайера, можно сказать, что в мире есть три вида надёжности: надежность, которая помешает читать ваши файлы вашей младшей сестре, надежность, которая помешает читать ваши файлы дядям из правительства и надёжность, которая помешает суперинтеллекту получить то, что он хочет. После этого можно ответить, что третий вид надёжности недостижим. А если бы он у нас и был, для нас было бы очень сложно знать, что он у нас есть. Может, суперинтеллекты и могут сделать себя абсолютно точно надёжными против других суперинтеллектов. Мы – нет, и знать, что сделали это, тоже.

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

Если вы спросите специалиста по кибербезопасности, как создать операционную систему, которую не смогут взломать в ближайшее столетие, если от этого буквально зависит судьбы мира, правильный ответ: «Пожалуйста, не позволяйте судьбам мира от этого зависеть».

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

В безопасности ИИ первая линия обороны – ИИ, который не хочет тебе навредить. Попытка поместить ИИ в взрывоустойчивый бетонный бункер может быть или не быть осмысленной и оправданной предосторожностью на случай если первая линия обороны окажется неидеальной. Но первой линией обороны всегда должно быть то, что ИИ не хочет навредить тебе или обойти твои прочие меры безопасности; не какой-то умный план, как предотвратить, чтобы суперинтеллект получил что хочет.

Крайний случай такого мышления о безопасности ИИ – «Всетест» – стал бы ИИ вредить нам (или обходить меры безопасности), если бы был всеведущим и всемогущим? Если да, то мы точно создали неправильный ИИ. Это мы создаём алгоритм. Создавать алгоритм, который нам вредит, не надо и точка. Если проект агента не соответствует «Всетесту», значит есть сценарии, которые для него предпочтительнее, чем те, что мы считаем приемлемыми. Тогда агент может начать искать путь такие сценарии реализовать.

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