Протокол Ньютон: защищаем середину, а не края
Сегодня утром я оставила телефон разблокированным на кухонном столе примерно минут на десять, пока занималась кое-чем другим. А когда вернулась, у меня случилась эта короткая мини-паника — не потому, что что-то произошло, а из-за того самого рефлекса: «Подожди, а вдруг кто-то это поднял». Ничего не случилось. Но меня это заставило задуматься о том, где в системе на самом деле живет безопасность, а где мы предполагаем, что она живет.
Эта мысль еще крутилась у меня в голове позже, когда я снова села разбирать материалы «Протокола Ньютон», на этот раз в рамках «повышения безопасности за счет проверяемой автоматизации». И вместо того чтобы просто кивнуть, я поймала себя на более конкретном вопросе — безопасность от чего, в точности, и безопасность начиная с чего. Так что я начала копать реальные границы того, что защищают слой TEE и ZK.
Вот что до меня дошло, и это немного тревожит, когда видишь это ясно. Система верификации очень хорошо защищает середину конвейера — она доказывает, что выполненное действие соответствовало правилам, которые были утверждены. В этой части всё действительно железно. Но она вообще не затрагивает момент до этого — как именно разрешение было создано и подписано в первую очередь, и чем. Если устройство или ключ, подписавшие область разрешения, скомпрометированы, или если кто-то с доступом просто составляет разрешение, которое формально действительно, но слишком широкое, вся нижестоящая система добросовестно и криптографически докажет, что итоговое плохое действие было «корректно выполнено». Потому что так и было. Корректно выполнено, согласно инструкциям, которые вообще не должны были быть даны.
Похоже, я исходил из того же предположения, что и о своём телефоне: пока никто активно не взламывает его удалённо, с ним в целом всё в порядке. Я думал, что история безопасности здесь начинается с самого начала и охватывает всю цепочку от начала до конца. Но это не так. Она начинается уже после того, как разрешение существует и считается легитимным. Всё, что до этого — человеческий шаг, шаг подписания, устройство, на котором хранятся ключи — вообще не попадает в то, что проверяется. Это не критика инженерии: внутри своих границ она действительно сильна. Скорее, граница просто уже, чем обещает звучать фраза «безопасность через проверяемую автоматизацию».
Но вот что меня действительно беспокоит. Исторически большинство реальных компрометаций в крипте происходило не из-за взлома самой криптографии, а именно на этом верхнем слое — украденные ключи, скомпрометированные устройства, когда кто-то под давлением или из-за путаницы подтверждает то, что подтверждать не должен. Если именно там по-прежнему сосредоточен реальный риск, то система, которая доказуемо защищает всё после появления разрешения, решает проблему, которая обычно не та, что кусает людей. Это немного похоже на установку очень хорошего замка на дверь, когда реальные взломы в основном происходят через открытое окно, которое никто не проверяет. Я не говорю, что замок бесполезен; просто не думаю, что он меняет вероятности так сильно, как это подразумевает сама подача.
Есть ещё вопрос отзыва разрешений, о котором я не ожидал вообще задумываться, но теперь не могу перестать — если разрешение уже активно и агент находится в середине цикла, как быстро пользователь реально может его отозвать, если что-то кажется неправильным. Я пока не до конца разобрался с этим; возможно, это просто пробел в том, что я прочитал до сих пор, а не в самой системе.
Полагаю, это особенно важно для тех, кто воспринимает такую проверяемую автоматизацию как повод быть менее осторожным с тем, что происходит выше по цепочке — гигиеной устройств, тем, у кого есть доступ к подписи, тем, как проверяются разрешения перед выдачей. Математика от этого не меняется только потому, что всё ниже по цепочке криптографически неуязвимо.
Впрочем, телефон снова в кармане, ничего не случилось, очевидно. Но всё равно проверяю дважды, прежде чем оставить его где попало. Старые привычки, наверное, даже когда реальный риск, скорее всего, был совсем в другом месте.