Pull to refresh

Comments 79

Объясните, пожалуйста, чем хранение hc-key лучше, чем хранение в том же «надежном месте» i-key?

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

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

Отнюдь. На случай кражи ключа в PGP существует так называемый key revocation certificate — сертификат отзыва ключа. Враг может его получить, но это ему ничего не даст. Любой, обладающий сертификатом отзыва, может опубликовать его, сделав таким образом украденный ключ бесполезным.
Удалить мастер-ключ в PGP тоже можно, но без мастер-ключа невозможно будет делать новые подключи. В этом и есть проблема Вашего подхода.
Отнюдь. На случай кражи ключа в PGP существует так называемый key revocation certificate — сертификат отзыва ключа. Враг может его получить, но это ему ничего не даст. Любой, обладающий сертификатом отзыва, может опубликовать его, сделав таким образом украденный ключ бесполезным.

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

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

Конечно. И то что предложил автор статьи эту проблему не решает, да и не существует такого метода в рамках асимметричной криптографии. Если украли секретный ключ незаметно, то жертва не сможет ничего сделать, пока не узнает об этом.
не существует такого метода в рамках асимметричной криптографии
А в рамках какой существует? (просто интересно)
Очень хотелось написать, что квантовая, но не знаю.
Полон я к ней, родимой, чёрного скептицизма.
Если говорить о раздаче IDшников, то и кража мастер-ключа, и публикация его revocation certificate полностью уничтожает учётку. В моей схеме невозможно никаким разумным способом ни украсть мастер-ключ, ни поиметь его revocation certificate. Это я и имею в виду, когда говорю об отсутствии фатальной уязвимости.
В PGP тоже можно удалить мастер-ключ и не создавать сертификат отзыва для него. Но это неудобно, если Вы хотите внести изменения в ID или сгенерировать новый подключ. Может измениться и почта и имя. Что делать в этом случае?
А так — пожалуйста, удаляйте на здоровье.
Вы можете заметить, что в описанном приёме вообще нет ничего выходящего за рамки стандартной давно всем известной криптофункциональности. Банальщина страшнейшая. Мощно усилить функциональность PGP добавлением команды del, ага. Тем не менее, эта смехотворная мелочь, будучи применённой к месту (особенно если она встраивается в архитектуру как «поведение по умолчанию»), становится затыканием той дыры, которая казалась незатыкаемой. Знаете, самому до сих пор смешно.
В первую очередь лучше тем, что если украли hc-ключ, то это не катастрофа. Мы публикуем его в списке отзывов, и пользуемся другими ключами, спрятанными заранее в других местах. Если же украли i-ключ, то учётка навсегда потеряна. В мире не остаётся того секрета, знанием которого изначальный владелец отличается от злоумышленника.

Для того, чтобы перестать отличаться от владельца ключа, злоумышленнику нужно найти все hc-ключи. А поскольку в нормальном режиме они не используются, они могут быть спрятаны как угодно далеко. Например, записаны на флешку, помещены в герметичный контейнер и закопаны в огороде. А ещё некоторые можно записать на бумажку и положить на дно бабушкиного сундука. Даже если злоумышленник придёт к владельцу с паяльником, владелец может под непереносимым физическим воздействием выдать флешку с огорода, но про бумажечку умолчать, и потом с её помощью вернуть себе власть.
Почитал. Немножко не то. Хотя бы потому, что там не предполагается немедленное уничтожение master key.

А в чём смысл его уничтожать? У Вас есть возможность создавать новые ключи, подписав их a-key. И эти новые ключи ничем (кроме длины цепочки, которая никак не учитывается) не отличаются от подписанных i-key.


Ещё не прояснён вопрос с тем, как именно отзываются ключи. Учитывая, что i-key удалён, надо полагать что для отзыва a-key1 нужен сам a-key1. Но ведь его могли забрать, а не скопировать (если у юзера нет бэкапов). И получается, что не имея украденного a-key1 юзер даже не сможет его отозвать. Был бы i-key — можно было бы отозвать его подпись для a-key1, но его удалили.


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

возможность создавать новые ключи, подписав их a-key
Если в список отзывов попадает a-key, в помойку сразу автоматически отправляются все ключи, которые им подписаны. Что логично. i-key интересен тем, что он не может быть скомпрометирован в принципе. Ввиду его физического отсутствия.

Ещё не прояснён вопрос с тем, как именно отзываются ключи.
В принципе, классический PGPшный способ через сертификат аннулирования вполне годится. То есть мы знаем, что любой ключ (за исключением, конечно, i-key) может быть скомпрометирована, и заранее создаём для всех них по сертификату отзыва. И всё разныкиваем по разным местам. Итого имеем:
— a-key — на компьютере, им мы пользуемся каждый день.
— hc-key1 — в баночке из-под детского питания под кустом сирени.
— hc-key2 — на бумажке на дне сундука.
— сертификат аннулирования для a-key — в зашифрованном zip-архиве послан самому себе на гмэйл. А заодно на всякий случай закатан на CD со свадебными фотками в метаданные одного из файлов.
— сертификат аннулирования для hc-key1 валяется в открытом виде на той же флешке, что и сам hc-key1, но ещё одна его копия стеганографией вшита в фотку, выложенную в ЖЖ.
— сертификат аннулирования для hc-key2 скормлен (опять же в зашифрованном виде) в Эвернот, а заодно зарыт в оставшиеся после института конспекты лекций по физике.

Достаточно параноидально? Если придут непреклонные ребята, можно им сдать a-key, hc-key1 и по одному сертификату аннулирования к каждому из них. А добравшись до безопасного места оставшимися аннуляторами их быстренько аннулировать и при помощи hc-key2 породить себе новый a-key и на всякий случай hc-key3.
Уффф, становится похоже на какой-то дурной боевик.

