Слой приватности Newton делает точное заявление о безопасности: когда частные данные шифруются и загружаются, шифротекст криптографически привязан к конкретной политике и конкретной цепочке.
Попробуйте воспроизвести тот же зашифрованный конверт где-то ещё — при другой политике, в другой цепочке — и проверка подлинности сразу же не проходит.
Доступ к расшифровке запрещён. Я хотел увидеть, что именно охватывает «привязано к», и, что так же важно, что оно не охватывает.
Вот формула.
Дополнительные аутентифицированные данные, прикреплённые к шифрованию, вычисляются ровно из двух входных параметров: клиента политики и идентификатора цепочки, которые затем хешируются вместе.
Этот хэш становится частью того, что алгоритм шифрования аутентифицирует вместе с самим шифртекстом.
Если меняется любой из входных параметров — другая политика или другая цепочка — весь тег аутентификации разрушается, и алгоритм отказывается расшифровывать.
Это сильная, хорошо ограниченная гарантия — и именно такой защиты вы бы хотели от попытки извлечь валидный зашифрованный полезный груз и использовать его в контексте, для которого он изначально не предназначался.
Но вызов загрузки, который несёт этот шифртекст, не передаёт только шифртекст и эти два связанных значения.
Он также несёт время жизни (time-to-live) — значение, которое определяет, как долго этот фрагмент данных должен оставаться действительным или доступным для извлечения, прежде чем он истечёт.
И когда я проверил, что именно входит в формулу аутентифицированных данных, TTL в неё не включён.
Формула покрывает ровно две вещи: клиент политики и идентификатор цепочки. Ничего больше.
Это реальное различие, а не формальность. Аутентифицированное поле — это такое, где любое подделывание разрушает криптографическое доказательство и автоматически фиксируется.
Неаутентифицированное поле — это то, что система просто принимает так, как оно заявлено, потому что ничто в самом шифровании за ним не следит.
Клиент политики и идентификатор цепочки относятся к первой категории.
TTL, судя по тому, что задокументировано, находится во второй категории.
Отсюда возникает вполне конкретный, проверяемый вопрос: если кто-то, имея возможность перехватывать или пересылать этот запрос на загрузку, изменит только TTL — при этом оставив шифртекст, клиент политики и идентификатор цепочки полностью неизменными — заметит ли вообще проверка аутентификации?
Исходя из формулы, как она написана, — не должен.
Шифртекст по-прежнему будет расшифровываться без проблем, потому что манипуляции с TTL не затрагивают те два значения, которые алгоритм действительно проверяет.
Данные остались бы ровно тем, что зашифровал исходный отправитель. Просто срок годности изменился бы тихо.
Это важно больше, чем может показаться на первый взгляд, потому что TTL — это не декоративные метаданные; это средство контроля безопасности само по себе.
По всей видимости, именно это ограничивает, как долго система всё ещё будет действовать с чувствительными зашифрованными данными, всё ещё извлекать их и всё ещё считать их актуальными.
Сокращённый TTL может привести к тому, что законные данные истекут слишком рано и тихо сломают рабочие процессы, которые от них зависят.
Удлинённый TTL мог бы позволить удерживать чувствительные данные живыми и доступными ещё долго после того, как исходная сторона решила, что это имеет значение.
Ни для этого не требуется ломать шифрование.
Ни то, ни другое не затрагивает ту единственную проверку целостности, которую системе предписано выполнять.
Я хочу точно сказать, чего именно я не утверждаю.
Я не знаю, можно ли в действительности воспользоваться этой брешью end-to-end — это зависит от вещей, которых нет в документации: например, коммитит ли Gateway TTL независимо на блокчейне в момент загрузки так, чтобы его потом нельзя было изменить; передаётся ли сам запрос на загрузку по каналу с собственной защитой целостности на уровне транспорта, которая перехватит подделку ещё до того, как она попадёт на этот уровень; или же TTL рассматривается как рекомендация, а не как критичный для безопасности параметр вообще.
Любое из этого может полностью закрыть эту брешь, и ничто из этого не проявится непосредственно в самой формуле AAD, потому что это были бы защиты, наложенные поверх, а не встроенные внутрь неё.
Итак, главный открытый вопрос сформулирован точно: фиксируется ли где-то значение TTL неизменно и проверяемо в момент загрузки — на блокчейне или внутри какой-то другой аутентифицированной структуры — или же оно принимается «как есть» как параметр вызова RPC, которому доверяют так же, как доверяют любому полю неаутентифицированного запроса?
Документация точно описывает, что именно защищает само шифрование.
Ничего не сказано о том, что защищает одно-единственное времязависящее значение, которое определяет, как долго эта защита вообще должна длиться.