(для понимания того, о чём говорится в этой статье, необходимо и достаточно хотя бы в общих чертах представлять, что такое асимметричная криптография и как работает электронная подпись)
Сценарий использования одноразового секретного ключа:
- Создаётся ключевая пара, состоящая из секретного (secret key, SK) и открытого (public key, PK) ключей.
- При помощи секретного ключа выполняется ряд операций. Первая из них, создание открытого ключа, уже выполнена на первом шаге.
- Выполняется на первый взгляд противологичное действие – секретный ключ уничтожается без возможности восстановления.
Использование оставшегося открытого ключа для шифрования данных смысла не имеет (расшифровывание при отсутствии секретного ключа считается невозможным), но открытый ключ может быть использован для проверки электронных подписей, созданных на втором шаге.
Данный подход может быть использован для криптографически достоверного связывания данных. При этом открытый ключ первоначальной ключевой пары становится идентификатором связи.
Существенное преимущество заключается в том, что использованная ключевая пара не может быть скомпрометирована иначе, как брутфорсом, либо через эксплуатацию математической уязвимости использованного алгоритма. Если секретного ключа больше вообще не существует, его невозможно ни украсть, ни выведать обманом, ни выпытать.
Пример использования
Задача: в распределённой системе участники регистрируются под создаваемыми ими самими уникальными идентификаторами. Требуется максимально затруднить задачу «угона» чужого идентификатора (identity theft). В случае состоявшегося угона идентификатора обеспечить истинному владельцу возможность возврата похищенного.
Способы решения задачи без использования рассматриваемой технологии:
- «Нулевой вариант». Понадеяться на честность участников процесса.
- «Административный запрет». При регистрации участников требовать паспорт. Законодательно запретить использование чужих идентификаторов. Привязать идентификатор к номеру телефона, использовать многофакторную авторизацию. При возникновении подозрений опять же требовать паспорт. Понадеяться на честность и неподкупность уполномоченных проверяющих. При выявлении случаев неправомерного использования штрафовать и/или сажать провинившихся в тюрьму.
- «Открытый ключ как идентификатор». Соответственно, секретный ключ используется в качестве средства авторизации. В принципе, достойный вариант (в частности, используется в криптоваютах) за тем исключением, что при потере либо компрометации секретного ключа участник необратимо выбывает из игры.
Решение задачи с использованием одноразовых секретных ключей:
- Участник создаёт идентифицирующую ключевую пару [SK0, PK0]. Открытый ключ PK0 (либо его хеш) становится уникальным идентификатором участника.
- Участник создаёт дополнительный набор ключевых пар [SK1, PK1], [SK2, PK2] … [SKn, PKn], и открытый ключ каждой из них подписывается ключом SK0.
- Ключ SK0 уничтожается. Шаги с первого по третий выполняются в рамках единого процесса без записи SK0 в энергонезависимую память.
- Для аутентификации участник использует одну из созданных на втором шаге ключевых пар (например, [SK1, PK1]), а остальные, если они были созданы, прячет в надёжном месте.
- Если используемая ключевая пара оказывается скомпрометированной, её ключ (в примере это PK1) помещается в список отзывов, а для аутентификации используется один из запасных ключей. Либо создаётся ещё один дополнительный ключ, имеющий цепочку сертификации, начинающуюся с PK0 (например, PK0 – PK2 – PKn+1).
Если говорить конкретно о криптовалютах, описанное здесь решение задачи особого смысла не имеет (при помощи похищенного ключа злоумышленник немедленно опустошает кошелёк), но тема «аутентификация» далеко не исчерпывается применением в криптовалютах.
Для удобства дальнейшего обсуждения можно предложить следующие обозначения для используемых ключей:
i-key – идентифицирующий ключ (identity key). В рассматриваемом примере это PK0.
a-key – аутентифицирующий ключ (authentication key). В рассматриваемом примере это PK1 либо любой другой ключ, прямо либо косвенно подписанный i-key.
hc-key – один из дополнительных надёжно спрятанных ключей (злоумышленнику неизвестен ни факт их существования, ни их количество), используемых для восстановления доступа в случае компрометации a-key.
Маленькое замечание к использованию одноразовых секретных ключей. Схема работоспособна только в том случае, если у субъекта, создавшего первоначальную ключевую пару, отсутствует мотивация сохранить себе секретный ключ для какой-то своей отдельной надобности. При использовании данной технологии для аутентификации все потребности полностью покрываются набором дополнительных hc-ключей (кстати, загадка для присутствующих: на что намекает аббревиатура «hc»?). Сохранение первоначального ключа никакой выгоды не приносит, зато создаёт уязвимость, делающую возможным необратимый угон идентификатора.
P.S. Если описанная здесь технология вдруг является оригинальной, то есть желание превратить эту публикацию в статью в каком-нибудь уважаемом англоязычном издании. Тем, кто может с этим помочь, предлагаю сотрудничество либо за вознаграждение, либо за соавторство.
Комментарии (79)
ultrinfaern
13.08.2018 19:00-2Мир криптографии на открытом/закрытом ключе не заканчивается. Есть куча разных алгоритмов. Как насчёт почитать книжку Applied Cryptography — очень интересное чтиво.
maslyaev Автор
13.08.2018 19:12+1Какую конкретно главу читать? С чем конкретно я пересёкся?
ultrinfaern
13.08.2018 20:16-2У вас нет совпадений, так как у вас не проблемы, которую нужно решить.
Насколько я понимаю, вас увлекло свойство открытого\закрытого ключа. Ну так в книжке куча таких-же увлекательных алгоритмов — вам будет интересно.maslyaev Автор
13.08.2018 21:08Как это нет проблемы? Прямым же текстом написано (Ctrl+F по слову «задача»).
Размышлял над тем, как в децентрализованной сети агентов можно организовать идентификацию участников при условии, что (а) identity theft если он не с концами, то это мелкая неприятность, но если с концами, то это катастрофа и (б) схема должна быть работоспособной на чудовищно длительных по нашим меркам интервалах времени (многие десятки, а возможно и сотни лет).
Потребовать от агентов напрячься и поохранять свои сверхсекретные ключи пару-тройку лет можно, но рассчитывать на то, что все будут умничками десятки лет — без шансов. Особенно, если захват чужих identity может быть чрезвычайно привлекательной идеей. В таких условиях может сработать только принцип «если у вас нету дома, пожары ему не страшны».
А потом, поковырявшись в памяти, обнаружил, что не помню, чтобы в каком-то из криптопротоколов предполагалось уничтожать секретный ключ через несколько секунд после создания ключевой пары, и этим обеспечить невзламываемость чего-нибудь. Подозреваю, если немножко пофантазировать, можно ещё, наверно, придумать кучу интересных применений этому финту ушами.
в книжке куча таких-же увлекательных алгоритмов
Безусловно. Сам её люблю. Не понимаю только, на что конкретно Вы намекаете.ultrinfaern
13.08.2018 22:04-2Извиняюсь, может я не внимательно читал. Мне показалось, что сначала был алгоритм, а потом придумка, где его можно использовать.
Тогда замечание — удаляя приватный ключ вы больше не сможете подтвердить свою идентичность, и кто угодно сворует ваш ид с открытым ключом и скажет что это его. Так даже воровать ничего не нужно — ну есть двоичные данные, ну и что, что у них структура какая то подпись и какой-то ключ, без закрытого ключа никто не сможет единолично подтвердить акт генерации именно им этих двоичных данных.maslyaev Автор
13.08.2018 23:13удаляя приватный ключ вы больше не сможете подтвердить свою идентичность
Таки могу. Допустим, ID — это открытая часть i-ключа. Вот прям как он есть. Я присылаю системе команду «два пива и пицца, пожалуйста». Как водится, команда подписана моим a-ключом. Но вместе с командой и подписью уходит также открытая часть моего а-ключа и подпись, выполненная i-ключом (созданная на шаге 2, пока секретная часть i-ключа была ещё не уничтожена), заверяющая подлинность а-ключа. Сервер пиццерии имеет мой ID, и вот прямо им удостоверяется в подлинности а-ключа, а уже зная, что а-ключ подлинный, убеждается в подлинности команды про два пива. В общем, всё как обычно делается с цепочками сертификации, но только мы с пиццерией обошлись без услуг третьей доверенной стороны в качестве корневого центра сертификации.
Чтобы злоумышленник смог воспользоваться моим IDшником, ему придётся решить маленькую, но весьма противную задачу — по открытой части i-ключа (он же, как мы помним, и есть IDшник) сгенерить его закрытую часть.ultrinfaern
13.08.2018 23:46Вы же знаете про MitM атаку? ;) Третья сторона, которой доверяете вы и пиццерия как раз и нужна для нивелирования таких атак.
Как можно дальше общаться с пицерией, если вы не сможете больше подписать ни одной команды со старым ключём/ид.
И кто тут «я», который присылает команду на два пива? Может это спам? Подтвердите, что вы это вы а не злой хакер Вася Пупкин! :)
После уничтожения закрытого ключа вы не сможете подтвердить в будущем что вы это вы и ваша подпись и открытый ключ превращаются просто в двоичный шум.
Теоретически сейчас вы шлёте команду и двоичный шум.maslyaev Автор
14.08.2018 00:09MITM-атака всегда играет в-короткую. Для неё нужно полностью контролировать коммуникацию между Алисой и Бобом. Сделать это на коротком интервале можно, но IDшник — это штука, эксплуатируемая годами. С разных компов. Через разные сети. Не, не реально. Вообще, MITM при активной защите от него (когда Алиса и Боб конкретно озаботились этой проблемой) весьма бесперспективен. Впрочем, это уже другая тема.
Как можно дальше общаться с пицерией, если вы не сможете больше подписать ни одной команды со старым ключём/ид
Я подписываю ключом, подписанным старым ключом. Что в этом вообще необычного? Никакого спама. Всё чётко.ultrinfaern
14.08.2018 00:24То есть на любую команду нужно выпускать новый ключ, а системе хранить все ваши старые ключи — вы решили убить систему спамом? :)
Вы не можете подписать старым ключём -вы убили приватный ключ — вы помните? ;)maslyaev Автор
14.08.2018 15:27Господи, откуда Вы это взяли? В нормальном режиме (если не было пожаров, взломов и прочих ЧП) я как с самого начала пользовался своим самым первым а-ключом, так и пользуюсь им всю жизнь. А к дополнительным даже не притрагиваюсь. Зачем что-то перевыпускать, пока всё хорошо?
ads83
14.08.2018 00:27Мне кажется, вы упускаете возможность, что Sk3 из "холодного хранилища" будет скомпрометирован. Это приведет к серии "я настоящий, он — подделка". Со временем Алиса сможет вернуть свою identity с помощью (Sk2;Pk2), но пиццу-то хакер себе закажет и даже съест.
maslyaev Автор
14.08.2018 15:29Но не лишит меня статуса почётного клиента, добытого многолетней историей покупок.
saipr
13.08.2018 21:57Схема работоспособна только в том случае, если у субъекта, создавшего первоначальную ключевую пару, отсутствует мотивация сохранить себе секретный ключ для какой-то своей отдельной надобности.
Да и не только мотивация! За промежуток времени, в который ключ использовался, от момента создания и до его уничтожения, он может куда угодно убежать. Ну и самое главное где создается ключевая пара. Если на компьютере, то смотри предыдущее предложение. Если на токене PKCS#11 с неизвлекаемым ключом, то зачем его уничтожать. Как говорил классик, — "он же памятник". Ну и т.д.
maslyaev Автор
13.08.2018 23:28от момента создания и до его уничтожения, он может куда угодно убежать
Нам нужно уметь обеспечивать всего несколько секунд безопасного исполнения кода. ИМХО, задача вполне реальная. Это намного проще, чем защищать активно используемый ключ от утечки на протяжении многих лет, разве нет?
Если на токене PKCS#11 с неизвлекаемым ключом, то зачем его уничтожать.
Токены с неизвлекаемыми ключами (особенно, когда действительно не извлекаемыми, а не как это часто бывает) — хорошие штуки, но с ними есть одна незадача. То, что ключ не извлекается, вовсе не говорит о том, что укравший этот злоумышленник не сможет его использовать. Если у него есть пин, то он будет им подписывать любую дрянь, пока ему не надоест или пока ключ не попадёт в списки отзывов. Что касается настоящего хозяина токена, то он в момент кражи лишается своей identity. Токен с неизвлекаемым ключом — прекрасный вариант, но только если нет чего поинтереснее.saipr
13.08.2018 23:39Нам нужно уметь обеспечивать всего несколько секунд безопасного исполнения кода
Это как в новогодней песенке про пять минут. Кто сказал, что на компьютере есть эти несколько секунд "безпасного исполнения кода". Сегодня их нету, все под контролем.
Ключ должен попадать в списки отзывов как только человек обнаружил или даже заподозрил пропажу.
Токен с неизвлекаемым ключом — прекрасный вариант, но только если нет чего поинтереснее.
А что, есть что-то интереснее?
maslyaev Автор
13.08.2018 23:54Сегодня их нету, все под контролем.
Не драматизируйте. Свежепоставленный Линукс, ни разу в жизни не подключённый к Сети — вполне себе безопасная среда исполнения.powerman
14.08.2018 01:25Ага. Уже забыли про баг в Debian OpenSSL, из-за которого приватные ключи созданные на этой системе на протяжении полутора лет можно легко взломать? Чистый линух, не подключенный к сети, да. И это мы ещё не начинали смотреть в сторону закладок в железе.
saipr
14.08.2018 10:02Не драматизируйте.
Свежеиспеченный Линукс (жалко, что вы не сказали от кого этот Линукс) не подключенный к сети спокойно схранит в своих закромах ваш закрытый ключ и как только появится сеть передаст его своим "хозяевам". Да и что делать на машине не имеющей выхода в свет? Любоваться?
maslyaev Автор
14.08.2018 12:03Если ключевую пару генерировать софтом без открытых исходников, скачанным «откуда-то из Интернета», то тут, конечно, сложно говорить о какой бы то ни было безопасности. Элементарные правила гигиены как-бы никто не отменял ;)
Любая технология обеззараживания будет «дырявой» если клиент имеет привычку иногда пить из лужи.saipr
14.08.2018 12:16А лужа это что Windows или Linux и его форки или Android или iOS или еще что-то? Вы откуда пьете?
ads83
14.08.2018 00:06Если я правильно понял вашу идею, законный владелец i-ключа Алиса в случае угона Sk1 рассылает своему контакт-листу сообщения "меня взломали, сообщениям, подписанным Pk1, не верить. Вот мой новый Pk2." Боб может проверить, что Pk2 принадлежит Алисе: он подписан Pk0. Я правильно понял идею?
Я не специалист по криптографии, поэтому не могу оценить новизну идеи. Чем-то напоминает одноразовый шифр-блокнот, разумеется с важными отличиями.
Мне кажется, у этой схемы есть несколькотрудностейнюансов.
- Были исследования, когда за счет манипулирования текстом сообщения, удавалось получить правильную подпись под ним без знания секретного ключа. Через X лет для выбранного алгоритма могут придумать атаку, позволяющую написать от имени Алисы "меня взломали!" N-1 раз. Это плохо, т.к. у Алисы нет способов обновить набор ключей.
- Конечность набора Pk1, Pk2, ..., PkN. Вы рассуждаете о надежности на протяжении десятилетий, и значит рано или поздно созданные на втором этапе ключи закончатся даже если универсального алгоритма создано не будет. By-design нет способа насоздавать новые. Как
в игреу кошки: количество жизней ограничено, пополнения нет. Если бы Алиса сохранила Sk0, количество "воскрешений" можно было бы увеличить как в игре. Сейчас, если identity угнали, создается новая и жизнь начинается сначала. Угон аккаунта подтверждается по другим каналам. То есть взамен "бесконечных жизней" получаем (кажущуюся?) повышенную безопасность одной длинной, но конечной. Вопрос, что лучше — философский :-) - Держать в действительно разных хранилищах возможно очень малое число ключей. Если на бабушкином огороде закопана одна флешка, найти ее трудно. Если сотня, шанс выкопать пару ключей стремится к 1. Запомнить больше 20-30 заначек и разных механизмов доступа, а затем вспомнить через десять лет тоже нереально. Считаем:
- рабочий, которым ежедневно пользуемся. Механизм доступа — учетка к компу.
- Флешка в огороде. Доступ по координатам.
- Банковская ячейка. Доступ по паспорту.
- Архив в облаке. Доступ — уникальная (за 10 лет!) парольная фраза.
- Что-то свое оригинальное.
Я бы поставил, что надежных независимых мест у Алисы будет меньше десятка. Может, это лучше чем один Sk0, но не так чтобы очень много
- Недоверие после смены ключей. Это Алиса отозвала Pk2 и прислала Pk3? Может хакер узнал не текущий ключ, а выкопал флешку?
С кем я подписываю контракт?Это Алиса зовет меня ночью на кладбище? С точки зрения Алисы, безопасность выросла — она сможет вернуть аккаунт. С точки зрения Боба, шансы что он "здесь и сейчас" разговаривает с хакером возросли.
В голову пришла еще одна аналогия: Волан-дер-Морт. Он создал девять Sk, "подписал" каждый и
развоплотилсяуничтожил Sk0, но это не спасло его.Не связывался бы с ПоттеромПри другой схеме безопасности, результат мог бы быть иным.maslyaev Автор
14.08.2018 13:441. Это у меня в статье обозначено как «через эксплуатацию математической уязвимости использованного алгоритма». То есть да, если есть секретная теорема про эллиптические кривые или способ быстрой факторизации, вся гражданская криптография псу под хвост. Это тот риск, про который знаем и на который приходится идти. Плюс, конечно, страшилка про квантовые компьютеры…
2. Набор теоретически конечен, но практически бесконечен. То есть (сами проверьте это на калькуляторе) если каждую наносекунду генерить триллион номерков, пространства 2128 хватит примерно на 10 млрд. лет. Ну ладно, с учётом парадокса дней рождений на миллиард. Если использовать пространство 256 бит (это несчастные 32 байта), то у нас количество атомов во Вселенной для записи номерков кончится раньше, чем вероятность возникновения хотя бы единичной коллизии превысит одну тысячную.
3. Важно не то, что клиент действительно рассовал ключи по хитрым нычкам, а то, что он имеет возможность это сделать и сам может выстраивать свою стратегию согласно своей благоразумности и степени своей параноидальности. Решил вообще не заморачиваться с доп. ключами — что же, сам себе злобный буратино. Создал один — тоже не плохой вариант. Создал 20 штук — ну, наверно, знал, как собирается этим управлять. Если опция по умолчанию — всё завязать на один хранящийся в сейфе мастер-ключ, злоумышленник имеет конкретную цель, и по ней работает. Если же опция по умолчанию — без ахиллесовой пяты, с одним основным ключом и одним запасным, то цель размывается и даже успешная атака вдруг отыгрывается атакованным взад и становится в итоге неуспешной.
4. Ключи в любом случае воруют. Любые. В долгосрочной перспективе, так точно. Особенно те, которые по архитектуре системы используются каждый день. Что касается возрастания вероятности того, что хакер украл запасной ключ и зовёт Боба на кладбище, то можно в систему заложить правило: запасной ключ без доп. геморроя признаётся Алисой только если отозван текущий рабочий.ads83
14.08.2018 21:422. Нет, практически набор ключей, подписанных Sk0, конечен. Практически нереально сохранить хотя бы миллион (Sk;Pk) так, чтобы вероятность угона хотя бы одного была так же низка, как вероятность угона Sk0 из сейфа. Пример с огородом, засеянным флешками, показывает что увеличение количества приводит к снижению надежности хранения.
3. Обычно атаку для угона identity совершают с определенной целью: попросить денег у знакомых, набросить на вентилятор в холиваре, слить карму, своровать данные. Атака успешная, если хакер получил перевод от друга или утащил фотки знаменитости. Алиса сможет вернуть свою учетку, но пицца уже съедена хакером, атака своей цели достигла. Задача: усложнить угон учетки. Считаю важным подчеркнуть, что не усложнить угон учетки навсегда, а усложнить угон даже на 5 минут. Ведь есть альтернативные каналы чтобы вернуть/заблокировать учетку: СМС на телефон, прийти с паспортом в банк и т.д. Я не вижу, как решает эту задачу ваше решение.
4.запасной ключ без доп. геморроя признаётся Алисой только если отозван текущий рабочий
Постойте, но ведь процесс отзыва ключа — это сообщение вида «вот мой новый публичный ключ, подписанный секретом-которого-никто-не-знает, а старый протух». Если отозвать текущий рабочий можно только с паспортом (тот самый геморрой), то зачем вся эта схема?
Я задаю вопросы и подвергаю сомнениям схему, чтобы понять чем она полезна и помочь вам лучше сформулировать плюсы. Пожалуйста, воспринимайте их как конструктивную критику, а не как нападки на вашу личность или неприятие идеи.maslyaev Автор
15.08.2018 12:482. Упс… Похоже, я неправильно понял вопрос. Да, набор 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, который подписал отзываемый ключ, но и секретной частью самого ключа. То есть имея закрытый ключ (и больше ничего), можно, грубо говоря, подписать сообщение «Я труп, забудьте меня», и эта подпись будет отзывным сертификатом. То есть никакого паспорта не надо. Надо только маленький файлик, наличие которого убивает использование ключа.
воспринимайте их как конструктивную критику
Не первый день в интернетах ;)
Критика, особенно конструктивная — на вес золота.ads83
15.08.2018 19:352. Я не улавливаю картины. Алиса пользуется в ежедневном режиме парой 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. Не знал, спасибоmaslyaev Автор
15.08.2018 20:472. Немножко не так. И 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шнику Алисы. Никакие сторонние каналы не нужны. Где мухлёж?ads83
15.08.2018 21:552. Простите, но если мы переименуем в этой схеме Sk2 в мастер-ключ, то чем эта схема принципиально будет отличаться от схемы держим секретный ключ в безопасном «холодном» хранилище? Если враг выкопает hc-key, он сможет создать PK3 и объявить себя Алисой. Или скомпрометировать Sk1, дождаться когда Алиса сообщит Перепрятушки! Теперь я использую Pk3, вот путь сертификации! и через полчаса хакер кричит Обознатушки! Pk3 сделала не я, верьте Pk4, вот пруфы!. Возможно, он даже утащил hc-key2 и не знает о существовании hc-1 и hc-3 — но об этом не знает и Боб! Боб видит двойников, у обоих валидный путь сертификации до Pk0 и оба отзывают друг друга как антипапы отлучали друг дружку от церкви. В распределенных системах хранения такое называется split-brain и любая современная система должна уметь с этим справляться / не давать возникнуть.
3. Мухлеж — это сильное слово, просто я не смог подобрать лучше. На мой взгляд, сравнивать вашу схему нужно с существующей централизованной схемой и убеждать, чем одна лучше другой. Для меня аргумента «децентрализация — это круто» недостаточно, потому что текущая схема работает и развивается.maslyaev Автор
15.08.2018 23:452. Если злой хакер упёр 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. Дело вовсе не в том, что децентрализация — это круто, модно и молодёжно. Бывает так, что для того, чтобы информационная система оказалась адекватной решаемой задаче, она просто обязана быть децентрализованной. Альтернативой, например, является жутко громоздкое, неповоротливое, намертво забюрократизированное вертикальное решение. С громадными накладными расходами. С уязвимым центром. С перекосами и злоупотреблениями, связанными с тем, что в вертикальной структуре есть элементы, изначально поставленные в привилегированное положение. Когда предметная область по природе своей горизонтальна, есть смысл попытаться воздержаться от забабахивания для неё вертикального решения.
demfloro
14.08.2018 08:32Подобный подход используется в подписи модулей ядра Linux с целью получить модульное ядро, которое не загрузит в себя левые модули. Это автоматизировано если включены опции:
CONFIG_MODULE_SIG=y CONFIG_MODULE_SIG_FORCE=y CONFIG_MODULE_SIG_ALL=y
Но удалять приватный ключ после сборки нужно явно. Конечно если надо загружать какой-то out-of-tree модуль то придется сохранить приватный ключ до момента подписи этого модуля.
maslyaev Автор
14.08.2018 13:48Конечно если надо загружать какой-то out-of-tree модуль то придется сохранить приватный ключ до момента подписи этого модуля.
А загружать доп. модуль будет надо с весьма высокой вероятностью. Поэтому разумная опция — сохранить приватный ключ.
Кстати, подписание модулей — тоже, возможно, интересный кейс для использования одноразовых секретных ключей. Имеет смысл над этим подумать.demfloro
14.08.2018 13:58А загружать доп. модуль будет надо с весьма высокой вероятностью. Поэтому разумная опция — сохранить приватный ключ.
Зависит от конкретных обстоятельств. Я не в курсе про железо в серьёзных вендорных серверах, но из обычного применения разве что nvidia и zfs.
imbasoft
14.08.2018 09:57Давайте поразмыслим над предлагаемой идеей с точки зрения безопасности:
1. Предлагаемый вами криптопротокол базируется на организационных мерах. Создание идентификационного и аутентификационных ключей математически не связаны друг с другом, а это открывает дорогу человеческой глупости — невыполнению требований безопасности.
2.Ключ SK0 уничтожается. Шаги с первого по третий выполняются в рамках единого процесса без записи SK0 в энергонезависимую память.
Очень сложно для реализации. Когда система работает в виртуальной инфраструктуре реализацию данного требования гарантировать невозможно. Во всех современных сертифицированных ФСБ России СКЗИ есть требования, чтобы после перезагрузки отчищался файл подкачки. Но это практически нигде не выполняется поскольку сильно замедляет процедуру перезагрузки. Были случаи когда активация данной фичи увеличивала время перезагрузки до 15 минут.
3.Если используемая ключевая пара оказывается скомпрометированной, её ключ (в примере это PK1) помещается в список отзывов
Проблема в том, что списки отзыва сейчас мало кто проверяет. Это в первую очередь относится к браузерам — habr.com/post/332730
4. В чем преимущество вашего подхода?
а) Если использовать стандартный подход с одной ключевой парой, безопасность базируется на обеспечения конфиденциальности 1-го секретного ключа. Скомпрометировали ключ — запускается относительно сложная процедура переидентификации участников, которая базируется на использования альтернативных бесключевых методов аутентификации (например, паспорт).
б) Если рассматривать ваш подход, то безопасность базируется на обеспечении конфиденциальности n-секретных ключей (ключей аутентификации). Сразу возникает вопрос, что сделать проще: засекретить 1 ключ или n-ключей. Ответ очевиден. Едем дальше.
Злоумышленник скомпрометировал 1 из ключей аутентификации и сказал что все остальные ваши легальные ключи скомпрометированы, что тогда? Опять приходим к задаче аутентификации бесключевым способом (паспорт).
в) Вы не определили сколько ключей аутентификации нужно генерить. Если абонент сгенерирует только 1 ключ, ваш подход схлопывается к стандартному.
г) Что будет если злоумышленник скомпрометировал сразу все n-ключей аутентификации? Опять возвращаемся к бесключевой аутентификации.
Рекомендации для улучшения подхода:
1. Посмотрите в сторону математической связи между генерацией ключей идентификации и аутентификации. Она должна быть такой, чтобы ее нельзя было обмануть / не делать и т.д.
2. Опишите всю вашу распределенную систему. Как минимум в ней я услышал про список отзыва ключей (CRL), а раз он есть, то должен быть центр сертификации, иначе как обеспечивается валидность CRL? Описав всю распределенную систему ее можно сравнить со аналогичными схемами классических криптографических задач: ЭДО, криптовалюты и т. д.
Возможно вы найдете определенные ниши, где ваш поход будет работать лучше стандартных.sena
14.08.2018 12:51Во всех современных сертифицированных ФСБ России СКЗИ есть требования, чтобы после перезагрузки отчищался файл подкачки. Но это практически нигде не выполняется поскольку сильно замедляет процедуру перезагрузки.
Как всё запущено! А ведь достаточно зашифровать файл подкачки и всё.KodyWiremane
14.08.2018 22:22… уникальным ключом, который генерируется при загрузке системы, никогда не свопится и стирается при перезагрузке. Вот он, применённый принцип из поста!
maslyaev Автор
14.08.2018 15:211.… Создание идентификационного и аутентификационных ключей математически не связаны друг с другом
Мне кажется, это не недостаток, а преимущество. Это очень хорошо, что а-ключ не даёт ни бита определённости относительно секретной части 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 должен был бы явиться с паспортом и доверенностью.sena
14.08.2018 17:37Если система глобальна и децентрализована, не существует того окошечка, в которое можно было бы принести паспорт.
Не нужно окошечко, нужно подписать свой ключ максимально возможным количеством людей, ключи которых уже в сети доверия (web of trust). Вот они и будут проверять паспорт перед подписью.maslyaev Автор
14.08.2018 18:45Сеть доверия оказалась нежизнеспособной идеей. По факту. Оно не взлетело. Могу рассказать почему.
На мой взгляд, концептуальная ошибка глубоко закопана во-первых в недоопределённость понятия «доверие», и во-вторых в то, что доверие, даже если его предельно чётко конкретизировать — одна из тех штук, которые не могут быть выражены скалярной величиной.
Что значит «я доверяю»? Допустим, вот автомеханик Вася. Я ему доверяю починить подвеску, но в страшном сне не доверю ребёнка. Вот тётя Таня. Ребёнка я ей доверю, но подвеску — ни за что. Есть люди, в порядочности которых я уверен, но не уверен в их осмотрительности. Есть наоборот. Есть те, кому я доверю переговоры с заказчиком, но не доверю мытьё полов.
Когда-то давно, когда сеть доверия была в новость и на неё ещё возлагали надежды, почитал, подумал, пожал в недоумении плечами и прошёл мимо.
нужно подписать свой ключ максимально возможным количеством людей
И тут вдруг окажется, что люди, обладающие максимальным количеством доверяющих им последователей — это рвущиеся к власти политики, религиозные проповедники и телезвёзды. Не знаю кому как, но мне чё-то расхотелось выяснять правду голосованием.sena
15.08.2018 03:17Сеть доверия оказалась нежизнеспособной идеей. По факту. Оно не взлетело.
Работает в Дебиане отлично. Лучшего пока не видел.maslyaev Автор
15.08.2018 11:16Что значит «работает в Дебиане»? Оно и в винде работает, только не пользуется толком никто. Или Вы имеете в виду что-то другое?
sena
15.08.2018 12:47Другое. Дебиан это некоммерческая организация без иерархической структуры. В ней состоит более тысячи человек, разбросанных по всему миру. Им нужно не только общаться, но и проводить удалённо голосования по важным вопросам, проверять аутентичность пакетов. Всё это много лет делается и верифицируется на основе вышеупомянутых PGP и web of trust. Вы слыхали про что-то подобное на основе других технологий? Я — нет.
maslyaev Автор
15.08.2018 13:00Ну, если у них получилось использовать этот подход для решения конкретно той своей задачи, могу за них только порадоваться. Но из этого единичного кейса вовсе не следует, что если попытаться повторить этот фокус для чего-нибудь совсем другого, результат обязательно будет положительным.
Из сказанного вовсе не следует, что я фанат CA-based PKI. Вовсе нет. Гадость редкостная, но приходится ею пользоваться, пока не придумано третьего подхода, принципиально отличающегося и от CA, и от WoT.sena
15.08.2018 14:15Но из этого единичного кейса вовсе не следует, что если попытаться повторить этот фокус для чего-нибудь совсем другого, результат обязательно будет положительным.
Для чего-то совсем другого, конечно же, наверное не выйдет. Но что это «другое»? Вот Ваше описание
Задача: в распределённой системе участники регистрируются под создаваемыми ими самими уникальными идентификаторами. Требуется максимально затруднить задачу «угона» чужого идентификатора (identity theft). В случае состоявшегося угона идентификатора обеспечить истинному владельцу возможность возврата похищенного.
Для этого вполне.maslyaev Автор
15.08.2018 18:43Здесь мы уже как-то плавно перешли на воспоминания о светлой памяти сети доверия и размышлениях о том, почему она «не взлетела».
Впрочем, применительно к рассматриваемой задаче можно тоже посмотреть, подходит решение с сетью доверия, или нет.
Сначала давайте разберёмся с тем, что такое эти самые идентификаторы, и для чего чего они нужны. Вообще, тема в полной мере раскрылась, когда были изобретены реляционные базы данных. То есть когда начали оперировать понятиями «сущность» и «связь» (entity & relationship). Если говорить привычным языком, данные начали записывать в таблички, и для некоторых из этих табличек оказалась востребованной возможность ссылаться на строку. Что использовать для ссылки? Номер строки не годится, потому что при удалении строки из середины съезжают ссылки на все хвостовые элементы. По описательным атрибутам — тоже криво. Во-первых, если записанные в базу атрибуты двух сущностей совпадают, то это не значит, что это один и тот же объект (Татьян Смирновых в РФ сильно больше, чем одна), а во-вторых сущности имеют свойство менять свои характеристики, оставаясь при этом самими собой (Таня Смирнова выходит замуж и становится Таней Петровой). Единственное по-настоящему правильное решение — добавить в таблицу искусственное поле, в которое писать ничего не значащую хрень, подчиняющуюся единственному требованию: каждая хренька должна быть уникальной в пределах таблицы. Притом если делать всё правильно и по науке, то требование того, чтобы хрень была именно что ничего не значащей, оказывается существенным. В правильных базах данных в идентификатор заталкивают длинные случайные числа. То есть учётка, идентифицируемая именем пользователя либо мэйлом — это по теории баз данных полный отстой. Даже те товарищи, которые придумывали ИНН для идентификации юриков и физиков, тоже косякнули в этом пункте, чем вызвали массу неудобств.
Через инфотехнологии тема идентификаторов проходит примерно везде. Если нет единого центра, раздающего номерочки, народ выкручивается разными способами. Например, мак-адреса раздаются производителями сетевого оборудования, каждому из которых выделяется диапазон. Штрихкоды товаров… ну, там вообще кромешный ад и хаос. Все эти ISBN, IMEI и прочее — это всё про раздачу номерков. Кто-то ценой титанических усилий весьма неплохо справляется, а где-то (как, например, со штрихкодами) трэш и угар. Но все эти случаи объединяет отсутствие мотивации воровать чужие номерки, что и даёт шанс справиться.
(извиняюсь за долгое вступление, уж очень к месту оказалось прогнать сказку про то, что это за собственно материя такая — IDшники, вокруг которых вся суета)
Теперь про сеть доверия. За/против какие утверждения будут голосовать участники? За то, что юзер 1bf15ca5-f533-49a9-b25b-776c24fd1489… что? Что его зовут Васей (что уже не правда, потому что он сменил пол и его зовут Василиса)? Или что он подписывает вот этим вот ключом? Последнее звучит разумно, но фактически оно сводится к тому, что толпа голосовальщиков должна выработать мнение о связанном с ID значении описательного атрибута «ключ ЭП». То есть получаем глобальную распределённую базу данных, в которой значения правятся по принципу «кто кого перекричит».
Кстати, я был бы не против заценить сначала глобальный IT-рэп-батл за ID Канье Уэста, потом эпичную битву Найка с Рибоком за их идентичности, а потом, почему бы и нет, флэшмоб с отъёмом полномочий Президента США в пользу кого-нибудь из стэндап-комиков.
Право слово, в моей технологии всё слишком скучно. Допустимость значения атрибута «ключ ЭП» легко вычисляется по самому ID. С таким не забалуешь.
ads83
14.08.2018 21:54Мне кажется, в таком сценарии как раз получается tradeoff вместо способа «реанимировать учетку по стороннему каналу» бесконечное число раз мы создаем способ реанимировать учетку в той же среде, но ограниченное число раз. Является ли такой размен допустимым — отдельная тема, я не хочу в нее вдаваться. Я хочу подчеркнуть, что мы не просто усилили слабое звено. Мы в одном месте выиграли, а в другом потеряли
maslyaev Автор
15.08.2018 11:50В децентрализованной среде не понятно, с кем конкретно устанавливать этот самый «сторонний канал». Это же придётся проводить сложные реанимационные мероприятия при каждом новом пиринговом соединении, разве нет?
Может показаться, что в такой среде некое authority всё равно пригодится, потому что нужно как-то вести глобальный список отзывов. Но нет, поскольку там задача несколько другая. В распространении отзывных сертификатов отсутствует момент принятия решения (отзывной сертификат либо есть, и тогда его нужно просто отдать по запросу, либо его нет, и тогда отдавать нечего), а при реанимации по стороннему каналу есть масса вопросов про то, признать ли надёжным сторонний канал, убедительные ли доказательства предоставил проверяемый и т.п.
Реанимация учётки с использованием стороннего канала приемлемо хорошо работает в централизованной архитектуре, но в глобальном пиринге она мне не кажется безнадёжной идеей. Или Вы можете предложить какое-нибудь интересное решение?ads83
15.08.2018 19:45Вы правы, я рассматривал текущую ситуацию, где есть центры авторизации. Это может быть Google OpenId, офис пиццерии, соцсеть или учетка ГосУслуг. В децентрализованных архитектурах я не силен :-)
SlavniyTeo
14.08.2018 15:36Предлагаю вам почитать про дизайн церемонии генерации параметров сети 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 человек.
Удивительно, что в русскоязычном интернете до сих пор нет перевода. Хотел даже перевести сам, но все руки не доходят.
maslyaev Автор
14.08.2018 16:23Спасибо. Интересно. Надо будет почитать.
Про ZCash слышал, но без подробностей. Есть на примете какое-нибудь толковое описание?SlavniyTeo
15.08.2018 08:34Сам Zcash — это тот же Bitcoin, но с возможностью проводить анонимные транзакции, благодаря алгоритму zk-SNARKs.
Русскоязычных источников не знаю, могу посоветовать пару англоязычных.
Здесь хорошее описание алгоритма zk-SNARKs от разработчиков Zcash.
Здесь попытка объяснить то же самое от Виталика Бутерина (советую просмотреть его блог, это интересно).
Здесь продолжение идеи с расширением до STARKs, где T — значит Transparent. Если уж на то пошло, еще один блок Бутерина.
ProstoUser
Объясните, пожалуйста, чем хранение hc-key лучше, чем хранение в том же «надежном месте» i-key?
Если место это абсолютно надежное, то в там можно хранить секретный ключ без всяких заморочек. А если злоумышленник до этого места добрался, получится в точности тот же эффект, что и с секретным ключом.
Если я правильно понимаю, владелец секретного ключа тем и отличается от всех остальных, что у него есть секретный ключ, который больше никому не доступен. Вы предлагаете вместо секретного ключа хранить «запасные пары». Но если злоумышленник получает доступ к «запасным парам», он точно так же перестает отличаться от истинного владельца — он может делать то же самое.
sena
Да, совершенно верно. Возможно автор имел в виду, что секретный ключ должен присутствовать на машине, для создания зашифрованных сообщений, но на самом деле в этом не необходимости, так как при необходимости можно создавать секретные подключи, которые подписываются главным секретным ключом, хранящимся в сейфе.
maslyaev Автор
Речь вообще не о шифровании. Оно даже не упоминается за исключением того случая, когда говорится о том, что описываемое непригодно для шифрования.
Основная идея не в том, чтобы как можно хитрее спрятать главный ключ (в сейф, под подушку, в банковскую ячейку), а в том, чтобы его вообще не иметь после того, как ему сделали memset нулями. Он — фатальная уязвимость, и её мы устранили. Остальные уязвимости фатальны только в том случае, если злоумышленнику удалось найти их все, в том числе и те, о существовании которых ему неоткуда узнать.
sena
Отнюдь. На случай кражи ключа в PGP существует так называемый key revocation certificate — сертификат отзыва ключа. Враг может его получить, но это ему ничего не даст. Любой, обладающий сертификатом отзыва, может опубликовать его, сделав таким образом украденный ключ бесполезным.
Удалить мастер-ключ в PGP тоже можно, но без мастер-ключа невозможно будет делать новые подключи. В этом и есть проблема Вашего подхода.
SlavniyTeo
Беда в том, что ключ могут украсть незаметно. И впоследствии подделывать доказательства с его помощью.
sena
Конечно. И то что предложил автор статьи эту проблему не решает, да и не существует такого метода в рамках асимметричной криптографии. Если украли секретный ключ незаметно, то жертва не сможет ничего сделать, пока не узнает об этом.
maslyaev Автор
sena
Не знаю.
sena
Очень хотелось написать, что квантовая, но не знаю.
maslyaev Автор
Полон я к ней, родимой, чёрного скептицизма.
maslyaev Автор
Если говорить о раздаче IDшников, то и кража мастер-ключа, и публикация его revocation certificate полностью уничтожает учётку. В моей схеме невозможно никаким разумным способом ни украсть мастер-ключ, ни поиметь его revocation certificate. Это я и имею в виду, когда говорю об отсутствии фатальной уязвимости.
sena
В PGP тоже можно удалить мастер-ключ и не создавать сертификат отзыва для него. Но это неудобно, если Вы хотите внести изменения в ID или сгенерировать новый подключ. Может измениться и почта и имя. Что делать в этом случае?
А так — пожалуйста, удаляйте на здоровье.
maslyaev Автор
Вы можете заметить, что в описанном приёме вообще нет ничего выходящего за рамки стандартной давно всем известной криптофункциональности. Банальщина страшнейшая. Мощно усилить функциональность PGP добавлением команды del, ага. Тем не менее, эта смехотворная мелочь, будучи применённой к месту (особенно если она встраивается в архитектуру как «поведение по умолчанию»), становится затыканием той дыры, которая казалась незатыкаемой. Знаете, самому до сих пор смешно.
maslyaev Автор
В первую очередь лучше тем, что если украли hc-ключ, то это не катастрофа. Мы публикуем его в списке отзывов, и пользуемся другими ключами, спрятанными заранее в других местах. Если же украли i-ключ, то учётка навсегда потеряна. В мире не остаётся того секрета, знанием которого изначальный владелец отличается от злоумышленника.
Для того, чтобы перестать отличаться от владельца ключа, злоумышленнику нужно найти все hc-ключи. А поскольку в нормальном режиме они не используются, они могут быть спрятаны как угодно далеко. Например, записаны на флешку, помещены в герметичный контейнер и закопаны в огороде. А ещё некоторые можно записать на бумажку и положить на дно бабушкиного сундука. Даже если злоумышленник придёт к владельцу с паяльником, владелец может под непереносимым физическим воздействием выдать флешку с огорода, но про бумажечку умолчать, и потом с её помощью вернуть себе власть.
sena
Почитайте про subkeys в PGP. Вы придумали то, что уже есть.
maslyaev Автор
Почитал. Немножко не то. Хотя бы потому, что там не предполагается немедленное уничтожение master key.
powerman
А в чём смысл его уничтожать? У Вас есть возможность создавать новые ключи, подписав их a-key. И эти новые ключи ничем (кроме длины цепочки, которая никак не учитывается) не отличаются от подписанных i-key.
Ещё не прояснён вопрос с тем, как именно отзываются ключи. Учитывая, что i-key удалён, надо полагать что для отзыва a-key1 нужен сам a-key1. Но ведь его могли забрать, а не скопировать (если у юзера нет бэкапов). И получается, что не имея украденного a-key1 юзер даже не сможет его отозвать. Был бы i-key — можно было бы отозвать его подпись для a-key1, но его удалили.
В общем, что такого нового и уникального даёт описанный подход — неясно. Всё крутится вокруг недоказуемости факта существования других ключей, но тут такое дело, если уже дошло до криптоанализа через паяльник — большинство сдаст все свои нычки с ключами а потом сдохнет, потому что паяльник будут использовать до последнего "а вдруг ещё одна нычка есть?"… а меньшинство сможет убедить что от стресса действительно забыли пароль от единственного ключа, или что единственный пароль был на флешке, которую специально сломали в момент нападения.
maslyaev Автор
В принципе, классический 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, но в случае его плохого поведения отобрать взад безо всяких последствий.
powerman
Все Ваши сценарии, которые не "экзотика" отлично решаются через PGP subkey и те же сертификаты аннулирования. Мастер-ключ при этом может лежать где-то в сейфе, острой необходимости его уничтожать через секунду после создания в этих сценариях — нет.
maslyaev Автор
powerman
Просто потому, что в его уничтожении нет никакого смысла. Ну или Вы пока этот смысл не смогли объяснить.
maslyaev Автор
Кащею тоже как-бы не было смысла насовсем избавляться от иглы, которая в яйце, которая в утке, которая в зайце ;)
Я не зря задал вопрос «зачем?». Именно в нём, по ходу дела, отгадка. Нельзя, наверно, просто так избавиться от мастер-ключа и не поиметь с этого убыток. А в моей схеме можно и нужно.
powerman
Никакого убытка — если заранее создать несколько subkey и сертификаты отзыва, то дальше наличие мастер-ключа не требуется (пока все subkey не будут отозваны, что довольно маловероятно, и в Вашей схеме работает точно так же).
Так что ответ на вопрос "зачем" тривиален: лень. Никакого смысла в его уничтожении нет, так чего ради напрягаться? А на самом деле его не уничтожают потому, что его наличие позволяет избежать суматохи при создании начальных ключей — достаточно создать один subkey для ежедневного использования и положить master в сейф. Если когда-нибудь потребуется отозвать этот subkey и/или создать новый — это можно будет сделать тогда, когда в этом будет необходимость.
Никто не говорит что Ваша схема не работает, она работает, просто непонятно, какой в ней смысл и в чём её преимущество по сравнению с уже имеющейся.
BigElectricCat
Googlовая почта не даёт возможности скачать зашифрованный архив (я так обломался этим летом, когда пытался переслать себе связку паролей, для развёртывания на новой железке, в зашифрованном архиве, правда архив был 7z).
MikailBag
А если перекодировать в Base64?
BigElectricCat
А для этого его надо скачать, а поскольку оригинал файла находился на зашифрованном винте ноута лежащем в сейфе за 2500 км… — было весело (даже через IMAP нельзя было скачать), так что выводы я сделал.
MikailBag
Я имею в виду, закодировать еще до выгрузки в Gmail.
Вряд ли гуглопочта заругается на безобидный текстовый файл)
BigElectricCat
А до этого случая мне не надо было пересылать через гуглопочту зашифрованные файлы, поэтому и думалось, что почтовик будет себя вести так, как должен по стандарту и, естественно, никто ничего не заранее проверил.
sena
Да, пожалуйста, уничтожайте, если так хочется. Обычно его не уничтожают по другой причине, например когда истёк срок действия подключа и нужно создать новый подключ или нужно внести какие-то другие изменения в мастер-ключ. Но можно его и уничтожить, если заранее создать сертификат для отзыва.
ProstoUser
А чем тогда это отличается от случая, когда секретный ключ делится на части и каждая часть закапывается в отдельной ямке на огороде?
Получается, что отличие в том, что HC ключей много (не известно сколько) и если некто предъявляет HC ключ, которого больше ни у кого нет, то он считается истинным владельцем. Это обходится тем, что владелец после применения паяльника показывает злоумышленнику бабушкин сундук, злоумышленник забирает бумажку и теперь у истинного владельца нет к ней доступа, а у злоумышленника есть. У бумажки, конечно, может быть спрятанная в колодце копия…
Вообще, это выглядит несколько не жизненным. В любом случае у владельца ключа есть нечто, что отличает его от остальных и обладание чем является сертификатом подлинности владельца.
Если не рассматривать ситуацию с паяльником, то остальное никакого смысла не имеет. А в случае с паяльником не так уж сложно добиться от объекта честного указания всех мест хранения «запасных» ключей.
Из минусов: много мест хранения запасных ключей — это много мест уязвимости. Доступ к любому из этих мест дает возможность злоумышленнику представиться истинным владельцем и успеть сделать гадость до того, как истинный владелец сумеет доказать, что у него запасных ключей больше.