что такого нового и уникального даёт описанный подход — неясно
Хотя бы то, что потерять идентичность так, чтобы с концами, становится труднее. Больше пространство для манёвра и отыгрывания взад мелких досадных глупостей. Сценарий с паяльником — это всё же экзотика. Если такое намечается, лучше не валять дурака и делать ноги куда-нибудь в тайгу. Проза жизни не так красочна. Зацепить кейлоггера, попасться на фишера по запарке и прочая дурь человеческая.
Опять же, если речь идёт не о людях, а о серваках, то все эти глупости помножаются на человеческий фактор наёмных работников. Сегодня админ — парень в доску свой, а завтра у его любимой тёти случается рак, и он готов душу дьяволу продать за возможность пролечить её в Израиле. Описанный подход позволяет выдать админу a-key, но в случае его плохого поведения отобрать взад безо всяких последствий.

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

Мастер-ключ при этом может лежать где-то в сейфе
Зачем?

Просто потому, что в его уничтожении нет никакого смысла. Ну или Вы пока этот смысл не смогли объяснить.

Кащею тоже как-бы не было смысла насовсем избавляться от иглы, которая в яйце, которая в утке, которая в зайце ;)

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

Никакого убытка — если заранее создать несколько subkey и сертификаты отзыва, то дальше наличие мастер-ключа не требуется (пока все subkey не будут отозваны, что довольно маловероятно, и в Вашей схеме работает точно так же).


Так что ответ на вопрос "зачем" тривиален: лень. Никакого смысла в его уничтожении нет, так чего ради напрягаться? А на самом деле его не уничтожают потому, что его наличие позволяет избежать суматохи при создании начальных ключей — достаточно создать один subkey для ежедневного использования и положить master в сейф. Если когда-нибудь потребуется отозвать этот subkey и/или создать новый — это можно будет сделать тогда, когда в этом будет необходимость.


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

в зашифрованном zip-архиве послан самому себе на гмэйл

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

А если перекодировать в Base64?

А для этого его надо скачать, а поскольку оригинал файла находился на зашифрованном винте ноута лежащем в сейфе за 2500 км… — было весело (даже через IMAP нельзя было скачать), так что выводы я сделал.

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

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

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

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

Если не рассматривать ситуацию с паяльником, то остальное никакого смысла не имеет. А в случае с паяльником не так уж сложно добиться от объекта честного указания всех мест хранения «запасных» ключей.
Из минусов: много мест хранения запасных ключей — это много мест уязвимости. Доступ к любому из этих мест дает возможность злоумышленнику представиться истинным владельцем и успеть сделать гадость до того, как истинный владелец сумеет доказать, что у него запасных ключей больше.
Мир криптографии на открытом/закрытом ключе не заканчивается. Есть куча разных алгоритмов. Как насчёт почитать книжку Applied Cryptography — очень интересное чтиво.
Какую конкретно главу читать? С чем конкретно я пересёкся?
У вас нет совпадений, так как у вас не проблемы, которую нужно решить.
Насколько я понимаю, вас увлекло свойство открытого\закрытого ключа. Ну так в книжке куча таких-же увлекательных алгоритмов — вам будет интересно.
Как это нет проблемы? Прямым же текстом написано (Ctrl+F по слову «задача»).
Размышлял над тем, как в децентрализованной сети агентов можно организовать идентификацию участников при условии, что (а) identity theft если он не с концами, то это мелкая неприятность, но если с концами, то это катастрофа и (б) схема должна быть работоспособной на чудовищно длительных по нашим меркам интервалах времени (многие десятки, а возможно и сотни лет).
Потребовать от агентов напрячься и поохранять свои сверхсекретные ключи пару-тройку лет можно, но рассчитывать на то, что все будут умничками десятки лет — без шансов. Особенно, если захват чужих identity может быть чрезвычайно привлекательной идеей. В таких условиях может сработать только принцип «если у вас нету дома, пожары ему не страшны».

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

в книжке куча таких-же увлекательных алгоритмов
Безусловно. Сам её люблю. Не понимаю только, на что конкретно Вы намекаете.
Извиняюсь, может я не внимательно читал. Мне показалось, что сначала был алгоритм, а потом придумка, где его можно использовать.

Тогда замечание — удаляя приватный ключ вы больше не сможете подтвердить свою идентичность, и кто угодно сворует ваш ид с открытым ключом и скажет что это его. Так даже воровать ничего не нужно — ну есть двоичные данные, ну и что, что у них структура какая то подпись и какой-то ключ, без закрытого ключа никто не сможет единолично подтвердить акт генерации именно им этих двоичных данных.
удаляя приватный ключ вы больше не сможете подтвердить свою идентичность
Таки могу. Допустим, ID — это открытая часть i-ключа. Вот прям как он есть. Я присылаю системе команду «два пива и пицца, пожалуйста». Как водится, команда подписана моим a-ключом. Но вместе с командой и подписью уходит также открытая часть моего а-ключа и подпись, выполненная i-ключом (созданная на шаге 2, пока секретная часть i-ключа была ещё не уничтожена), заверяющая подлинность а-ключа. Сервер пиццерии имеет мой ID, и вот прямо им удостоверяется в подлинности а-ключа, а уже зная, что а-ключ подлинный, убеждается в подлинности команды про два пива. В общем, всё как обычно делается с цепочками сертификации, но только мы с пиццерией обошлись без услуг третьей доверенной стороны в качестве корневого центра сертификации.

