Конфиденциальное раскрытие без публикации файла

Вы можете подтвердить, что файл существовал в определённый момент, не делая сам файл публичным.

Именно это и делает запечатанная запись Label 309. Отправитель вычисляет хеш открытого текста, шифрует файл и публикует запись-подтверждение на Cardano. Шифротекст хранится в контентно-адресуемом расположении и доступен только тем держателям ключей, которые могут его расшифровать. Публичный блокчейн подтверждает, что определённое обязательство существовало к публичному времени блока; открытый текст остаётся доступным для чтения только выбранной аудитории.

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

Что здесь означает конфиденциальное раскрытие?

Это значит делиться доказательствами с конкретной аудиторией, а не со всем миром.

Такой аудиторией может быть юрист, аудитор, регулятор, журналист, команда внутреннего расследования, контактное лицо по безопасности у клиента, комитет совета директоров, партнёр — или вы сами в будущем.

Цель — подтвердить, что доказательства существовали в определённый момент, не выкладывая открытый текст в публичный блокчейн или на публичный сайт. Запечатанное Proof of Existence создано именно под эту форму: публичное утверждение о времени над приватным файлом.

Что на самом деле попадает в публичный блокчейн?

Запись-подтверждение становится публичной. Открытый текст — нет.

Запись в блокчейне может нести:

хеш открытого текста — это и есть подтверждение времени;
время блока транзакции Cardano;
конверт шифрования с упакованным ключевым материалом;
один или несколько контентно-адресуемых URI шифротекста (ar:// или ipfs://);
необязательную подпись, если отправитель решит подписать запись;
корень Merkle, если раскрытие охватывает сразу множество файлов.

Запись намеренно не несёт:

сам файл с открытым текстом;
читаемый список получателей;
приватный ключ какого-либо получателя;
ваш Identity Seed;
расшифрованные доказательства.

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

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

Как получатель открывает запечатанную запись?

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

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

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

Поскольку получатель владеет приватным ключом, именно здесь проверка переходит от «обязательство существовало» к «это конкретное содержимое существовало». О механике на стороне отправителя — как сообщить адрес получателя и принимать запечатанные записи — читайте в материале как принимать запечатанные записи.

Почему бы просто не отправить зашифрованный файл по электронной почте?

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

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

Запечатанная запись Label 309 даёт файлу публичную точку фиксации подтверждения, которая не зависит ни от вашего почтового ящика, ни от чьего-либо сервера. Зашифрованные данные можно хранить отдельно, и позже получатель сможет доказать, что расшифрованное содержимое соответствует хешу, зафиксированному в публичном блокчейне. Уведомить получателя по электронной почте по-прежнему можно — просто не позволяйте подтверждению зависеть от неё.

Почему бы просто не загрузить зашифрованный файл в приватное хранилище?

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

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

Label 309 добавляет обязательство с меткой времени. Он не заменяет ваше защищённое хранилище — он даёт этому хранилищу проверяемый слой подтверждения поверх него.

Когда запись о раскрытии стоит подписывать?

Подписывайте её, когда подотчётность важнее анонимности.

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

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

Может ли одна запись охватить несколько получателей?

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

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

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

А как быть с большим пакетом доказательств из множества файлов?

Используйте манифест и пакетирование Merkle вместо одной транзакции на файл.

Превратите каждый файл в лист через его хеш, сверните листья в единый корень Merkle и опубликуйте этот один корень в записи Label 309. Запечатайте манифест и сопутствующие файлы по необходимости. Позже получатель или аудитор сможет проверить любой отдельный файл с помощью короткого доказательства включения — полностью офлайн — вместо того чтобы относиться ко всему пакету как к непрозрачному архиву. Доказательства включения растут лишь логарифмически от размера пакета, поэтому раскрытие из тысячи файлов всё равно проверяется по одному элементу.

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

Что на самом деле подтверждает запечатанная запись?

Утверждения сильны, но они конкретны. Запечатанная запись Label 309 может показать:

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

Каждое из этих утверждений — точное, независимо проверяемое заявление о времени и целостности.

Что она не подтверждает?

Не менее важно вот что — чего она не устанавливает:

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

Общую версию этой границы смотрите в материале чего подтверждение не доказывает.

Как команде настроить это заранее, до того как понадобится?

Определите процесс раскрытия до кризиса, а не во время него. Решите заранее:

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

Криптография — лишь один слой. Именно окружающий процесс определяет, окажется ли подтверждение по-настоящему полезным в напряжённый момент. О подходе к работе с доказательствами читайте в материале юридические доказательства и e-discovery, а для источников с повышенным риском — доказательства от информаторов.

Коротко

Конфиденциальному раскрытию нужны сразу две вещи: приватность и подтверждение.

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

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

Что почитать дальше

Label 309 — открытый, не привязанный к поставщику стандарт Proof of Existence, лежащий в основе запечатанных записей. Label 309 — это метка метаданных в блокчейне; предложение рассматривается в процессе Cardano CIP как CIP категории Metadata (открытый PR).
Открытый код CardanoWall — корпус стандарта, SDK и инструмент командной строки cardanowall, который умеет строить, запечатывать и проверять записи.
Чего подтверждение не доказывает — границы любого Proof of Existence.
Проверьте получателя, прежде чем запечатывать файл — самая частая человеческая ошибка в зашифрованных рабочих процессах.