Модель распределённой сети хранения ключа

Можно завести свои серверы в сети tor (у нас много про него обсуждений в форуме). Их IP и месторасположение будут неизвестны. Они (если не атакованы и не взломаны) невидимы и анонимны.
На серверах разместить скрипт – выслать ключ или уничтожить его.

Реальные их IP нужно как-то забыть (только непонятно как ими управлять? Если отключить SSH то они долго не проживут, если оставить – то у Вас попросят пароль на SSH и получат доступ). Возможно придётся изобрести промежуточный TOR-сервер для связи с ними.

Для получения ключа расшифрования диска нужно соединиться с сервером в сети tor по SSL. Поскольку его IP неизвестен, то третьи лица не
могут придти и снять с него данные. Если Вы введёте "уничтожающий" пароль, то сервер сотрёт ключ (или его часть), вместо того чтобы его Вам выслать.

На ЛОРе писали про 97% ключа, это неверно. Криптостойкость ключа при разбиении значения не уменьшается. Разбивается или XOR со случайной величиной (тогда надо собрать все доли) или при помощи полиномов над множеством простых чисел (протокол Шамира из работы "How to share a secret", 1979 год).

Я тоже изначально о tor подумал. Здесь цена вопроса сводится к тому, насколько "неуязвимым" разумно считать сервера tor. В общем-то вопрос довольно спорный... и наболевший. Как и вообще tor.

Аналогия с квантовым состоянием и цель протокола мне кажутся очень интересными, но признаюсь, готового решения мне неизвестно.

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

Кросспостинг на ЛОР не делаю, пока пишу то, что думаю здесь.

На лоре человек очень хорошо выразил мысль в 2-х словах. Я забыл её привести сразу. Нужна _система_самоуничтожения_закрытого_ключа_по_не_правильной_пассфразе_(!). Огород я начал городить как раз затем, чтобы создать коссвенным образом качественно именно такую систему.

Может быть, SATtva знает?

Нужна _система_самоуничтожения_закрытого_ключа_по_не_правильной_пассфразе_(!).

Не совсем. Может быть три состояния пассфразы:

Правильная – поиск ключа по индексу (256 бит), если найден, то выдать часть ключа для сборки. Но перед выдачей проверка по HMAC, два значения HMAC тоже хранятся на сервере, одно для уничтожения, другое для выдачи. (Сошлось значение по полю "выдача")

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

Уничтожающая – индекс ключа на сервере найден, прошла проверка запроса по HMAC со вторым полем "уничтожить": уничтожить долю ключа на сервере, а вместо неё выдать опять таки случайную строку.

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

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

Чтобы серверы не знали, доли чьих ключей они хранят, им всё равно придётся образовывать между собой сеть типа (cipherpunk / mixmaster) – шифрование вложенными публичными ключами по цепочкам, выбранным пользователем, для анонимной загрузки долей ключей в сеть. Плюс еще одна доля остаётся у пользователя.

И что-то типа tor или своего протокола peer-to-peеr для быстрого получения ответа с множества серверов. Те же цепочки, только ближе к протоколу SSL.

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

Пока считаем, что часть серверов может отключиться от сети, но нет постоянныой их смены как в peer-to-peer

Куча всех индексов, проверочных значений HMAC, долей ключей разворачивается из основного пароля.

Эта общая идея, которая как мне кажется, показывает, что протокол возможен, но нужно очень потрудиться, чтобы его формализовать, доказать стойкость ("provably security"), чтобы он был быстрым, практичным, отказоустойчивым и сопротивляющимся разным видам атак.

Спасибо, unknown.
На свежую голову я подумаю над этим идеями. Довольно интересно.

Непонятно, как поможет эта схема против предложенного выше(по ссылке) метода:

"1) снимаем компию моего диска, ложим её в шкаф.
2) заставляемменя ввести пароль расшифровки
3) я ввожу пароль уничтожения вместо пароля расшифровки
4) 3-и лица смотрят на какой сервер пересылается информация и идут туда
5) 3-и лица получают контроль над этим сервером и получают к нему
полный доступ (предположим)
6) в итоге 3-и лица узнают, к чему бы привёл потенциально мой пароль
(к уничтожению), копия же диска 2-го сервера также лежит в шкафу.
7) узнав, что я ввёл пароль уничтожения они снова идут ко мне...
и так до сходимости."

Да, откровенно говоря никак. Должно быть что-то более сложное. Нужно думать дальше.

Например, кроме прямых цепочек, должны быть обратные.

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

Что-то всё больше мне это напоминает tor или mixminion.

Против предложенной "полной упреждающей инкрементальной виртуализации" поможет только квантовая криптография, имхо.

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

"И лишь немногие будут догадываться или даже понимать, что происходит."

Ну понятно, что если в качесте подсистемы использовать тор, предполагая его неуязвимым для 3-их лиц... то тогда то, что предложил unknown, будет работать. Пусть это не идеал, но это совсем не такое плохое решение, и оно много лучше того, когда вообще никакого нет :)

Пусть мы пошлём запрос на индекс пароля на все серверы,

...широковещательный запрос! Подумал я и решил, что идеально было бы использовать не tor.
За основу иожно взять протокол P5 – "Peer to Peer personal privacy protocol".

http://www.cs.umd.edu/projects/p5/

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

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

Что будет, если он сможет повторять запросы или искажать их по принципу "разделяй и властвуй"?


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

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

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

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

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