Чтобы злоумышленник смог воспользоваться моим IDшником, ему придётся решить маленькую, но весьма противную задачу — по открытой части i-ключа (он же, как мы помним, и есть IDшник) сгенерить его закрытую часть.
Вы же знаете про MitM атаку? ;) Третья сторона, которой доверяете вы и пиццерия как раз и нужна для нивелирования таких атак.

Как можно дальше общаться с пицерией, если вы не сможете больше подписать ни одной команды со старым ключём/ид.

И кто тут «я», который присылает команду на два пива? Может это спам? Подтвердите, что вы это вы а не злой хакер Вася Пупкин! :)

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

Теоретически сейчас вы шлёте команду и двоичный шум.
MITM-атака всегда играет в-короткую. Для неё нужно полностью контролировать коммуникацию между Алисой и Бобом. Сделать это на коротком интервале можно, но IDшник — это штука, эксплуатируемая годами. С разных компов. Через разные сети. Не, не реально. Вообще, MITM при активной защите от него (когда Алиса и Боб конкретно озаботились этой проблемой) весьма бесперспективен. Впрочем, это уже другая тема.

Как можно дальше общаться с пицерией, если вы не сможете больше подписать ни одной команды со старым ключём/ид
Я подписываю ключом, подписанным старым ключом. Что в этом вообще необычного? Никакого спама. Всё чётко.
То есть на любую команду нужно выпускать новый ключ, а системе хранить все ваши старые ключи — вы решили убить систему спамом? :)

Вы не можете подписать старым ключём -вы убили приватный ключ — вы помните? ;)
Господи, откуда Вы это взяли? В нормальном режиме (если не было пожаров, взломов и прочих ЧП) я как с самого начала пользовался своим самым первым а-ключом, так и пользуюсь им всю жизнь. А к дополнительным даже не притрагиваюсь. Зачем что-то перевыпускать, пока всё хорошо?

Мне кажется, вы упускаете возможность, что Sk3 из "холодного хранилища" будет скомпрометирован. Это приведет к серии "я настоящий, он — подделка". Со временем Алиса сможет вернуть свою identity с помощью (Sk2;Pk2), но пиццу-то хакер себе закажет и даже съест.

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

Да и не только мотивация! За промежуток времени, в который ключ использовался, от момента создания и до его уничтожения, он может куда угодно убежать. Ну и самое главное где создается ключевая пара. Если на компьютере, то смотри предыдущее предложение. Если на токене PKCS#11 с неизвлекаемым ключом, то зачем его уничтожать. Как говорил классик, — "он же памятник". Ну и т.д.

от момента создания и до его уничтожения, он может куда угодно убежать
Нам нужно уметь обеспечивать всего несколько секунд безопасного исполнения кода. ИМХО, задача вполне реальная. Это намного проще, чем защищать активно используемый ключ от утечки на протяжении многих лет, разве нет?

Если на токене PKCS#11 с неизвлекаемым ключом, то зачем его уничтожать.
Токены с неизвлекаемыми ключами (особенно, когда действительно не извлекаемыми, а не как это часто бывает) — хорошие штуки, но с ними есть одна незадача. То, что ключ не извлекается, вовсе не говорит о том, что укравший этот злоумышленник не сможет его использовать. Если у него есть пин, то он будет им подписывать любую дрянь, пока ему не надоест или пока ключ не попадёт в списки отзывов. Что касается настоящего хозяина токена, то он в момент кражи лишается своей identity. Токен с неизвлекаемым ключом — прекрасный вариант, но только если нет чего поинтереснее.
Нам нужно уметь обеспечивать всего несколько секунд безопасного исполнения кода

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


Токен с неизвлекаемым ключом — прекрасный вариант, но только если нет чего поинтереснее.

А что, есть что-то интереснее?

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

Ага. Уже забыли про баг в Debian OpenSSL, из-за которого приватные ключи созданные на этой системе на протяжении полутора лет можно легко взломать? Чистый линух, не подключенный к сети, да. И это мы ещё не начинали смотреть в сторону закладок в железе.

Не драматизируйте.

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

Если ключевую пару генерировать софтом без открытых исходников, скачанным «откуда-то из Интернета», то тут, конечно, сложно говорить о какой бы то ни было безопасности. Элементарные правила гигиены как-бы никто не отменял ;)
Любая технология обеззараживания будет «дырявой» если клиент имеет привычку иногда пить из лужи.

А лужа это что Windows или Linux и его форки или Android или iOS или еще что-то? Вы откуда пьете?

Если я правильно понял вашу идею, законный владелец i-ключа Алиса в случае угона Sk1 рассылает своему контакт-листу сообщения "меня взломали, сообщениям, подписанным Pk1, не верить. Вот мой новый Pk2." Боб может проверить, что Pk2 принадлежит Алисе: он подписан Pk0. Я правильно понял идею?
Я не специалист по криптографии, поэтому не могу оценить новизну идеи. Чем-то напоминает одноразовый шифр-блокнот, разумеется с важными отличиями.
Мне кажется, у этой схемы есть несколько трудностей нюансов.


  1. Были исследования, когда за счет манипулирования текстом сообщения, удавалось получить правильную подпись под ним без знания секретного ключа. Через X лет для выбранного алгоритма могут придумать атаку, позволяющую написать от имени Алисы "меня взломали!" N-1 раз. Это плохо, т.к. у Алисы нет способов обновить набор ключей.
  2. Конечность набора Pk1, Pk2, ..., PkN. Вы рассуждаете о надежности на протяжении десятилетий, и значит рано или поздно созданные на втором этапе ключи закончатся даже если универсального алгоритма создано не будет. By-design нет способа насоздавать новые. Как в игреу кошки: количество жизней ограничено, пополнения нет. Если бы Алиса сохранила Sk0, количество "воскрешений" можно было бы увеличить как в игре. Сейчас, если identity угнали, создается новая и жизнь начинается сначала. Угон аккаунта подтверждается по другим каналам. То есть взамен "бесконечных жизней" получаем (кажущуюся?) повышенную безопасность одной длинной, но конечной. Вопрос, что лучше — философский :-)
  3. Держать в действительно разных хранилищах возможно очень малое число ключей. Если на бабушкином огороде закопана одна флешка, найти ее трудно. Если сотня, шанс выкопать пару ключей стремится к 1. Запомнить больше 20-30 заначек и разных механизмов доступа, а затем вспомнить через десять лет тоже нереально. Считаем:
    1. рабочий, которым ежедневно пользуемся. Механизм доступа — учетка к компу.
    2. Флешка в огороде. Доступ по координатам.
    3. Банковская ячейка. Доступ по паспорту.
    4. Архив в облаке. Доступ — уникальная (за 10 лет!) парольная фраза.
    5. Что-то свое оригинальное.
      Я бы поставил, что надежных независимых мест у Алисы будет меньше десятка. Может, это лучше чем один Sk0, но не так чтобы очень много
  4. Недоверие после смены ключей. Это Алиса отозвала Pk2 и прислала Pk3? Может хакер узнал не текущий ключ, а выкопал флешку? С кем я подписываю контракт? Это Алиса зовет меня ночью на кладбище? С точки зрения Алисы, безопасность выросла — она сможет вернуть аккаунт. С точки зрения Боба, шансы что он "здесь и сейчас" разговаривает с хакером возросли.

В голову пришла еще одна аналогия: Волан-дер-Морт. Он создал девять Sk, "подписал" каждый и развоплотился уничтожил Sk0, но это не спасло его. Не связывался бы с ПоттеромПри другой схеме безопасности, результат мог бы быть иным.

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

2. Набор теоретически конечен, но практически бесконечен. То есть (сами проверьте это на калькуляторе) если каждую наносекунду генерить триллион номерков, пространства 2128 хватит примерно на 10 млрд. лет. Ну ладно, с учётом парадокса дней рождений на миллиард. Если использовать пространство 256 бит (это несчастные 32 байта), то у нас количество атомов во Вселенной для записи номерков кончится раньше, чем вероятность возникновения хотя бы единичной коллизии превысит одну тысячную.

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

4. Ключи в любом случае воруют. Любые. В долгосрочной перспективе, так точно. Особенно те, которые по архитектуре системы используются каждый день. Что касается возрастания вероятности того, что хакер украл запасной ключ и зовёт Боба на кладбище, то можно в систему заложить правило: запасной ключ без доп. геморроя признаётся Алисой только если отозван текущий рабочий.
2. Нет, практически набор ключей, подписанных Sk0, конечен. Практически нереально сохранить хотя бы миллион (Sk;Pk) так, чтобы вероятность угона хотя бы одного была так же низка, как вероятность угона Sk0 из сейфа. Пример с огородом, засеянным флешками, показывает что увеличение количества приводит к снижению надежности хранения.
3. Обычно атаку для угона identity совершают с определенной целью: попросить денег у знакомых, набросить на вентилятор в холиваре, слить карму, своровать данные. Атака успешная, если хакер получил перевод от друга или утащил фотки знаменитости. Алиса сможет вернуть свою учетку, но пицца уже съедена хакером, атака своей цели достигла. Задача: усложнить угон учетки. Считаю важным подчеркнуть, что не усложнить угон учетки навсегда, а усложнить угон даже на 5 минут. Ведь есть альтернативные каналы чтобы вернуть/заблокировать учетку: СМС на телефон, прийти с паспортом в банк и т.д. Я не вижу, как решает эту задачу ваше решение.
4.
запасной ключ без доп. геморроя признаётся Алисой только если отозван текущий рабочий
Постойте, но ведь процесс отзыва ключа — это сообщение вида «вот мой новый публичный ключ, подписанный секретом-которого-никто-не-знает, а старый протух». Если отозвать текущий рабочий можно только с паспортом (тот самый геморрой), то зачем вся эта схема?

Я задаю вопросы и подвергаю сомнениям схему, чтобы понять чем она полезна и помочь вам лучше сформулировать плюсы. Пожалуйста, воспринимайте их как конструктивную критику, а не как нападки на вашу личность или неприятие идеи.
2. Упс… Похоже, я неправильно понял вопрос. Да, набор hc-ключей конечен. Да, делать их миллион и рассовывать куда попало — редкостная глупость. Но даже если hc-ключ создан один, всё равно он легко превращается в неисчерпаемое количество а-ключей. Когда у нас воруют а-ключ, мы вытаскиваем из заначки hc-ключ, и используем не его самого, а порождаем новый а-ключ с такой цепочкой сертификации:
i-key — hc-key — a-key2
И прячем hc-key обратно в заначку. Когда у нас крадут a-key2, аналогичным образом изготавливаем a-key3:
i-key — hc-key — a-key3
И так далее. Создавать не один, а два и более hc-ключей есть смысл на случай пожара, наводнения, забывчивости, парней с паяльником и других неприятностей.

3. По опыту работы с соцсетями могу сказать, что ломают учётку и рассылают от моего имени трэш — это, конечно, неприятно (а иногда ещё и дорого по деньгам), но если бы нельзя было обратиться в службу поддержки и восстановить свою власть, было бы совсем больно. И это всего лишь какие-то вонючие соцсети с лайками и комментами. Если децентрализованная сеть про что-нибудь более серьёзное, возможность реанимации учётки может стать критически важной фичей.
Вот просто представьте себе. Допустим, юрлица идентифицируются по ИНН, но работаем в децентрализованной экономике, и нет никаких налоговых инспекций, которые эти ИННы выдают. Злоумышленник может совершить identity theft и немножко покуралесить от лица ограбленного. Например, вывести средства с расчётного счёта, заключить договор о продаже завода на металлолом и сотрудников на органы. Средствам, ушедшим с р/с, конечно, можно только сделать ручкой, но их там обычно не много, и их потеря не смертельна. Договоры можно разорвать, мотивируя это тем, что «my account was hacked». Возможно, не без геморроя, но можно. Но терять бизнес целиком (активы, действующие договоры, репутация, персонал, бренды и т.п.) из-за того, что воры унесли сервак — это, извините, вообще не радует.

4. Насколько я знаком с теорией и практикой, revocation certificate может быть подписан не только тем CA, который подписал отзываемый ключ, но и секретной частью самого ключа. То есть имея закрытый ключ (и больше ничего), можно, грубо говоря, подписать сообщение «Я труп, забудьте меня», и эта подпись будет отзывным сертификатом. То есть никакого паспорта не надо. Надо только маленький файлик, наличие которого убивает использование ключа.

воспринимайте их как конструктивную критику
Не первый день в интернетах ;)
Критика, особенно конструктивная — на вес золота.
2. Я не улавливаю картины. Алиса пользуется в ежедневном режиме парой hc-key1;a-key1 (в моей терминологии Sk1;Pk1), в один грустный момент ключ скомпрометировали. Она достает пару hc-key2;a-key2, объявляет что первая пара утекла и… по моим представлениям, начинает использовать hc-key2 в ежедневном режиме. Боб проверяет письма по a-key2. Он доверяет a-key2 только потому, что он подписан тем же i-key что и a-key1 — только поэтому он знает, что это Алиса. Она не может спрятать обратно в заначку hc-key2 — это уже активный, а не «холодный» ключ.
Мы не можем и сгенерировать a-key3 — ведь чтобы ему доверяли, он должен быть подписан стертым i-key. Мы на шаге 2 алгоритма создали конечный набор ключей, которыми в будущем можем подписываться.

3. Мне кажется, вы немножко мухлюете :) Сначала вы придумываете задачу «реализовать схему возвращения доступа без использования сторонних каналов», а потом предлагаете реализацию. «Мухлеж» в том, что сравниваете свою схему не с текущей схемой «восстановить доступ к identity по стороннему каналу», а с теоретической «восстановить доступ в том же канале нельзя». Во втором сравнении выгоды ясны и очевидны, в первом нужно доказывать зачем трогать то, что работает. Простого желания работать в децентрализованной системе без центров доверия, на мой взгляд, недостаточно.

4. Не знал, спасибо
2. Немножко не так. И a-key, и hc-key являются ключевыми парами. Соответственно [SK1 и PK1] и [SK2 и PK2]. Их пути сертификации соответственно:
PK0 — PK1
PK0 — PK2

Парочка a-key (то есть SK1 и PK1) живёт на компе и активно используется, а парочка hc-key (то есть SK2 и PK2) отправляется под куст сирени. В грустный момент генерируем новую пару [SK3 и PK3], выкапываем hc-key из-под куста, и ключом SK2 подписываем PK3. После этого hc-key закапываем обратно под куст. Теперь у нас новый свеженький a-key (SK3 и PK3), у которого такой путь сертификации:
PK0 — PK2 — PK3
Если с ним что-то тоже случится, ещё раз проделаем упражнение и а-ключом будет новая пара [SK4 и PK4] с путём сертификации:
PK0 — PK2 — PK4

3. Не понял, в чём мухлёж. Боб имеет IDшник Алисы, который не что иное как PK0. Алиса к нему логинится своим новым а-ключом [SK4 и PK4]. Боб, даже ни разу до этого не видевший PK2, легко проверяет цепочку «PK0 — PK2 — PK4» и делает вывод, что PK4 тоже годится для доступа к IDшнику Алисы. Никакие сторонние каналы не нужны. Где мухлёж?
2. Простите, но если мы переименуем в этой схеме Sk2 в мастер-ключ, то чем эта схема принципиально будет отличаться от схемы держим секретный ключ в безопасном «холодном» хранилище? Если враг выкопает hc-key, он сможет создать PK3 и объявить себя Алисой. Или скомпрометировать Sk1, дождаться когда Алиса сообщит Перепрятушки! Теперь я использую Pk3, вот путь сертификации! и через полчаса хакер кричит Обознатушки! Pk3 сделала не я, верьте Pk4, вот пруфы!. Возможно, он даже утащил hc-key2 и не знает о существовании hc-1 и hc-3 — но об этом не знает и Боб! Боб видит двойников, у обоих валидный путь сертификации до Pk0 и оба отзывают друг друга как антипапы отлучали друг дружку от церкви. В распределенных системах хранения такое называется split-brain и любая современная система должна уметь с этим справляться / не давать возникнуть.

3. Мухлеж — это сильное слово, просто я не смог подобрать лучше. На мой взгляд, сравнивать вашу схему нужно с существующей централизованной схемой и убеждать, чем одна лучше другой. Для меня аргумента «децентрализация — это круто» недостаточно, потому что текущая схема работает и развивается.
2. Если злой хакер упёр hc-key и взялся плодить ключи, то публикуем revocation на этот hc-key, и проверка всех ключей, у которых цепочка проходит через этот ключ, обламывается. То есть хозяину ключа не нужно бегать с ножницами вокруг этого куста и состригать ветки, а можно сразу рубануть корень.

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

Кстати, интересна ситуация, когда хакер смог украсть единственный hc-key, но до рабочего ключа (a-key) не добрался. Хозяин учётки может сделать следующее:
а). Первым делом, естественно, публикует revocation для краденого hc-key.
б). Генерит две новые ключевые пары и подписывает их своим a-key.
в). Уничтожает a-key, т.к. именно этот ключ стал ахиллесовой пятой.
г). Одна из сгенерённых в пункте «б» пар становится новым a-key, а другая — новым hc-key, который с учётом горького опыта прячет не в огороде, а куда-нибудь подальше.

Приемлемая с точки зрения Боба цепочка сертификации совсем не обязательно должна быть из двух-трёх звеньев. Что-нибудь вроде такого тоже ОК:
PK0 — PK1 — PK5 — PK8 — PK10 — PK25
Единственное, что немножко возрастают накладные расходы на пересылку лишних нескольких килобайт. Плюс, конечно, Бобу больше ключей проверять по спискам отзыва.

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

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


CONFIG_MODULE_SIG=y
CONFIG_MODULE_SIG_FORCE=y
CONFIG_MODULE_SIG_ALL=y

Но удалять приватный ключ после сборки нужно явно. Конечно если надо загружать какой-то out-of-tree модуль то придется сохранить приватный ключ до момента подписи этого модуля.

Конечно если надо загружать какой-то out-of-tree модуль то придется сохранить приватный ключ до момента подписи этого модуля.
А загружать доп. модуль будет надо с весьма высокой вероятностью. Поэтому разумная опция — сохранить приватный ключ.
Кстати, подписание модулей — тоже, возможно, интересный кейс для использования одноразовых секретных ключей. Имеет смысл над этим подумать.
А загружать доп. модуль будет надо с весьма высокой вероятностью. Поэтому разумная опция — сохранить приватный ключ.

Зависит от конкретных обстоятельств. Я не в курсе про железо в серьёзных вендорных серверах, но из обычного применения разве что nvidia и zfs.

Давайте поразмыслим над предлагаемой идеей с точки зрения безопасности:

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

2.
Ключ SK0 уничтожается. Шаги с первого по третий выполняются в рамках единого процесса без записи SK0 в энергонезависимую память.
Очень сложно для реализации. Когда система работает в виртуальной инфраструктуре реализацию данного требования гарантировать невозможно. Во всех современных сертифицированных ФСБ России СКЗИ есть требования, чтобы после перезагрузки отчищался файл подкачки. Но это практически нигде не выполняется поскольку сильно замедляет процедуру перезагрузки. Были случаи когда активация данной фичи увеличивала время перезагрузки до 15 минут.
3.
Если используемая ключевая пара оказывается скомпрометированной, её ключ (в примере это PK1) помещается в список отзывов

Проблема в том, что списки отзыва сейчас мало кто проверяет. Это в первую очередь относится к браузерам — habr.com/post/332730

4. В чем преимущество вашего подхода?

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

б) Если рассматривать ваш подход, то безопасность базируется на обеспечении конфиденциальности n-секретных ключей (ключей аутентификации). Сразу возникает вопрос, что сделать проще: засекретить 1 ключ или n-ключей. Ответ очевиден. Едем дальше.
Злоумышленник скомпрометировал 1 из ключей аутентификации и сказал что все остальные ваши легальные ключи скомпрометированы, что тогда? Опять приходим к задаче аутентификации бесключевым способом (паспорт).

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

г) Что будет если злоумышленник скомпрометировал сразу все n-ключей аутентификации? Опять возвращаемся к бесключевой аутентификации.

Рекомендации для улучшения подхода:
1. Посмотрите в сторону математической связи между генерацией ключей идентификации и аутентификации. Она должна быть такой, чтобы ее нельзя было обмануть / не делать и т.д.

2. Опишите всю вашу распределенную систему. Как минимум в ней я услышал про список отзыва ключей (CRL), а раз он есть, то должен быть центр сертификации, иначе как обеспечивается валидность CRL? Описав всю распределенную систему ее можно сравнить со аналогичными схемами классических криптографических задач: ЭДО, криптовалюты и т. д.

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

Как всё запущено! А ведь достаточно зашифровать файл подкачки и всё.
… уникальным ключом, который генерируется при загрузке системы, никогда не свопится и стирается при перезагрузке. Вот он, применённый принцип из поста!
1.… Создание идентификационного и аутентификационных ключей математически не связаны друг с другом
Мне кажется, это не недостаток, а преимущество. Это очень хорошо, что а-ключ не даёт ни бита определённости относительно секретной части i-ключа.

2. <про файл подкачки>
Почему-то считал, что в файл подкачки отправляется то, что не используется активно. То есть если на коротком промежутке времени (секунды) активно используется относительно небольшой кусок памяти (килобайты), который на последнем шаге затирается нулями, то ничего интересного в файл подкачки не попадёт.

3. Проблема в том, что списки отзыва сейчас мало кто проверяет.
Речь идёт совсем не про «как нам реорганизовать Рабкрин TLS». Фантазируем о гипотетической системе, в которой децентрализована раздача идентификаторов. Как заложить в архитектуру системы работу со списками отзывов — отдельный вопрос, на который тоже можно при желании найти ответ.

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

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

4в. Если абонент сгенерирует только 1 ключ, ваш подход схлопывается к стандартному.
Сам знал, на что шёл, скручивая опцию, установленную по умолчанию.

4г. Что будет если злоумышленник скомпрометировал сразу все n-ключей аутентификации? Опять возвращаемся к бесключевой аутентификации.
Для этого ему сначала нужно узнать, чему равно n. А потом решить задачу взлома, помноженную на n.

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

Предположим, вознамерились мы создать полностью децентрализованную соцсеть. Всё как мы любим: посты, лайки, комменты, френды, группы, фотки, музыка и т.п. удовольствия, но только нет конторы, которая всей этой радостью владеет. То есть любой желающий может поднять ноду и захостить на ней себя любимого и, если щедрость позволяет, кого-нибудь из друзей. Плюс в дополнение к ноде, можно организовать для себя же в своём мобильнике «ноду на ножках», и таким образом физически хостить себя сразу в двух местах, которые между собой будут оперативно синхронизироваться. Каждый субъект (юзер, группа, корпоративный блог и т.п.) в такой системе должен получить идентификатор. Заставлять пользователя выдумывать логин — слишком тупо. Кто и где будет решать, кто из Вась Ивановых имеет больше прав на логин VasyaIvanov? Или на логин CocaCola? Кто первый занял? А если примерно одновременно? Как разруливать коллизии?

Системно правильный способ — использование длинных бессмысленных УИДов. Но как раздавать номерки, как гарантировать их уникальность и как предотвращать их угон? Ведь это так сладко — прикинуться компанией Apple и разослать хохмы ради рекламу Самсунга. Или фейковый квартальный отчёт. Нужен какой-то способ сделать так, чтобы если собеседник представился как «62b4a0a8-2adb-4d7c-9437-af3d23052682», то это с весьма высокой вероятностью именно он. По крайней мере не дурачок с улицы, пробующий свои силы в пранке.

В биткойновой сети идентификатором кошелька служит открытый ключ ЭП. Там этого достаточно. Но в рассматриваемом примере — нет, потому что если компании Apple в случае кражи ключа придётся хоронить старую учётку и с нуля набирать многомиллионную армию подписчиков, это будет серьёзным скандалом. Архитектору системы за такое должно икаться всю жизнь. Нужно более разумное решение, при котором Apple будет иметь возможность вернуть себе номерок «62b4a0a8-2adb-4d7c-9437-af3d23052682». Но при этом, как мы помним, всё напрочь децентрализовано, и поэтому нет того окошечка, в которое CEO Apple должен был бы явиться с паспортом и доверенностью.
Если система глобальна и децентрализована, не существует того окошечка, в которое можно было бы принести паспорт.

Не нужно окошечко, нужно подписать свой ключ максимально возможным количеством людей, ключи которых уже в сети доверия (web of trust). Вот они и будут проверять паспорт перед подписью.
Сеть доверия оказалась нежизнеспособной идеей. По факту. Оно не взлетело. Могу рассказать почему.
На мой взгляд, концептуальная ошибка глубоко закопана во-первых в недоопределённость понятия «доверие», и во-вторых в то, что доверие, даже если его предельно чётко конкретизировать — одна из тех штук, которые не могут быть выражены скалярной величиной.

Что значит «я доверяю»? Допустим, вот автомеханик Вася. Я ему доверяю починить подвеску, но в страшном сне не доверю ребёнка. Вот тётя Таня. Ребёнка я ей доверю, но подвеску — ни за что. Есть люди, в порядочности которых я уверен, но не уверен в их осмотрительности. Есть наоборот. Есть те, кому я доверю переговоры с заказчиком, но не доверю мытьё полов.

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

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

Работает в Дебиане отлично. Лучшего пока не видел.
Что значит «работает в Дебиане»? Оно и в винде работает, только не пользуется толком никто. Или Вы имеете в виду что-то другое?
Другое. Дебиан это некоммерческая организация без иерархической структуры. В ней состоит более тысячи человек, разбросанных по всему миру. Им нужно не только общаться, но и проводить удалённо голосования по важным вопросам, проверять аутентичность пакетов. Всё это много лет делается и верифицируется на основе вышеупомянутых PGP и web of trust. Вы слыхали про что-то подобное на основе других технологий? Я — нет.
Ну, если у них получилось использовать этот подход для решения конкретно той своей задачи, могу за них только порадоваться. Но из этого единичного кейса вовсе не следует, что если попытаться повторить этот фокус для чего-нибудь совсем другого, результат обязательно будет положительным.

Из сказанного вовсе не следует, что я фанат CA-based PKI. Вовсе нет. Гадость редкостная, но приходится ею пользоваться, пока не придумано третьего подхода, принципиально отличающегося и от CA, и от WoT.
Но из этого единичного кейса вовсе не следует, что если попытаться повторить этот фокус для чего-нибудь совсем другого, результат обязательно будет положительным.

Для чего-то совсем другого, конечно же, наверное не выйдет. Но что это «другое»? Вот Ваше описание

Задача: в распределённой системе участники регистрируются под создаваемыми ими самими уникальными идентификаторами. Требуется максимально затруднить задачу «угона» чужого идентификатора (identity theft). В случае состоявшегося угона идентификатора обеспечить истинному владельцу возможность возврата похищенного.


Для этого вполне.
Здесь мы уже как-то плавно перешли на воспоминания о светлой памяти сети доверия и размышлениях о том, почему она «не взлетела».

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

Сначала давайте разберёмся с тем, что такое эти самые идентификаторы, и для чего чего они нужны. Вообще, тема в полной мере раскрылась, когда были изобретены реляционные базы данных. То есть когда начали оперировать понятиями «сущность» и «связь» (entity & relationship). Если говорить привычным языком, данные начали записывать в таблички, и для некоторых из этих табличек оказалась востребованной возможность ссылаться на строку. Что использовать для ссылки? Номер строки не годится, потому что при удалении строки из середины съезжают ссылки на все хвостовые элементы. По описательным атрибутам — тоже криво. Во-первых, если записанные в базу атрибуты двух сущностей совпадают, то это не значит, что это один и тот же объект (Татьян Смирновых в РФ сильно больше, чем одна), а во-вторых сущности имеют свойство менять свои характеристики, оставаясь при этом самими собой (Таня Смирнова выходит замуж и становится Таней Петровой). Единственное по-настоящему правильное решение — добавить в таблицу искусственное поле, в которое писать ничего не значащую хрень, подчиняющуюся единственному требованию: каждая хренька должна быть уникальной в пределах таблицы. Притом если делать всё правильно и по науке, то требование того, чтобы хрень была именно что ничего не значащей, оказывается существенным. В правильных базах данных в идентификатор заталкивают длинные случайные числа. То есть учётка, идентифицируемая именем пользователя либо мэйлом — это по теории баз данных полный отстой. Даже те товарищи, которые придумывали ИНН для идентификации юриков и физиков, тоже косякнули в этом пункте, чем вызвали массу неудобств.
Через инфотехнологии тема идентификаторов проходит примерно везде. Если нет единого центра, раздающего номерочки, народ выкручивается разными способами. Например, мак-адреса раздаются производителями сетевого оборудования, каждому из которых выделяется диапазон. Штрихкоды товаров… ну, там вообще кромешный ад и хаос. Все эти ISBN, IMEI и прочее — это всё про раздачу номерков. Кто-то ценой титанических усилий весьма неплохо справляется, а где-то (как, например, со штрихкодами) трэш и угар. Но все эти случаи объединяет отсутствие мотивации воровать чужие номерки, что и даёт шанс справиться.
(извиняюсь за долгое вступление, уж очень к месту оказалось прогнать сказку про то, что это за собственно материя такая — IDшники, вокруг которых вся суета)

Теперь про сеть доверия. За/против какие утверждения будут голосовать участники? За то, что юзер 1bf15ca5-f533-49a9-b25b-776c24fd1489… что? Что его зовут Васей (что уже не правда, потому что он сменил пол и его зовут Василиса)? Или что он подписывает вот этим вот ключом? Последнее звучит разумно, но фактически оно сводится к тому, что толпа голосовальщиков должна выработать мнение о связанном с ID значении описательного атрибута «ключ ЭП». То есть получаем глобальную распределённую базу данных, в которой значения правятся по принципу «кто кого перекричит».

Кстати, я был бы не против заценить сначала глобальный IT-рэп-батл за ID Канье Уэста, потом эпичную битву Найка с Рибоком за их идентичности, а потом, почему бы и нет, флэшмоб с отъёмом полномочий Президента США в пользу кого-нибудь из стэндап-комиков.

Право слово, в моей технологии всё слишком скучно. Допустимость значения атрибута «ключ ЭП» легко вычисляется по самому ID. С таким не забалуешь.
Мне кажется, в таком сценарии как раз получается tradeoff вместо способа «реанимировать учетку по стороннему каналу» бесконечное число раз мы создаем способ реанимировать учетку в той же среде, но ограниченное число раз. Является ли такой размен допустимым — отдельная тема, я не хочу в нее вдаваться. Я хочу подчеркнуть, что мы не просто усилили слабое звено. Мы в одном месте выиграли, а в другом потеряли
В децентрализованной среде не понятно, с кем конкретно устанавливать этот самый «сторонний канал». Это же придётся проводить сложные реанимационные мероприятия при каждом новом пиринговом соединении, разве нет?

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

Реанимация учётки с использованием стороннего канала приемлемо хорошо работает в централизованной архитектуре, но в глобальном пиринге она мне не кажется безнадёжной идеей. Или Вы можете предложить какое-нибудь интересное решение?
Вы правы, я рассматривал текущую ситуацию, где есть центры авторизации. Это может быть Google OpenId, офис пиццерии, соцсеть или учетка ГосУслуг. В децентрализованных архитектурах я не силен :-)

Предлагаю вам почитать про дизайн церемонии генерации параметров сети Zcash.
Интересное чтиво.

Generating SNARK public parameters is basically equivalent to generating a public/private keypair, keeping the public key, and destroying the private key.
Генерация публичных параметров SNARK — то же самое, что генерация пары ключей с сохранением публичного ключа и уничтожением приватного.
Первая церемония прошла в 2016 году с привлечением шести человек, каждый из которых генерировал свою часть ключа на разном железе в разных частях света без доступа к сети и тд. Для восстановления приватного ключа потребовалась бы компрометация (или сговор) всех шестерых.
К слову, вторая церемония (в преддверии хардфорка) прошла в апреле 2018, в ней участвовали уже 88 человек.

Удивительно, что в русскоязычном интернете до сих пор нет перевода. Хотел даже перевести сам, но все руки не доходят.

Спасибо. Интересно. Надо будет почитать.
Про ZCash слышал, но без подробностей. Есть на примете какое-нибудь толковое описание?

Сам Zcash — это тот же Bitcoin, но с возможностью проводить анонимные транзакции, благодаря алгоритму zk-SNARKs.
Русскоязычных источников не знаю, могу посоветовать пару англоязычных.


Здесь хорошее описание алгоритма zk-SNARKs от разработчиков Zcash.
Здесь попытка объяснить то же самое от Виталика Бутерина (советую просмотреть его блог, это интересно).
Здесь продолжение идеи с расширением до STARKs, где T — значит Transparent. Если уж на то пошло, еще один блок Бутерина.

Sign up to leave a comment.

Articles